might be the expected behaviour although I fail to see why is this happening so maybe someone have an answer or it might be considered a bug?
using protected temp-table in class inheritance and extending the temp-table from base class leads to loosing some information (like serialize names for instance).
=============== base class ==========================
class BaseTable:
define protected temp-table ttItem
serialize-name 'Item'
field itemId as character serialize-name 'Id'.
method override public character ToString( ):
return getItemTable():default-buffer-handle:buffer-field('itemId'):serialize-name.
end method.
method protected handle getItemTable ():
return temp-table ttItem:handle.
end method.
end class.
=============== child class ===========================
class ChildTable inherits BaseTable:
define protected temp-table ttTask
like ttItem.
method override protected handle getItemTable( ):
return temp-table ttTask:handle.
end method.
end class.
=============== test ===========================
define variable ttBase as BaseTable no-undo.
define variable ttChild as BaseTable no-undo.
assign
ttBase = new BaseTable()
ttChild = new ChildTable().
message ttBase skip ttChild view-as alert-box.
I was expecting 'Id', 'Id' but it yields 'Id', 'itemId' so the field serialize-name information on child class is lost in translation :(
Had a look through the OpenEdge Help file:
"DEFINE TEMP-TABLE statement
....
LIKE field
Specifies a database field or a variable whose characteristics the temp-table field inherits..... The temp-table field inherits the data type, extents, format, initial value, label, and column label."
From that description it would seem to indicate that the behaviour is expected.
I'm using temp-table like not field by field like and if the temp-table I wish to extend is not from the base class things works just fine if temp-table like is used. If field like option is used looks like it's the 'expected behaviour' as you say although this doesn't seem to consistent to me :(
define temp-table ttItem
serialize-name 'Item'
field itemId as character serialize-name 'Id'.
define temp-table ttTask
like ttItem.
define temp-table ttTest
field itemId like ttItem.itemId.
message temp-table ttItem:default-buffer-handle:buffer-field('itemId'):serialize-name
skip temp-table ttTask:default-buffer-handle:buffer-field('itemId'):serialize-name
skip temp-table ttTest:default-buffer-handle:buffer-field('itemId'):serialize-name
view-as alert-box.
Hi medu,
This is just taking a stab at something. Define your temp-tables (especially in BaseTable) with the rcode-information option. I have a suspicion that this will carry the attributes you are looking for.
Thanks, did tried that before although the doc clearly said it's only for backward compatibility so didn't mentioned in my original post :(
The issue seems to be only when 'extending' tables defined in base classes, I the table is defined as private in base class and the as 'reference-only' in child the issue goes away... so it's really something related to temp-table inheritance. Might not look that important but given all that xml/json serialization nowadays keeping that kind of information is more than a nice to have :)
Be sure to log this with Progress Technical Support to confirm if it's a bug or intended behaviour. From what you're describing I think it's a bug...
yeah I realised that, however it is the the Serialize-name attribute of the 'ItemID' field, not the table attribute you were expecting. If the field level 'LIKE' does not inherit the attribute, then it would seem logical to expect that the attribute would still not inherit when the 'Like' inheritance is specified at the table definition level (I would imagine that Progress would possibly even delegate to the same logic internally to take care of the field inheritance in either case).
Having said that though, I do agree with you that the behaviour being inconsistent under the two methods, as you've described, is not expected, regardless of which is behaving as intended. Hopefully, if Progress confirms this is a bug, they will fix it so that the attribute is inherited consistently, rather than consistently not.
(Chris, the RCODE-INFO option also occurred to me as a long shot, initially, but I actually don't think it is factor here, as it is only still supported for backward compatibility - but no harm in trying, I guess)