[hibernate-dev] SQM and cast targets

[Steve Ebersole]

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 JavaTypeDescriptorRegistry
   2. A JDBC type (either by code or name) we can resolve against the
   SqlTypeDescriptorRegistry
   3. Any other text we can resolve against the Dialect as a "valid SQL
   type"

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 at 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 work
> 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 therefore
> > pretty inconsistent).  What does that mean?  Well, what is a valid cast
> > 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 registered
> with
> > with JavaTypeDescriptorRegistry, and specifically any that properly
> > 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>