During compilation of EQL queries, each expression is assigned a type through the process of type
inference. The domain of inferrable types, however, has been observed to be incomplete, i.e.,
there exist some types that aren't recognised by the type inference algorithm.
When a type of an expression is unrecognised, it is up to the JDBC driver to resolve its type. And
if the driver cannot resolve it either, then it's the responsibility of the database engine.
This characteristic of the current state of the type inference algorithm has been identified solely
due to the changes introduced in https://github.com/fieldenms/tg/issues/2213. Specifically, due to
explicit type casts inserted at the SQL level, which rely on correctness of type inference.
For example, the following expression is resolved to be of an integer type, while its expected type
is a floating-point numeric (double/float).
// property n has type Integer
// Compiles to Expression of type Integer
expr().prop("n").mult().val(0.5)
// Compiles to Expression of type Integer
expr().val(9).mult().val(0.5).model()
With PostgreSQL, the above expressions, if used in a subquery, compile to:
CAST ((n * 0.5) AS integer)
CAST ((9 * 0.5) AS integer)
This results in the loss of the number's fractional part.
The type inference algorithm needs to be improved so that all data types accepted by EQL are taken into account.
It should be understood that this issue affects not only PostgreSQL, but anything relying on
correctness of type inference, hence it is more of a fundamental problem.
Expected outcome
Hibernate type resolution algorithm in EQL covers all possible data types.
Notes
One hypothesis is that some data types, such as Double and Float, simply "slipped" by because
they aren't in the set of supported types of entity properties. Nevertheless, they are perfectly valid,
and actually required, for intermediate values of expressions (results of which are, ultimately,
assigned to entity properties).
Description
During compilation of EQL queries, each expression is assigned a type through the process of type inference. The domain of inferrable types, however, has been observed to be incomplete, i.e., there exist some types that aren't recognised by the type inference algorithm.
When a type of an expression is unrecognised, it is up to the JDBC driver to resolve its type. And if the driver cannot resolve it either, then it's the responsibility of the database engine.
This characteristic of the current state of the type inference algorithm has been identified solely due to the changes introduced in https://github.com/fieldenms/tg/issues/2213. Specifically, due to explicit type casts inserted at the SQL level, which rely on correctness of type inference.
For example, the following expression is resolved to be of an integer type, while its expected type is a floating-point numeric (double/float).
With PostgreSQL, the above expressions, if used in a subquery, compile to:
This results in the loss of the number's fractional part.
The type inference algorithm needs to be improved so that all data types accepted by EQL are taken into account.
The following locations should be of interest:
ua.com.fielden.platform.eql.retrieval.EntityResultTreeBuilder#hibTypeFromJavaTypeua.com.fielden.platform.eql.meta.EqlEntityMetadataGenerator#getHibernateTypeua.com.fielden.platform.eql.stage2.operands.AbstractSingleOperand2#getTypeHighestPrecedenceIt should be understood that this issue affects not only PostgreSQL, but anything relying on correctness of type inference, hence it is more of a fundamental problem.
Expected outcome
Hibernate type resolution algorithm in EQL covers all possible data types.
Notes
One hypothesis is that some data types, such as
DoubleandFloat, simply "slipped" by because they aren't in the set of supported types of entity properties. Nevertheless, they are perfectly valid, and actually required, for intermediate values of expressions (results of which are, ultimately, assigned to entity properties).