Issue Details (XML | Word | Printable)

Key: NUCMONGODB-126
Type: New Feature New Feature
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Unassigned
Reporter: Marcin Jurkowski
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
DataNucleus Store MongoDB

Add support for setOrdering to execute in-database

Created: 08/Sep/13 12:32 AM   Updated: 14/Nov/13 07:45 PM   Resolved: 09/Oct/13 05:27 PM
Component/s: Query
Affects Version/s: None
Fix Version/s: 3.2.4

File Attachments: 1. Text File datanucleus_mongodb_ordering.patch (10 kB)
2. Text File datanucleus_mongodb_ordering_r2.patch (10 kB)


Datastore: MongoDB


 Description  « Hide
Currently MongoDB queries are evaluated in-memory if result list is ordered. This patch enables MongoDB plugin to use native database ordering in case when it's possible to use native MongoDB range selection.

Marcin Jurkowski added a comment - 08/Sep/13 12:35 AM
Patch to add support for in-database MongoDB result ordering

Marcin Jurkowski made changes - 08/Sep/13 12:35 AM
Field Original Value New Value
Attachment datanucleus_mongodb_ordering.patch [ 12003 ]
Andy Jefferson added a comment - 08/Sep/13 01:37 PM
am currently out of the country but will look at this patch when I return in October

Marcin Jurkowski added a comment - 15/Sep/13 11:32 PM
Updated patch for native MongoDB result ordering

Marcin Jurkowski made changes - 15/Sep/13 11:32 PM
Marcin Jurkowski added a comment - 16/Sep/13 12:13 AM
I've attached an updated patch. Please ignore previous and use this one.
Apart from silly error in getObjectsOfCandidateType method it fixes the following issues:
 - when filter is null, we don't need in-memory filtering,
 - to avoid applying range selection twice, we must ensure that range is applied in-database only if it's not applied in-memory and vice versa, which requires checking the same condition in both places.

There's still a room for performance improvements eg. result expression containing only field names don't need Java query evaluator but it's not a common case and I don't indent to cover it by this patch.

Andy Jefferson added a comment - 08/Oct/13 04:34 PM
Your patch (the one with "r2" in the title, only one applied) causes test "test.jdo.mongodb" org.datanucleus.tests.JDOQLTest to fail with
testRangeWithOrdering(org.datanucleus.tests.JDOQLTest) Time elapsed: 0.043 sec <<< FAILURE!
junit.framework.AssertionFailedError: expected:<2> but was:<4>
        at junit.framework.Assert.fail(Assert.java:47)
        at junit.framework.Assert.failNotEquals(Assert.java:280)
        at junit.framework.Assert.assertEquals(Assert.java:64)
        at junit.framework.Assert.assertEquals(Assert.java:198)
        at junit.framework.Assert.assertEquals(Assert.java:204)
        at org.datanucleus.tests.JDOQLTest.testRangeWithOrdering(JDOQLTest.java:1142)

Please look at this, and then when it works as before I can apply your (latest) patch. Thanks

Andy Jefferson added a comment - 09/Oct/13 05:27 PM
SVN trunk applies your patch, plus has explicit check on range specification (if specified evaluates it in-memory)

Andy Jefferson made changes - 09/Oct/13 05:27 PM
Status Open [ 1 ] Resolved [ 5 ]
Fix Version/s 3.2.4 [ 12011 ]
Resolution Fixed [ 1 ]
Andy Jefferson made changes - 22/Oct/13 11:44 AM
Status Resolved [ 5 ] Closed [ 6 ]
Marcin Jurkowski added a comment - 14/Nov/13 07:45 PM
Sorry, I missed your comment.

Indeed, the second patch was not tested by the test suite (the first one was OK and tested).

Thank you for fixing and releasing that despite my lack of answer.