<div dir="ltr"><div>According to the mongo docs: <a href="http://docs.mongodb.org/manual/core/document/#record-documents">http://docs.mongodb.org/manual/core/document/#record-documents</a><br></div><div><li>The field name <tt class=""><span class="">_id</span></tt> is reserved for use as a primary key; its
value must be unique in the collection, is immutable, and may be of
any type other than an array.</li></div><div class="gmail_extra"><br></div><div class="gmail_extra">That makes it sound like we *could* use an object for the _id field and do _id = {env_uuid:, name:}</div><div class="gmail_extra">
<br></div><div class="gmail_extra">Though I thought the purpose of doing something like that is to allow efficient sharding in a multi-environment world.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Looking here: <a href="http://docs.mongodb.org/manual/core/sharding-shard-key/">http://docs.mongodb.org/manual/core/sharding-shard-key/</a></div>
<div class="gmail_extra">The shard key must be indexed (which is just fine for us w/ the primary _id field or with any other field on the documents), and "The index on the shard key <strong>cannot</strong> be a <em><a class="" href="http://docs.mongodb.org/manual/core/index-multikey/#index-type-multikey">multikey index</a>".</em></div>
<div class="gmail_extra">I don't really know what that means in the case of wanting to shard based on an object instead of a simple string, but it does sound like it might be a problem.</div><div class="gmail_extra">Anyway, for purposes of being *unique* we may need to put environ uuid in there, but for the purposes of sharding we could just put it on another field and index that field.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">John</div><div class="gmail_extra">=:-></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">
On Fri, Jul 4, 2014 at 5:01 AM, Tim Penhey <span dir="ltr"><<a href="mailto:tim.penhey@canonical.com" target="_blank">tim.penhey@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hi folks,<br>
<br>
Very shortly we are going to start on the work to be able to store<br>
multiple environments within a single mongo database.<br>
<br>
Most of our current entities are stored in the database with their name<br>
or id fields serialized to bson as the _id field.<br>
<br>
As far as I know (and I may be wrong), if you are adding a document to<br>
the mongo collection, and you do not specify an _id field, mongo will<br>
create a unique value for you.<br>
<br>
In our new world, things that used to be unique, like machines,<br>
services, units etc, are now only unique when paired with the<br>
environment id.<br>
<br>
It seems we have a number of options here.<br>
<br>
1. change the _id field to be a "composed" field where it is the<br>
concatenation of the environment id and the existing id or name field.<br>
If we do take this approach, I strongly recommend having the fields that<br>
make up the key be available by themselves elsewhere in the document<br>
structure.<br>
<br>
2. let mongo create the _id field, and we ensure uniqueness over the<br>
pair of values with a unique index. One think I am unsure about with<br>
this approach is how we currently do our insertion checks, where we do a<br>
"document does not exist" check. We wouldn't be able to do this as a<br>
transaction assertion as it can only check for _id values. How fast are<br>
the indices updated? Can having a unique index for a document work for<br>
us? I'm hoping it can if this is the way to go.<br>
<br>
3. use a composite _id field such that the document may start like this:<br>
{ _id: { env_uuid: "blah", name: "foo"}, ...<br>
This gives the benefit of existence checks, and real names for the _id<br>
parts.<br>
<br>
Thoughts? Opinions? Recommendations?<br>
<br>
BTW, I think that if we can make 3 work, then it is the best approach.<br>
<span class=""><font color="#888888"><br>
Tim<br>
<br>
--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
</font></span></blockquote></div><br></div></div>