Yeah the example you gave would reflect what I was thinking about. How would you determine the expression type if the castTarget is just "passed-through" then?
Mit freundlichen Grüßen, ------------------------------------------------------------------------ *Christian Beikov* Am 31.05.2017 um 13:44 schrieb Steve Ebersole: > 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 <st...@hibernate.org > <mailto:st...@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 > <christian.bei...@gmail.com <mailto:christian.bei...@gmail.com>> > wrote: > > 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? >> >> 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 <mailto: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 >> <mailto: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 >> <mailto:hibernate-dev@lists.jboss.org> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> <mailto: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
