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.
Force column read/write to use non-nationalized driver methods since the driver does
not implement the nationalized equivalents.
(cherry picked from commit 005d5b7c74)
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.
Andrea Boriero
Yoann Rodière
Martin Simka
Gail Badner
Chris Cranford
Guillaume Smet
nikowitt
Ulrich Bestfleisch