RFC: state entities, replace globalKey() with .Tag().String()

[Dimiter Naydenov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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".

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).

Also, what I didn't understand is how using tags as global keys will
solve the case with multiple environments in the same DB?

> One good part of this, is that for any element of the other
> collections, we can use the existing state.FindEntity(tag
> names.Tag) function.
> 
> Is anyone opposed to this change?
> 
> Cheers, Tim
> 


- -- 
Dimiter Naydenov <dimiter.naydenov at canonical.com>
juju-core team
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUIl6FAAoJENzxV2TbLzHwTIEH/2UBuTZDZ+q/4cA+lobBkzlF
USCuH2QWHh2IAjDqpTBgOyhqfBiN/eWXlxkoay6WfdPMeulUuZfcNG+E2rK/0Zs6
GE6W5MLLUEftgPm4cBCKyaaJozcpK4Yr7aQfLM9A0XcD3iQziyQPaceHZh5jB+Al
bzuoCdAy1d8oC5D0Ir3SIBWN5scytDCUyhOfrkqJCa8euFxTkYwidgCcLXyer1wn
I0MuoBP1yEfloJx2y7WAbVkmPU9vs8rjNMu5mLh+DyjwJWlF2s2q2kATccu/E9zu
tx991nqkplmrfqIOqX/OREYt6vwrnkYQUsZDMARIhDwLA1JzgT7/mXzGuxOs5fc=
=82Nr
-----END PGP SIGNATURE-----