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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

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(a)gmail.com&gt; 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(a)hibernate.org&gt; > >> 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev