Hibernate OGM integration with ORM 5.3
by Davide D'Alto
Hi,
I'm working on the integration with ORM 5.3 and I've created a branch
where I'm applying the changes.
You can see some initial discussions on the pull request I've sent as
preview: https://github.com/hibernate/hibernate-ogm/pull/961
I didn't find any specific issue with ORM 5.3 that could create a
problem for OGM so far.
Main problems are
1) check the JpaCompliance property and behave the same way as ORM
from a user point of view when possible
2) Positional parameters can now start from 1
3) The method that creates the factory doesn't thow exceptions anymoew
and in OGM we will have to do something similar when the OGM provider
is used
Anyway, it doesn't seem that these issues require changes in ORM.
I still have to update the integration tests with WildFly, so
something else might appears.
Cheers,
Davide
8 years, 1 month
ORM 5.1 vs compatibility with Java 6
by Sanne Grinovero
Is Hibernate ORM 5.1 still meant to be compatible with Java 6?
The readme seems to promise that it should be, but it's not: I
happened to try compiling it and it failed, as some recent changes are
using JDK classes which have been introduced in 7.
Turns out it builds fine for Andrea an Chris, as they don't have the
JAVA6_HOME variable set: in this case the build will be lenient: log a
warning and move on.
I guess the same was done by all others on the team? CI is not
checking this either.
Wondering if you all feel like it's worth fixing branch 5.1, or if
it's a dead branch anyway.
Thanks,
Sanne
8 years, 1 month
5.3.0 and JPA TCK
by Steve Ebersole
At this point, all of our challenges with Oracle over JPA TCK tests are
resolved. Today I will be rerunning the ful TCK to verify that.
Anyway, long story short unless there are objections I plan to make this
version CR1 considering we've really just been waiting on the resolution of
these challenges to "finalize" 5.3.
P.S. it might be very late until I can do the release depending on how long
the TCK takes to run (it generally takes a looooong time).
8 years, 1 month
Re: [hibernate-dev] module org.hibernate.commons.annotations
by Sanne Grinovero
Thanks all, HCANN 5.0.2.Final is released.
Changelog:
- https://hibernate.atlassian.net/projects/HCANN/versions/30400/tab/release...
Andrej Golovnin had contributed a neat patch improving memory
allocation last year, but we never released the branch so this wasn't
effective. I'll send PRs to upgrade all projects to benefit from it.
Thanks,
Sanne
On 14 February 2018 at 08:37, Yoann Rodiere <yrodiere(a)redhat.com> wrote:
> Sounds good.
>
> On Tue, 13 Feb 2018 at 22:53 Steve Ebersole <steve(a)hibernate.org> wrote:
>>
>> +1
>>
>> On Tue, Feb 13, 2018, 3:42 PM Sanne Grinovero <sanne(a)hibernate.org> wrote:
>>
>> > I'd like to release an Hibernate Commons Annotations version
>> > 5.0.2.Final to declare its Jigsaw module name as an automatic module
>> > name. Version 6 - whihch I proposed in a different thread - should
>> > then use this module but have a proper module definition.
>> >
>> > Is module name `org.hibernate.commons.annotations` acceptable for you
>> > all?
>> >
>> > Incidentally, there happens to be another nice improvement in branch
>> > 5.0 which was never released so it would be nice to upgrade to this
>> > version even if you have no interest in modularity yet.
>> >
>> > As soon as there's agreement on the module name I'll release it.
>> >
>> > Thanks,
>> > Sanne
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> --
> Yoann Rodiere
> yoann(a)hibernate.org / yrodiere(a)redhat.com
> Software Engineer
> Hibernate NoORM team
8 years, 1 month
module org.hibernate.commons.annotations
by Sanne Grinovero
I'd like to release an Hibernate Commons Annotations version
5.0.2.Final to declare its Jigsaw module name as an automatic module
name. Version 6 - whihch I proposed in a different thread - should
then use this module but have a proper module definition.
Is module name `org.hibernate.commons.annotations` acceptable for you all?
Incidentally, there happens to be another nice improvement in branch
5.0 which was never released so it would be nice to upgrade to this
version even if you have no interest in modularity yet.
As soon as there's agreement on the module name I'll release it.
Thanks,
Sanne
8 years, 1 month
ORM CI jobs - erroneous github triggers
by Steve Ebersole
The legacy ORM jobs (5.1-based ones at least) are getting triggered when
they should not be. Generally they all show they the run is triggered by a
"SCM change", but it does not show any changes. The underlying problem
(although I am at a loss as to why) is that there has indeed been SCM
changes pushed to Github, but against completely different branches. As
far as I can tell these job's Github setting are correct. Any ideas what
is going on?
This would not be such a big deal if the CI environment did not throttle
all waiting jobs down to one active job. So the jobs I am actually
interested in are forced to wait (sometimes over an hour) for these jobs
that should not even be running.
8 years, 1 month
Re: [hibernate-dev] Some insight about HHH-12101 / remove HQL-style positional parameters
by Steve Ebersole
Yes, I understood the situation.
I'm saying that in your query you should just be able to switch to use
named parameters (prefixed with `:`, rather than `?`) as a workaround
On Wed, Feb 7, 2018 at 11:21 AM Laurent Almeras <laurent.almeras(a)laposte.net>
wrote:
> Hi,
>
> Thanks for this insight ; but as I stated (and this is a correction of the
> assumptions of my first email) in my second email, it seems that the wrong
> query (with mixed positional and named parameters) is built in hibernate
> inside layers (and not in QueryDSL).
>
> I get rid of my QueryDSL query and replace it with raw JPQL query :
>
>
> ============================
> Query query = getEntityManager().createQuery("select
> queuedTaskHolder\n" +
> "from QueuedTaskHolder queuedTaskHolder\n" +
> "where queuedTaskHolder.status in (?1) and
> queuedTaskHolder.queueId = ?2\n" +
> "order by queuedTaskHolder.id asc").setParameter(1,
> ImmutableList.of(TaskStatus.CANCELLED,
> TaskStatus.COMPLETED)).setParameter(2, "queue");
> return query.getResultList();
> ============================
>
> And it fails with the very same message :
>
>
> ============================
>
>
> Cannot define positional and named parameterSpecs : select queuedTaskHolder
> from org.iglooproject.jpa.more.business.task.model.QueuedTaskHolder
> queuedTaskHolder
>
> where queuedTaskHolder.status in (:x1_0, :x1_1) and
> queuedTaskHolder.queueId = ?2
> order by queuedTaskHolder.id asc
> at
> org.hibernate.hql.internal.ast.HqlSqlWalker.generatePositionalParameter(HqlSqlWalker.java:1094)
> at
> org.hibernate.hql.internal.antlr.HqlSqlBaseWalker.parameter(HqlSqlBaseWalker.java:3463)
> ============================
>
> It used to work with Hibernate 5.2.x ; and by reading JPQL spec (not sure
> if this is the right version -
> https://docs.oracle.com/html/E13946_01/ejb3_langref.html#ejb3_langref_in
> ) it seems that " IN (?param) " is a valid syntax.
>
> I agree that mixed query may not be supported, but even if positional
> parameter queries bring nothing more than named parameters ones, there are
> also required for JPA compliance ?
>
> Can you say me if I made some wrong assumptions ? If not, is it usefull I
> provide some minimal test-case ?
>
>
>
> *Side-note:* same query written with named parameters is OK (as expected):
>
>
> ============================
> Query query = getEntityManager().createQuery("select
> queuedTaskHolder\n" +
> "from QueuedTaskHolder queuedTaskHolder\n" +
> "where queuedTaskHolder.status in (:statuses) and
> queuedTaskHolder.queueId = :queue\n" +
> "order by queuedTaskHolder.id asc").setParameter("statuses",
> ImmutableList.of(TaskStatus.CANCELLED,
> TaskStatus.COMPLETED)).setParameter("queue", "queue");
> return query.getResultList();
> ============================
>
>
>
> Thanks,
>
> Le 07/02/2018 à 17:30, Steve Ebersole a écrit :
>
> Yes, I can see this being a problem. Its caused by some very old, fulgy
> code in how "list-valued parameters" are handled internally.
>
> I'm not sure the best way to deal with this. Unfortunately reverting this
> is not possible - its necessary for JPA compliance. The simple workaround
> of course is to use named parameters yourself. Honestly JPA's notion of
> "positional" parameters is nonsensical since they are not positional - the
> ordinals can repeat and can appear in any order... nothing particularly
> positional about that. In fact they are really nothing more than named
> parameters that happen to use int-valued labels.
>
> Longer term 6.0 will address this because it changes that "old, fulgy"
> internal code - but those same changes are not possibly in 5.3.
>
>
>
>
8 years, 1 month
Jenkins Updates on Friday
by Davide D'Alto
Hi,
I'm going to run some updates on Jenkins this Friday.
They are minor updates and should be painless but you never know.
Cheers,
Davide
8 years, 1 month
