Re: [hibernate-dev] boolean type support

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 <steve(a)hibernate.org&gt; 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 <steve(a)hibernate.org&gt; wrote: > On Fri, Jan 27, 2017 at 10:46 AM Christian Beikov < > christian.beikov(a)gmail.com&gt; 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev