* [OPENJPA-2883] test for the issue
* [OPENJPA-2883] 'supportsAutoAssign' is turned OFF when 'useTriggersForAutoAssign' is ON
* Assert is improved
* Warning is logged when conflicting options are selected by user
* Build should be fixed
* EntityManager is properly closed
Boolean is the correct return value.
This should actually have been returned for all dictionaries.
The problem is that we always only return the _internal_ representation.
The reason is because CASE/WHEN can be used to return values, but also as subquery.
Now imagine a database uses 0 and 1 for false and true. If CASE/WHEN is used
as subquery we really have to return 0/1 (number) because otherwise the WHERE clause
would not fit. When not executing the query on a Entity, we do not know the target type.
So there is probably no way we can later do a BooleanRepresentation call to switch to boolean.
And this would also break existing applications.
The sorting behaviour of characters )'a..z, A..Z') and
numbers (0..9) is depending on NLS. For e.g. german NLS
in Oracle 0 comes only after z, so we get esub1,esub2,e1,e2
while on some other databases we get e1,e2,esub1,esub2.
Easy fix is to have the second position also a Character to
force a distinctive order over all different databases and
settings.
Raw did loose the internal type. Once 'interned' to Raw the type was always String.class.
And this broke quite a few return type situations in quite a nasty way.
On MariaDB and MySQL the allowed size of compound primary keys is very limited.
This very test will not work with them. It's nothing JPA can heal, users
are restricted and have to work around it.
* java.sql.Time parameters must be on date Jan 1st 1970, otherwise MariaDB won't find anything in the DB
* from > 10 onwards MariaDB supports up to 6 fractions in TIME as well.
From the MS SQL Server documentation, it looks like JDBC4 drivers changed the behaviour.
"The next call to a getter method implicitly closes the stream".
Thus storing the InputStream in an entity will always result in a closed stream.
Since JDBC4 all drivers should behave that way actually.
And this is a sane way to prevent file handle leaks.
UnaryOps should use the DBDictionary to resolve the requested data whenever possible.
Previously we always have been requesting JDBC native types when doing max(), min(), etc.
But this returns values of types which we potentially cannot handle.
Thomas Andraschko
Maxim Solodovnik
Will Dazey
Jean-Louis Monteiro
Mark Struberg