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.
8 years, 7 months
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.
8 years, 7 months
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
8 years, 7 months
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
8 years, 7 months
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.
8 years, 7 months
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
8 years, 8 months
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
8 years, 8 months
[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
8 years, 8 months
Slots of the OGM modules
by Sanne Grinovero
I just noticed something which seems very wrong with the OGM modules,
although I guess I'm correcting a mistake of a younger self :)
The various modules of Hibernate OGM use the "main" slot, rather than
using the version of the project.
This makes it impossible for people to deploy different versions of
OGM, or worse it makes it possible for people to unintentionally
overwrite some parts of it with a different version.
In Hibernate Search we learned long ago - probably thanks to the
experience of the complex integration with both WildFly and Infinispan
and others - that it's much safer to provide modules using the slot
name "major.minor", i.e. we'd have "5.0" for the upcoming OGM release
5.0.0.Final.
Even better, we should publish the public modules (the ones the end
users are expected to mention in their configuration files / metadata)
with this scheme, but these to be aliases which resolve to the
specific version: that allows people to be decoupled from the micro
updates, yet be able to override this in case of need and still
require a specific micro.
Not least, we seem to have various properties which allow each module
to be released with a different slot id (i.e. couchdb and mongodb
modules could use a different scheme) and I currently can't think of
when this is useful, I'd suggest we get rid of that and make it all a
bit simpler.
Since I'm cleaning up other modules changes now I'd like to do this right now?
Thanks,
Sanne
8 years, 8 months
HHH-9440 Support for Java 8: parameter names
by Lovro Pandzic
Hello,
I'd like to discuss issue HHH-9440.
Basic idea behind this issue is that we try to and eliminate the
requirement for no arg constructor on entities or at least weaken that
requirement to specific cases.
Construction from both the user code and the hibernate itself would go
through user specified constructors.
This would enable use cases like enforcing invariants in constructors,
immutable entities and in the long run, maybe even support for value types
coming in Java 10 that, at least for now, we know will be immutable and
won't have a no arg constructor.
By using parameter names and Java 8 API you can, for instance, map those
parameter names to fields to find out column mappings and other information
required for mapping arguments to parameters.
A similar approach like this is used by jackson-databind with the
jackson-module-parameter-names (this will soon be integrated into the
jackson-databind itself). Another example, Spring also uses parameter names
to map bean names to parameters in constructors.
There are border cases like the one Steve mentioned in the issue:
> How would you see lazy loading working then?
>
>From my perspective, there are 2 approaches here:
- use a library like Objenesis that enables you to construct classes
without using the constructor
- document that all entities that are to be proxied must have a no arg
constructor
What do you guys think?
8 years, 8 months
