[hibernate-dev] boolean type support

[Steve Ebersole]

Correction : If they have not done that either, we'd simply *ask* the
Dialect.

On Fri, Jan 27, 2017 at 12:24 PM Steve Ebersole <steve at hibernate.org> wrote:

> On Fri, Jan 27, 2017 at 10:46 AM Christian Beikov <
> christian.beikov at gmail.com> wrote:
>
> Am 27.01.2017 um 17:31 schrieb Steve Ebersole:
> > Obviously that only works if there is not already an AttributeConverter
> > applied to to the attribute.  I cannot imagine that ever happens in a
> > supported way, or a way that we want to support.  Essentially that would
> > mean a condition where we convert the value twice in each direction.  But
> > in case we miss some ase, I wanted to ask the list.
> So if a user defines a converter for Boolean=>Enum for example, that
> would not work on e.g. Oracle since on such a DB the column type is
> integer?
>
>
> I am not following what you mean.  Why would an enum be a boolean?  You
> mean something like:
>
> enum Sex { MALE, FEMALE )
>
> and then storing into the DB as `IS_MALE`?
>
> I mean I guess someone *could* write an app that way.  I'd laugh at them,
> but I guess they could ;)
>
> Anyway, they can already do that... it called an AttributeConverter :P
>
> More I am asking about the legacy BooleanType, YesNoType and
> TrueFalseType.  These each used different JavaTypeDescriptor instances
> encoding the specific true/false DB ('Y'/'N', 'T'/'F', 1/0, ..)
> representations.
>
> So in stepping back and thinking about how this "should" be designed, I am
> thinking that the most logical design is to have just a single
> JavaTypeDesriptor for boolean and to somehow keep the specific DB storage
> representations as part of the attribute[1].
>
> But then we start thinking how that should affect the wrap/unwrap
> process.  Well, we already have a way for attribute-level "config" to alter
> the wrap/unwrap process - again, AttributeConverter.  So at the minimum we
> will handle this in the same manner as we hande AttributeConverter.  But
> then we asked whether we might just *use* AttributeConverter for this; this
> design works well, so long as these attributes do not also have an
> AttributeConverter associated with them.
>
> I think I'd propose this...
>
> We'd essentially say that we do not natively understand how to store
> booleans (just bear with me...).  Specifically how to convert them into a
> DB storable format.  Which means we'd need something to help us perform
> that conversion.  If the user has attached an AttributeConverter to the
> attribute we'd simply use that.  If they have not, then we'd look to this
> config option to see if they have specified how to do that globally.  If
> they have not done that either, we'd simply as the Dialect.
>
>
> [1] I'd never do this, but it is entirely possible that a user would want
> a boolean value from one attribute stored in the DB as 0/1 and another
> attribute store as Y/N.  So attribute is the highest granularity we need to
> resolve this at.  But they might instead very well want to store all
> boolean values in their app to the DB as a single representation - we'd
> support that via config, as well as fallback to Dialect
>
>