If you think we can handle this better using Attributes, then we can give
it a try.
Nevertheless, the current implementation is nice as well. We have a single
Java descriptor and multiple Sql descriptors to cover various DB column
types or column values.
Vlad
On Fri, Jan 27, 2017 at 8:28 PM, Steve Ebersole <st...@hibernate.org> wrote:
> 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
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
