API differences in Hibernate ORM 5.1 vs 5.3
by Gail Badner
Hi,
There were lots of differences in the compatibility report, so as a first
step, I've excluded packages/classes that I considered SPI, internal, or
"grey area". This reduced the the differences to a more manageable amount.
You can see a summary of the incompatibilities along with suggested
mitigation at [1].
The report is attached to [1], along with a zip with instructions for
running the report.
I believe there are some "false positives" in the report, and I have
documented them in the section, "False Positives?".
Feel free to comment on the article.
Thanks,
Gail
[1]
https://developer.jboss.org/wiki/HibernateORMBinaryCompatibilityBetween51...
5 months, 4 weeks
IP banned from forum
by Gunnar Morling
Hi,
Is anyone banning users from the forum? I am getting "A ban has been
issued on your IP address."
I don't think banning by IP is a good strategy as many users will have
dynamic IPs from their hoster's shared pool, so it's a random game to
hit an IP previously banned due to some other user's spam.
Thanks,
--Gunnar
5 months, 4 weeks
New CI machine preview
by Sanne Grinovero
You're all welcome to play with http://54.225.162.168/
however please keep these in mind:
- it's not the final machine: don't put too much effort in creating
nice build scripts as we'll reset it to clean state soon. We *might*
be able to store jobs defined so far, but we might choose not to.
- domain name should be coming: ci.hibernate.org ..not sure when, got
no replies so far from.
- authentication: just click on login, it will use OAuth2 to request
your identity via your GitHub account. Permissions to create new jobs,
edit existing jobs, run a build manually depend on your github account
be part of the Hibernate organization (or not, in which case you have
read only status)
At this stage I'd like to get a feeling if the hardware is powerful
enough, and also we need to select which other plugins we want to use,
I'm looking especially to:
- static analysis reports
- pull requests integration
both are relatively undefined, we can of course start simple and
improve later.. just checking this fits basic needs now.
Sanne
8 months, 1 week
Which branch to target?
by Mark Rotteveel
After a significant hiatus, I have restarted my work on adding improved
support for Firebird 2.5 and 3.0 (and more importantly struggling
through some test failures).
I am wondering what I should target for my changes: the current master
branch or the upstream/wip/6.0 branch. What would be the preferred or
'better' option?
Mark
--
Mark Rotteveel
7 years
Test FormulaWithPartitionByTest seems to rely on implementation specific ordering
by Mark Rotteveel
The test FormulaWithPartitionByTest against Firebird 3 fails because the
returned result has a different order than the one expected by the test.
As far as I can tell, the order expected by the test is arbitrary or at
least, as far as I can tell, the order expected is not necessarily
required by the SQL standard (although it might as well be a bug in
Firebird, I'm just not sure).
The testdata is
(ID, DISCOUNT_CODE, DISCOUNT_VALUE)
(1, "20", 12.34)
(2, "20", 15.89)
(3, "100", 12.5)
With generated query:
select
formulawit0_.id as id1_0_,
formulawit0_.DISCOUNT_CODE as DISCOUNT_CODE2_0_,
formulawit0_.DISCOUNT_VALUE as DISCOUNT_VALUE3_0_,
ROW_NUMBER() OVER( PARTITION
BY
formulawit0_.DISCOUNT_CODE
ORDER BY
SIGN(formulawit0_.DISCOUNT_VALUE) DESC ) as formula0_
from
DisplayItem formulawit0_
order by
formulawit0_.id
The expected order of the row_number() is 1, 2, 1 but due to the
evaluation order in Firebird of order by in window functions and the top
level order by, the resulting order is 2, 1, 1.
I can see four solutions for this:
1. Just ignore the test for Firebird 3
2. Add a Firebird specific expectation of order (although that would be
testing what is likely an implementation artifact)
3. Enforce a more specific order in the window function by changing the
order by to ORDER BY SIGN(DISCOUNT_VALUE) DESC, ID
4. Enforce an order by that is consistent with the data: ORDER BY
DISCOUNT_VALUE (the use of SIGN with the shown data can lead to an
arbitrary order as the result is always 1).
What would have your preference?
Mark
--
Mark Rotteveel
7 years
Fwd: Test FormulaWithPartitionByTest seems to rely on implementation specific ordering
by Graham Collinson
Didn't include the list on my original email, sorry.
---------- Forwarded message ---------
From: Graham Collinson <graham_hibernate(a)collo.me.uk>
Date: Tue, 25 Jun 2019 at 02:56
Subject: Re: [hibernate-dev] Test FormulaWithPartitionByTest seems to rely
on implementation specific ordering
To: Steve Ebersole <steve(a)hibernate.org>
Hi,
I get similar results when trying this as a manual test in mariadb
(10.3.8-MariaDB).
The full results returned are:
+--------+-------------------+--------------------+-----------+
| id1_0_ | DISCOUNT_CODE2_0_ | DISCOUNT_VALUE3_0_ | formula0_ |
+--------+-------------------+--------------------+-----------+
| 1 | 20 | 12.34 | 2 |
| 2 | 20 | 15.89 | 1 |
| 3 | 100 | 12.5 | 1 |
+--------+-------------------+--------------------+-----------+
If the test is against the row_number (or formula0_) column then expecting
1,2,1 appears to be incorrect.
The row_number is over a partition on discount code with rows ordered by
sign(discount_value) descending.
As Mark says sign(discount_value) is always 1. So should this query lead
to the list of row_numbers expected by the test?
I tested in oracle (11.2.0.3) and got the order the test expects.
ID1_0_ DISCOUNT_CODE2_0_ DISCOUNT_VALUE3_0_ FORMULA0_
1 20 12.34 1
2 20 15.89 2
3 100 12.5 1
It looks like it may be a bit random to me.
Regards,
Graham
On Mon, 24 Jun 2019 at 16:56, Steve Ebersole <steve(a)hibernate.org> wrote:
> The query is selecting ids, so I assume you mean `1,2,3` as the
> expectation.
>
> Clearly Firebird cannot support what the query is attempting to do - so the
> best option is to skip this test for Firebird. However, the order-by is
> really not serving any purpose to the test aside from making the assertions
> easier; so another option would be to remove the order-by and assert the
> results via iterating them.
>
> On Sat, Jun 22, 2019 at 3:19 AM Mark Rotteveel <mark(a)lawinegevaar.nl>
> wrote:
>
> > The test FormulaWithPartitionByTest against Firebird 3 fails because the
> > returned result has a different order than the one expected by the test.
> >
> > As far as I can tell, the order expected by the test is arbitrary or at
> > least, as far as I can tell, the order expected is not necessarily
> > required by the SQL standard (although it might as well be a bug in
> > Firebird, I'm just not sure).
> >
> > The testdata is
> > (ID, DISCOUNT_CODE, DISCOUNT_VALUE)
> > (1, "20", 12.34)
> > (2, "20", 15.89)
> > (3, "100", 12.5)
> >
> > With generated query:
> > select
> > formulawit0_.id as id1_0_,
> > formulawit0_.DISCOUNT_CODE as DISCOUNT_CODE2_0_,
> > formulawit0_.DISCOUNT_VALUE as DISCOUNT_VALUE3_0_,
> > ROW_NUMBER() OVER( PARTITION
> > BY
> > formulawit0_.DISCOUNT_CODE
> > ORDER BY
> > SIGN(formulawit0_.DISCOUNT_VALUE) DESC ) as formula0_
> > from
> > DisplayItem formulawit0_
> > order by
> > formulawit0_.id
> >
> > The expected order of the row_number() is 1, 2, 1 but due to the
> > evaluation order in Firebird of order by in window functions and the top
> > level order by, the resulting order is 2, 1, 1.
> >
> > I can see four solutions for this:
> >
> > 1. Just ignore the test for Firebird 3
> > 2. Add a Firebird specific expectation of order (although that would be
> > testing what is likely an implementation artifact)
> > 3. Enforce a more specific order in the window function by changing the
> > order by to ORDER BY SIGN(DISCOUNT_VALUE) DESC, ID
> > 4. Enforce an order by that is consistent with the data: ORDER BY
> > DISCOUNT_VALUE (the use of SIGN with the shown data can lead to an
> > arbitrary order as the result is always 1).
> >
> > What would have your preference?
> >
> > Mark
> > --
> > Mark Rotteveel
> > _______________________________________________
> > 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
>
7 years
Hibernate Search 6.0.0.Alpha7 released
by Yoann Rodiere
Hello,
We just published Hibernate Search 6.0.0.Alpha7, a new release of the
still-in-development 6.0 branch.
This release mainly restores missing parameters for index field types,
restores explicit indexing APIs, and upgrades to Elasticsearch 6.8 and 7.1.
As an Alpha, this version is an early technology preview. Be sure to read
about it on our blog before you try it out:
https://in.relation.to/2019/06/24/hibernate-search-6-0-0-Alpha7/
Yoann Rodière
Hibernate NoORM Team
yoann(a)hibernate.org
7 years
NoORM IRC meeting minutes
by Guillaume Smet
Hi,
As usual, here are the minutes of the NoORM IRC meeting.
15:01 < gsmet> #topic Progress Davide
15:01 < DavideD> On the OGM side, there have been a couple of PRs and
several questions. Always on the MongoDB side. In theory, there is a guy
looking at the support for transaction on MongoDB but I haven't
received any news about it yet.
15:01 < DavideD> On the Hibernate Async side, I'm still working on it but
progressing very slowly.
15:02 < DavideD> That's pretty much it
15:02 < gsmet> OK
15:02 < gsmet> #topic Next 2 weeks Davide
15:02 < DavideD> There are going to be some OGM prs to review and I will
continue the work on the async side
15:03 < gsmet> is there anything that should be done to help you make more
progress on the async side?
15:03 < DavideD> That's all
15:04 < DavideD> I don't know, I talked about it with Sanne last week
15:04 < gsmet> OK
15:04 < DavideD> I think the main issue is that I'm working on it on my own
15:04 < gsmet> yeah, that sure doesn't help
15:04 < DavideD> But he is aware of it, so I guess at some point we will
have some reorganization
15:05 < gsmet> OK!
15:05 < gsmet> thanks!
15:05 < gsmet> #topic Progress Fabio
15:05 < fax4ever> Starting from where we stayed last time...
15:05 < fax4ever> We have made it possible to provide a
missing-value-replacement for sorting
15:05 < fax4ever> on a String field using the Lucene backend.
15:06 < fax4ever> Furthermore, it seems that Elasticsearch does not apply
some normalizer
15:06 < fax4ever> defined on a field on the sort missing value provied at
query time.
15:06 < fax4ever> We do it in the Lucene backend and it would be nice
having the same behavior
15:06 < fax4ever> on Elasticsearch too.
15:06 < fax4ever> For that reason I wrote this post:
15:06 < fax4ever>
https://discuss.elastic.co/t/should-sort-missing-values-be-normalized/184222
.
15:06 < jbossbot> Title: Should sort missing values be normalized? -
Elasticsearch - Discuss the Elastic Stack
15:06 < yrodiere> From what I can see nobody answered, you should probably
try a bug report instead
15:07 < fax4ever> OK let's do that
15:07 < fax4ever> thanks
15:07 < fax4ever> using github?
15:07 < yrodiere> yes
15:07 < fax4ever> they don't have Jira... OK
15:07 < fax4ever> So I'll
15:07 < fax4ever> it's time to do that :)
15:07 < yrodiere> let's have a look together, maybe? Wouldn't want it to be
dismissed just because something is not clear
15:07 < fax4ever> Moreover, we removed any dependence on
java.beans.Introspector.
15:08 < fax4ever> Since it won’t be included in future versions of the JDK.
15:08 < fax4ever> Using Hibernate commons annotations
15:08 < fax4ever> that provide excellent support for annotations
15:08 < fax4ever> but not for generics
15:09 < fax4ever> so for the generics part we kept the Hibernate Search
implementation
15:09 < fax4ever> Furthermore, we handled what happens when a client reuses
a query component,
15:09 < fax4ever> such as an instance of predicate, sort or projection.
15:09 < fax4ever> We rely on the addressed index set to check whether a
component can be used on a given scope.
15:10 < fax4ever> If they don't match, we throw an exception log
15:10 < fax4ever> Finally, I revied some large pull requests.
15:10 < gsmet> fax4ever: keep in mind that we don't need all the details of
each issue :)
15:10 < fax4ever> But I'm still to slow in reviewing :/
15:10 < fax4ever> OK :P
15:11 < fax4ever> That's all about Progess...
15:11 < fax4ever> too slow
15:11 < gsmet> #topic Next 2 weeks Fabio
15:11 < fax4ever> I'll be staying on PTO from June 22 to July 15.
15:11 < yrodiere> fax4ever: I still think you're fast enough, just a bit
too meticulous ;)
15:11 < fax4ever> too good :)
15:11 < fax4ever> So in the next three days, the ones up to June 21,
15:12 < fax4ever> I would like to spend much time as possible reviewing
further pull requests.
15:12 < fax4ever> Finally, maybe I'll have the time to solve some issues
too.
15:12 < fax4ever> Like the one to handle the case where a GeoPoint field is
declared sortable.
15:12 < fax4ever> That's all from me.
15:12 < gsmet> ok, thanks!
15:12 < fax4ever> Thank you!
15:12 < gsmet> #topic Progress Guillaume
15:13 -!- sfikes [~sfikes(a)c-69-246-28-50.hsd1.tn.comcast.net] has joined
#hibernate-dev
15:13 < gsmet> so I worked a bit on ORM to fix an enhancement issue
15:13 < gsmet> and a bit on HV to push new releases for the 6.0 branch and
the 6.1 branch
15:14 < gsmet> nothing much but it was high time we release them as they
contained a few minor but annoying fixes
15:14 < gsmet> #topic Next 2 weeks Guillaume
15:14 < gsmet> I won't work on Hibernate stuff that much
15:14 < gsmet> I want to make progress on the ORM integration in Quarkus
15:15 < gsmet> I made some progress this week but there is still some work
to do
15:15 < gsmet> I also have a talk next week and I will demo Quarkus +
Hibernate Search as a live demo
15:15 < yrodiere> \o/
15:15 < gsmet> so I have to practice a lot until then :)
15:16 < gsmet> that's pretty much it for me
15:16 < gsmet> #topic Progress Koen
15:16 < koentsje> i have integrated quarkus 0.16.0 in the eclipse tools
15:16 < fax4ever> nice!
15:16 < koentsje> also continued to work (a tiny bit) on the quarkus
run/debug configuration in eclips
15:17 < koentsje> yrodiere helped me setting up a continuous integration
job for the quarkus-eclipse project
15:17 < koentsje> (basically he did all the work ;) )
15:18 < koentsje> i did a bit of maintenance on the core hibernate tools,
updating dependencies
15:18 < yrodiere> I didn't debug the build :P
15:19 < koentsje> and i investigated a jboss tools problem that i lost
track of, it concerns failure of creation of hibernate consoles for
hibernate 5.3 and 5.4
15:19 < koentsje> but so far, i haven’t been able to reproduce it… even
though our qe guys are adamant
15:19 < koentsje> that’s it for me for the past sprint
15:20 < gsmet> #topic Next 2 weeks Koen
15:20 < koentsje> i will first try continue with this jboss tools problem
15:20 < koentsje> reproduce it and (hopefully) fix it
15:21 < koentsje> then continue the quarkus run/debug configuration
15:21 < koentsje> and finally if time, tackle the issues carried over from
last period:
15:21 < koentsje> - improve the quarkus extension view
15:22 < koentsje> - elaborate the reddeer automatic integration test
15:22 < koentsje> also, i plan to take off next week thursday and friday…
15:22 < koentsje> that’s it
15:23 < gsmet> thanks!
15:23 < gsmet> #topic Progress Yoann
15:23 < yrodiere> First, I finished the work I started during the previous
sprint about adding write APIs that go beyond just automatic indexing.
15:23 < yrodiere> It allows more fine-grained control over indexing when
executing batch processes, in particular.
15:23 < yrodiere> After that I tried to make a case for giving more
precision to the `scaled_float` type in Elasticsearch, which would be
useful to us when indexing BigDecimal or BigInteger.
15:24 < yrodiere> Long story short, there was an easy fix but would not
improve the precision of all features (aggregations in particular), so they
were adamant about it: it's a no
15:24 < yrodiere> So we'll have better precision in the Lucene backend than
in the Elasticsearch backend, there's not much we can do about it.
15:24 < yrodiere> Next, I fixed several minor issues with the Search DSL,
mainly the fact that we used to require a Function for lambdas in the
predicate and projection DSL, and a Consumer for lambdas in the
Sort DSL
15:24 < yrodiere> Now we'll expect a Function everywhere.
15:24 < yrodiere> I also worked on the ORM mapper, restoring support for
indexed entities whose document ID is extracted from a property that is not
the entity ID
15:25 < yrodiere> Apart from that, most of my time was spent on the
documentation
15:25 < yrodiere> both the javadoc and the reference documentation
15:25 < yrodiere> It took way longer than I initially imagined, but now we
have something
15:25 < yrodiere> Next two weeks...
15:25 < gsmet> #topic Next 2 weeks Yoann
15:25 < yrodiere> I already started a code cleanup in the POJO mapper,
which I expect to submit soon
15:26 < yrodiere> It's mostly related to what I did regarding entities
whose document ID is not the entity ID:
15:26 < yrodiere> I had to implement a quick and dirty fix, a clean one
requires more extensive changes
15:26 < yrodiere> In parallel I've also started investigating a bug related
to distance projections; I will finish that
15:26 < yrodiere> I also want to test and implement support for ES 6.8
15:26 < yrodiere> Then I intend to release a new Alpha, probably by the end
of the week
15:27 < yrodiere> I will also work on some API changes that should happen
before the beta, but they probably won't make it into master before the
release
15:27 < yrodiere> Some changes are not very impacting to users, such as
renaming some DSL interfaces (users don't reference these types directly
anyway),
15:27 < yrodiere> but others are more extensive, such as moving the mapping
annotations to a common package (it's a bit of a mess right now)
15:27 < yrodiere> I think that's all
15:27 < yrodiere> gsmet: Fabio will be on PTO starting next week, so I may
need your help for reviews... ? :)
15:27 < gsmet> ping me when you have some stuff to review
15:28 < gsmet> ah wait
15:28 < gsmet> I'm on PTO starting next Wednesday (had 5 days that I *have*
to take in June)
15:28 -!- rvansa [rvansa@nat/redhat/x-lsbsmokpiytmhfpj] has quit [Ping
timeout: 245 seconds]
15:28 < gsmet> and polishing my talk until then but I should hopefully have
some time here and there
15:28 < yrodiere> ok
15:29 < gsmet> and I'm on semi-PTO on Friday
15:29 < gsmet> (meaning, I took a PTO but I will probably work a bit)
15:29 < yrodiere> don't hesitate to ask if I can help with something, that
will leave your more time to review and will reduce the amount of stuff to
review ;)
15:29 < gsmet> yeah, well, it's mostly about practicing and practicing
15:29 < gsmet> so nobody can really help
15:30 < gsmet> well, you can practice if you want but it won't help me ;)
15:30 < yrodiere> developers, developers, developers
15:30 < fax4ever> :)
7 years
JDK 13 enters Rampdown Phase One
by Rory O'Donnell
Hi Sanne,
*JDK 13 Early Access build **25 is now available **at : - jdk.java.net/13/*
* Per the JDK 13 schedule [1], we are now in Rampdown Phase One.
o For more details , see Mark Reinhold's email to jdk-dev mailing
list [2]
o The overall feature set is frozen, no further JEPs will be
targeted to this release.
* Changes in this build 25 [4]
*Request for feedback on JEP 353 integrated in b24
*
JEP 353: Reimplement the Legacy Socket API" has been integrated into
jdk-13+24. It would be very useful if applications or libraries using
java.net.Socket or java.net.ServerSocket APIs could test with this build
and report any issues found. The JEP provides information on the system
property that can be used to switch back to the old implementation and
that may be useful to check for behavior differences between the old and
new implementation. It would be very useful to get feedback via the
OpenJDK net-dev mailing list, bugs via the usual channel.
*Updates to Release Notes since last email*
* b25 - Support Kerberos cross-realm referrals (RFC 6806)(JDK-8215032
<https://bugs.openjdk.java.net/browse/JDK-8215032>)
* b25 - Add -XX:SoftMaxHeapSize flag(JDK-8222145
<https://bugs.openjdk.java.net/browse/JDK-8222145>)
* b24 - Reimplement the Legacy Socket API(JDK-8221481
<https://bugs.openjdk.java.net/browse/JDK-8221481>)
o see above request for feedback
* b24 - Deprecated rmic tool For Removal(JDK-8217412
<https://bugs.openjdk.java.net/browse/JDK-8217412>)
* b24 - New String constants for Canonical XML 1.1 URIs(JDK-8224767
<https://bugs.openjdk.java.net/browse/JDK-8224767>)
* b23 - Support for Unicode 12.1 (JDK-8221431
<https://bugs.openjdk.java.net/browse/JDK-8221431>)
* b21 - Upgrade CLDR to Version 35.1 (JDK-8221432
<https://bugs.openjdk.java.net/browse/JDK-8221432>)
*OpenJDK 14 **Early Access build 1 **is now available **at : -
jdk.java.net/14/*
* These early-access, open-source builds are provided under the GNU
General Public License, version 2, with the Classpath Exception
<http://openjdk.java.net/legal/gplv2+ce.html>.
* Changes in this build [5]
**
Rgds, Rory
[1] http://openjdk.java.net/projects/jdk/13/#Schedule
<http://openjdk.java.net/projects/jdk/12/#Schedule>
[2] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-June/003060.html
[3] http://jdk.java.net/13/release-notes
[4] JDK 13 - Changes in b25 here
<http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B24%22%3A...>
[5] JDK 14 - Changes in b1 here
<http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-14%2B0%22%3A%...>
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin,Ireland
7 years
