FWD » Core Development » Database

Session.PK was introduced during our ORM refactoring (when we removed Hibernate from FWD), to represent the configurable name of the surrogate primary key. This role already was being served in part by the static variable DatabaseManager.PRIMARY_KEY, but this class was not available for use in all situations where the primary key name was needed (e.g., database import). This is due to DatabaseManager's separate dependencies on the directory (only used at runtime), from which it pulls configuration for other purposes.

The result is technical debt, in that both variables are used across classes now in a seemingly arbitrary way, which has made a bit of a mess. Furthermore, the runtime value of DatabaseManager.PRIMARY_KEY depends upon the value of Session.PK being set first during server bootstrap.

To the degree possible, I would like to eliminate DatabaseManager.PRIMARY_KEY altogether, and only be left with Session.PK. Some analysis is required to ensure this replacement is safe in all use cases. This includes both normal runtime use, as well as special cases which do not require the FWD server to be running (such as database import).

This should also be extended to FWD-H2 direct-access, as it presumes that the primary key column is always named recid, so it doesn't honor the real name. For that, consider propagating the FWD name of the primary key to FWD-H2, so it can properly do the invariant check.

Committed 7567a/rev.14714 and 7567a_h2/rev.27. Removed DatabaseManager.PRIMARY_KEY and replaced it's usage with Session.PK. The flag was removed entirely because Session.PK is instantiated really early at server bootstrap. I managed to test the database import on a customer application and there were no problems at all. Sadly I did not manage to run the customer application (just the server startup which was enough to confirm that DatabaseManager.PRIMARY_KEY is instantiated after Session.PK) because of a configuration problem.

I had to make a few small changes to DirectAccessHelper to fit the changes made in H2. When I tried to test Hotel_GUI, the project did not working even after configuring it again from zero. I can't get past the login screen because it can't find the adm2/smart.p file.

Danut, please double check: searchPath and propath in directory.xml and propath in p2j.cfg.xml. Is smart.p at least converted to Java?

Alexandru Lungu wrote:

Danut, please double check: searchPath and propath in directory.xml and propath in p2j.cfg.xml. Is smart.p at least converted to Java?

The problem was with the searchPath and propath, they were not configured properly. Thank you!

It seems that the "recid" is hard coded in SchemaConfig and is used by the meta database, this causes the server to fail at startup when the primary key name configured in p2j.cfg.xml is different.

• 7567a without changes - primaryKeyName="recid" and persistence/primary-key-name with "recid". Everything worked well, there were no problems during conversion or testing the application.
• 7567a without changes - primaryKeyName="id" and persistence/primary-key-name with "id". During conversion, I got a lot of org.postgresql.util.PSQLException: ERROR: column "recid" of relation "..." does not exist;
• 7567a patched and slightly modified to fit the new DirectAccessHelper changes - primaryKeyName="recid" and persistence/primary-key-name with "recid". Worked properly.
• 7567a patched and slightly modified to fit the new DirectAccessHelper changes - primaryKeyName="id" and persistence/primary-key-name with "id". Same problem during conversion;

There seems to be an existent issue with using a different primary key name or I did not set it up properly. For the configuration I used <schema primaryKeyName="id"> in p2j.cfg.xml and added

<node class="string" name="primary-key-name">
  <node-attribute name="value" value="id"/>
</node>

If only we completed #7782, we could remove this useless id workaround code. Problems like the above are just extra cost for no value.