New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PostgreSQL: Strict typing requires explicit type casts #2213
Comments
…formation Field `dbVersion: DbVersion` was removed due to it being inferable from a `Dialect` instance. This change provides access to more information about the active SQL dialect. For example, we get access to Hibernate's knowledge of SQL type names, which is required to solve the problem described in this issue.
* Increase immutability * Be concise * Add documentation and comments
Needed additional code to overcome limitations of Hibernate
Further research revealed that the type mismatch problem is more general and is not limited to the UNION case only. Nevertheless, instead of tackling the problem in its full generality, it might be sufficient to cover the following cases:
|
… literal null Programming with nulls is undesirable.
|
This is to avoid 2 placeholder types from different contexts being accidentally considered equal.
- Add documentation - Implement toString() methods to facilitate reasoning - Reduce visibility of PropType constructor (static method should be used)
…ions This is achieved by casting the NULL to the type of the other operand
In general, this approach of asserting that an exception is thrown is far from the best because it ignores potential exceptions that may be thrown for unexpected reasons. Being more specific and expecting only a certain type of exceptions doesn't work either since the exception gets rethrown at some higher level, effectively becoming a cause of another exception. Should we be making assertions about the stack trace at this point? I don't think so.
The converstion itself was also slightly modified: * Use an unbounded VARCHAR by default instead of setting the limit to 255 chars, which has no clear basis. * Optimise for Integers by limiting the VARCHAR length to 10 chars.
And for all DB back-ends, not just PostgreSQL and SQL Server.
… with string type Wheels of EQL3 are turning so the workaround is no longer needed. Moreover, we can now be confident that the null type is never taken for the string type by mistake, which is vastly important for PostgreSQL.
* Use a sealed interface with inner classes to facilitate pattern matching with switch. * Instead of inserting type casts conditionally, depending on the database, always insert them. The conditional approach likely relied on implicit type conversion performed by some DBs. Although, endAsInt() worked correctly only with H2, which had gone unnoticed as its usage has been scarce.
This assertion reports list contents in case of failure.
Description
A problem with execution of EQL queries against PostgreSQL has been identified.
Queries that get compiled to the
UNION
SQL statements are affected. This includes:Query sources that are composed of other queries (aka nested
SELECT
).Relevant classes:
ua.com.fielden.platform.eql.stage3.sources.Source3BasedOnQueries
The core of the problem stems from the way Type Resolution for UNION is designed in PostgreSQL.
In short:
unknown
, resolve as typetext
.For example,
is represented by the following S-expression:
which leads to
ERROR: UNION types text and integer cannot be matched
.This problem can be solved by inserting explicit type casts where there are multiple unions.
Considering the above example, the following version would work correctly:
Insertion of explicit type casts could be achieved by performing additional analysis during the
transformation of EQL into SQL.
Expected outcome
UNION statements for PostgreSQL are generated with explicit type casts inserted where necessary.
The text was updated successfully, but these errors were encountered: