rashtao
commented
4 years ago What would you suggest to solve your problem?
Disabling the type hints completely would break the deserialization in cases where the target type cannot be inferred at runtime, eg. in case of generic types or polymorphic deserialization. So this comes with many limitations regarding the Java entities modeling. Maybe the NPE you get are related to this?
Another possibility to mitigate the problem could be introducing a specific annotation to opt-out type hints on specific fields or classes. Would this help you?
On the other side a full implementation for handling such cases in a configurable way is a quite more complex problem to solve. For reference this is how it is implemented in Jackson and JSONB:
Hi,
We are meeting a rather disturbing issue with the feature introduced by #33
I know it to be rather old, and all, but we haven't met the problem until recent migration to latest arango versions.
I am currently working on a micro-services project, making use of arangodb as one of our primary storage solution.
Each collection has one microservice responsible for persisting data
Lots of our microservices are reading data from thoses same collections.
With the persistance of the _class property we are getting reads error because the type mapping fails, due to our microservices not always mapping those objects to the same class (in term of fully qualified name). Sometimes the package name is different, sometimes the class name is not the same, and so on and so forth.
We tried disabling the feature by overrifing typeKey() and have it return null, but we end getting a NPE on every save operation
To add our humble contribution to this old debate, although we understand the intent of this feature, it is a real inconvenience in a distributed system where multiple agents are reading from arango in a variety of manner, and do not (and wish not to) share the same code base as far as the data access layer is concerned.
More over, on a more personnal opinion, i do not think it wise to introduce such a strong adherence between a given langage and the data model.
In this project, for instance, we are reading/persisting data from/to arango with services in node, python, and java.
Having bits of data introduced tied to a specific langage for the sake of type mapping is at best an inconvenience, at worst a source of bugs, and seems to only be suitable with arango being storage for a single application/service, of for services sharing the same dal code.