When not being logged into JIRA, I am getting an error when opening
the "Activity" view in JIRA, e.g. at
"This gadget cannot be displayed on your dashboard. This could be
due to a licensing problem or an application error."
Anyone knows whether/how this can be fixed on our side? Or is it
something for which we need to reach out to Atlassian to get it fixed?
As mentioned in our last discussion, I explored adding Travis support to
The diff is here:
(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
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:
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.
It seems like a good step to tackle the SEO optimization problem is to
offer a "curent" link in our site to point to the latest docs.
That's how PostgreSQL and Spring do it and once this link is indexed by
google, it will always render the latest version of the docs:
MySQL does not offer this option and when googling something about MySQL,
there's a big chance of getting a 5.0 page instead of 5.6 or 5.7.
I think we should add a "current" "symbolic link" in the docs folder:
and when we publish a new version, we need to go to Google Webmaster Tools
(at least that's how I do it on my blog) and ask google to reindex that
particular "current" link. I guess that could be automated too.
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
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.
HHH-9548 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...
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.
Per HHH-10487, I want to add an @Incubating annotation to mark APIs that
are still incubating. Specifically, what do y'all think of
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:
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.
The guys at Plumbr wrote an article about how MySQL JDBC warnings are
handled by Hibernate:
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?