[hibernate-dev] [OGM] MongoDB dialect and treatment of _id

[Emmanuel Bernard]

Any more thoughts on that?
I like Sanne's approach but it means that people not use @Column will very often have id and _id and of course that we need to maintain secondary indexes.

On 10 avr. 2012, at 16:26, Sanne Grinovero wrote:

> Why should we not rely on the flexibility of the object/physical
> mapping we normally provide to relational database users?
> 
> Specifically, would it be possible to use "javax.persistence.Column"
> to have the user specify how the @Id attribute should be mapped in the
> "physical" MongoDB "schema" ?
> 
> If that's possible, we'd use your proposal "Use _id as a OracleDB
> rowid" for cases the user specifically asked to use a different
> property, or use the _id when he's asking us to do so.
> 
> The next question would be, should we use _id by default if no
> explicit option is set? I'd rather be consistent and use the attribute
> name, even if that is suboptimal in MongoDB, as I think we should
> provide the same flexibility people is used to when using Hibernate,
> like the ability to highly customize the mapping, to have it play
> nicely even with existing legacy schemas.
> 
> Assuming using an attribute named "id" is a common convention, maybe
> we could have a dialect option to either
>  a) assume the mapping "id" > "_id" ?
>  b) prefix all attributes with an underscore?
> 
> Sorry for not answering directly to your points, I'm not familiar with
> the MongoDB best practices.
> 
> Cheers,
> Sanne
> 
> On 10 April 2012 14:54, Nicolas Helleringer
> <nicolas.helleringer at gmail.com> wrote:
>> My DBA background tells me 'do not do thing behind the back of rou db' : I
>> shall use the second strategy.
>> 
>> But I am not sure what is the exact contract around _id column from the
>> MongoDb devs.
>> 
>> Niko
>> 
>> 2012/4/6 Emmanuel Bernard <emmanuel at hibernate.org>
>> 
>>> 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
>>> 
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev