In the release 3.2.3, or we can say in the starting of the release 3.2.3. We found here 2 new generators which represent a re-thinking with 2 different aspects of identifier generation.
1. Database portability.
2. Optimization Optimization means that you do not have to query the database for every request for a new identifier value.
These two new generators are intended to take the place of some of the named generators which described above, In starting 3.3.x. They are included in the current releases and can be referenced by FQN.
The first of all these new generators is org.hibernate.id.enhanced.SequenceStyleGenerator from which is intended,
First we do Replacement for the sequence generator and
second is better portability generator than native.
All the above just because native generally chooses between identity and sequence which have largely different semantics that can cause subtle issues in applications eyeing portability.
org.hibernate.id.enhanced.SequenceStyleGenerator, achieves portability in a different manner. It chooses between a table or a sequence in the database to store its incrementing values, depending on the capabilities of the dialect being used. The difference between this and native is that table-based and sequence-based storage have the same exact semantic. In fact, sequences are exactly what Hibernate tries to emulate with its table-based generators.
This generator has a number of configuration parameters which are given below:
1. sequence_name (optional, defaults to hibernate_sequence): Name of the sequence or table to be used.
2. initial_value (optional, defaults to 1): Initial value to be retrieved from the sequence/table. In sequence creation terms, this is analogous to the clause typically named "STARTS WITH".
3. increment_size (optional - defaults to 1): Value by which subsequent calls to the sequence/table should differ. In sequence creation terms, this is analogous to the clause typically named "INCREMENT BY".
4. force_table_use (optional - defaults to false): should we force the use of a table as the backing structure even though the dialect might support sequence?
5. value_column (optional - defaults to next_val): only relevant for table structures, it is the name of the column on the table which is used to hold the value.
6. optimizer (optional - defaults to none): See Section 5.1.6, “Identifier generator optimization”
Second new generators is org.hibernate.id.enhanced.TableGenerator, which is intended, as a replacement for the table generator, even though it actually functions much more like org.hibernate.id.MultipleHiLoPerTableGenerator, and secondly, as a re-implementation of org.hibernate.id.MultipleHiLoPerTableGenerator that utilizes the notion of pluggable optimizers. Essentially this generator defines a table capable of holding a number of different increment values simultaneously by using multiple distinctly keyed rows.
This generator has a number of configuration parameters:
1. table_name (optional - defaults to hibernate_sequences): the name of the table to be used.
2. value_column_name (optional - defaults to next_val): the name of the column on the table that is used to hold the value.
3. segment_column_name (optional - defaults to sequence_name): the name of the column on the table that is used to hold the "segment key". This is the value which identifies which increment value to use.
4. segment_value (optional - defaults to default): The "segment key" value for the segment from which we want to pull increment values for this generator.
5. segment_value_length (optional - defaults to 255): Used for schema generation; the column size to create this segment key column.
6. initial_value (optional - defaults to 1): The initial value to be retrieved from the table.
7. increment_size (optional - defaults to 1): The value by which subsequent calls to the table should differ.
8. optimizer (optional - defaults to ): See Section 5.1.6, “Identifier generator optimization”