FWD » Core Development » Database

• _file-name
• _dump-name
• _file-label
• _desc
• _hidden
• _crc
• _file-number
• _prime-index
• _tbl-type

• _numfld

• _field-name
• _file-recid
• _label
• _data-type
• _extent
• _order

• _initial
• _format
• _col-label
• _valmsg
• _valexp
• _mandatory
• _field-physpos or _field-rpos (presumably, for POSITION attribute)

We need a runtime facility to map between legacy (4GL) file/field names and converted (P2J) file/field names, for things like error messages, dynamic query and temp-table support, embedded SQL support. One fairly clean way to provide this is to add some P2J-specific fields (e.g., _java-name, _sql-name) to the _File and _Field (also I suppose, the _Index and _Index-field) metadata tables.

• a change to a writable attribute changes the corresponding, backing metadata record;
• a change to a metadata record changes the corresponding, readable, handle-based attribute;
• dynamically creating a temp-table adds the corresponding records to the _file, _field, _index, and _index-field metadata tables (and deleting the temp-table removes these records);
• all metadata for all databases an application uses are shared in a single metadata database instance (there is a _db table, and _file has a _db-recid field, so this suggests a single metadata database instance -- the database qualifier to _file references in application code must internally trigger a join between the _file and _db tables).

The current plan is to build an embedded, in-memory, H2 database to back the _file, _field, _index, _index-field, _lock, _user [and _db?] metadata tables. The [_db,] _file, _field, _index, and _index-field tables will be initialized/loaded at server startup time from static data, either gathered at conversion or exported from the application (which way is yet TBD), or some combination of both. Runtime code which dynamically creates/destroys temp-tables must make the corresponding metadata record updates.

Application access to these metadata tables already should be properly synchronized by record locking in the converted business logic; however, access from the runtime will need to be synchronized as well, using manual record-locking.

Currently, the metadata DMOs are created at conversion time, but we should create cut-down, hand-written Java classes for these which include the fields we care about from notes 2 & 3 above, plus the custom additions (e.g., javaName, sqlName) in note 4.

We will need a new class to implement this core functionality (MetadataManager?). It will be called from Persistence.initialize to initialize the metadata, and will be used by other parts of the persistence runtime for dynamic temp-table support, attribute services, and other support purposes.

• perform testing in note 5 to determine whether assumptions are correct;
• implement MetadataManager to create embedded, in-memory, H2 database and initialize it (will involve adding conversion-time resources, like .p2o files or 4GL export files to application jar file to enable loading of metadata).

MetadataManager may need to provide some helper methods for those who need runtime metadata services, but I envision specific metadata queries being handled by those who actually implement these services (i.e., that is not part of this task, but may require some coordination among team members).

For an example of using an embedded H2 database with shared tables, see the com.goldencode.p2j.persist.dirty package, though I'm not sure if we should use temporary or regular tables.

CREATE DATABASE statement (not supported now) will be one more place for creating metadata tables.

Will tables _File, _Field, _Index and so on have some unique fields like file_id, field_id, index_id, ... for joining these tables when needed? For example, in order to find table for concrete index from _Index, field from _Field.

Sorry I missed this earlier. Yes, these tables have a RECID field, generally of the form {table_name}-recid. But, I plan on hiding this behind the MetaSchema API. Is there a reason you would need to join them directly to support some runtime feature that is not well suited to using the MetaSchema interface?

No reasons, I also think they could be hidden behind MetaSchema API.

I asked only to understand tables structures.