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
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:
formulawit0_.id as id1_0_,
formulawit0_.DISCOUNT_CODE as DISCOUNT_CODE2_0_,
formulawit0_.DISCOUNT_VALUE as DISCOUNT_VALUE3_0_,
ROW_NUMBER() OVER( PARTITION
SIGN(formulawit0_.DISCOUNT_VALUE) DESC ) as formula0_
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?
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>
I get similar results when trying this as a manual test in 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
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 (184.108.40.206) 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.
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
> 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>
> > 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
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:
Hibernate NoORM Team
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
15:06 < fax4ever> defined on a field on the sort missing value provied at
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>
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
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
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
15:12 < fax4ever> Like the one to handle the case where a GeoPoint field is
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
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
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,
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
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
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
15:25 < yrodiere> both the javadoc and the reference documentation
15:25 < yrodiere> It took way longer than I initially imagined, but now we
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
15:27 < yrodiere> Some changes are not very impacting to users, such as
renaming some DSL interfaces (users don't reference these types directly
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
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> :)
We just published two maintenance releases for the Hibernate Search:
5.11.2.Final and 5.10.6.Final. These releases mainly upgrade Hibernate
Search to the latest compatible Hibernate ORM versions and fix several
issues with the Elasticsearch integration.
Find more detailed information on our blog:
Hibernate NoORM Team
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
15:03 -!- rvansa [rvansa@nat/redhat/x-xhodhuijvfvkddtt] has joined
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
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
15:05 < fax4ever> 3. Add a test for indexEmbedded depth parameter shared
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
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
15:06 < fax4ever> replacement for sorting,
15:06 < fax4ever> even if the field has a String type and the backend is
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
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
15:13 -!- sfikes [~sfikes(a)c-69-246-28-50.hsd1.ms.comcast.net] has joined
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
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
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
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
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
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
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
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
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
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,
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
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
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 :)
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