foundation
instance, a foundation in where everything is configured, from which the StorageManager
is created.Storer
and Loader
. Because Legacy Type Mapping affects loading, it has to go in there.InquiringLegacyTypeMappingResultor
) there are a few settings: When should he ask? Always or only if something is unclear. Never does not make any sense of course, then you shouldn't use it, or alternatively the printing resultor.Person
class.customerid
and pin
are too different to be automatically assigned to each other. Therefore, it is wrongly assumed that customerid
is omitted and pin
is new. comment
and commerceId
are surprisingly similar (75%) and are therefore assigned.
But that's not what we want.customerid
would be eliminated by the implicit decision. This is too delicate not to inquire, so it is always necessary to ask.customerid
is now called pin
comment
should be omittedcustomerid
to pin
, the similarity does not matter, it is the mapping that matters. To indicate this, it says "[mapped]" instead of the similarity. The rest is as usual. Only comment is now "[discarded]", according to the mapping. The difference to the above is namely: This is an explicitly predetermined absence. That does not force inquiry.surname
to lastName
is below the required "minimum similarity", so rather ask. comment
example above: is 75% similar to commerceId
. Still wrong. Then prefer 80%? Or 90%? Of course it is better, but the danger is still there.