Bug #4200
verify and fix all temp-table options which must result in different DMO implementations classes in FWD
0%
History
#1 Updated by Constantin Asofiei almost 5 years ago
There was at least a case where FWD was 'losing' a temp-table option or field option, as it was generating a single DMO implementation class when it needed different versions. This option was serialize-name.
The fix for this (and any other) is at p2o.xml, the tmpTabCrit map.
We need to verify all other field and temp-table options, and any index setting, which must result in different DMO implementation classes. This is required because, for example, these two definitions:
def temp-table tt2 serialize-name "xtt2" field f2-1 as int serialize-name "xf2-1" field F2-2 as char field F2-3 as dec.
and
def temp-table tt2 serialize-name "y-tt2" field f2-1 as int serialize-name "yf2-1" field F2-2 as char field F2-3 as dec.
are different resources in 4GL. In FWD, we keep these legacy settings at the DMO implementation class, via the 'legacy' annotations. And, if we don't compute the 'table match' properly, we will lose this legacy information.
#2 Updated by Eric Faulhaber almost 5 years ago
TODO: are there places in the runtime where we are using the DMO implementation class legacy annotations directly (as opposed to using TableMapper)? I want to avoid adding any more such direct dependencies and ultimately eliminate any that currently exist.
In the next few months, the DMO annotations are going to be modified considerably, and they will be moving to the interface. DMO implementation classes will no longer be emitted by default during conversion. Having all access to annotation information go through TableMapper will be key in making this transition smooth.
#3 Updated by Constantin Asofiei over 4 years ago
Another part I needed to add is BEFORE-TABLE - if this doesn't match between two tables, then we must emit two different DMOs (for Hibernate, this will be the Impl DMO; for the new, non-hibernate approach, I guess these will be at the DMO Iface).