As previously explained, the
TABLE identifier generator does not scale, so you should avoid id. However, some enterprise applications might need to run on both MySQL (which does not support database sequences), as well as Oracle, PostgreSQL, and SQL Server 2012.
This is article is going to explain how easily you can achieve this goal using the JPA mapping overriding.
Continue reading “How to replace the TABLE identifier generator with either SEQUENCE or IDENTITY in a portable way”
From a data access perspective, JPA supports two major types of identifiers:
The assigned identifiers must be manually set on every given entity prior to being persisted. For this reason, assigned identifiers are suitable for natural keys.
For synthetic Primary Keys, we need to use a generated entity identifier, which is supported by JPA through the use of the
There are four types of generated identifier strategies which are defined by the
AUTO identifier generator strategy chooses one of the other three strategies (
TABLE) based on the underlying relational database capabilities.
IDENTITY maps to an auto-incremented column (e.g.
IDENTITY in SQL Server or
AUTO_INCREMENT in MySQL) and
SEQUENCE is used for delegating the identifier generation to a database sequence, the
TABLE generator has no direct implementation in relational databases.
This post is going to analyze why the
TABLE generator is a poor choice for every enterprise application that cares for performance and scalability.
Continue reading “Why you should never use the TABLE identifier generator with JPA and Hibernate”