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 <st...@hibernate.org> wrote:
> On Fri, Jan 27, 2017 at 10:46 AM Christian Beikov <
> christian.bei...@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
>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
