We would not be able to. That is the trouble with any kind of "pass-through. We would need some form of hint/directive from the user.
Also in thinking about it some more, I think that re-using treat is not appropriate. treat is specifically defined in regards to hierarchies, which mean this use would be counter-intuitive. But a "wrapper" of some sort (and really cast and treat are just specialized typing wrappers) seems like a good option. We'd just need a good name for it. On Wed, May 31, 2017 at 7:24 AM Christian Beikov <christian.bei...@gmail.com> wrote: > 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> > 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> 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> >>> 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
