Merging hibernate spatial Dialects with the core ones
by Vlad Mihalcea
Hi,
Since hibenrate-spatial has been merged into Hibernate code base, shouldn't
we merge the Dialects as well.
For instance, we have MySQL56InnoDBSpatialDialect which can simply be
merged into a MySQL56InnoDBDialect.
This way, MySQL57InnoDBDialect can take advantage of spatial queries as
well.
The only drawback is that we need to add the geolatte-geom lib to
hibernate-orm.
Let me know what you think.
Vlad
8 years, 8 months
Redis and TTL
by Guillaume Smet
Hi,
So, I'm currently working on reducing the number of calls issued to Redis
in OGM as part of OGM-1064.
At the moment, we execute a call to Redis to get the TTL already configured
on an object before saving it. If the TTL is not explicitly configured with
@TTL, we set this TTL again after having stored this entity (see
RedisJsonDialect#storeEntity). Same for associations stored in a different
document.
In fact, this call returns the time remaining before expiration, not the
TTL previously configured, so I find this behavior quite weird. Basically,
we store information which will expire sooner than expected. I can't really
get a use case for this and I don't think we should have an additional call
every time we store an object for a so obscure thing. Do we really expect
people to mess with TTLs of objects stored by OGM without relying on OGM
@TTL management?
IMHO, we should get rid of this call and only deal with TTL when it's
configured via the @TTL annotation.
Thoughts?
--
Guillaume
8 years, 8 months
Module ZIP for upgrading Hibernate ORM in WildFly
by Gunnar Morling
Hi,
As discussed by some of us during the No ORM meeting in May, it'd be great
if there was a module ZIP allowing people to easily upgrade Hibernate ORM
in the WildFly version they are using.
Just the other day there was a blog post published [1] describing how to
use Hibernate ORM 5.2 in WF 10, essentially via Search & Replace on the
existing module.xml files. We could do better than that, leaving the
original version intact and providing a new one with a specific slot
("5.2") in the ZIP.
That'd also be helpful for other projects such as Hibernate OGM which
already provide a module ZIP for WF but currently need to package ORM, too,
in case they need features from a later ORM version.
If we all agree that's a good thing to have, I can help with making it
happen.
Thanks,
--Gunnar
[1]
http://avolpe.github.io/docker/2016/06/05/docker-wildfly-hibernate-5.2.html
8 years, 8 months
JDK 9 b124 now running on ci.hibernate.org
by Sanne Grinovero
I've updated the OpenJDK preview of JDK 9 to build 9-ea+124 on our CI servers.
I expect it all to work like before, but in case you receive a failure
report be aware that it might relate to the JVM upgrade.
For a general overview of our Java 9 compatibility status see here as usual:
- http://ci.hibernate.org/view/JDK9/
[The OGM failure isn't a JDK regression but is my mistake; should be
fixed soon: OGM-1107]
Thanks,
Sanne
8 years, 8 months
ActionQueue order question
by Vlad Mihalcea
Hi,
Does anyone know why the "orphan-removal" is the first action to be
executed while "delete" is the last one?
Shouldn't the "delete"action queue operation be executed after
"orphan-removal" before insert or update?
Thanks,
Vlad
8 years, 8 months
HIbernate ORM CI builds
by Steve Ebersole
We have been having a lot of timeouts on the ORM CI builds. Mainly this is
due to ancillary tasks. Currently the ORM jobs execute:
1. clean
2. test
3. check
4. :documentation:aggregateJavadocs
5. publish
A huge chunk of the time is taken up in (3) which performs (a) checkstyle
and (b) findbugs. Also, I am not sure of the benefit of building
aggregated javadocs for each and every CI build. So I propose we break
these up as follows:
1. A check job
2. A clean/test/publish job
3. (?) aggregated javadocs job (?)
This would allow us to split the cost of the Job timeout across the jobs.
In fact we might even consider making some of these into nightly job(s).
Initially in setting up this server we decided to just have singular,
all-encompassing jobs because moving to a new dedicated set of hardware
(dedicated to Hibernate team) was supposed to free us from jobs fighting
for resources. But as our jobs have grown on the dedicated hardware we are
seeing some of the same. For certain we want a clean/test/publish job that
is run on every push. To me the others are more flexible in terms of
scheduling. We could have a separate check job that is run on each push,
or it could be a nightly job. We might even decide to leave off building
aggregated javadocs as an automated job/task, or we might decide to make it
a nightly job as well (maybe even with full documentation builds).
WDYT?
8 years, 8 months
[OGM] Doing a 5.0.1 release?
by Gunnar Morling
Hi,
I noticed there is a 5.0.1 version in JIRA for OGM, and a handful of issues
are assigned to it. Do we still plan to do such 5.0.1, or is everyone
focused on the first preview for 5.1 right now?
There is one interesting issue in 5.0.1 which alone I'd find worth
releasing: OGM-828 ("Need to list entities when using Hibernate OGM on
WildFly"). We also might consider to backport some of the recent bugfixes
and create a branch for 5.0 off master, prior to the first work meant for
5.1 (Neo4j Remote etc.).
I'd like that, not the least to have another release soon-ish (say next
week?), preventing another long phase without news from OGM. Thoughts?
Thanks,
--Gunnar
8 years, 8 months
No Hibernate Search version compatible with Hibernate ORM 5.2.0.Final
by Sanne Grinovero
There have been various complaints that people can't upgrade to the
latest Hibernate ORM because they don't have a compatible version of
Hibernate Search.
Rejected 3 issues on JIRA as duplicates of:
https://hibernate.atlassian.net/browse/HSEARCH-2296
We never guaranteed compatibility beyond the micro-range, still we
probably should do something about this as I hate rejecting issues.
Status reminder:
- we're not ready to release a "Final" version of Hibernate Search
branch 5.6 because the Elasticsearch work isn't complete.
- the changes needed to be compatible with Hibernate ORM 5.2 are
breaking, i.e. it won't work with Hibernate ORM 5.0 and 5.1 if I apply
them.
- Hibernate Search 5.5 (the previous stable branch) works fine with
both ORM 5.0.x and 5.1.x.
- Breaking compatibility with ORM 5.1 means to break compatibility
with WildFly 10 (unless they also upgrade or we start shipping
alternative ORM modules).
On top of this, Hibernate OGM was wishing to have an upgrade to ORM
5.1.x. I don't see how we can squeeze that in.
The only solution I see is that people will have to be patient and use
ORM 5.0 / 5.1 for now.
Better ideas?
I have a branch of Search which is making progress towards ORM 5.2
compatibility.. not fully complete but it's very clear already that we
can't keep compatibility open for a wider range of ORM versions. Feel
free to try ;)
Also related, the proposal here:
- https://hibernate.atlassian.net/browse/HHH-10793
Thanks,
Sanne
8 years, 8 months
Is org.hibernate.cache.spi.OptimisticCacheSource#getVersionComparator obsolete?
by Gail Badner
It is implemented by AbstractEntityPersister, but as of 5.0.9 (using
Infinispan 7.2.5.Final) I see no references to this method in Hibernate
ORM, other than in Javadoc for OptimisticCacheSource#isVersioned [1] that
says:
"If true, it is illegal for {@link #getVersionComparator} to return null"
[1]
Long story short, if OptimisticCacheSource#getVersionComparator is
obsolete, then there is no reason to create a meaningful Comparator for
Sybase timestamps for HHH-10413.
The long story...
Sybase timestamp can be used as an entity version which is treated as
byte[]. This seems to have caused problems in the past when caching,
because an array does not have a Comparator.
I tried creating a simple comparator that uses Byte#compareTo(Byte), but
unfortunately this does not work for Sybase timestamps, because
Byte#compareTo(Byte)
uses a signed comparison. Sybase timestamps require an unsigned comparison.
I can change the comparator to do unsigned comparisons of byte elements.
One thing to consider is that the same comparator will also be used for
when sorting actions by byte[] IDs.
We discussed earlier that it doesn't make sense to compare IDs that are
arrays. If
OptimisticCacheSource#getVersionComparator is obsolete, then I can simply
use IncomparableComparator#INSTANCE.
If OptimisticCacheSource#getVersionComparator is not obsolete, then is it
worth creating a special BinaryTimestampType that implements
VersionType<byte[]> (instead of BinaryType implementing
VersionType<byte[]>) with a comparator that does unsigned comparisons?
I'm also trying to wrap up HHH-8999, which is also impacted by this.
Regards,
Gail
[1]
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src...
8 years, 8 months
