I’m working with the Java client, and I want to do some BSON encoding (for append operations) and I’m unable to leverage bson4jackson because it depends on the public Jackson namespace, yet rather the dependency on Jackson is included in core-io.
So, I’m stuck with:
com.couchbase.client.deps.com.fasterxml.jackson.core.JsonFactory
versus:
com.fasterxml.jackson.core.JsonFactory
Why is it this way and not a traditional dependency? Any workarounds?
The intent is actually to simplify this kind of deployment. You should just bring in your own Jackson. By doing so, you’re not bound by the version and APIs we embed. This was the intent.
It does make the number of classes loaded and the memory used larger, but just barely so. It’s such a small difference that I don’t think you’d notice on most deployments.
If you have any trouble depending on a canonical Jackson dependency, let us know. That’d be a bug.
bring in the version of Jackson you want as a dependency to your project
use the plugin for BSON with it
since you deal with the JSON marshalling/unmarshalling yourself, skip the JsonObject abstraction, just store plain JSON strings into **RawJsonDocument**s
(you’ll have to specify that you want that kind of document by passing RawJsonDocument.class to get operations and any operation that you invoke with a String id rather than a Document)
Yep. Did a bunch of reading on those; the bugs in the example provided here:
Helped me ensure that I did the correct things…
Since the bucket operations do a release(), the subsequent releases + the finally block release caused errors
Bumping this up to re-engage discussion. Just got burned by things not working as expected due to a mix of Jacksons. If I have my entities annotated with “real” Jackson and then they are processed by “couchbase” Jackson, the annotations are in a different namespace and not respected.
This leads to really awful, undesirable behavior: Data loss.
I think it should be reconsidered to have this. It just opens up the opportunities for undetectable bugs.
So, to be clear, we haven’t had any real world data loss (that I know of), but it became clear that it could easily happen when I was playing around with different serializes for my testing.
Basically what happens is, I have a forward / backward compatible class (uses the annotations @JsonAnySetter and @JsonAnyGetter).
Since these annotations are in an alternate namespace, they’re not invoked by Jackson.