How about this rule then? castTarget // 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 <st...@hibernate.org> wrote: > 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.bei...@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@lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
