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
5 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
5 years, 1 month
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
>
5 years, 1 month
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
5 years, 1 month
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> :)
5 years, 1 month
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
5 years, 1 month
Hibernate NoORM meeting minutes
by Guillaume Smet
Hi,
As usual, here are the minutes of this week's NoORM meeting.
Once again carefully crafted by hand.
15:01 < gsmet> #topic Progress Fabio
15:01 < fax4ever> First of all, we merged the contribution to support
15:02 < fax4ever> @DecimalScale within BigDecimal and BigInteger field
types.
15:03 -!- rvansa [rvansa@nat/redhat/x-xhodhuijvfvkddtt] has joined
#hibernate-dev
15:03 < fax4ever> Most of the effort of the last two weeks were about
adding field type options,
15:03 < fax4ever> that are present on Hibernate Search 5,
15:03 < fax4ever> but that weren't present on Hibernate Search 6.
15:03 < fax4ever> Now we supports the options:
15:03 < fax4ever> 1. norms
15:03 < fax4ever> 2. searchable
15:04 < fax4ever> 3. termVector
15:04 < fax4ever> I think that was a significant milestone to release a
beta.
15:04 < fax4ever> The rest of time...
15:04 < fax4ever> On one hand, I reviewed some pull requests.
15:04 < fax4ever> On the other hand, I completed all the issues
15:04 < fax4ever> that were supposed to be done in the current sprint.
15:04 < fax4ever> Actually, it has been the first time I do it. :/
15:05 < fax4ever> They were about:
15:05 < fax4ever> 1. Handle .onMissingValue().use() properly for date
fields in Elasticsearch
15:05 < fax4ever> 2. Return a CompletableFuture instead of a Future from
MassIndexer.start().
15:05 < fax4ever> 3. Add a test for indexEmbedded depth parameter shared
across class.
15:05 < fax4ever> (for Search 6 and 5)
15:05 < fax4ever> 4. Support correctly `.withPrefixLength` in Elasticsearch.
15:05 < fax4ever> (Search 5)
15:06 < fax4ever> That has been the first time that I contributed to Search
5 too.
15:06 < fax4ever> Next two weeks, please.
15:06 < gsmet> #topic Next 2 weeks Fabio
15:06 < fax4ever> Thanks
15:06 < fax4ever> I started today a new issue to allow to provide a missing
value
15:06 < fax4ever> replacement for sorting,
15:06 < fax4ever> even if the field has a String type and the backend is
Lucene.
15:07 < fax4ever> That's not supported by Lucene, you know.
15:07 < fax4ever> But Elasticsearch does it.
15:07 < fax4ever> So I've studied the code of Elasticsearch
15:07 < fax4ever> and now I'm trying to do something `similar` for the
issue.
15:07 < fax4ever> About the rest, as usual a new sprint has been created,
15:07 < fax4ever> so you can see the forecast of the next two weeks on Jira.
15:07 < fax4ever> See `HSEARCH - 2019-10`.
15:08 < fax4ever> That's all from me. Thanks for your attention.
15:08 < gsmet> thanks!
15:08 < gsmet> #topic Progress Guillaume
15:08 < gsmet> so I haven't done much on the Hibernate front
15:08 < gsmet> I released ORM 5.4.3.Final
15:09 < gsmet> not totally Hibernate related but still, I wrote a guide + a
quickstart for using Hibernate Search on Quarkus
15:09 < gsmet> it was long overdue but Search is now a first class citizen
in the Quarkus world
15:09 < gsmet> now, we just need a Final, guys :)
15:10 < gsmet> I also spent some time on HV, merging a few things in and
preparing new releases
15:10 < yrodiere> when it's ready ;)
15:10 < gsmet> #topic Next 2 weeks Guillaume
15:10 < gsmet> so I need to fix an issue with HV + Quarkus then release new
versions of HV
15:11 < gsmet> that's my number one priority for now
15:11 < gsmet> I have to prepare for a couple of talks so I will probably
code less than usual
15:12 < gsmet> please ping me when you release new Search version so that I
can upgrade the one used by Quarkus
15:12 < yrodiere> ok I'll try to remember
15:12 < gsmet> that's pretty much it for me
15:12 < yrodiere> worst case you'll get an email on hibernate-dev :)
15:12 < gsmet> usually, you ping me to review the blog post :)
15:12 < yrodiere> right :)
15:12 < gsmet> #topic Progress Koen
15:13 < koentsje> i have finished the integration of quarkus 0.15.0 in the
eclipse tools
15:13 -!- sfikes [~sfikes(a)c-69-246-28-50.hsd1.ms.comcast.net] has joined
#hibernate-dev
15:13 < koentsje> i worked on an implementation for a quarkus run/debug
configuration for running quarkus inside eclipse
15:14 < gsmet> good thing I released 0.16.0 yesterday then :]
15:14 < koentsje> this is not working yet, so i need to continue to work on
this
15:14 < koentsje> @gsmet, yes this is for next sprint ;)
15:15 < koentsje> i had to do some maintenance on the hibernate tooling
15:15 < koentsje> i released hibernate tools 5.4.3.Final in lockstep with
orm 5.4.3.Final
15:15 < koentsje> did the integration of 5.4.3.Final in JBoss tools
15:16 < koentsje> and this is about it so i miserably failed to work on the
continuous integration
15:16 < gsmet> #topic Next 2 weeks Koen
15:17 < koentsje> integration of the 0.16.0 release in quarkus eclipse tools
15:17 < koentsje> look at some bug reports for hibernate tools that came in
recently
15:18 < koentsje> continue the quarkus run/debug configuration
15:18 < koentsje> elaborate on the reddeer automatic integration tests
15:19 < koentsje> and finally, the continuous integration of the quarkus
eclipse tooling
15:19 < koentsje> thanks
15:19 < gsmet> thanks!
15:19 < gsmet> #topic Progress Yoann
15:20 < yrodiere> First, I worked on making Search work properly in Quarkus
15:20 < yrodiere> I had to make Hibernate Search 6 work with ORM bytecode
enhancement enabled,
15:20 < yrodiere> since Quarkus enables that by default
15:20 < yrodiere> It looks like it works now... I don't know how well, but
at least it's better than it used to be :)
15:20 < yrodiere> Guillaume reported a few issues with Search in Eclipse,
so I had to fix the code so that ECJ (the Eclipse compiler) was happy
15:20 < yrodiere> I also added a step to our Jenkins CI job to build with
ECJ in headless mode
15:20 < yrodiere> so that next time we don't have to wait for Guillaume to
know something is wrong :)
15:21 < yrodiere> And since *someone* insisted, I also reported several ECJ
bugs.
15:21 < yrodiere> Not sure they will fix them anytime soon, but I guess it
was worth a shot.
15:21 < gsmet> I'm becoming more useless every day :/
15:21 < yrodiere> And yeah, it's in our best interest, I know :)
15:21 < fax4ever> :)
15:21 < yrodiere> After that, we released Search 6.0.0.Alpha6, which is the
version used in Quarkus at the moment
15:22 < yrodiere> (yay!)
15:22 < yrodiere> Next, I tried to make Hibernate Search work in JDK11 in
the modulepath
15:22 < yrodiere> Turns out it didn't work because of a classloading issue
that is present both in ORM and in Search
15:22 < yrodiere> I submitted a PR to fix that in ORM as a first step, it's
pending review
15:22 < yrodiere> I have everything ready to make Search work in the
modulepath, but I need this ORM fix to be merged and released firsst
15:22 < yrodiere> well, except the lucene backend of course
15:23 < yrodiere> Lucene is lightyears away from working in the modulepath
15:23 < yrodiere> While I was on ORM, I also submitted a PR to add support
for JPA criteria on stateless sessions
15:23 < yrodiere> which will be necessary sooner or later, since we use
Hibernate criteria in Search on stateless sessions,
15:23 < yrodiere> and Hibernate Criteria will be removed in ORM 6 in favor
of JPA criteria
15:23 < yrodiere> I also upgraded Search to Hibernate ORM 5.4.3.Final
15:23 < yrodiere> There was an incompatibility, which was easily worked
around but still annoying
15:23 < yrodiere> So I set up CI jobs that build search against the latest
ORM snapshot every day.
15:23 < yrodiere> Next time I may be able to catch the problem sooner.
15:24 < yrodiere> I also upgraded Search to Elasticsearch 7.1.
15:24 < yrodiere> Everything went just fine, for once.
15:24 < yrodiere> Apart from that, I worked on a few clean-up PRs
15:24 < yrodiere> And most importantly, on exposing index write APIs in the
Hibernate Search ORM integration
15:24 < yrodiere> It's almost done, I'm writing the documentation and will
submit a PR soon
15:24 < yrodiere> Next two weeks...
15:24 < gsmet> #topic Next 2 weeks Yoann
15:24 < yrodiere> After I'm finished with the write APIs, I intend to
submit a fix for a problem we noticed with Fabio in Elasticsearch
15:25 < yrodiere> Essentially they store some numbers with 64-bit
precision, but they parse them as a double (~53-bit precision) when we send
values through the rest API
15:25 < yrodiere> That's a problem for our support for indexing BigDecimal,
in particular.
15:25 < yrodiere> because what good is a BigDecimal if you only get the
precision of a double?
15:25 < fax4ever> good question
15:26 < yrodiere> Then I intend to write a bit of documentation
15:26 < yrodiere> Most likely referencing the various predicates, sorts and
projections
15:26 < gsmet> \o/
15:26 < yrodiere> that'll be fascinating, I'm sure :)
15:26 < yrodiere> And when I'm done I'll try to fix some of the remaining
problems of the ORM mapper
15:26 < yrodiere> such as support for document IDs that are not the entity
ID
15:26 < yrodiere> or initialization of lazy collection/map/array properties
when indexing (if necessary)
15:26 < yrodiere> That's all from me!
15:27 < gsmet> ok, thanks
15:27 < gsmet> #topic Other topics
15:27 < gsmet> Monday is a holiday in France
15:28 < koentsje> also in belgium \o/
15:29 < fax4ever> not in Italy :)
5 years, 1 month
Doing some maintenance on ci.hibernate.org
by Sanne Grinovero
Hey all,
today I'll be restarting the server running ci.hibernate.org, and
installing some updates.
You can login as usual, but it might ask your permission again to
allow github to share your profile with the ci server.
I will need to repeat such operation multiple times this week, please
be patient.
Thanks,
Sanne
5 years, 1 month
