1387 criteria reader doesn't respect getter prefixes

[SpyrosKou]

This is an attempt to fix autogenerated Criteria that do not work in find() in the MongoBackend an issue also described in #1387 with more details.
The conversion from the property names to the MongoDB fields seems to take place in MongoSession.java.
There the _id property was handled individually and all other properties were delegated to PathNaming.defaultNaming() which returned the path as a field name. This did not work in MongoDB filter queries. As for example it returned getDescription instead of description and the filter query required the field name, being description.
Replacing the PathNaming.defaultNaming() with the JavaBeanNaming() provides accurate field name transitions.

2 tests have also been included that test that find() works with the ID, with a getter of the form getProperty()' and with a getter of the form property()'. I named properties more specifically to facilitate any potential future references.

PS: This PR solves some cases and improves the situation, but more changes should be examined. For instance taking into account the @JsonProperty annotation.

[elucash]

@asereda-gs can you check this when you have time. I would just merge it, but need to understand how well it addresses the underlying problem and if it causes any issues / incompatibilities

[asereda-gs]

@elucash let me check this PR on weekend. Sorry was busy lately.

[asereda-gs]

Hello.

Thank you for this PR!

I'm thinking if allowing users to register their own PathNaming instance in MongoSetup would be a more flexible strategy?

Overall PathNaming needs to be better integrated with Gson/Jackson/Bson serializations.

I assume this issue also affects ElasticSearch backend?

[asereda-gs]

Ideally one should re-use existing BSON Codec which is being employed when entities are being persisted. The problem is that we can't know the path mapping unless the entity is serialized.

[asereda-gs]

I have prepared some ideas in a separate branch: https://github.com/immutables/immutables/tree/jackson-pathnaming

it needs some more work

[asereda-gs]

Please take a look at 3fb8e3 and let me know if it works for you.

[SpyrosKou]

Hello and thank you for your response.

I'm thinking if allowing users to register their own PathNaming instance in MongoSetup would be a more flexible strategy?

That would indeed give flexibility to more advanced users, giving more control over the PathNaming.
Ideally a default implementation that works with all Immutables features would make the concept of PathNaming completely transparent to the users.

Ideally one should re-use existing BSON Codec which is being employed when entities are being persisted. The problem is that we can't know the path mapping unless the entity is serialized.

I would also agree, the ideal solution should use the same functions that are used to serialize an Entity in JSON. If the Codec is provided it could be possible to use it in queries.

I assume this issue also affects ElasticSearch backend?
I have not used ElasticSearch backend with immutables.

I have been testing the solution provided and will come back with feedback.