FWD » Core Development » Database

Metadata tables and fields are used in Progress 4GL like regular table and field references, however, they do not map to regular schema tables. We will need to develop special conversion rules that map each construct to an appropriate snippet of Java code in the converted application. The outcome will vary, depending on the type/purpose of the original construct. Currently, only the following subset of constructs needs to be supported:

• _file: needs to be mapped into the application's schema, probably via DB-specific sys tables; i.e., using JDBC metadata
• _field: similar implementation to _file
• _lock: backed by the lock manager
• _index-field: similar implementation to _file, probably also needs to be dmo-index aware
• _index: similar implementation to _file, probably also needs to be dmo-index aware
• _user: probably this should be mapped to a table, it is used for security purposes; probably will require custom rules to properly integrate with each application's custom security model

Discussed with Greg. Probably the best approach is to use an embedded H2 database to provide access to these metadata constructs, so queries using them can convert naturally.

My initial idea of backing _file and _field with JDBC metadata is not really feasible, since we need to return the legacy names, not the converted names. Business logic will be expecting legacy names.

The _file, _field, _index, and _index-field constructs should be relatively static; probably we load the backing tables at server startup.

The _lock and _user constructs are a bit trickier, since the backing data will be much more dynamic. Probably have to refresh these tables on demand at the right moments (as opposed to keeping them up to date constantly, which likely would be a performance killer). Choosing the right moments is the challenging part...

The approach to support conversion of business logic which uses metadata is to treat these references just like any other database access code. This means we have to convert the metadata tables in use to DMOs, just like application-specific DMOs. Since metadata tables are ignored after the SchemaLoader step currently, this required some changes to the project configuration, schema conversion, P2O lookup services

I removed the metadata attribute from the schema element in p2j.cfg.xml, and added metadata element as a child of schema. The metadata element has a name attribute and child elements which list the metadata tables in use in the project. During the schema fixups conversion step (the transition from .dict to .schema file), all of the tables not so listed are dropped, so that only the listed tables appear in the .schema file. During this step we also set the database name to the standard "_meta" name.

We now allow the metadata schema file to be further converted to a .p2o file. The classes in the .p2o file are now added during P2OLookup initialization to each business schema, so that references to metadata constructs in the business logic can convert to normal DMO usage (but the business database name is passed into RecordBuffer.define calls instead of the _meta database name).

Currently, I can only convert tables which do not use INT64 and DATETIME[-TZ] data types (as well as any other, non-standard data types). Once these types are supported, all the tables needed for Milestone 4 will convert.

I have not yet added any runtime backing support.

Further information on p2j.cfg.xml change...

Old example schema node structure:

<schema metadata="standard">
   <namespace
      name="standard" 
      ... />
   <namespace>
      ...
   </namespace>
</schema>

New example schema node structure:

<schema>
   <namespace
      name="standard" 
      ... />
   <namespace>
      ...
   </namespace>
   <metadata name="standard">
      <table name="_file" />
      <table name="_user" />
      ...
   </metadata>
</schema>

The table elements under metadata are optional. They are only needed if metadata tables are actually in use in the target project. In that case, one would list the names of the metadata tables in use, and only they will be converted.