HHH-10999 Array datatypes module

[coladict]

What works:

• Using single-dimensional Object arrays in Entities (no primitive arrays).
• Saving arrays through entities through the EntityManager interface.
• Loading arrays into entities through the EntityManager interface.
• Tested under PostgreSQL.

What doesn't work:

• Table creation without setting columnDefinition on the javax.persistence.Column annotation.
• Passing null in the position of an array in manually written queries (bug is in Postgre server, not Hibernate).
• Using arrays of primitives, which are optional for JDBC drivers, even when arrays are supported.

TODO list without changes to core:

• Test more types
• Determine which types should be contributed, and which should be optional.
• Test on HyperSQL (only other database listed in the test suite that supports arrays).
• Annotate the tests to only use compatible dialects or features

TODO list with core changes:

• Add dialect feature checks for arrays to use for testing.
• Change StandardTableExporter to recognize and use arrays when desired.
• Use option to determine to use legacy model (default) or new array model.

[vladmihalcea]

Thanks for the Pull Request. Did you sign the CLA?

[vladmihalcea]

Good work. For PostgreSQL, it works nicely. I tried it also on H2, Oracle, SQL Server and MySQL and the main issue that the JDBC drivers do not implement the createArrayOf method.

Since we are reworking the types for 6.0, we need to take into consideration arrays as well, but first, we need to see how to address them in a generic fashion.

If we are to add support for ARRAYS. we need to cover most database systems in order to add the TypeDescriptors in the generic package.

[coladict]

Unless it has changed and invalidated old signatures in the past 8 months or so, I have signed it.
But Oracle, MSSQL and MySQL do not support have native array types, unless they maybe they internally convert it to text, blobs or something like that.

I've thought of several bugs in the current PR, relating to multi-dimensional javatype registration and that of primitive arrays, but their time will probably come with 6.0.

Meanwhile, we can iron this out as an optional module for 5.x.
As of right now the only potential bug in available functionality, that I can think of, is maybe the Mutability plan is wrong. Btw, shouldn't it really be called Immutability plan?

[coladict]

I made some changes to the tests to be compatible with HyperSQL and discovered bugs that need addressing. Currently three tests fail and it's not the fault of the tests.
Datatypes using the java.time package can only be used in Postgres JDBC 4.2 driver 9.4.1208 or newer. Some conversion would obviously be required and the current Generic solution is not sufficient to handle their conversion to java.sql types that are more compatible.

[coladict]

Currently known problems/tasks:

• ArrayTypes misuses LiteralType.
• Java 8 java.time types must be converted to java.sql.Date, java.sql.Time and java.sql.Timestamp accordingly for compatibility with HyperSQL and older PostgreSQL JDBC drivers.
• Write more (and more understandable) comments. Write documentation.
• GenericArrayTypeDescriptor's toString(value) and fromString(value) may not work properly. Needs testing.
• The MutabilityPlan needs testing.

[coladict]

It's almost ready. Currently one test fails, because of an error in hibernate-core, in a part that had been previously untested. It can be somewhat fixed with this patch.

diff --git a/hibernate-core/src/main/java/org/hibernate/type/descriptor/java/LocalDateJavaDescriptor.java b/hibernate-core/src/main/java/org/hibernate/type/descriptor/java/LocalDateJavaDescriptor.java
index d911e0f..f640c53 100644
--- a/hibernate-core/src/main/java/org/hibernate/type/descriptor/java/LocalDateJavaDescriptor.java
+++ b/hibernate-core/src/main/java/org/hibernate/type/descriptor/java/LocalDateJavaDescriptor.java
@@ -42,7 +42,7 @@ public class LocalDateJavaDescriptor extends AbstractTypeDescriptor<LocalDate> {

    @Override
    public LocalDate fromString(String string) {
-       return (LocalDate) LocalDateType.FORMATTER.parse( string );
+       return LocalDate.parse( string, LocalDateType.FORMATTER );
    }

    @Override

An analogous solution will probably have to be applied to the other Java 8 time types, because the same mistake is in all of them.

There are some warnings about type registration on start-up that also need to be looked at.

[jwgmeligmeyling]

It seems primitive arrays are since supported in pgjdbc: pgjdbc/pgjdbc#887

[beikov]

Superseded by #3799