[JAVA-1458] Aggregation problem with Enterprise version Created: 19/Sep/14  Updated: 11/Sep/19  Resolved: 04/Oct/14

Status: Closed
Project: Java Driver
Component/s: API
Affects Version/s: 2.12.3
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Mike Gozaloff Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: aggregation, java, spring
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

RHEL 5.9 (open source) and 6.4 (enterprise server)


Issue Links:
Duplicate
duplicates JAVA-1253 AggregationOutput should not throw Il... Closed

 Description   

We are getting an error on our new enterprise server that does not appear on the open source version. We use the same code but change the pointer to the servers. Both servers are MongodB 2.6.4.

We are using Spring Data 1.6.0-RELEASE to load the MongoDB java driver.
When we execute an aggregation using only the $out operation we see using only the $out operator to copy the collection, we get an error (below). Here is the code:
// Get the collection
DBCollection sourceCollection = mongoOperations.getCollection(sourceCollectionName);
// Set up a pipeline
List<DBObject> ops = new ArrayList<DBObject>();
// Write to the target collection
ops.add(new BasicDBObject("$out", targetCollectionName));
// Do the copy
sourceCollection.aggregate(ops);

When the code runs, it makes sure the target collection does not exist.

Here is the important part of the error:

Caused by: java.lang.IllegalArgumentException: result undefined
at com.mongodb.AggregationOutput.<init>(AggregationOutput.java:80)
at com.mongodb.DBCollection.aggregate(DBCollection.java:1554)
at com.mongodb.DBCollection.aggregate(DBCollection.java:1532)
at com.bankofamerica.risk.aml.lms.service.ListService.copyCollection(ListService.java:978)



 Comments   
Comment by Jeffrey Yemin [ 04/Oct/14 ]

Closing this as a duplicate of JAVA-1253.

Comment by Marcelo Rocha DaSilva [ 19/Sep/14 ]

Gozer,

The best way to be sure of the best performance outcome is to benchmark it.

When using RDBMSs, as you know, dropping the indexes during a batch load is a smart performance optimization trick.

With MongoDB, typically I would expect you to gain a "small" performance benefit by creating the indexes after the table has been loaded. The performance gain by doing that is certainly much less significant than what you see in a "legacy" RDBMS.

Comment by Mike Gozaloff [ 19/Sep/14 ]

It looks like it works when doing the aggregation from the client.

We can try your code next.

On a similar note... When doing an aggregation to copy a collection, is it better/faster to have an empty collection with indexes already in place or should we copy the documents into a new collection then apply the indexes after?

Thanks,

gozer

Comment by Jeffrey Yemin [ 19/Sep/14 ]

I'm not sure yet why enterprise server would return different results, but I think you'll be able to work around this by using this DBCollection method instead:

    Cursor aggregate(final List<DBObject> pipeline, AggregationOptions options)

This method has explicit handing for $out and will return a lazy cursor on the output collection.

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