FWD » Core Development » Database

See this test:

def temp-table tt1 xml-node-name "table1" field f1 as int.
def dataset ds1 for tt1.

def var ht as handle.
def var hds as handle.

create temp-table ht.
ht:create-like(temp-table tt1:handle).
ht:temp-table-prepare("tab1").
message ht:xml-node-name. // tab1

create dataset hds.
hds:create-like(dataset ds1:handle).
message hds::tt1:table-handle:xml-node-name. // table1

message hds::tt1:xml-node-name. // fails in FWD, must show table1 (BUFFER:XML-NODE-NAME is not supported)

For some reason, DATASET:CREATE-LIKE copies the temp-table metadata (like XML-NODE-NAME), too, while the TEMP-TABLE version seems to not do this.

I will do it tomorrow, first thing.

A fix is in 6129a/13933. Ovidiu, please do more tests and confirm this is OK (see the TODOs in the fix).

6128a/13934 adds unknown protection to the temp-table options copy.

From my tests, so far, the namespace-URI and namespace-prefix attributes are incorrectly copied in 6128a/13934. (lines 6210-6218 in copyTempTableOptions() must be removed).

There is also a copy/paste bug in AbstractTempTable.setMinSchemaMarshal(). At line 928 in setMinSchemaMarshal(boolean on) the line should be:

      schemaMarshal = on ? SM_MIN : SM_DEFAULT;

I have other changes (including TRPL) but they are risky - I think - now and I will commit them when not so stressed.

I encountered an incorrect optimization issue. Assume we create a copy of a dataset. It will use the DynamicTablesHelper.createDynamicDMO() to create the DMOInfo structure and a CacheData to avoid all TPL processing for creating a new DMO. The CacheData is mapped using CacheKey which is composed on the fields and indexes of the table. However, there is no information on the table.

Next time a new table is created using a very similar structure the cache in DynamicTablesHelper will hit and the old CacheData is returned. It will be used with all old data of the old table, including the table attributes (like the legacy table name which is mandatory in @Table annotation).

I am thinking of adding the table attributes in the CacheKey but I think we will rarely have a cache hit in this case.

A second issue: is it OK to commit a large change set to 6129a (~25 files)?

Ovidiu Maxiniuc wrote:

Next time a new table is created using a very similar structure the cache in DynamicTablesHelper will hit and the old CacheData is returned. It will be used with all old data of the old table, including the table attributes (like the legacy table name which is mandatory in @Table annotation).

Why not force setting the legacy table name after the dynamic table is created, like we do for XML-NODE-NAME and others?

A second issue: is it OK to commit a large change set to 6129a (~25 files)?

Please wait a little to have some downtime with #6277 first, so I can test it.

Another idea for CREATE-LIKE: does this actually build a dynamic DMO? Why not reuse the source DMO, as multiplexing will work, regardless if the source DMO is dynamic or static? Or is it because the legacy name and other annotations?

Yes, it is possible that some attributes can be changed between create-like and temp-table-prepare.

Constantin, please let me know when it is a good time to commit my changes (note that a full reconversion is required after that).

• rules/convert/methods_attributes.rules: why was this code removed?
  

                 <!-- COMPILER -->
                 <rule>methodText.length() == 0 and
                       (htype == prog.kw_compiler or ref.type == prog.var_handle)
  
                    <!-- ERROR  attribute of the COMPILER handle -->             <!--- this was removed
                    <rule>ftype == prog.kw_error  
                       <rule>isAssign
                          <action>methodText = "error"</action>
                          <action on="false">methodText = "error"</action>
                       </rule>
                    </rule>
  
  

  
  This prevents COMPILER:ERROR to convert properly.
• rules/convert/expressions.rules, BufferField, BufferFieldImpl, DynamicTablesHelper, TempTableBuilder, XmlNode, DmoMeta, Property, ErrorManager - missing history entry
• AbstractTempTable.numReferences - missing javadoc
• P2jField.computeHash - missing javadoc, method should be in the private section
• P2JIndex has a import org.aspectj.org.eclipse.jdt.core.dom.*; import
• BufferImpl.getDbName has this return new character("PROGRESST"); instead of "PROGRESS" ... is this a typo?
• handle$WorkArea - what is the reason for this change?
  

        private long nextId = 7753 - 1000 + 1000;
  

  
  The IDs start from 1000 in OE...

I have not tested functional issues in 6129a, as I need to reconvert.

Ovidiu, good catch with COMPILER:ERROR, please commit the patch to 6129a.

#6502+#6450_2.patch.zip was committed in revision 6129a/13955.