Make mapper's ignored properties configurable

Description

Since 3.1.0, the object mapper has the ability to map properties inherited from parent classes. However it has to ignore getter-like methods inherited from base classes, like Object.getClass() or metaClass in Groovy.

Make the list of ignored properties configurable. Ideally this should be possible at the manager level, and for each mapper.

Environment

None

Pull Requests

None

Activity

Show:
Aviv Carmi
November 17, 2016, 1:59 PM

OK so I about implementing these abilities, as said before, at the mapper level.
I think there are two subjects to discuss before doing so: first one is defining the configuration interface (annotations/configuration object/etc...), and then the actual features and properties to support upon it.

Regarding the interface, iv'e read the discussion here, as i understand there are two possible directions to go. First of which is going with annotations as already pushed and implemented, the other way would be to create a mapper configuration object to be passed at mapper creation time.
Since the first one is already implemented i would suggest leaving it, but i think we should also consider the configuration solution, for a couple of reasons.
First of all, as stated in the PR it would be possible to exclude some property once and target all entities without having to copy-paste the annotation.
Second, i think it would allow a more flexible interface - for example, we can pass a default mapper configuration object to the mapper manager, thus each mapper created inherits these configurations, plus we can pass an overriding object to each mapper created so we can then even override some setting for a single mapper.
Additionally, since we may want to extend this behavior in the future (for example, not just blocking fields by their hard-coded name but maybe implement a function that decides whether or not to transient a field), annotations would be more limited.

What do you think?

Second - the actual features. I think this is less important and it doesn't have to be a final list, once we implement the basic behavior we can easily add more features on top of it later.
So as Alexandre suggested, i think these are the options:

  • Make the annotation parsing logic configurable at mapper level (only fields, only getters, or both)

  • Make transient properties configurable at mapper level (should properties be transient by default or not)

  • Make the class hierarchy scan configurable at mapper level (scan the whole hierarchy, or just annotated classes) (Alexandre - can you clarify it for me?)

I whink we can add to this list the original issue in hand: supplying a list of transient property names

Alexandre Dutra
November 17, 2016, 3:36 PM

First of which is going with annotations as already pushed and implemented, the other way would be to create a mapper configuration object to be passed at mapper creation time.

We might also consider having both. If someone wants to exclude all foo properties at once, then a mapper-level configuration sounds the way to go; if, however, one wants foo properties to be scanned except in a certain class, then a class-level configuration would be ideal (note that the class level configuration would probably have to cope with inclusions and exclusions).

Make the class hierarchy scan configurable at mapper level (scan the whole hierarchy, or just annotated classes) (Alexandre - can you clarify it for me?)

What I meant is that with the mapper started scanning superclasses and interfaces, where previously, it would only consider annotated classes. This is a powerful feature, but also a game changer that could complicate things for users that have complex data models and actually do not want the entire model to be scanned and mapped.

So I was suggesting that we make whether superclasses and interfaces should be scanned or not a configurable option, probably at mapper level.

Aviv Carmi
November 17, 2016, 7:06 PM

OK so i think a first good step would be to design a configuration passing mechanism which we would later be able to implement more and more features on top of.

So I saw it this way, let me know if you guys like it.
I'll example my idea by creating a few instances of each class just for sake of the example.

I think this way we both have settings that apply to all mapper, and also we can override some of those settings for each mapper - as you suggested.

I'll implement it with 1-2 initial features. Let me have some feedback regarding the interface.


As a side note i'd say that it might become a bit confusing for a consumer to have many different ways to define properties as transient (field/getter annotation, class annotation, mapper/manager conf).

Aviv Carmi
November 18, 2016, 9:49 AM
Edited

Code correction, sorry:

Alexandre Dutra
December 22, 2016, 4:59 PM

Tentatively scheduling for 3.2.0.

Fixed

Assignee

Unassigned

Reporter

Olivier Michallat

Labels

None

PM Priority

None

Affects versions

None

Fix versions

Pull Request

None

Doc Impact

None

Size

None

External issue ID

None

External issue ID

None

Priority

Minor
Configure