[Search] Travis support
by Guillaume Smet
Hi,
As mentioned in our last discussion, I explored adding Travis support to
Search.
The diff is here:
https://github.com/gsmet/hibernate-search/commit/cbd2c1fff05532974823da57...
(yes it's short but it was a long road :))
I had to raise a bit the JGroups timeout for one test and had to fix
TestRunnerStandalone
so that it effectively uses the configuration from the profile (this change
is not specific to Travis and should be committed anyway).
The result is here:
https://travis-ci.org/gsmet/hibernate-search
What I like in Travis:
- The CI configuration is code and is versioned
- Parallelization with a *lot* of resources
- The ability to build a test matrix very easily
- Complete isolation as each build is run in its own Docker container
What is less cool:
- The only way to get the logs is to ship them to AWS S3 - that said, I did
it and it's pretty straightforward as it's well integrated (I commented out
the code in the .travis.yml for now)
- It might seem less flexible as we are depending on the Travis
infrastructure (for instance, I created a ticket to ask for the support of
JDK 9: https://github.com/travis-ci/travis-ci/issues/5520) but in fact, you
can do whatever you want: see https://github.com/Blazebit/blaze-persistence
.travis.yml file for a comprehensive example
So if we move to Travis, I think the regular builds could run on Travis and
we could keep Jenkins for specific ones (deploy/release).
I'll take a look at OGM tomorrow. Travis supports out of the box most of
the NoSQL databases (https://docs.travis-ci.com/user/database-setup/) so
I'm pretty curious to see how it goes.
Thoughts?
--
Guillaume
8 years, 8 months
JSR 354 - Money and Currency
by Steve Ebersole
So it sounds like JSR 354 may not be included in Java 9. Do we still want
to support this for ORM 5? I am not sure if "moneta" requires Java 9...
8 years, 9 months
SQM and Query#getReturnTypes
by Steve Ebersole
There are a few reasons I want to remove Query#getReturnTypes. At least in
its current form. Currently it simply returns the Hibernate Type(s) that
the query will return.
One of the big reasons I want to remove this method is that it is simply
not expressive enough to handle some not-so-edge-cases like dynamic
instantiation queries (we'd have no idea about a Type for the
instantiation).
So the main question is whether to simply remove that method or whether
some representation of the Query return(s) is valuable. If this
information is deemed valuable, the idea would be to develop a contract
that caters to both "normal selections" and dynamic instantiations.
8 years, 9 months
HHH-9548 - stored procedures and null parameter values
by Steve Ebersole
HHH-9548[1] presents an interesting conundrum in terms of how to handle
null parameter values in regards to stored procedures and specifically in
terms of any argument defaults that might be defined on the database. At
the moment our support decides to not pass along the null in the desire to
not "over power" any defined argument defaults - if we pass the NULL, the
database would use that rather than the defined argument default.
Essentially it is one of those 50/50 calls. I started a discussion on the
JIRA, but please add your thoughts...
[1] https://hibernate.atlassian.net/browse/HHH-9548
8 years, 9 months
5.1 tentative release date
by Steve Ebersole
Just a heads up that I tentatively set Jan 27th as the release date for
5.1. Please let me know if that does not work for anyone. Also please
keep that date in mind if there is anything you want to get into 5.1.
8 years, 9 months
[Search] ElasticSearch - DSL
by Guillaume Smet
Hi all (and especially Gunnar),
I dug a bit in your ElasticSearch work today as I wanted to give a try to
the facet implementation and I was wondering if maybe we should use the
ElasticSearch DSL to build the queries instead of building raw JSON strings.
I experimented here:
https://github.com/gsmet/hibernate-search/commit/18737f720a1200b125adf2bb...
I think the code is a bit clearer now. I haven't changed all the queries in
the tests so I kept the fromJson method in ElasticSearchQueries but I think
we should remove it and rely on the DSL: I'll wait for your opinion as you
might have had a very good reason to not use the DSL.
One of the challenges waiting for us will be to transform the Lucene
Filters into proper Elastic Search queries.
--
Guillaume
8 years, 9 months
JDBC warnings performance matter
by Vlad Mihalcea
Hi,
The guys at Plumbr wrote an article about how MySQL JDBC warnings are
handled by Hibernate:
https://plumbr.eu/blog/io/how-we-accidentally-doubled-our-jdbc-traffic-wi...
I remember seeing this issue on StackOverflow too and I was curious if you
want to tweak it a little bit.
I also agree that relying on the log levels to prevent fetching warnings
might come as a surprise to many users and we should document this behavior.
We could also have a hibernate.jdbc.log.warnings boolean property to
control whether we want to log those warnings or not.
This way, if users set the logger level to WARN, they will see the logs
generated by the framework stack and the JDBC warnings will be logged only
if this configuration property is true.
What do you think?
Vlad
8 years, 9 months
