5.0 defaults
by Steve Ebersole
Scott has been asking about making some setting defaults consistent between
Hibernate and WildFly. Most I think WildFly should just use the ORM
defaults. But 3 in particular I thought we should all discuss and decide
on..
1) hibernate.implicit_naming_strategy - by default Hibernate uses its
legacy implicit naming strategy which predates the clarifications made in
JPA 2.0 by many years. The question here is whether we want to change this
(now/ever) to use the JPA (2.0) compliant one?
2) hibernate.auto_quote_keyword - by default we decided to have Hibernate
automatically quote identifiers it thinks are key/reserved words in the
underlying database. We know at the moment this is a bit too aggressive as
it pulls in all of SQL:2003 defined keywords. The question is whether we
disable this by default?
3) hibernate.id.new_generator_mappings - by default we currently still map
to the old identifier generators. I personally also think it is time to
change this default. There are some risks here though.
Take an example... Legacy JPA users would have gotten
MultipleHiLoPerTableGenerator
when they used table-generation. The new mapping for table-generation
would be to use org.hibernate.id.enhanced.TableGenerator. In theory the
enhanced TableGenerator could be made to mimic the same "hi lo" based
values using the correct optimizer (in *theory* because I have not tried
it). If selecting the proper optimizer works this one might not be a
problem and there is no need for data migration. But if it does not, we
really have no migration path for user to migrate data.
Another "difficulty" is that AUTO is mapped *very* differently. AUTO used
to map to the idea of a "native" generator which would choose between
IDENTITY, SEQUENCE, etc. The new mapping is to use the enhanced
SequenceStyleGenerator. For dialects where the old mapping picked
IDENTITY, this is a very difficult migration point. Granted they could
change all the needed id mappings to specify identity...
And of course we could also just say "this is a (painful) migration point"
and document the known migration issues for existing apps in the migration
guide.
11 years
Embedded Composite Identifiers
by Steve Ebersole
I am thinking we should start to soft-deprecate[1] the historical feature
of embedded composite identifiers. This is the feature that allowed an
entity to define a composite identifier without any kind of "pk class"
(EmbeddedId/IdClass):
@Entity
public class MyEntity {
@Id
public Integer key1;
@Id
public Integer key2;
...
}
The you'd always have to instantiate the entity to deal with its
identifier. For example, to load such an entity:
MyEntity id = new MyEntity(1,2);
MyEntity it = session.get( MyEntity.class, id );
Between EmbeddedId and IdClass there are better alternatives to document.
Thoughts?
[1] - By "soft-deprecate" I mean remove discussion of it from the
documentation, and don't really push it.
11 years
[CI] Shutting down CouchDB
by Sanne Grinovero
I've stopped and disabled CouchDB on each slave node as it looks like
it's conflicting with Byteman ports and making many testsuites fail.
We'll need to reconfigure it before enabling again:
https://hibernate.atlassian.net/browse/WEBSITE-387
Sorry for the failure notices! If they are Byteman related, please
have the job run again.
Sanne
11 years
Hibernate Search branching and an update to 5.4.0.x work
by Sanne Grinovero
The Lucene 5 related work - which is now almost ready - is not meant
to be included in the 5.4 release, but we postponed the release of
5.4.0.Final a bit as we're waiting for a .Final of Hibernate ORM 5.
However there are a couple other pull requests which are open and
suited to be merged now, so we'll create a 5.4 branch as soon as those
are merged too, to then continue with the Lucene 5 work on master
(which will be called 5.5.0-SNAPSHOT).
Essentially we'll create the 5.4 maintenance branch and start working
on 5.5 before releasing 5.4.0.Final; also since we had quite some
improvements merged after 5.4.0.CR1, I think we could do a CR2 after
merging those last PRs.
Thanks,
Sanne
11 years
Minor SPI *addition*
by Steve Ebersole
I don't think this should require a new CR as it is an *addition* to an
SPI, but wanted to run it past everyone and get y'alls thoughts. I ran
across the need for this while re-working the documentation.
Basically I needed a (easy) way to allow users to override the implicit
resolution for a built-in basic type. So I added the following method to
MetadataBuilder:
applyBasicType(BasicType type, String... keys)
specifically passing in some keys, intending to allow overriding the keys
defined by BasicType. To that end I did have to make one additional change
to add a new type, BasicTypeRegistration, to act as a tuple for the
BasicType+keys and MetadataBuildingOptions#getBasicTypeRegistrations to
return this type rather than "just" returning BasicType.
The specific use-case was to allow users to easy remap how UUID attributes
are handled (store as CHAR rather than BINARY). But really it is useful
for altering any implicit attribute type mapping.
11 years
