Feb 28th, 2011, 02:46 PM
MongoDb: the type of the _id attribute
We have been using Mongo for a while and are very eager to start using the spring mongo integration.
On our first try we ran into an issue where the MongoTempate code is casting the value of the _id attribute to an ObjectId. We generate our own _id values as String types so this cast fails. Seems like this could be handled better, for example by wrapping String valued _id's in ObjectId's.
This type of casting occurs in three different methods in MongoTemplate, including the saveDBObject method. Is this a bug?
Feb 28th, 2011, 04:24 PM
After some more testing I realize the ObjectId(String id) constructor only accepts certain kinds of strings, so my suggestion does not work. My question still stands.
Mar 5th, 2011, 07:03 PM
Doesn't look good
I've looked at the code and found that using the default template you can't. It expects and returns an ObjectId. I'm sure this is just an example and one that will be cleaned up when more code is written to support arbitrary _id types with a better template.
There seem to be some very rough edges in the code and many lacking features that need implementation.
Mar 5th, 2011, 09:38 PM
I believe your issue is similar to this one:
Property bug in Spring Data MongoDB Support 1.0.0.M1
Mar 5th, 2011, 09:44 PM
As you can see here some of the underlying methods have ObjectId hardcoded.
Mar 7th, 2011, 10:28 AM
Thanks for the replies. I have spent some time looking at the code, especially MongoTemplate and see the way ObjectId is assumed in several places. However, it seems like a bad implementation decision and an easy thing to fix.
We are heavily invested in spring and have been using mongo for a while and were hoping to adopt the spring mongo integration asap. This looks like the only blocker.
We are using Jackson to serialize/deserialize java objects to/from JSON and the mongo java driver to go between JSON and DBObject. It is trivial to hook our Jackson infrastructure into MongoTemplate by implementing the MongoReaderWriter interface. We have already tried this out. This would allow us to keep using Jackson while the spring mongo project comes up with a useable serialization/deserialization mechanism.
Mar 7th, 2011, 10:58 AM
Looks like there is already a bug on this issue: https://jira.springsource.org/browse/DATADOC-38
Please vote for it ...
Tags for this Thread