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.fi...@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@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
