[JAVA-862] DBCollection.find doesn't use custom DBEncoder to encode query Created: 28/Jun/13 Updated: 13/Nov/14 Resolved: 13/Nov/14 |
|
| Status: | Closed |
| Project: | Java Driver |
| Component/s: | API, Query Operations |
| Affects Version/s: | 2.10.1, 2.11.2 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Chris Sachs | Assignee: | Unassigned |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | bson, driver, query | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Description |
|
DBApiLayer.__find (DBApiLayer.java:273) references the global DefaultDBEncoder.FACTORY instance, instead of using the collection's own custom encoder. This makes it impossible to pervasively use more than one encoder per process. We use a custom Scala wrapper, and this could cause us serious problems. Hopefully it's an easy fix. Thanks. |
| Comments |
| Comment by Jeffrey Yemin [ 13/Nov/14 ] | |||||||||||
|
Resolving as duplicate of Please let me know if you have any further questions. | |||||||||||
| Comment by Jeffrey Yemin [ 31/Jul/14 ] | |||||||||||
|
We should take this into consideration when designing API in scope of | |||||||||||
| Comment by Jeffrey Yemin [ 01/Jul/13 ] | |||||||||||
|
Yes, the signature for Database.getCollection is something like:
where
| |||||||||||
| Comment by Chris Sachs [ 01/Jul/13 ] | |||||||||||
|
I see. Providing the encoder as an extra parameter would be an ideal solution from my perspective. I much prefer passing things like encoders on the stack over maintaining internal state in a DBCollection. The Encoder<F> you postulated would exactly be a typeclass! Though for a strongly typed MongoCollection, providing the encoder to the constructor might be preferable. | |||||||||||
| Comment by Jeffrey Yemin [ 01/Jul/13 ] | |||||||||||
|
In 3.0 API, query filters/sort criteria are encoded in the standard way. In principle, it wouldn't be too hard to change it. The problem is more the API. Currently we have something like this:
so MongoCollection is generic, so you can do something like:
We don't want the find method parameterized on the same type, but I could see something like this working:
| |||||||||||
| Comment by Chris Sachs [ 01/Jul/13 ] | |||||||||||
|
Great news. Yes, we were encoding BSON queries using our custom DBObject implementation. Our BSON implementation builds on an immutable object graph. We can quickly calculate BSON object sizes and write BSON straight to a plain OutputStream–no seeking necessary to overwrite the object size field. Do you currently encode queries in the standard way you do to avoid using an intermediate OutputBuffer? | |||||||||||
| Comment by Uladzimir Mihura [ 01/Jul/13 ] | |||||||||||
|
Chris, Actually queries are the same bson as documents you are reading and writing. The difference in the extensibility - you can change the process of encoding and decoding documents, but this is not true for queries. They are encoded in a standard way and sent to socket. -vova | |||||||||||
| Comment by Chris Sachs [ 28/Jun/13 ] | |||||||||||
|
Thanks for the quick and helpful reply. After looking through the code a bit more, I see that the driver transforms queries internally and doesn't just spit them out to the database socket. We use an abstract intermediate representation to stream large datasets though a web API in various formats with minimal transformation. We thought it would be convenient to represent queries this way too, since we already have the infrastructure in place. We worked around the problem by recursively transforming our internal representation to generic Java types for queries only. This is an acceptable solution since query objects are small. I understand if this bug is a won't fix. I think I just desire a native Scala mongo driver. One that uses typeclasses to serialize arbitrary types instead of a whole bunch of reflection-foo. I've considered doing this myself, and the wire protocol looks super straightforward. But the "out of date" messages all over the docs gives me pause. | |||||||||||
| Comment by Uladzimir Mihura [ 28/Jun/13 ] | |||||||||||
|
Chris, Using collection's own encoder for a queries is not entirely correct. Custom encoders and decoders are used only while you are dealing with objects from collection (encoding objects to be written, decode objects on read). Can you please clarify what you mean under 'pervasively use more than one encoder per process' ? -vova |