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.hellerin...@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 <emman...@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@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
