[JAVA-2783] InsertOne/InsertMany/ReplaceOne do not accept a BsonValue parameter like updateOne/updateMany does. Created: 15/Feb/18 Updated: 09/Jan/19 Resolved: 09/Jan/19 |
|
| Status: | Closed |
| Project: | Java Driver |
| Component/s: | API |
| Affects Version/s: | 3.6.3 |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Minor - P4 |
| Reporter: | Jesse van Houten | Assignee: | Jeffrey Yemin |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
We started implementing the ORM that came with version 3.x. We decorate our Pojos with a custom hash. We now use your ORM to convert the object to BsonDocuments, we then edit it, and then we use it with your MongoCollection. I've got it all to work, but i'm disappointed that some methods do not accept 'raw' bson as a parameter (eg: insertOne and replaceOne). I've got 2 work-a-rounds for this:
I much prefer if MongoCollection supports these method with Bson as a value, as update does. For your reference, what I suggest is adding:
Looking through the code of MongoCollectionImpl, it seems internally the Pojo is rather quickly converted to Bson. |
| Comments |
| Comment by Jeffrey Yemin [ 09/Jan/19 ] |
|
Closing as Won't Fix based on the reasons in my previous comment. |
| Comment by Jeffrey Yemin [ 17/Dec/18 ] |
|
From my count, in order to be complete we'd have to overload around 15-20 methods to cover all the cases where T is required. The MongoCollection interface is already pretty large, so I don't think this is an acceptable tradeoff given that applications can already use:
that will accomplish the same thing, albeit at the cost of an extra MongoCollection to track.
|