RFC: mongo "_id" fields in the multi-environment juju server world
Tim Penhey
tim.penhey at canonical.com
Fri Jul 4 01:01:48 UTC 2014
Hi folks,
Very shortly we are going to start on the work to be able to store
multiple environments within a single mongo database.
Most of our current entities are stored in the database with their name
or id fields serialized to bson as the _id field.
As far as I know (and I may be wrong), if you are adding a document to
the mongo collection, and you do not specify an _id field, mongo will
create a unique value for you.
In our new world, things that used to be unique, like machines,
services, units etc, are now only unique when paired with the
environment id.
It seems we have a number of options here.
1. change the _id field to be a "composed" field where it is the
concatenation of the environment id and the existing id or name field.
If we do take this approach, I strongly recommend having the fields that
make up the key be available by themselves elsewhere in the document
structure.
2. let mongo create the _id field, and we ensure uniqueness over the
pair of values with a unique index. One think I am unsure about with
this approach is how we currently do our insertion checks, where we do a
"document does not exist" check. We wouldn't be able to do this as a
transaction assertion as it can only check for _id values. How fast are
the indices updated? Can having a unique index for a document work for
us? I'm hoping it can if this is the way to go.
3. use a composite _id field such that the document may start like this:
{ _id: { env_uuid: "blah", name: "foo"}, ...
This gives the benefit of existence checks, and real names for the _id
parts.
Thoughts? Opinions? Recommendations?
BTW, I think that if we can make 3 work, then it is the best approach.
Tim
More information about the Juju-dev
mailing list