Oh, I just saw your last statement. I'm not a fan of "only ever [using
cast function] for the pass-through case"
On Wed, May 31, 2017 at 6:43 AM Steve Ebersole <steve(a)hibernate.org> wrote:
You mean something like `treat( cast(x as some_db_type) as String)`?
On Wed, May 31, 2017 at 1:12 AM Christian Beikov <
> 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,
> *Christian Beikov*
> 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
>> 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
>> 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 the
>> 3. Any other text we can resolve against the Dialect as a "valid SQL
>> 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) and (2).
>> On Mon, May 29, 2017 at 10:36 AM Christian Beikov <
>> christian.beikov(a)gmail.com> wrote:
>>> 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 character types
>>> that are available in the different DBMS. A cast to "String" might
>>> most of the time, but we should still have an option to cast to CLOB,
>>> TEXT or whatever other datatype a DBMS offers.
>>> Mit freundlichen Grüßen,
>>> *Christian Beikov*
>>> Am 29.05.2017 um 16:17 schrieb Steve Ebersole:
>>> > Currently casting in HQL is under-defined and open-ended (and
>>> > pretty inconsistent). What does that mean? Well, what is a valid
>>> > 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 properly
>>> > implements `#getJdbcRecommendedSqlType` (using the Dialect to resolve
>>> > cast target in the generated SQL).
>>> > Anyone have objections to this? Thoughts?
>>> > _______________________________________________
>>> > hibernate-dev mailing list
>>> > hibernate-dev(a)lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> hibernate-dev mailing list