NitriteMapper - must it really contain is toJson and parse?

[almondtools]

I recently used the nitrite dependency in my project. I cannot use the Jackson-Mapper because I have store data that is not JSON-serializable.

I tried to write my own mapper from Object to the Document class, which was quite easy - yet the interface NitriteMapper requires me to implement a toJson-method and a parse-method, which would have forced me to add the complete JSON-Serialization/Deserialization (coming up with almost the same code as JacksonMapper).

Extending the JacksonMapper also failed because I would have inserted some configurable Features to the Objectmapper (for correctly serializing/deserializing the nonserializable data), yet ObjectMapper is called as first Method in JacksonMapper so I cannot pass any arguments to it.

So I came up with copying the JacksonMapper and changing the parts that are not common. Yet this also did not work because the naive ObjectMapper cannot handle Maps of typed Objects correctly (these always get Maps of Maps after the round trip) and the configured ObjectMapper (with defaultTyping) violates some internals of Nitrite.

After some research, I think that NitriteMapper has two idependent responsibilities:

• converting Objects to Documents and vice versa
• converting Objects to JSON and vice versa

Can these both Interface not be separate such that a NitriteMapper does only implement the Object <=> Document conversions and another interface handles the Object <=> JSON conversions.

What do you think about this?

[anidotnet]

NitriteMapper is an interface for different types of json serializers like jackson(default), gson, fastjson etc. If you are not dealing with json then NitriteMapper is not for you.

Does Mappable interface serves your purpose? You don't need to use NitriteMapper, if your object implements Mappable, nitrite will bypass the invocation of NitriteMapper and the serializer altogether. This conversion is blazing fast as it does not involves reflection that comes with serialization.

Please look into this test where nitrite is persisting an object which implements Mappable and does not implement Serializable. Look into this example class also for implementation, it contains a nested object also.

[almondtools]

From my point of view the system does not rely on the JSON features of NitriteMapper. There is no class in src/main/java that uses parse and toJSON. parse is used only in unit test setups, toJSON is never used.

Maybe you are confused what I mean with "rely on JSON Features":
It is pretty clear that JacksonMapper is an implementation of NitriteMapper using the Jackson Framework (and thus relying on JSON). However your System does not depend on JSON (which is the reason why a chose it). Another NitriteMapper implementation just implementing all other methods will work perfectly fine.

A more extensible implementation would be to remove parse and toJSON from the interface and to have a separate Class that handles Parsing and JSON-serialization for tests.

The changes implied by this recommendations have very low footprint. The testsuite does behave the same way after the change (unforunately not green, there seems to be a problem with the windows Filesystem). Shall I fork nitrite, and apply these patch such that you can review it?

[anidotnet]

Ah! now I get it what you are trying to say. I have not really considered this refactoring before. It is a good idea. If it is possible for you then please go ahead and create a PR, you are most welcome 😄 .

[anidotnet]

This change should be available in the latest snapshot - 3.0.1-SNAPSHOT