On 04/07/14 23:56, Gustavo Niemeyer wrote: > On Thu, Jul 3, 2014 at 10:01 PM, Tim Penhey <[email protected]> wrote: >> 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. > > That's right in most cases, and a requirement for replication. > >> 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. > > I'd go with this, including your suggestion of splitting the data > apart in proper fields. Sounds straightforward and comfortable to deal > with.
I'm late to this discussion, but I am generally -1 on assigning any business meaning to document ids - too many bad experiences in the past where this has severely impacted the ability to change implementation detail for performance or other reasons. Such ids should be opaque and considered a database implementation detail, often referred to as surrogate keys. Natural keys should be implemented as separate fields, backed by unique indices if required. If a composite key is required as an additional field, that's fine, as is a field added to facilitate sharding. Unfortunately, I think the option of using a surrogate key may be infeasible given how the mongo transaction assertions are implemented. The DocExsists assertion is done based on document id, which forces the use of natural keys for id. I wonder if there's a way around this? So given the above, I don't think there's a choice and option 1 seems to be the best option as others have said. But I wish we had the choice to use surrogate ids. -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
