6.0 planning
by Steve Ebersole
We have been having a few side discussions about plans for 6.0, and I
thought it would be a good idea to consolidate them together.
1. Incorporate the SQM work. Lots of pieces go into this:
1. Replacing the interpretation of HQL/JPQL and Criteria queries.
2. *Possibly* leveraging SQM to deal with entity operations
(load-by-id, merge, etc).
3. Improved Query contracts
4. Improved persister contracts (including addition of an "embeddable
persister").
5. Improved Type contracts
2. Extensions to JPA criteria based on SQM work(this is probably more on
ongoing 6.x task)
3. Baseline on Java 8
Is there anything else anyone wants to discuss getting included?
Another one I'd like to discuss is the consolidation of the hibernate-core
and hibernate-entitymanager modules into a single module (possibly renamed
hibernate-orm). There are a lot of reasons and benefits to doing this:
1. A major one would be the consolidation of "type systems". Hibernate
has org.hibernate.type.Type. JPA defines javax.persistence.Type. Now with
SQM we have a 3rd type system in play.
2. It is also the major hurdle to moving to being able to fully replace
the legacy criteria with JPA criteria. If Session and EntityManager (as
well as SessionFactory ad EntiytManagerFactory) were fully integrated then
Session would be able to build/handle JPA criteria queries.
3. Simplified HEM bootstrapping
There are also a few challenges to doing this consolidation of the
hibernate-core and hibernate-entitymanager modules. The big one tht stick
out in my head is event-listener with different behaviors between core and
hem.
10 years
[OGM] Reduce the integrationtest directiry size
by Emmanuel Bernard
I noticed that for each integration test module we do download a full Wildfly distribution. Since we are having more and more integration test module it adds up significantly. On top of that the integrationtest module itself also downloads Wildfly. The current size is of integrationtest is 1.3 GB with most of it attributed to Wildfly. Could we share the same download somehow ?
On a side note, what are the ORM target/test-results/binary/test/output.bin? In my quest for more space I stumbled upon them.
Emmanuel
10 years, 1 month
Jira
by Steve Ebersole
A heads up that Atlassian will sometime soon be restarting the Jira
instance to fix the 500 errors when accessing project pages.
They are aware of the problem and are awaiting a proper fix, but in the
meantime they believe a restart will solve the problem in the short term.
10 years, 1 month
5.1 now branched; master is 6.0
by Steve Ebersole
Following along the earlier discussion I went ahead and branched off 5.1
and made master baseline Java 8.
10 years, 1 month
Configuration default values inconsitencies
by Vlad Mihalcea
Hi,
I found an inconsistency in JavaDocs and code:
1. The GLOBALLY_QUOTED_IDENTIFIERS_SKIP_COLUMN_DEFINITIONS JavaDocs says
"JPA states that column-definitions are subject to global quoting, so by
default this setting is {@code false} for JPA compliance. Set to {@code
true} to avoid column-definitions"
While in the code we say the contrary:
private boolean
globalQuotingSkippedForColumnDefinitions(ConfigurationService cfgService) {
return cfgService.getSetting(
AvailableSettings.GLOBALLY_QUOTED_IDENTIFIERS_SKIP_COLUMN_DEFINITIONS,
StandardConverters.BOOLEAN,
// default is true for JPA compliance - DO NOT CHANGE!
true
);
}
Andrea Boriero thinks the Javadoc is correct, but the code is wrong
2. Another inconsistency:
/**
* Specifies whether to automatically quote any names that are deemed
keywords. Auto-quoting
* is enabled by default. Set to false to disable.
*
* @since 5.0
*/
String KEYWORD_AUTO_QUOTING_ENABLED = "hibernate.auto_quote_keyword";
This one is said to be enabled by default, but if it's missing:
private static boolean autoKeywordQuoting(ConfigurationService cfgService) {
return cfgService.getSetting(
AvailableSettings.KEYWORD_AUTO_QUOTING_ENABLED,
StandardConverters.BOOLEAN,
false
);
}
It's the set to false
I discuss this also with Andrea on HipChat:
Andrea Boriero·12:02 PM
@VladMihalcea also in this case I think the javadoc is correct, just an
oversight in the code
Vlad Mihalcea·12:02 PM
So we should change the code to match the JavaDoc then
Andrea Boriero·12:04 PM
i think so but better to ask Steve before
Vlad Mihalcea·12:04 PM
I also think so
Andrea Boriero·12:10 PM
for the KEYWORD_AUTO_QUOTING_ENABLED i have found
https://hibernate.atlassian.net/browse/HHH-10014
Vlad Mihalcea·12:10 PM
Ok, so there must be some plan
Andrea Boriero·12:10 PM
so probably the code is fine in this case, just the doc is incorrect
Steve, can you confirm that the JavaDoc version is the right one in both
cases?
Vlad
10 years, 1 month
Hibernate OGM 5 CR1 released
by Davide D'Alto
We are getting closer and closer to the final release of Hibernate OGM
<http://hibernate.org/ogm/> 5.
This release includes support for Redis Cluster and a new dialect to store
data within Redis hashes; java.util.UUID are now using the native uuid type
in Apache Cassandra; more queries are now supported using the MonogDB CLI
syntax.
This release is also aligned to the Hibernate 5 family and it will work
with Hibernate ORM 5, Hibernate Search 5.5 and the latest WildFly 10.
You will find more information in the blog post:
http://in.relation.to/2016/03/30/hibernate-ogm-5-CR1-released
Cheers,
Davide
10 years, 1 month
Java 8 default methods as a refactoring tool
by Steve Ebersole
One question we have discussed but never really answered with regard to ORM
as we work on SQM has to do with the version of Java we would baseline on.
Currently ORM 5.0 and 5.1 continue the tradition of still running in Java 6
runtimes. Java 8 has since come along and offered some JDK "goodies" and a
new update of JDBC. So the question was whether we stick with Java 6
support or look to leverage and take advantage of these new Java 8 features?
Another argument for switching to Java 8 on top of those we have already
discussed is that Java 8's "default methods" feature would allow us to
continue to develop major changes but in a possibly less disruptive way.
In a lot of cases anyway. Say I am adding a new method on a public API
interface (org.hibernate.type.Type, e.g.). That breaks all implementors of
that interface, until they provide an implementation of that new interface
method. We've seen this in the past with bootstrapping in ORM and OGM,
where ORM being able to define default implementations of the methods on
the interface.. tat just makes it easier for seamless updating of Hibernate
versions. We handled that in the ORM/OGM bootstrapping case by means of
introducing an implementation of that interface that OGM would then extend,
as opposed to just implementing the interface.
10 years, 1 month
JTA platform configuration: Hibernate OGM on WildFly
by Sanne Grinovero
When using Hibernate OGM on WildFly it's currently necessary to set
this property:
hibernate.transaction.jta.platform = JBossAS
1 -- Would you all be ok for me to add a "WildFly" alias which
resolves to the same implementation?
This would be a patch for Hibernate ORM so it affects everyone.
I'm not proposing (yet) to remove or deprecate the old value.
2 -- Could JipiJapa help so that end users don't need to set this?
We had plans for OGM support for JipiJapa, this could be a good time
to refresh that idea?
Thanks,
Sanne
10 years, 1 month
hibernate.hbm2ddl.auto = none
by Sanne Grinovero
Hello all,
I've often used, and see others use, the value "none" for the property
hibernate.hbm2ddl.auto.
In recent versions of Hibernate ORM I now get the following warning:
[WARN] SessionFactoryBuilderImpl: Unrecognized hbm2ddl_auto value :
none. Supported values include create, create-drop, update, and
validate. Ignoring
To my surprise, the warning is not a bug as there's not such thing as
"none" in the source code, nor could I find mention of it in older
versions of the documentation... so I'm not sure were I learned about
it but I've always found it to be quite handy as in many scripts using
properties, it's easy to give a value to a placeholder but it's not as
easy to not define a property at all.
My guess is that "none" simply worked fine in practice on older
versions as it's not matching any of the actionable values, but now we
get this WARN which sounds concerning.
Could we add "none" as an officially valid value for this property?
Thanks,
Sanne
10 years, 1 month
[OGM] Any idea for OGM-1000?
by Davide D'Alto
Next JIRA will be OGM-1000, any interesting idea we should use for this
ticket?
Cheers,
Davide
10 years, 1 month
