You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 #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 Integerexpr().prop("n").mult().val(0.5)
// Compiles to Expression of type Integerexpr().val(9).mult().val(0.5).model()
With PostgreSQL, the above expressions, if used in a subquery, compile to:
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).
The text was updated successfully, but these errors were encountered:
homedirectory
changed the title
Hibernate type resolution for EQL operands is incomplete
Hibernate type resolution for EQL expressions is incomplete
Apr 23, 2024
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 #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#hibTypeFromJavaType
ua.com.fielden.platform.eql.meta.EqlEntityMetadataGenerator#getHibernateType
ua.com.fielden.platform.eql.stage2.operands.AbstractSingleOperand2#getTypeHighestPrecedence
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
andFloat
, simply "slipped" by becausethey 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).
The text was updated successfully, but these errors were encountered: