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
1 day, 3 hours
Releases and CI setup
by Guillaume Smet
Hi,
So, as expected, I'm not very happy with the new CI setup when doing
releases.
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)
--
Guillaume
7 years, 5 months
HSEARCH-3000 Pick Jigsaw Automatic Module names for all published modules
by Sanne Grinovero
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 [1].
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:
Engine module:
- org.hibernate.search.engine
ORM integration module:
- org.hibernate.search.orm
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
future ]
Elasticsearch integration module [hibernate-search-elasticsearch.jar]:
- org.hibernate.search.elasticsearch
Elasticsearch / AWS security integration:
[ no automatic module name: no public API ]
Serialization / Avro
[ no automatic module name: no public API ]
WDYT?
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
coming, ..).
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.
Thanks,
Sanne
[1] http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html
7 years, 5 months
How to deal with a constant in CriteriaQuery
by Gail Badner
SQL Server defines a function:
DATEDIFF ( datepart , startdate , enddate ) [1]
(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?
Thanks,
Gail
[1]
https://docs.microsoft.com/en-us/sql/t-sql/functions/datediff-transact-sq...
7 years, 6 months
Analyzing the ORM testsuite
by Sanne Grinovero
Hi all,
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
real issue.
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
org.hibernate.test.criteria.CriteriaLockingTest >
testSetLockModeDifferentFromNONELogAWarnMessageWhenTheDialectUseFollowOnLockingIsTrue
FAILED
org.junit.runners.model.TestTimedOutException
org.hibernate.test.criteria.CriteriaLockingTest >
testSetLockModeNONEDoNotLogAWarnMessageWhenTheDialectUseFollowOnLockingIsTrue
FAILED
java.lang.Exception
org.hibernate.test.criteria.CriteriaLockingTest >
org.hibernate.test.criteria.CriteriaLockingTest FAILED
java.lang.Exception
org.hibernate.test.locking.warning.LockNoneWarmingTest >
org.hibernate.test.locking.warning.LockNoneWarmingTest FAILED
java.lang.Exception
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
context.
Thanks,
Sanne
7 years, 6 months
