FWD » Core Development » Database

Because File.listFiles() does not work on jar locations, the initialization of the DatabaseTriggerManager (gathering the trigger classes for mapping to database objects) is broken and have to be rewritten.

A solution is using the intermediary xml file. This would also improved the startup time by locating the files directly. The difficulty is that the values from 'schema-triggers.xml' are progress-oriented because of the early stage when the file is created. Further rule-set pass on schema-triggers.xml later in schema conversion to create a derivative file needed at server startup.

Note:
This defect is not related #2222 nor to Windows insensitive-case file lookup (see om_upd20140707b.zip from #2332).

Ovidiu Maxiniuc wrote:

Fixed the issue. It proved to be rather simple, just to add the class name (including package to current xml list of triggers) and save back (for the moment with another name) and load the xml when initiating the DatabaseTriggerManager. The new xml will be added to one of the application's jars (probably in the root of <customer>_dmo ?).

I would not add this to the root of the jar, if it is associated with a particular schema (<db_name>). What if a project has multiple schemas? Are all triggers combined from all schemas into a single XML file, or does each schema generate a separate XML file. If the latter, I would suggest putting the file in com/something/server/dmo/<db_name>. If the former (all triggers across all schemas combined in one XML file), I would suggest that directory's parent.

However, when testing, I found that ASSIGN triggers are not converted correctly (they are treated as UI triggers).

How much effort to fix this?

LE: GES removed the customer-specific name, package path and database name from this entry.

Eric Faulhaber wrote:

I would not add this to the root of the jar, if it is associated with a particular schema (<db_name>). What if a project has multiple schemas? Are all triggers combined from all schemas into a single XML file, or does each schema generate a separate XML file. If the latter, I would suggest putting the file in com/something/server/dmo/<db_name>. If the former (all triggers across all schemas combined in one XML file), I would suggest that directory's parent.

At the start of the middle part of conversion, all permanent databases are processed by schema/p2o.xml in a single tree, and temp-tables in the following step. That's the initial point when the schema-triggers.xml is created, dropping any old version of the file. Because of that, each trigger entry has an attribute with the database.
The utility of schema-triggers.xml is at the middle of back end within convert/base_structure.xml. At this time, the file is processed from the trigger point of view, extracting the values for annotations and also updating the xml with the now-known class name of the trigger.
I guess I'll use the second option. I will add the rule for copying the file to run/server and load it accordingly.

However, when testing, I found that ASSIGN triggers are not converted correctly (they are treated as UI triggers).

How much effort to fix this?

Probably it's a side-effect of something that has changed. Since the customer's server does not use session triggers (at least ASSIGNs), this did not surfaced until I run some basic tests for checking my update. I believe a couple of hours should be enough to find and fix this issue.

LE: GES removed the customer-specific name, package path and database name from this entry.

I found the cause why ASSIGNS are not converted correctly.
In the progress.g, in the on_stmt function, the following was added:

           // dbevent names can be used with widgets instead of buffers (customer code shows
           // that at least DELETE can be used this way); so we must look ahead and only match
           // here if this is really a database case
           { sym.isTable(LT(3).getText()) }?

{ sym.isTable(LT(3).getText()) || sym.isField(LT(3).getText()) }?

Ovidiu Maxiniuc wrote:

I will add the rule for copying the file to run/server and load it accordingly.

I followed everything up to this point. Do you mean to put the loose file in the run/server directory instead of loading it from the <app_name>_dmo.jar file at runtime? We don't want to do this -- it should be loaded from the jar file.

LE: GES removed the customer app name from this entry.

I see, for the customer, com/something/server/dmo, it make more sense.
I was fooled by "directory's parent". I interpreted it as runtime directory, the xml file.

LE: GES removed the customer-specific package prefix for this entry.

Ah, OK. Sorry for the confusion I caused.

I converted the customer's server project. The schema-triggers.xml file is left at the project root directory, but it is never copied to src/com/something/server/dmo, so it never ends up in <app_name>_dmo.jar.

If we ultimately decide to stay with this approach, we should do this as part of conversion (in base_structure.xml), rather than delegating it to each application's build.xml. The customer's server app build.xml should already copy it to the build/classes/... directory, without the need for additional changes.

LE: GES replaced customer-specific application name and package path from this entry.

Let's keep all these alternatives in mind, but considering that it works well as is (I tested with the schema-triggers.xml file manually copied to the proper location), I want to leave it as is now. We can come back around and revert to a scanning approach if someone has a strong preference, but it is not high priority now.

Please fix conversion to copy the file to src/{application path}/dmo directory and post an update.

Greg: when Ovidiu posts the next update, would you please review the parser change?

Code Review 0711a

I only reviewed the parser change. It looks good. Nice catch.

In regard to the annotations vs xml file approach question, my preference is for the annotations approach. If the performance of the server startup is an issue, then we can always write a tool to generate the xml "cache" file from the annotations, such that it could be part of the application build process and thus that file would always be up to date when changes are made to the application jar.

I'm fine with cleaning this up later, but you'd better add a task otherwise we will forget.

Code review 0714a:

Looks good, please commit and distribute when this passes testing.

There were no conversion differences (Except for the schema-triggers.xml file itself in src/aero/timco/majic/dmo).
There are a few failed tests:
6 in ctrl+c / gso_ctrlc_3way_tests (some killed client did the mess)
1 in main / gso_tests
7 in main / tc_tests (most of them cascading from clock jobs)
Re-run the tests.

After lots of failing tests I asked for Constantin's opinion and he confirmed that the update is safe for commit.
Luckily, the update was not affected by latest committed updates.

Committed in rev 10581 and distributed by mail.