Don't try to duplicate the logic from
org.hibernate.hql.internal.ast.tree.FromElementType#toColumns(java.lang.String, java.lang.String, boolean, boolean)
in other classes, it's complex enough and already seems to handle all
the cases we might encounter.
In this specific case, we want the table name to be used to qualify
column names, because the target table doesn't have any alias (it's not
supported by every version of every RDBMS), and not qualifying columns
at all may lead to a confusing statement, in particular if tables
referenced in the subquery contain columns with the same name.
Since we use aliases for every other table in the query, referencing the
table should not lead to any conflict.
We don't need to run them with all our dialects: we just need to check
the mechanism works correctly.
At least TransactionExceptionHandlingTest fails with MariaDB so better
be safe.
DB2 has no issue with reserved keywords in the CREATE TABLE clause so
let's skip these tests.
There is very little value to test them for every dialect anyway.
DB2 converts the numeric type to decimal and returns Types.DECIMAL for a
numeric. We change the type name used so that we have a match when
comparing the type names as last resort.
While Javassist only generates one proxy as the name is stable,
ByteBuddy uses random names and thus generates a new proxy for every
call, leading to the generation of 18 different proxies for the other
test of the test class.
We can't do better than using a volatile/synchronized pattern as the
Component is not fully initialized in the constructor.
Maybe we could take the risk of admitting that the getType() method is
called at least once before we pass the element to a multi-threaded
environment but that's a bet I don't want to take alone.
In a shared containerized environment like Travis, it's not obvious that
the second read will be faster than the first one.
And indeed, the test often fails.
There's no real value in testing that, we are just testing I/O, and the OS
cache.
Bytecode enhancement is harder to test, so I didn't add a test for that,
but since bytecode enhancement dirty checking is called exactly at the
same place, if one works, the other should, too.
SessionImpl.initQueryFromNamedDefinition calls its super implementation
AbstractSharedSessionContract.initQueryFromNamedDefinition, which
already does a lot of the work performed in
SessionImpl.initQueryFromNamedDefinition.
The only difference is that SessionImpl uses hints to set values on the
query, whereas AbstractSharedSessionContract uses direct calls to
setters. But that should produce the same result, since setHint() just
delegates to the setters.
Only one thing was done in SessionImpl but not in
AbstractSharedSessionContract: lock mode handling.
I left it in SessionImpl since moving it to the superclass would also
affect other subclasses such as StatelessSession or OGM sessions, and I
certainly don't want to change any behavior without further
investigation.
Guenther Demetz
Yoann Rodière
Martin Simka
Jan-Willem Gmelig Meyling
Alvaro Esteban Pedraza
Sanne Grinovero
Chris Cranford
Karel Maesen
Guillaume Smet
Gail Badner
nikowitt
Ulrich Bestfleisch