Attribute mapper: single step or pipeline?

[aklenik]

As per the current plans: an attribute can be subjected to a single mapper class: from an arbitrary type to string:

• pro: this is a simple solution, where type compatibility can be easily checked runtime
• con: this will create compound mappers, like integer flipper & padder

The alternative: attributes can be tagged with a pipeline of mappers:

• pro: more modular, promotes transformation reusability
• con: more complex solution, harder to check the type-compatibility of input-output wirings of atomic transformation steps

[aklenik]

@bzp99

Additional thought: the main purpose of mappers is to transform a business-level attribute state into a storage-level representation. These two representations shouldn't be so far away from each other as to require a complex chain of transformations. This would also lead to a feature of combining two or more attribute values into a single key-level part (which could be supported by specifying getters in AttributeInfo annotations).

However, these features would open up a lot of corner cases that we couldn't really support in a robust manner: type safety of mapper chains, getters hiding schema changes, or its attribute dependencies for query index maintenance, etc.

Instead, I think devs should just write their own custom, simple mappers if the built-ins are not enough (number padding, string padding could be supported too, etc.), and key parts should reference attributes directly (making them explicit part of the entity schema, which is future work).

Suggestion: simple, one-step mappers of explicit attributes (i.e., instance variables) of entity classes.