RFC: mongo "_id" fields in the multi-environment juju server world

[Ian Booth]

On 04/07/14 23:56, Gustavo Niemeyer wrote:
> On Thu, Jul 3, 2014 at 10:01 PM, Tim Penhey <tim.penhey at canonical.com> 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.