On 24/09/14 18:02, Dimiter Naydenov wrote: > On 24.09.2014 06:53, Tim Penhey wrote: >> Hi folks, > >> I have been going through much of the code in the state package >> looking at the work to migrate all the collection keys to handle >> multiple environments. > >> In the long and distant past (earlier this year), the Tag() method >> returned a string. There is a second tag like thing in the state >> package called the "globalKey". This is used as a collection >> independent key into annotations, presence, settings, networks and >> status. It seems that the only things we ever use for this are >> entities that have their own tag types. > >> If we ignore actions (which I don't think should bother >> implementing globalKey), then we are talking about: machine, >> service, unit, and network. > >> I propose that we replace all occurrences of the globalKey with a >> string representation of the Tag for that entity. > > Why? Global keys are a shorter than tags, and in several places we use > fast regular expression searches using a prefix based on the global key. > So instead of having "m#0#n#juju-public" as global key for a port > ranges document, we'll have to use "machine-0<*>network-juju-public", > where "<*>" is some unambiguous separator. The same is valid for > service settings - "s#wordpress" will become "service-wordpress".
Sorry, but this is terrible. The regex searches we have are needlessly complicated, and the documents should have real fields rather than disassembling the _id field. I think that having a slightly longer value stored in mongo is worth the code when it means we go from having two ways to identity an entity down to one. > I'd rather have a transparent transformation in place to convert > global keys to tags, where needed (the only special case I can think > of is relation tags "relation-123", which cannot be converted back to > relation names (e.g "wordpress:db mysql:server") without a DB lookup). I'd rather just have one way to identify an entity in state. > Also, what I didn't understand is how using tags as global keys will > solve the case with multiple environments in the same DB? It doesn't, it is just code cleanup that I think we should do. Tim -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
