In the interest of questioning everything, just to make sure we are all on
the same page, Hibernate's support for native SQL queries currently
recognizes named parameters, positional parameters as well as JDBC-style
JPA only defines support for "JDBC-style parameters" as valid for native
It is assumed that for native queries the parameters themselves use the SQL
syntax (i.e., “?”, rather than “?1”).
Furthermore Hibernate does not support a native query using both positional
parameters and JDBC-style parameters in the same query because it causes a
non-determinism wrt the positions.
I assume we want to continue to support that full complement of parameter
types, with the positional/JDBC-style caveat.
Further I assume we will hook up the use of any non-JDBC-style parameters
in with the "strict JPA compliance" checking and throw an error when
Anyone have objections to any of that?
I implemented the approach that I proposed in the issue and a test in
It detects left joins with join tables that use the target table alias.
The join table is replaced with a subquery and the WITH clause is moved
to the join of the subquery.
Is there any way we can get HipChat Plus licenses for the team from
The free client provides access only to a limited part of the chat history,
making it impossible to search for discussions discussed more than a few
That's starting to be a real problem now that we've been using HipChat for
a while and early discussions begin to fall below the threshold of being
available in the free version.
I don't know whom to reach out to at Atlassian, otherwise I'd do it myself.
I'd hope they are supportive given that we can use JIRA at all for free,
I just happened to build Hibernate ORM's latest "master" on a clean
machine and this is how the build log looks like:
No compatible daemons found:
- an idle daemon with different JVM constraints can't run this build
Starting a new Gradle Daemon for this build: subsequent builds will be faster
I'm not having any specific failure, but it seems very suspicious that
the build is needing to download hibernate-core at the very beginning
of the build?
I'm not familiar enough with ORM's build scripts to investigate myself
but I suspect some dependency order needs to be cleaned up, or you
might be including some side-effects from previous builds.
I'm trying to build the 5.1 branch with "./gradlew publishToMavenLocal" but
I get the following error:
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Starting AnimalSniffer checks using [java16-1.0.signature] against
Undefined reference: int
Undefined reference: int
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':hibernate-ehcache:compileJava'.
> Signature errors found for SourceSet main against java16-1.0.signature.
Verify errors and ignore them with the proper annotation if needed.
Run with --stacktrace option to get the stack trace. Run with --info or
--debug option to get more log output.
Total time: 23.979 secs
Can you please help me?
Public PGP Key at:
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611
While reviewing and adding a test case for
I realized that if we enable the AvailableSettings.DISCARD_PC_ON_CLOSE
the database connection gets closed when the EntityManager is closed, while
the EntityTransaction status remains ACTIVE.
I noticed that in the call:
But this method is no-op and deprecated as well.
Is this behavior intended? If the database connection was closed, at least
for RESOURCE_LOCAL, on most RDBMS engines, the underlying transaction gets
rolled back as well.
For JTA, the connection might still be open and allocated to the current
user since the TM controls when the resources are to be released.
Should we leave this behavior like that?
This is a follow-up of https://github.com/hibernate/hibernate-ogm/pull/767 .
So, in the PR, I commented the following test:
(the "ManyToOneGlobalTest>" part is important)
The test is a Redis one but the issue is a general one.
When running under the ManyToOneGlobalTest umbrella, the associations
are created as separate documents.
The behavior of the test is the following:
=== Creation phase
Create a SalesForce with 2 SalesGuys associated.
The association is managed by SalesGuy.
It creates 4 documents:
SalesForce1_SalesGuy navigational information
=== Let's delete the SalesForce1 entity
It removes the SalesForce1 document (note that SalesGuy.salesForce has
a @NotFound(action = NotFoundAction.IGNORE) annotation).
So we end up with having:
SalesForce1_SalesGuy navigational information 
=== Then we delete the 2 SalesGuy
-> SalesForce_SalesGuy navigational information updated
-> SalesForce1_SalesGuy navigational information removed as it is empty 
In , we still have the navigational information for SalesForce1 <->
With the new grouping infrastructure, I don't save every operation to
the datastore as it's currently done. I have to store the Association
object somewhere to keep track of the association state so I store it
in OgmEntityEntryState in a Map<String, Association>, the key being
the role of the association, just next to the Tuple which has the same
purpose. It works perfectly well except that when we arrive at ,
the OgmEntityEntryState for SalesForce1 is gone as the entity has been
removed in  so I can't access the OgmEntityEntryState of the entity
and so the association document is not removed (and thus the test
fails as it checks there isn't any entity/association left).
Gunnar proposed the idea of storing the inverse Associations in the
OgmEntityEntryState of the association owner. It's indeed one way to
solve the issue.
The issue with this approach is that we need to have the association
owner when we create the AssociationPersister and, while it's not a
problem for most of the cases, I don't see how I can do it in
OgmLoader#getResultSet. I posted a WIP patch here: