Tags and object IDs

[William Reade]

Need a bit more context here. What layer are you working in?

In general terms, entity references in the API *must* use tags; entity
references that leak out to users *must not* use tags; otherwise it's a
matter of judgment and convenience. In state code, it's annoying to use
tags because we've already got the globalKey convention; in worker code
it's often justifiable if not exactly awesome. See
https://github.com/juju/juju/wiki/Managing-complexity#workers

Cheers
William

On Fri, Jan 22, 2016 at 6:02 PM, Nate Finch <nate.finch at canonical.com>
wrote:

> I have a function that is recording which unit is using a specific
> resource.  I wrote the function to take a UnitTag, because that's the
> closest thing we have to an ID type. However, I and others seem to remember
> hearing that Tags are really only supposed to be used for the API. That
> leaves me with a problem - what can I pass to this function to indicate
> which unit I'm talking about?  I'd be fine passing a pointer to the unit
> object itself, but we're trying to avoid direct dependencies on state.
> People have suggested just passing a string (presumably
> unit.Tag().String()), but then my API is too lenient - it appears to say
> "give me any string you want for an id", but what it really means is "give
> me a serialized UnitTag".
>
> I think most places in the code just use a string for an ID, but this
> opens up the code to abuses and developer errors.
>
> Can someone explain why tags should only be used in the API? It seems like
> the perfect type to pass around to indicate the ID of a specific object.
>
> -Nate
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20160122/41271f0a/attachment.html>