[hibernate-dev] hibernate-dev Digest, Vol 70, Issue 9

[William Riley-Land]

Mongo can index on any field, so it shouldn't be slow to ignore _id.  It is akin to a rowid/oid.  Although, people seem to have started to use SOLR to index MongoDB (still wrapping my head around this), so maybe your concern is valid.  

William P. Riley-Land
Sole Proprietor
Software Engineer
Riley-Land Software
http://william.nodejitsu.com/
573.268.4900

On Apr 7, 2012, at 11:00 AM, hibernate-dev-request at lists.jboss.org wrote:

> Send hibernate-dev mailing list submissions to
> 	hibernate-dev at lists.jboss.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.jboss.org/mailman/listinfo/hibernate-dev
> or, via email, send a message with subject or body 'help' to
> 	hibernate-dev-request at lists.jboss.org
> 
> You can reach the person managing the list at
> 	hibernate-dev-owner at lists.jboss.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of hibernate-dev digest..."
> 
> 
> Today's Topics:
> 
>   1. [OGM] MongoDB dialect and treatment of _id (Emmanuel Bernard)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Fri, 6 Apr 2012 18:41:42 +0200
> From: Emmanuel Bernard <emmanuel at hibernate.org>
> Subject: [hibernate-dev] [OGM] MongoDB dialect and treatment of _id
> To: hibernate-dev at lists.jboss.org
> Message-ID: <5AD5A697-8C7C-42B7-8DF7-B5ADDDD54803 at hibernate.org>
> Content-Type: text/plain; charset=us-ascii
> 
> I would like to discuss the problem of _id in MongoDB and how to map that in Hibernate OGM.
> 
> MongoDB is a bit psycho-rigid in how it uniquely identifies a document. A special property named _id is used for that and must be unique across a collection. It is also strongly recommended to let MongoDB generate this id (a UUID essentially).
> 
> In the MongoDb dialect we have not settled on how to use _id. and I would like to clarify that. Today we use `dbObject.put(ID_FIELDNAME, key.getColumnValues()[0])` but that is only correct if the id property is mapped to a single column. (ie `key.getColumnNames().length == 1`)
> 
> ## Use _id as a OracleDB rowid
> 
> We could decide to use _id as a purely internal identifier for a document and basically never ever rely on it. All queries and lookup with use the identifier columns and their value to find a document.
> That has the benefit of not having to deal with _id but I don't know if that's an OK practice in MongoDB or if it's not recommended at all as it would lead to costly lookups. Anybody familiar with MongoDB can shime in?
> 
> ## Map _id when we have a identifier mapped on one column
> 
> In this case, I will only discuss the case where an id is mapped to a single column.
> We could decide to map the id column value to both the id column and to _id. That creates some duplication but OGM would be happy and MongoDB's queries could be efficient.
> Alternatively, we could decide to completely ignore the id column name and use _id for this. The TupleShapshot would then be responsible for binding the id column name to the value stored in _id. My concern with the alternative is that someone reading the data from the mongodb store will not find the JPA id column but rather see _id. On the other hand it seems to be the norm in the MongoDB land.
> 
> ### Identifiers mapped on several columns
> 
> In this case, we have three approaches that can be combined:
> 
> 1. treat _id as rowid (see avove)
> 2. map id values as a complex object and put that in _id  eg { "_id": { "firstname": "Emmanuel", "lastname": "Bernard"} }
> 
> Note that we can then decide to bind the id columns as top level attributes of the document as well.
> 
> Do you guys have any thoughts on the best approach?
> 
> 
> ------------------------------
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 
> End of hibernate-dev Digest, Vol 70, Issue 9
> ********************************************