[JAVA-254] Converting arrays of embedded documents to custom objects Created: 11/Jan/11  Updated: 31/Mar/15  Resolved: 25/Jun/13

Status: Closed
Project: Java Driver
Component/s: API
Affects Version/s: 2.4
Fix Version/s: 3.0.0

Type: New Feature Priority: Major - P3
Reporter: Javier Ferrero Assignee: Unassigned
Resolution: Done Votes: 6
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File DBCollection.java.diff     File DBCollectionTest.java.diff    

 Description   

DBCollection.setObjectClass() and DBCollection.setInternalClass() offer a convinient way to convert DBObjects to custom objects without using reflection.

However there is no proper way of converting DBObjects contained in arrays to custom objects. This is due to the way the driver retrieves "internal classes" by path.

For instance, having:

public class Question implements DBObject {
/* ... */
public List<Answer> answers;
}

public class Answer implements DBObject {
/* ... */
}

The way to convert "answers" array items to Answer instances is as follows:

collection.setInternalClass("answers.0", Answer.class);
collection.setInternalClass("answers.1", Answer.class);
collection.setInternalClass("answers.2", Answer.class);
and so on...

it would be nice to have a way of setting a custom class for all items inside an array? Maybe using setInternalClass or a new method:

collection.setInternalClass("answers.$", Answer.class);
collection.setCollectionItemClass("answers", Answer.class);



 Comments   
Comment by Jeffrey Yemin [ 31/Mar/15 ]

Closing all resolved 3.0.0 issues, as 3.0.0 has been tagged and released.

Comment by auto [ 30/May/13 ]

Author:

{u'username': u'jyemin', u'name': u'Jeff Yemin', u'email': u'jeff.yemin@10gen.com'}

Message: JAVA-254: DBCollection.setInternalClass works with arrays. The fix is in DBObjectSerializer.
Branch: 3.0.x
https://github.com/mongodb/mongo-java-driver/commit/633dff2bdc17f7e567b94a5c82eeffb815220f30

Comment by Jeffrey Yemin [ 28/Feb/13 ]

Sorry for the lack of response. This will be part of the 3.0 release. Until then, have you considered using an ODM like Morphia or Spring Data MongoDB, which provide much more functionality than this?

Comment by Matej Briskar [ 28/Feb/13 ]

It is quite a time since last reply and still with no update. It would be good to give us some information about current status so we would know what to expect.

Thanks,
Mat

Comment by Leif Mortenson [ 29/Oct/12 ]

Have there been any updates on this issue? I provided a patch over a year and a half ago to fix the problem. But there are still no updates.

We are fine with another solution if it exists, but we need a way to do this and would prefer not having to keep patching new driver versions

Thanks,
Leif

Comment by Leif Mortenson [ 02/Nov/11 ]

I would also love to see this make it into a regular release. We have been live with our patched version for several months and it has been working great. We of course want to stick with the core Mongo driver as much as possible to make sure we don't go in a direction that leads to a dead end for us.

Comment by Javier Ferrero [ 01/Nov/11 ]

Any plan to include this in a next release? Honestly, I think a document oriented storage should be able to work with lists of internal documents easily.

Comment by Leif Mortenson [ 01/Apr/11 ]

Patches to implement wildcard class mapping. And it even includes full tests!!

Comment by Leif Mortenson [ 01/Apr/11 ]

This is also a big deal for us. I had come up with the exact same temporary workaround before being pointed to this issue.

The best way to elevate this is to implement it so I have done so. I will attache two diffs for DBCollection.java and DBCollectionTest.java in a moment.

The way I implemented it will work almost exactly the same as now unless setInternalClass is called with a value that has one or more wildcards. In that case, when getInternalClass is called we have to iterate over all the registered mappings and do some wildcard matching. This is still fairly fast. It should not cause problems for existing applications as it only happens if the mappings were registered with wildcards. It should be fast even when used because most collections only have a handful mappings in the first place.

The patch will break up a name into an array of fields, separating them by ".". An individual wildcard can only match a full field name. There are two wildcards. "${*}" will match any field name. "${n}" will only match field names that are 100% made up of digits.

So "groups.${n}" can be used to match "groups.0", "groups.1", etc. But it will not match "groups.foobar".

Please let me know if this patch is acceptable or if you would like to change the format of the wildcards. We will use the patched version for now, but would of course like to get back to using a standard released jar.

Thanks for the great product!
Leif

Generated at Thu Feb 08 08:51:51 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.