Project

General

Profile

Bug #2577

extent information in meta table

Added by Ovidiu Maxiniuc almost 9 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Eric Faulhaber
Target version:
FWD - Cleanup and Stablization for Server Features
Start date:
Due date:
% Done:

100%

billable:
No
vendor_id:
GCD
case_num:

om_upd20150518b.zip (4.28 KB) Ovidiu Maxiniuc, 05/18/2015 12:54 PM

History

#1 Updated by Ovidiu Maxiniuc almost 9 years ago

I discovered that the extent information is missing in the field meta table (it's always 0). This causes some testcases to fail because when the customer server code will attempt to check if the field is valid (ex: schedule[2] of table Person from p2j_test) against the *_meta tables.

    FIND _File NO-LOCK WHERE _File._file-name = "Person" NO-ERROR.
    MESSAGE CAN-FIND (FIRST _Field OF _File 
                      WHERE _Field._Field-name = "schedule" 
                        AND _Field._Extent >= 2).

After some investigations I realized that there is no support for extent attribute in the <persistent-database>.meta.xml bundle file. After adding the correct node in the generated DOM, the MetadataManager is able to initialize the meta database correctly and my testcase works fine.

I am not able to test this against the customer server code because it need to be re-converted.

Please review the attached update that should fix this issue.

#2 Updated by Eric Faulhaber almost 9 years ago

Code review 0518b:

The fix looks fine. Please check it in as is, no regression testing needed (it is additive and is not used in the regression test environment).

Separately, please ensure this works when the following hint is used in p2j_test.schema.hints:

<table name="person">
   <custom-extent/>
</table>

#3 Updated by Ovidiu Maxiniuc almost 9 years ago

Committed to bzr as revno 10865.

I've just checked the custom-extent support. As you thought, it doesn't work. The message displays no - the field is not valid.

There is one annoying thing, that when RecordBuffer.toString() is called automatically in debugger, it iterates all getters and the console gets full of stack traces (the old extent methods are disabled and will throw UnsupportedOperationException), but this is off-topic of this task.

#4 Updated by Eric Faulhaber almost 9 years ago

  • Target version set to Milestone 11
  • Priority changed from Normal to Low

Ovidiu Maxiniuc wrote:

I've just checked the custom-extent support. As you thought, it doesn't work. The message displays no - the field is not valid.

At minimum, we have to roll back Vadim's rev. 10500 in metaschema.xml. Any 4GL code that is using the metadata will know nothing about the "new" fields; they don't belong in the metadata. It must appear to be the original schema metadata. I didn't think carefully enough about this when I reviewed that update.

The problem is, when denormalized fields exist, the source AST for metaschema.xml is different than the original, since the extent fields have been exploded by the time we walk the AST, so the metadata will be wrong altogether. We need to adjust for that, so the metadata looks like the original schema. Perhaps the first exploded field needs to have some special annotations to convey the original name/size, while the remaining exploded fields are annotated to be ignored for metaschema purposes?

Not sure, but we may need changes in DMO field annotations as well. If so, this has to be done carefully; there probably are other dependencies on any changes introduced there.

I'm setting this to low priority for the moment -- we have to get it done, but there are other issues to address first, and I'm not sure which of us should address this.

#5 Updated by Eric Faulhaber almost 9 years ago

  • Assignee changed from Ovidiu Maxiniuc to Eric Faulhaber
  • Priority changed from Low to Normal

#6 Updated by Eric Faulhaber about 8 years ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100

This issue was resolved in P2J trunk rev. 10977.

#7 Updated by Greg Shah over 7 years ago

  • Target version changed from Milestone 11 to Cleanup and Stablization for Server Features

Also available in: Atom PDF