Re: [hibernate-dev] boolean type support
On Fri, Jan 27, 2017 at 10:46 AM Christian Beikov <
christian.beikov(a)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