So during parsing you try to lookup the castTarget and if it can't be
found, just pass through? If you pass it through, what would be the type
of the expression?
I'd like to present an idea I just had. How about we reuse the "TREAT"
function/operator for doing these "casts" to named types. Applying the
operator does not necessarily cause a SQL "cast" i.e. if the expression
is a select item and the JDBC driver supports converting a value to the
desired type automatically, there is no need for a cast. The main
difference to a "cast" function would be, that the expression type will
be set to the desired type, whereas the "cast" function will set the
type to "unknown" i.e. requiring the user to use the treat operator
around the cast. The cast function will then only ever be used for the
pass-through case. Wdyt?
Mit freundlichen Grüßen,
Am 30.05.2017 um 18:00 schrieb Steve Ebersole:
How about this rule then?
// should allow either
// - named cast (IDENTIFIER)
//- JavaTypeDescriptorRegistry (imported) key
//- java.sql.Types field NAME (coded cast synonym - field's value)
//- "pass through"
//- coded cast (INTEGER_LITERAL)
//- SqlTypeDescriptorRegistry key
: IDENTIFIER | INTEGER_LITERAL
On Mon, May 29, 2017 at 11:16 AM Steve Ebersole <steve(a)hibernate.org
Yes, ultimately these need to resolve to SqlTypeDescriptor. So
perhaps we allow both.
What I just want to get out of is the open-ended-ness.
Non-determinism is bad. E.g., like what you just mentioned...
how should the parser understand that "TEXT" `cast(x as TEXT)` is
a database type name versus Java class name versus something
else? Structurally we cannot - one String is syntactically the
same as any other String.
So do we just accept some policy of "well if we don't understand
it we'll just pass it through to the database"? To me that's just
a cop-out. Not to mention that it invariably leaves the door open
to non-portability. If instead we limited this to just Java types
(JavaTypeDescriptorRegistry keys) and JDBC type codes
(SqlTypeDescriptorRegistry keys) we can fully support this in a
portable manner. Now that does lead to a question for databases
which make the silly decision (looking at you pgsql) to map
multiple types to the same JDBC type code.
As much as possible I think we ought to not be relying on the
database to validate these kinds of things. An error from the
database is going to be much less descriptive as to what exactly
is wrong compared to a validation done by Hibernate.
Not sure the correct answer, just some thoughts.
An option is to allow 3 types of cast targets:
1. Java type name we can resolve against the
2. A JDBC type (either by code or name) we can resolve against
3. Any other text we can resolve against the Dialect as a "valid
I'm kind of leery of (3), but if everyone else agrees it is
important to allow that non-portability then I will consider it.
And keep in mind that this is really only needed for databases
like pgsql to handle the multiple types it maps to a single JDBC
type code... all other cases can (and should) be handled by (1)
On Mon, May 29, 2017 at 10:36 AM Christian Beikov
Sounds good, although I guess there might be cases when ONLY this
approach won't work that well.
I am specifically thinking about casts to the various
that are available in the different DBMS. A cast to "String"
most of the time, but we should still have an option to cast
TEXT or whatever other datatype a DBMS offers.
Mit freundlichen Grüßen,
Am 29.05.2017 um 16:17 schrieb Steve Ebersole:
> Currently casting in HQL is under-defined and open-ended
> pretty inconsistent). What does that mean? Well, what is a
> target in HQL? There really is not a defined
> answer to that.
> I'd like to start formalizing the answer to this.
> Specifically, I am thinking this should be defined around
> JavaTypeDescriptor. So that we'd understand any Java type
> with JavaTypeDescriptorRegistry, and specifically any that
> implements `#getJdbcRecommendedSqlType` (using the Dialect
to resolve the
> cast target in the generated SQL).
> Anyone have objections to this? Thoughts?
> hibernate-dev mailing list
hibernate-dev mailing list