Project

General

Profile

Feature #9822

« Previous | Next »

artifacts that are shared project-wide should be moved into the cvtdb

Added by Stefan Vieru over 1 year ago. Updated over 1 year ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
Due date:
% Done:

0%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:
reviewer:
production:
No
env_name:
topics:

Related issues

Related to Conversion Tools - Feature #5586: move all conversion artifacts/outputs into the cvtdb or into a dedicated directory sub-tree that is separate from the original 4GL code/schema inputs Closed

History

#1 Updated by Stefan Vieru over 1 year ago

  • Parent task deleted (#5586)

#2 Updated by Stefan Vieru over 1 year ago

  • Related to Feature #5586: move all conversion artifacts/outputs into the cvtdb or into a dedicated directory sub-tree that is separate from the original 4GL code/schema inputs added

#3 Updated by Stefan Vieru over 1 year ago

Artifacts that are shared project-wide should be moved into the cvtdb. For example, the registry.xml and name_map.xml should be in the database instead of as .xml in the file system.

#4 Updated by Greg Shah over 1 year ago

This is just one future approach to be considered. Using a database has pros and cons. Roughly:

  • pros
    • The interface is abstracted and can easily be moved to a remote connection, which might be useful for sharing the output or for scaling.
    • There may be optimizations we can implement to access only the portions of data we need rather than reading entire artifacts from the filesystem.
  • cons
    • Human review and access is made much harder than simple text output in the filesystem. We would need some tools to export/import such artifacts and we might need to create interactive editors.
    • Some outputs must be in the filesystem so that we can compile/jar them.
    • The code to process these artifacts will be much more complicated which means more effort and more bugs.

#5 Updated by Alexandru Lungu over 1 year ago

Human review and access is made much harder than simple text output in the filesystem. We would need some tools to export/import such artifacts and we might need to create interactive editors.

Jokingly, opening a name_map.xml from a large customer app within Eclipse is always crashing my IDE :) A 200MB file doesn't provide much access; grep is still the thing I use.
Also, the tooling for an H2 database is very nice with java -jar fwd-h2.jar that opens a Web console to edit the database.

#6 Updated by Greg Shah over 1 year ago

A fair point.

In the specific case of the name_map.xml, we have good reason to eliminate the artifact completely. See #6407.

Also available in: Atom PDF