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).
6 years, 2 months
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
6 years, 2 months
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
6 years, 2 months
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.
6 years, 2 months
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.
>
>
>
>
6 years, 2 months
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
6 years, 2 months
HCANN 6
by Sanne Grinovero
I'd like to push some updates to Hibernate Commons Annotations, looks
like a good time to plan it as a 6.0 release to nicely align with
plans of our other projects.
I plan to:
- bump its version to 6.0.0-SNAPSHOT
- upgrade the Gradle build
- upgrade its dependencies to latest (which means just JBoss Logger)
- baseline the requirement to Java 8 (still was on old Java 6 bytecode)
- merge the one open PR: looks good to me and we were not confident
on merging it in 5.x
- if possible, include a proper Jigsaw module definition.
Any objections? I hope not as I've already mostly done it all locally ;)
I'll create JIRA issues soon.
Thanks,
Sanne
6 years, 2 months
Make JpaCompliance available earlier
by Steve Ebersole
I am working on HHH-12282. I was thinking that the best solution would be
to check this setting at the time when Join#setOptional is called. The
reason being to centralize the place that this check needs to be done. I
can do it inside the persister as it consumes the Join, but that leads to
duplicated code.
But in order to fix in the way I just described, we would have to make
JpaCompliance available earlier in the boot process (currently it is built
as part of SessionFactoryOptions/Builder).
WDYT?
6 years, 2 months
