Re: [hibernate-dev] boolean type support

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