TLDR: Should we adjust to allow Dialect to know the "context" of where the remapping is requested? Ah Oracle... So this comes from the fact that Oracle does not support a BOOLEAN datatype. Well kind of. It does not support a BOOLEAN datatype in its "SQL engine". However, in PL/SQL it does in fact support a BOOLEAN datatype. Which comes into play when we talk about calling functions and procedures: the arguments and returns can in fact be a BOOLEAN. As far as I know, Oracle is the only database with this type of inconsistency in its type system. But the question is whether we want to pass along some kind of information regarding the context (SQL v function v procedure) to the Dialect#remapSqlTypeDescriptor. You can look at https://hibernate.atlassian.net/browse/HHH-11141 for an illustration of how this impacts applications. And if you look through the comments you can see the kind-of-crazy workaround needed. _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

I also consider that we should provide info so that we can properly map the Boolean type according to the expected SQL type. Especially since we have revamped the support for Stored procedures and functions. Vlad On Fri, Sep 30, 2016 at 5:11 PM, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > TLDR: Should we adjust to allow Dialect to know the "context" of where the > remapping is requested? > > Ah Oracle... > > So this comes from the fact that Oracle does not support a BOOLEAN > datatype. Well kind of. It does not support a BOOLEAN datatype in its > "SQL engine". However, in PL/SQL it does in fact support a BOOLEAN > datatype. Which comes into play when we talk about calling functions and > procedures: the arguments and returns can in fact be a BOOLEAN. > > As far as I know, Oracle is the only database with this type of > inconsistency in its type system. But the question is whether we want to > pass along some kind of information regarding the context (SQL v function > v > procedure) to the Dialect#remapSqlTypeDescriptor. > > You can look at https://hibernate.atlassian.net/browse/HHH-11141 for an > illustration of how this impacts applications. And if you look through > the > comments you can see the kind-of-crazy workaround needed. > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev >

Specifically, does anyone know how Oracle driver reports ParameterMetaData#getParameterType for CallableStatement arguments that are defined as PL/SQL BOOLEAN types? On Fri, Sep 30, 2016 at 7:02 PM Steve Ebersole <steve(a)hibernate.org&gt; wrote: We may be able to look at the procedures Metadata from CallableStatement. I forget the exact details of how it reports the argument types, especially for Oracle specifcally On Fri, Sep 30, 2016, 12:57 PM Vlad Mihalcea <mihalcea.vlad(a)gmail.com&gt; wrote: I also consider that we should provide info so that we can properly map the Boolean type according to the expected SQL type. Especially since we have revamped the support for Stored procedures and functions. Vlad On Fri, Sep 30, 2016 at 5:11 PM, Steve Ebersole <steve(a)hibernate.org&gt; wrote: TLDR: Should we adjust to allow Dialect to know the "context" of where the remapping is requested? Ah Oracle... So this comes from the fact that Oracle does not support a BOOLEAN datatype. Well kind of. It does not support a BOOLEAN datatype in its "SQL engine". However, in PL/SQL it does in fact support a BOOLEAN datatype. Which comes into play when we talk about calling functions and procedures: the arguments and returns can in fact be a BOOLEAN. As far as I know, Oracle is the only database with this type of inconsistency in its type system. But the question is whether we want to pass along some kind of information regarding the context (SQL v function v procedure) to the Dialect#remapSqlTypeDescriptor. You can look at https://hibernate.atlassian.net/browse/HHH-11141 for an illustration of how this impacts applications. And if you look through the comments you can see the kind-of-crazy workaround needed. _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev