TableGenerator.registerExportables should be optional

Description

Currently TableGenerator must be initialized by calling both configure and registerExportables.
This is OK when using annotations to automatically create your Identifiers for you, but occasionally, you need to subclass your own TableGenerator (for example to add a prefix to the PK). Configure is easy to use takes intuitive parameters. registerExportables is impossible to use, taking some 'Database' object as a parameter. Also registerExportables is only used on rare occasion when we need to mutate database models. If one manages ones own DDLs (not everyone grants root privs to their java apps) and also manually generates an ID, TableGenerator is unusable.

Suggested Solution:
Please initialize critical class variables in the configure method, as intuition would suggest:
Add these 3 assignments to the end of the configure method:
selectQuery = buildSelectQuery( jdbcEnvironment.getDialect() );
updateQuery = buildUpdateQuery();
insertQuery = buildInsertQuery();

Environment

None

Activity

Show:
Vlad Mihalcea
November 29, 2016, 6:17 AM

The IDENTITY is a much better option because it uses soft locks. There's nothing wrong with IDENTITY for a MySQL perspective. It's just how Hibernate uses the identifier that leads to disabling JDBC inserts for this identifier generator type. But, I plan on investigating if we could optimize this in the near future, when I'll have some spare time.

On the other hand, TABLE generator uses row-level locks, and it requires an additional Tx to be issued whenever an identifier value needs to be calculated. This puts pressure on the DB transaction log and on the connection pool as well.

Charles Federspiel
November 29, 2016, 6:59 AM

IDENTITY and AUTO INCREMENT apply to numeric IDs, my intent is generate a varchar ID by prefixing a String onto the generated number. SEQUENCE (and thus your example) is not available to me since I'm using mysql. System is low volume with a single application accessing the DB, so scaling is not one of my concerns. Alternatively, I could adapt your example, creating my own IdentifierGenerator, but I would end up re-writing the TableGenerator class.
Can we move forward with adding the build statement calls to configure method?

Charles Federspiel
November 29, 2016, 7:10 AM

So I would have separate Identity table and Domain Object table both with the same number of rows, and Identity table would only contain numbers and the Object table would by keyed by my prefixed IDs?

Vlad Mihalcea
November 29, 2016, 7:40 AM

If scaling is not an issue for you, then you can just use the TABLE generator. I told you about the scaling issue because I wanted you to be aware of it.

Vlad Mihalcea
November 29, 2016, 8:29 PM

It's been clarified what the OP wants, and it could use the TableGenerator without needing to call the registerExportables method.

Assignee

Vlad Mihalcea

Reporter

Charles Federspiel

Fix versions

None

Labels

None

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

Components

Affects versions

Priority

Critical
Configure