FWD » Core Development » Conversion Tools

The goal here is to stop relying on the file system for database info during conversion.

This was discovered while working on #9638. The current implementation uses P2OLookup instances to solve such dependencies, recursively. Since that task deals with classes already packed into jars, we don’t have access to the original artifacts or ASTs to grab the database details we need.

This is relatred to app-by-app conversion. Anything related to the lookup or processing of database/temp-tables that are defined in another "app" (a.k.a. module) must come from the jar instead of the file system since those features will not be present locally or won't be part of the current conversion run even if they are present locally.

This process is similar (if not identical) to that from MetadataManager.populateFileTable() which scans the dmo structure and populates the _file, _fields, _index and relate metas. So we have this information in-memory as H2 database. I wonder if we can (if it is feasible from performance PoV) we use queries on this database during conversion?

Note: these VSTs are R/O during FWD server lifetime, but during conversion they will have to be writeable to accommodate the new table definitions.

Ovidiu Maxiniuc wrote:

This process is similar (if not identical) to that from MetadataManager.populateFileTable() which scans the dmo structure and populates the _file, _fields, _index and relate metas. So we have this information in-memory as H2 database. I wonder if we can (if it is feasible from performance PoV) we use queries on this database during conversion?

Note: these VSTs are R/O during FWD server lifetime, but during conversion they will have to be writeable to accommodate the new table definitions.

And temp-table definitions. I don't think we can do that. We need to abstractize the P2OLookup and other cases of dependencies on .ast, where we determine which temp-tables to load from super-classes.

I was thinking mostly of 'provided' dmos from a previous iteration of an app-by-app conversion. There are no .ast provided. The conversion will have to work with what it 'finds' in the classpath, if I get this right.

Ovidiu Maxiniuc wrote:

I was thinking mostly of 'provided' dmos from a previous iteration of an app-by-app conversion. There are no .ast provided. The conversion will have to work with what it 'finds' in the classpath, if I get this right.

Correct. Ultimately, when we support shared schemata, then the permanent DMOs may be split across jars and be the source of this kind of schema info.