this was apparently a sorta nasty bandaid to a performance problem in query compilation
and it caused problems for some users, breaking interpretation of enum values
the following are gone:
hibernate.ejb.resource_scanner
hibernate.query.substitutions
hibernate.jdbc.sql_exception_converter
hibernate.native_exception_handling_51_compliance
hibernate.legacy_limit_handler
hibernate.jdbc.wrap_result_sets
Strictly, elements() and indices() don't make sense as select items, but we
have tests for this, and users who reported bugs and sent in patches, etc, etc,
so I'm going to go ahead and keep accepting them in the select clause as a
blessed misuse.
I'm not however going to allow them to be dereferenced because no, that's why.
This was a bug!
Also add checkConstraint member to @Table to allow check constraints on secondary tables
Also clean up some Javadoc of some related annotations
This is in principle a breaking change, but one I consider pretty innocuous,
since I can't imagine why anyone was calling Hibernate.getLobCreator(session)
instead of session.getLobHelper().
- deprecated load()
- deprecated save(), saveOrUpdate(), and update()
- deprecated delete()
- deprecated "dangerous" overloads of refresh()
- added getReference() taking an entity name
- improved the Javadoc for lots of operations
Drop `@CollectionSemantics`;
Drop `@CollectionSemanticsRegistration(s)`;
Add `@CollectionTypeRegistration(s)`;
Rename `@CustomType` to `@Type`;
User Guide and Migration Guide changes
these are needed for executing insert/update/delete queries, because we
deprecated the createQuery() methods that accept no Class as a parameter
these are much better-named anyway, and have a better return type
* and add tests and documentation for 'collate'
* much better and less-ambiguous syntax for collate(), consistent with cast() and treat()
* reimplement collate() using the function infrastructure
* implement collate() for HSQLDB
This feature was previously untested and at least partially broken, and was making a mess
of the HQL grammar.
- simplify two rules that were unnecessarily flexible
- remove useless parens
- rename some rules for readability
- clean up some warnings in SemanticQueryBuilder
to make it easy to produce portable DDL with 'generated always as'
or equivalent
also add 'name' to @ColumnDefault, and add some missing tests for
basic usage patterns of @ColumnDefault
- and add a second new overload
- tolerate non-entity classes as arguments to these methods
- the overloads accept a result class, and return a typed Query<R>
I hate doing this but it's necessary since Query is often
used as a raw type, and the wildcards result in additional
compiler warnings at the usage site
Also clean up some other warnings I encountered in this code
See if anything makes sense as additions to SqmNodeBuilder (as JPA CriteriaBuilder extension); make list; delete
The only one I considered was support for the legacy `Restrictions#naturalId`
`@Where` and `@Filter` fragments are now fully handled as AST - each fragment gets its own Predicate instance.
Some more work coming to clean up methods we no longer use which require the old String-manip approach.
`@Where` and `@Filter` fragments are now fully handled as AST - each fragment gets its own Predicate instance.
Some more work coming to clean up methods we no longer use which require the old String-manip approach.
`@Where` and `@Filter` fragments are now fully handled as AST - each fragment gets its own Predicate instance.
Some more work coming to clean up methods we no longer use which require the old String-manip approach.
Next iteration where `@Where` fragments generate AST one or more `WhereFilterPredicate` instances.
At the moment, `@Filter` fragments are collected together using the existing String-manipulation style and still collected into a single `FilterPredicate`. Next step is to make that more AST-centric and hopefully get rid of the String-manip-based methods
add Length class with useful constant values
well-defined mappings for "long" varchar/varbinary types
make LONGVARCHAR a synonym for VARCHAR with length=LONG32
make LONGVARBINARY a synonym for VARBINARY with length=LONG32
add Dialect.getMaxVarcharLength() + friends
make schema validator ignore the differences between string types
there is a problem with this approach: the user now gets unchecked
warnings since we've recently filled in the type args of the params
of some methods of Query and NativeQuery
but it's very hard to see how to fix the problem without breaking
compatibility
HHH-14718 - Drop deprecated generator implementations;
HHH-14959 - Drop IdentifierGeneratorFactory as a Service;
HHH-14960 - Add @GeneratorType for better custom generator config;
HHH-14496 - Deprecate (or drop) IdGeneratorStrategyInterpreter;
HHH-14961 - Deprecate (or drop) IdentifierGeneratorStrategyProvider;
HHH-14962 - Delay actual creation of IdentifierGenerator instances as late as possible
Add `GenerationTypeStrategy` and `GenerationTypeStrategyRegistration`;
deprecate org.hibernate.jpa.spi.IdentifierGeneratorStrategyProvider
HHH-14718 - Drop deprecated generator implementations;
HHH-14959 - Drop IdentifierGeneratorFactory as a Service;
HHH-14960 - Add @GeneratorType for better custom generator config
Fixed CustomGeneratorTests failure on databases which do not support sequences
HHH-14718 - Drop deprecated generator implementations;
HHH-14959 - Drop IdentifierGeneratorFactory as a Service;
HHH-14960 - Add @GeneratorType for better custom generator config
org.hibernate.id.factory.spi.StandardGenerator
HHH-14718 - Drop deprecated generator implementations;
HHH-14959 - Drop IdentifierGeneratorFactory as a Service;
HHH-14960 - Add @GeneratorType for better custom generator config
HHH-14718 - Drop deprecated generator implementations;
HHH-14959 - Drop IdentifierGeneratorFactory as a Service;
HHH-14960 - Add @GeneratorType for better custom generator config
* Fix insert handling with respect to version, discriminator and generated identifier insertion
* Introduce SqmMultiTableInsertStrategy to handle multi-table inserts
* Introduce the notion of an "entity table" similar to the "id table" to handle multi-table insertions
* Implement table based and cte based multi-table insertion to support all dialects
* Implement identifier generator optimizer support for multi-table insert
* Fix validation of insert target paths against select item types
* Fix some DML validations
* Implement over-clause support in SQL AST
* Fix multi-valued filter parameter support
This is necessary if we want the default catalog/schema to take
precedence, since the default catalog/schema is applied late,
on schema management tool or session factory creation.
- added log message when this condition occurs
- tried adding a `LoggerInspectionRule` based assertion to the test, but found that that rule is unfortunately very dependent on the message actually being logged
* Revert "HHH-14857 - Deprecations in preparation for 6"
This reverts commit 91e29358be.
* Revert "HHH-14857 - Deprecations in preparation for 6"
This reverts commit e4b56b9271.
HHH-14951 - Add @EmbeddableRepresentationStrategy
Prep work for `@EmbeddableRepresentationStrategy` - mostly move things from spi package to api, generally all marked `@Incubating`
HHH-14950 - Support mapping of embeddables with no setters (assuming a custom instantiator or repo-strategy is used)
Tests illustrating that HHH-14950 does indeed happen
- shared `#finishInitialization` handling for `VirtualIdEmbeddable` and `IdClassEmbeddable`
note: was not yet able to get that working with `EmbeddableMappingType`
- clean up ComponentType, esp wrt its use of ComponentTuplizer
Still need to
- integrate embedded forms. `VirtualIdEmbeddable` does not really need it as it can use the id-mapping itself as the embedded form. But `IdClassEmbedded` should really be integrated
- integrate `VirtualKeyEmbeddable` and `VirtualKeyEmbedded` for use as inverse composite fks
- ability to use the containing composite owner as the parent of a composite (legacy behavior is to always use the "first" entity
- Clean up Component Type, removing as many calls to its tuplizer as possible atm
- Clean up ManagedMappingType, EntityPersister, etc - mainly work around getting and setting value(s)
Still need to
- integrate embedded forms. `VirtualIdEmbeddable` does not really need it as it can use the id-mapping itself as the embedded form. But `IdClassEmbedded` should really be integrated
- integrate `VirtualKeyEmbeddable` and `VirtualKeyEmbedded` for use as inverse composite fks
- share `#finishInit` handling for `EmbeddableMappingType`, `VirtualIdEmbeddable` and `IdClassEmbeddable`
- ability to use the containing composite owner as the parent of a composite (legacy behavior is to always use the "first" entity
- clean up ComponentType, esp wrt its use of ComponentTuplizer
- Clean up Component Type, removing as many calls to its tuplizer as possible atm
- Clean up ManagedMappingType, EntityPersister, etc - mainly work around getting and setting value(s)
Still need to
- integrate embedded forms. `VirtualIdEmbeddable` does not really need it as it can use the id-mapping itself as the embedded form. But `IdClassEmbedded` should really be integrated
- integrate `VirtualKeyEmbeddable` and `VirtualKeyEmbedded` for use as inverse composite fks
- share `#finishInit` handling for `EmbeddableMappingType`, `VirtualIdEmbeddable` and `IdClassEmbeddable`
- ability to use the containing composite owner as the parent of a composite (legacy behavior is to always use the "first" entity
- clean up ComponentType, esp wrt its use of ComponentTuplizer
Move all component instantiations to use the new mapping model EmbeddableInstantiator
Still need to
- integrate embedded forms. `VirtualIdEmbeddable` does not really need it as it can use the id-mapping itself as the embedded form. But `IdClassEmbedded` should really be integrated
- integrate `VirtualKeyEmbeddable` and `VirtualKeyEmbedded` for use as inverse composite fks
- share `#finishInit` handling for `EmbeddableMappingType`, `VirtualIdEmbeddable` and `IdClassEmbeddable`
- ability to use the containing composite owner as the parent of a composite (legacy behavior is to always use the "first" entity
- clean up ComponentType, esp wrt its use of ComponentTuplizer
EmbeddableInitializer fully uses EmbeddableInstantiator and value injection
Still need to
- integrate EmbeddableInstantiator work (ComponentType/ComponentTuplizer)
- integrate embedded forms. `VirtualIdEmbeddable` does not really need it as it can use the id-mapping itself as the embedded form. But `IdClassEmbedded` should really be integrated
- integrate `VirtualKeyEmbeddable` and `VirtualKeyEmbedded` for use as inverse composite fks
- share `#finishInit` handling for `EmbeddableMappingType`, `VirtualIdEmbeddable` and `IdClassEmbeddable`
- ability to use the containing composite owner as the parent of a composite (legacy behavior is to always use the "first" entity
EmbeddableInitializer fully uses EmbeddableInstantiator and value injection
Still need to
- integrate EmbeddableInstantiator work (ComponentType/ComponentTuplizer)
- integrate embedded forms. `VirtualIdEmbeddable` does not really need it as it can use the id-mapping itself as the embedded form. But `IdClassEmbedded` should really be integrated
- integrate `VirtualKeyEmbeddable` and `VirtualKeyEmbedded` for use as inverse composite fks
- share `#finishInit` handling for `EmbeddableMappingType`, `VirtualIdEmbeddable` and `IdClassEmbeddable`
- ability to use the containing composite owner as the parent of a composite (legacy behavior is to always use the "first" entity
Prep work for EmbeddableInstantiator - initializer
Still need to
- integrate EmbeddableInstantiator work
- integrate embedded forms. `VirtualIdEmbeddable` does not really need it as it can use the id-mapping itself as the embedded form. But `IdClassEmbedded` should really be integrated
- integrate `VirtualKeyEmbeddable` and `VirtualKeyEmbedded` for use as inverse composite fks
- share `#finishInit` handling for `EmbeddableMappingType`, `VirtualIdEmbeddable` and `IdClassEmbeddable`
- ability to use the containing composite owner as the parent of a composite (legacy behavior is to always use the "first" entity
Prep work for EmbeddableInstantiator - initializer
Still need to
- integrate EmbeddableInstantiator work
- integrate embedded forms. `VirtualIdEmbeddable` does not really need it as it can use the id-mapping itself as the embedded form. But `IdClassEmbedded` should really be integrated
- integrate `VirtualKeyEmbeddable` and `VirtualKeyEmbedded` for use as inverse composite fks
- share `#finishInit` handling for `EmbeddableMappingType`, `VirtualIdEmbeddable` and `IdClassEmbeddable`
- ability to use the containing composite owner as the parent of a composite (legacy behavior is to always use the "first" entity
Prep work for EmbeddableInstantiator - initializer
Still need to
- integrate EmbeddableInstantiator work
- integrate embedded forms. `VirtualIdEmbeddable` does not really need it as it can use the id-mapping itself as the embedded form. But `IdClassEmbedded` should really be integrated
- integrate `VirtualKeyEmbeddable` and `VirtualKeyEmbedded` for use as inverse composite fks
- share `#finishInit` handling for `EmbeddableMappingType`, `VirtualIdEmbeddable` and `IdClassEmbeddable`
- ability to use the containing composite owner as the parent of a composite (legacy behavior is to always use the "first" entity
Prep work for EmbeddableInstantiator - initializer
Still need to
- integrate EmbeddableInstantiator work
- integrate embedded forms. `VirtualIdEmbeddable` does not really need it as it can use the id-mapping itself as the embedded form. But `IdClassEmbedded` should really be integrated
- integrate `VirtualKeyEmbeddable` and `VirtualKeyEmbedded` for use as inverse composite fks
- share `#finishInit` handling for `EmbeddableMappingType`, `VirtualIdEmbeddable` and `IdClassEmbeddable`
- ability to use the containing composite owner as the parent of a composite (legacy behavior is to always use the "first" entity
Prep work for EmbeddableInstantiator - initializer
Still need to
- integrate EmbeddableInstantiator work
- integrate embedded forms. `VirtualIdEmbeddable` does not really need it as it can use the id-mapping itself as the embedded form. But `IdClassEmbedded` should really be integrated
- integrate `VirtualKeyEmbeddable` and `VirtualKeyEmbedded` for use as inverse composite fks
- share `#finishInit` handling for `EmbeddableMappingType`, `VirtualIdEmbeddable` and `IdClassEmbeddable`
- ability to use the containing composite owner as the parent of a composite (legacy behavior is to always use the "first" entity
Prep work for EmbeddableInstantiator - initializer
Still need to
- integrate EmbeddableInstantiator work
- integrate embedded forms. `VirtualIdEmbeddable` does not really need it as it can use the id-mapping itself as the embedded form. But `IdClassEmbedded` should really be integrated
- integrate `VirtualKeyEmbeddable` and `VirtualKeyEmbedded` for use as inverse composite fks
- share `#finishInit` handling for `EmbeddableMappingType`, `VirtualIdEmbeddable` and `IdClassEmbeddable`
- ability to use the containing composite owner as the parent of a composite (legacy behavior is to always use the "first" entity
More clean-up (Tuplizers!!)
Mostly EntityTuplizer in this commit
Still need to
- integrate EmbeddableInstantiator work
- integrate embedded forms. `VirtualIdEmbeddable` does not really need it as it can use the id-mapping itself as the embedded form. But `IdClassEmbedded` should really be integrated
- integrate `VirtualKeyEmbeddable` and `VirtualKeyEmbedded` for use as inverse composite fks
- share `#finishInit` handling for `EmbeddableMappingType`, `VirtualIdEmbeddable` and `IdClassEmbeddable`
Clean-up
Still need to
- integrate EmbeddableInstantiator work
- integrate embedded forms. `VirtualIdEmbeddable` does not really need it as it can use the id-mapping itself as the embedded form. But `IdClassEmbedded` should really be integrated
- integrate `VirtualKeyEmbeddable` and `VirtualKeyEmbedded` for use as inverse composite fks
- share `#finishInit` handling for `EmbeddableMappingType`, `VirtualIdEmbeddable` and `IdClassEmbeddable`
EmbeddableInstantiator
Still need to
- integrate EmbeddableInstantiator work
- integrate embedded forms. `VirtualIdEmbeddable` does not really need it as it can use the id-mapping itself as the embedded form. But `IdClassEmbedded` should really be integrated
- integrate `VirtualKeyEmbeddable` and `VirtualKeyEmbedded` for use as inverse composite fks
- share `#finishInit` handling for `EmbeddableMappingType`, `VirtualIdEmbeddable` and `IdClassEmbeddable`
Added new form of `SqlExpressionResolver#createColumnReferenceKey`
Still need to
- integrate EmbeddableInstantiator work
- integrate embedded forms. `VirtualIdEmbeddable` does not really need it as it can use the id-mapping itself as the embedded form. But `IdClassEmbedded` should really be integrated
- integrate `VirtualKeyEmbeddable` and `VirtualKeyEmbedded` for use as inverse composite fks
- share `#finishInit` handling for `EmbeddableMappingType`, `VirtualIdEmbeddable` and `IdClassEmbeddable`
This 3rd commit cleans up some code
Still need to
- integrate EmbeddableInstantiator work
- integrate embedded forms. `VirtualIdEmbeddable` does not really need it as it can use the id-mapping itself as the embedded form. But `IdClassEmbedded` should really be integrated
- integrate `VirtualKeyEmbeddable` and `VirtualKeyEmbedded` for use as inverse composite fks
- share `#finishInit` handling for `EmbeddableMappingType`, `VirtualIdEmbeddable` and `IdClassEmbeddable`
This second commit renames `EmbeddableMappingType`
Still need to
- integrate EmbeddableInstantiator work
- integrate embedded forms. `VirtualIdEmbeddable` does not really need it as it can use the id-mapping itself as the embedded form. But `IdClassEmbedded` should really be integrated
- integrate `VirtualKeyEmbeddable` and `VirtualKeyEmbedded` for use as inverse composite fks
- share `#finishInit` handling for `EmbeddableMappingType`, `VirtualIdEmbeddable` and `IdClassEmbeddable`
This initial commit is scaled back - it only introduces the embeddable forms and supporting changes.
Still need to
- integrate EmbeddableInstantiator work
- integrate embedded forms. `VirtualIdEmbeddable` does not really need it as it can use the id-mapping itself as the embedded form. But `IdClassEmbedded` should really be integrated
- integrate `VirtualKeyEmbeddable` and `VirtualKeyEmbedded` for use as inverse composite fks
Gavin King
Steve Ebersole
Christian Beikov
Andrea Boriero
og151037
Yoann Rodière
William Burns
Sanne Grinovero
Filipe Roque
Fabio Massimo Ercoli
Dariush Moshiri
Jan Schatteman
Ivaylo Mitrev
nathan.xu
Jan Schatteman