On Fri, Jan 22, 2016 at 9:53 PM, Nate Finch <[email protected]> wrote:
> Working in the model layer on the server between the API and the DB. > Specifically in my instance, an API call comes in from a unit, requesting > the bytes for a resource. We want to record that this unit is now using > the bytes from that specific revision of the resource. I have a pointer to > a state.Unit, and a function that takes a Resource metadata object and some > reference to the unit, and does the actual transaction to the DB to store > the unit's ID and the resource information. > I'm a bit surprised that we'd be transferring those bytes over an API call in the first place (is json-over-websocket really a great way to send potential gigabytes? shouldn't we be getting URL+SHA256 from the apiserver as we do for charms, and downloading separately? and do we really want to enforce charmstore == apiserver?); and I'd point out that merely having agreed to deliver some bytes to a client is no indication that the client will actually be using those bytes for anything; but we should probably chat about those elsewhere, I'm evidently missing some context. But whenever we do record the unit-X-uses-resource-Y info I assume we'll have much the same stuff available in the apiserver, in which case I think you just want to pass the *Unit back into state; without it, you just need to read the doc from the DB all over again to make appropriate liveness/existence checks [0], and why bother unless you've already hit an assertion failure in your first txn attempt? Cheers William [0] I imagine you're not just dumping (unit, resource) pairs into the DB without checking that they're sane? that's really not safe > On Fri, Jan 22, 2016 at 3:34 PM William Reade <[email protected]> > wrote: > >> 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 <[email protected]> >> 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 >>> [email protected] >>> Modify settings or unsubscribe at: >>> https://lists.ubuntu.com/mailman/listinfo/juju-dev >>> >>>
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
