So, as expected, I'm not very happy with the new CI setup when doing
The issue is that each commit to ORM triggers at least 5 jobs (5.0, 5.1,
5,2, master-h2, master-check) which takes all the slave bandwidth we have.
Note that I'm talking of ORM because it's where the issue is the most
prominent but I'm pretty sure I would have the same issue with HV,
considering we now have quite a few maintenance branches, except that the
HV builds are faster.
So I would say:
- either we fix the issue we have with all the branches being tested for
each commit that we discussed numerous times
- or we need a mechanism to start specific slaves for releases - but I'm
not sure it's fast enough tbh
Because it's really annoying. Especially when you have to run your release
job 3 times in a row due to SF.net issues...
Releasing is already a tedious process, let's not make it even more tedious.
(yeah I know it's not the first time I complain about it but it's really
worse than it was before)
Picking automatic module names for Hibernate Search isn't going to be
straight-forward as our two main jars (hibernate-search-engine &
hibernate-search-orm) suffer from split package among them.
We can't really fix the split package problem without breaking all
users, so if we want to consider that, we can debate it but that will
need to happen at another round as we're doing a minor release, so
let's focus on:
# Which names to pick
# Should we pick the names at all
# Which modules should have a name
For a great background on the possible strategies and pitfalls I
recommend reading Stephen Colebourne's blog on this subject .
He persuaded me there are good reasons to use the "reverse DNS, the
top level package", however since we have the split package problem we
can't simply go with that.
Still, we can respect the principles he recommends with a small
variation. It's fair to assume that the `org.hibernate.search` prefix
is "ours"; since the nature of the suggestion is focused on making
sure there are no misunderstandings in the community about which names
you can choose - as there is no central authority making sure module
names aren't clashing - we should be fine within Hibernate projects
with any `org.hibernate.X` prefix, as long as we coordinate and reach
an agreement on this list.
So, I propose we use:
ORM integration module:
JGroups, JMS backends:
[ no automatic module name ? Excepting some "guidelines" in the JMS
module, these are not public API so nobody would benefit from it -
also we think we might want to phase out the name "backend" in the
Elasticsearch integration module [hibernate-search-elasticsearch.jar]:
Elasticsearch / AWS security integration:
[ no automatic module name: no public API ]
Serialization / Avro
[ no automatic module name: no public API ]
We could also pick names for the ones which I've listed as "no public
API" but I see no point: as we're only assigning an "Automatic Module
Name" we won't be able to explicitly state that the other modules
depend on these. So nobody will use them, and things are a bit in flux
anyway in this area because of Hibernate Search 6 plans.
Another optional altogether: since we have split packages which we'll
have to resolve before we can actually transform these into fully
fledged modules, I think an acceptable position is also to say we
won't be publishing any automatic module name yet. Personally I'm
inclined to go with the names suggested above, at least some others
can start making baby steps, even if it's not all there.
# What I don't like:
For one, that the typical application will need to import both
`org.hibernate.search.engine` and `org.hibernate.search.orm`, and
likely more as well (e.g. Elasticsearch API, Lucene API module is
Maybe similar to BOM's today we could publish a module which
statically imports multiple of these, that could be nicer to use but
we risk needing to publish (and document) one for each of a selection
of combinations. So let's not start with such things yet.
SQL Server defines a function:
DATEDIFF ( datepart , startdate , enddate ) 
(This method still needs to be added to SQLServer2012Dialect.)
datepart can be one of a variety of time values, e.g., day, week, year, etc.
On SQL Server (at least) the value for datepart cannot be treated as a
literal (enclosed in quotes) or bound as a parameter.
This causes problems when using DATEDIFF in a CriteriaQuery.
final Expression<Integer> diff = cb.function("DATEDIFF", Integer.class,
cb.literal("day"), ... ).as(Integer.class);
SQL Server throws:
com.microsoft.sqlserver.jdbc.SQLServerException: Invalid parameter 1
specified for datediff.
There is no problem using the function in a query, as long as datepart is
not enclosed in quotes or bound to the query:
"select datediff( day, ... ) from ..."
Is there some way to set a literal value using a CriteriaQuery that will
not ultimately be enclosed in quotes or bound to a query?
I've also been trying to find an integer constant that would be equivalent
to 'day', but haven't had any luck.
Anyone have an idea how this could be done with CriteriaQuery?
I'm trying to analyze the memory usage of current master of Hibernate
ORM; I started looking because of OOM errors on the PostgreSQL
testsuite (as mentioned in another thread).
So far I've seen that Mockito is allocating a "lot of stuff"; I might
be able to improve some things in that area but it's a distraction
from my goal as clearly we use Mockito even when not running the
PostgreSQL backed tests and that seems to run fine. But it's polluting
the data reports so making it hard (and slow!) to verify if there is a
I could use some help to verify some tangential issues though; when
running the testsuite locally it's taking much longer than what I've
been used to see for the same testsuite some weeks ago, and I have
some failures - regularly seeing the same failures.
These are triggered by running a default build, on H2:
> Task :hibernate-core:test
6307 tests completed, 4 failed, 327 skipped
Yet the puzzling point: on ci.hibernate.org I don't see these failures
happening, nor the testsuite time seems to have increased of any
significant amount (it regularly completes in somewhere between 15 and
20 minutes). It takes me more than an hour to get this result on a
machine which would normally complete the testsuite in 8 minutes, and
I got the same 4 failures when re-running it a second time.
Could other developers also please checkout master - specifically at
commit 291d4a3eeaa2ade32a42cfbcad5868b2114c34fe - and let me know if
it works allright for you and if the build time is consistent with the
usual times for your machine? I need to understand what might be
different between my workstation and the CI server.
I might even have some great improvements ready to reduce the
testsuite time, but I'm not comfortable in committing them in this