Hibernate OGM 5.1 CR1 is out!
by Davide D'Alto
Good news!
The first candidate release for Hibernate OGM 5.1 is out.
Compared to 5.1 Beta3, this release upgrades Hibernate Search to
version 5.5.6.Final and supports MongoDB aggregate operation in native
queries.
This means that now you can use Hibernate OGM to do CRUD operations on
your favourite NoSQL database while having it also transparently
synchronize to an Elasticsearch cluster.
You can find all the details in the blog post:
http://in.relation.to/2017/02/15/hibernate-ogm-5-1-cr1-released
Thanks,
Davide
8 years, 10 months
JDK 9 EA Build 155 is available on java.net
by Rory O'Donnell
Hi Sanne,
*JDK 9 Early Access* b155 <https://jdk9.java.net/download/> is
available on java.net
There have been a number of fixes to bugs reported by Open Source
projects since the last availability email :
* b155 - JDK-8167273 : Calendar.getDisplayNames inconsistent with
DateFormatSymbols
* b154 - JDK-8157611 : field visiblePackages is null for the unnamed
module producing NPE when accessed
* b153 - JDK-8163449 : Allow per protocol setting for URLConnection
defaultUseCaches
* b152 - JDK-8172158 : Annotation processor not run with -source <= 8
Dalibor and I are presenting at FOSDEM this weekend, we would love to
meet you there!
* JDK 9 Outreach - The Awesome Parts
<https://fosdem.org/2017/schedule/event/outreach/>
Rgds,Rory
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
8 years, 10 months
SUBSTRING example in documentation uses start position 0 instead of 1.
by Mark Rotteveel
I'm still working on getting tests working for Firebird.
One of the tests that fails is the documentation test
org.hibernate.userguide.hql.HQLTest.test_hql_substring_function_example
The reason this test fails is that Firebird hasn't implemented the
SQL:2011 requirement that start positions lower than 1 should be handled
as 1. See: http://tracker.firebirdsql.org/browse/CORE-5480
The example code is:
List<String> prefixes = entityManager.createQuery(
"select substring( p.number, 0, 2 ) " +
"from Call c " +
"join c.phone p", String.class )
.getResultList();
However this example is slightly confusing in that it implies that start
position is 0-based, while both SQL and JPA 2.1 (section 4.6.17.2.1)
make clear it should be 1-based.
Any objections if I prepare a pull request to change this example to use
1 and the related documentation to specify that start position is 1-based?
Or is there a specific reason this example uses 0?
Mark
--
Mark Rotteveel
8 years, 10 months
Refactor MySQL Dialects
by Vlad Mihalcea
Hi,
While working on MariaDB Dialects, I realize that we should also refactor
the MySQL ones.
The problem is that we introduced the InnoDB hierarchy.
Since the only difference between those two is related to 3 methods, I
think we should hide them behind a MySQLStorageEngine hierarchy with InnoDB
being the default one.
This way, we'll have a single MySQL Dialect hierarchy, and users can switch
to MyISAM via a configuration property which define what MySQLStorageEngine
implementation we are using.
Let me know what you think.
Vlad
8 years, 10 months
Issue with unidirectional one-to-many association with a join column that references a column that is not the primary key
by Marcello Romano
Hi,
A one-to-many association is causing Hibernate to
throw the following exception when loading an entity via
Session.get(domainClass, identifier), under the following conditions:
1. the association collection is annotated with @Fetch(FetchMode.JOIN)
2. the association's join column is referencing a non-primary key of the
owning entity
3. the association's join column value is referencing a non-existing record
of the associated table (the "many" side).
Caused by: org.hibernate.property.access.spi.PropertyAccessException: Error
accessing field [protected java.lang.Long ...] by reflection for persistent
property [...] : 1GBE4E1E04
at
org.hibernate.property.access.spi.GetterFieldImpl.get(GetterFieldImpl.java:43)
at
org.hibernate.tuple.component.AbstractComponentTuplizer.getPropertyValue(AbstractComponentTuplizer.java:58)
at org.hibernate.type.ComponentType.getPropertyValue(ComponentType.java:419)
at org.hibernate.type.ComponentType.getHashCode(ComponentType.java:242)
at
org.hibernate.engine.spi.CollectionKey.generateHashCode(CollectionKey.java:64)
at org.hibernate.engine.spi.CollectionKey.<init>(CollectionKey.java:58)
at org.hibernate.engine.spi.CollectionKey.<init>(CollectionKey.java:43)
at
org.hibernate.engine.loading.internal.CollectionLoadContext.getLoadingCollection(CollectionLoadContext.java:95)
at
org.hibernate.loader.plan.exec.process.internal.CollectionReferenceInitializerImpl.finishUpRow(CollectionReferenceInitializerImpl.java:105)
at
org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.readRow(AbstractRowReader.java:121)
at
org.hibernate.loader.plan.exec.internal.EntityLoadQueryDetails$EntityLoaderRowReader.readRow(EntityLoadQueryDetails.java:239)
at
org.hibernate.loader.plan.exec.process.internal.ResultSetProcessorImpl.extractResults(ResultSetProcessorImpl.java:122)
at
org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:122)
at
org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:86)
at
org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.load(AbstractLoadPlanBasedEntityLoader.java:167)
at
org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:3967)
at
org.hibernate.event.internal.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:508)
at
org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:478)
at
org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:219)
at
org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:278)
at
org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(DefaultLoadEventListener.java:121)
at
org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:89)
at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1129)
at org.hibernate.internal.SessionImpl.access$2600(SessionImpl.java:164)
at
org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.load(SessionImpl.java:2696)
at org.hibernate.internal.SessionImpl.get(SessionImpl.java:975)
...
Caused by: java.lang.IllegalArgumentException: Can not set ... to
java.lang.String
at
sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:164)
at
sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:168)
at
sun.reflect.UnsafeFieldAccessorImpl.ensureObj(UnsafeFieldAccessorImpl.java:55)
at
sun.reflect.UnsafeObjectFieldAccessorImpl.get(UnsafeObjectFieldAccessorImpl.java:36)
at java.lang.reflect.Field.get(Field.java:379)
at
org.hibernate.property.access.spi.GetterFieldImpl.get(GetterFieldImpl.java:39)
... 44 more
The problem is that when initializing the collection, Hibernate is not able
to retrieve the association key value in
CollectionReferenceInitializerImpl.finishUpRow and will fall back to use
the entity owner's primary key instead, causing the
IllegalArgumentException.
We have noticed that there is a related open issue:
https://hibernate.atlassian.net/browse/HHH-9370
We have worked around this issue by changing the way optionalKey is
retrieved in CollectionReferenceInitializerImpl.finishUpRow,
foreignKeyPropertyName );
ResultSetProcessingContext.EntityReferenceProcessingState ownerState =
context.getOwnerProcessingState( (Fetch) collectionReference );
Serializable optionalKey =
collectionReference.getCollectionPersister().getCollectionType().getKeyOfOwner(ownerState.getEntityInstance(),
context.getSession());
Although this seems to work for us, we would like to collaborate to have
this fixed upstream, if you believe this is actually caused by a bug and
not by using Hibernate associations in the wrong way.
Thanks,
Marcello
8 years, 10 months
Behaviour of validation mode "auto" in case of error during validator factory bootstrap
by Gunnar Morling
Hi,
JPA defines for validation mode "auto" that bean validation must occur
if a BV provider is present and that no validation shall occur
otherwise.
What should happen though if a BV provider such as HV is present but
it fails to bootstrap? In case of HV this happens if no expression
language implementation can be found.
Currently, the user has a very hard time to find out about this, as
this exception essentially is suppressed (for mode "callback" the
exception is raised).
Should we raise a specific exception in HV if it cannot be
bootstrapped? In ORM, we could handle that one specifically and raise
it also if for validation mode "auto" (would have to happen
reflectively, though, as to avoid a hard dependency).
I can do this change but first wanted to make sure that this is inline
with what you all think should be done.
Thanks,
--Gunnar
8 years, 10 months
Re: [hibernate-dev] [HV/HSEARCH] Free form
by Emmanuel Bernard
Your prototype is very Hibernate Search tainted. I wonder how or whether we want it reusable across Hibernate Validator, Search and possibly more.
Have you captured somewhere the discussion about the new document builder so I could get a better grip of what’s at bay?
Would this reverse of logic also be embraced by Hibernate Validator? There are runtime decisions done in HV during traversal that made me doubt that it would be as pertinent.
> On 30 Jan 2017, at 11:21, Yoann Rodiere <yrodiere(a)redhat.com> wrote:
>
> Hi,
>
> Did the same this week-end, and adapted your work to match the bigger picture of what we discussed on Friday.
> Basically the "StructureTraverser" is now called "ValueProcessor", because it's not responsible for exposing the internals of a structure anymore, but only to process a structure according to previously defined metadata, passing the output to the "DocumentContext". I think it's the second option you suggested. It makes sense in my opinion, since metadata will be defined differently for different source types (POJO, JSON, ...).
> This design allows in particular what Sanne suggested: when bootstrapping, we can build some kind of "walker" (a composition of "ValueProcessors") from the metadata, and avoid metadata lookup at runtime.
>
> The snippet is there: https://gist.github.com/yrodiere/9ff8fe8a8c7f59c1a051b36db20fbd4d <https://gist.github.com/yrodiere/9ff8fe8a8c7f59c1a051b36db20fbd4d>
>
> I'm sure it'll have to be refined to address additional constraints, but in its current state it seems to address all of our requirements.
>
> Yoann Rodière <yrodiere(a)redhat.com <mailto:yrodiere@redhat.com>>
> Software Engineer
> Red Hat / Hibernate NoORM Team
>
> On 27 January 2017 at 18:23, Emmanuel Bernard <emmanuel(a)hibernate.org <mailto:emmanuel@hibernate.org>> wrote:
> I took the flight home to play with free form and specifically how we would retrieve data from the free form structure.
> By free-form I mean non POJO but they will have schema (not expressed here).
>
> https://github.com/emmanuelbernard/hibernate-search/commit/0bd3fbab137bda... <https://github.com/emmanuelbernard/hibernate-search/commit/0bd3fbab137bda...>
>
> And in particular
> https://github.com/emmanuelbernard/hibernate-search/blob/freeform/freefor... <https://github.com/emmanuelbernard/hibernate-search/blob/freeform/freefor...>
> https://github.com/emmanuelbernard/hibernate-search/blob/freeform/freefor... <https://github.com/emmanuelbernard/hibernate-search/blob/freeform/freefor...>
>
> It probably does not compile, I could not make the build work.
>
> I figured it was important to dump this raw thinking because it will influence and will be influenced by the redesign of the DocumentBuilder of Hibernate Search.
>
> There are several options for traversing a free form structure
> - expose the traversing API as a holder to navigate all properties per structure and sub structure. This is what the prototype shows. Caching needs to be accessed via a hashmap get or other lookup. Metadata and the traversing structure will be navigated in parallel
> - expose a structure that is specialized to a single property or container unwrapping aspect. The structures will be spread across and embedded in the Metadata
>
>
> Another angle:
> - create a traversable object per payload to carry it (sharing metadata info per type)
> - have a stateless traversable object that is provided the payload for each access
>
> The former seems better as it does not create a traversable object per object navigated.
> The latter is better for payloads that need parsing or are better at sequential access since state could be cached.
>
> We need to discuss that and know where DocumentBuilder is going to properly design this API.
>
> Emmanuel
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hibernate-dev <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>
8 years, 10 months
Re: [hibernate-dev] Hibernate Commons project
by Guillaume Smet
On Mon, Jan 30, 2017 at 3:26 PM, Yoann Rodiere <yrodiere(a)redhat.com> wrote:
>
> On 30 January 2017 at 13:58, Guillaume Smet <guillaume.smet(a)gmail.com>
> wrote:
>
>> Note that the current version of hibernate-commons-annotations is
>> org.hibernate.common (without the s at the end, not org.hibernate as Yoann
>> stated it).
>>
> You're right. Wouldn't the simplest solution be to use the same groupId
> (without a "s") in our new repo?
>
I'm not so sure it's a good idea to share the groupId while it being a
completely different project.
I'm starting to think that maybe the good groupId for these common internal
projects could be org.hibernate.*internal*. We plan them to be purely
internal artifacts and we might as well state it.
What do you all think about it?
> Moving hibernate-commons-annotations is not such a good idea IMHO:
>> - it's licensed under the LGPL so it would force us to use this license
>> (or
>> relicense it or having different licenses for the submodules but they are
>> all bad ideas)
>>
>
> It sure seems complicated. But relicensing from LGPL to ASL2 may not be
> such a big deal, since LGPL seems stricter than ASL2.
> Couldn't we simply dual-license the whole repository under ASL2/LGPL? That
> way, previous users wouldn't need to be aware of the change, and new users
> could choose to comply with whichever suits them best.
>
Yeah, dual licensing might be the better solution. But I think it would be
OK with ASL2. Anyway, let's wait for Emmanuel to decide on this subject.
> - we would release a new version of this module each time we want to
>> upgrade the theme and I don't think it would be readable for consumers of
>> this preexisting artifact.
>>
>> The latter point is what worries me about centralizing all the utils in
>> the
>> same repo with the same lifecycle.
>>
>
> We already got through this discussion, but let's sum it up:
>
Not exactly. I was specifically talking about hibernate-commons-annotations
as it's a different beast: it's already released and people might use it in
their projects. Thus I don't think it's a good idea to think of it as a
purely internal project.
IMHO, it makes a difference.
--
Guillaume
8 years, 10 months
