Simplified "boolean strategy" handling

[sebersole]

We have support for storing a boolean in the domain model in multiple ways in the database. In addition to normal BIT/BOOLEAN storage, we also support Y/N, T/F and 1/0.

At the moment, to use any of these you have to explicitly use @Type to specify the mapping. E.g.

@Basic
@Type( type = "yes_no" )
boolean enabled;

I've been thinking it would be nice to have a simpler way to specify these. This might be an annotation

@Basic
@Boolean( strategy = YES_NO )
boolean enabled;

or maybe just publishing AttributeConverter impls for these cases.

WDYT?

[dreab8]

I like @Boolean( strategy = YES_NO )

[beikov]

I like the idea, but only in addition to the possibility to of using @type as because:

• The annotation with enum approach is not extendible (what if some user wants J/N instead of Y/N)
• I think we need to handle the types internally in a special way as we do for the YesNoType, TrueFalseType and NumericBooleanType. Not sure if the attribute converter approach works here

So overall, I favor the annotation approach for exposing builtin strategies. Users can still use custom types though.

[gavinking]

Dunno. I guess I'm sorta not that keen on introducing an enum to model something that's in principle open-ended. I mean, yes, sure, for legacy reasons and convenience, we have these three built-in options, and that's OK as far as it goes, in that it's a pretty minimal API surface. But it's not like it's such a really super-excellent model that we should be freezing it into new constructs.

(Also I don't think you would literally call it Boolean, since you probably want to be able to use it on a field of type java.lang.Boolean.)

maybe just publishing AttributeConverter impls for these cases.

That sounds like a better option to me.

[sebersole]

I ended up doing both.

I added 3 AttributeConverter impls:

• org.hibernate.type.YesNoConverter
• org.hibernate.type.TrueFalseConverter
• org.hibernate.type.NumericBooleanConverter

And an annotation form taking an enum with these 3 options:

@Basic
@BooleanMapping( style = Y_N )
boolean annotatedYesNo;

@Basic
@BooleanMapping( style = T_F )
boolean annotatedTrueFalse;

@Basic
@BooleanMapping( style = NUMERIC )
boolean annotatedNumeric;

This is all covered in the revamped basic-type section/chapter

[gavinking]

@beikov @Stereotype would make sense I guess if we were planning to combine lots of meta-annotations together in one annotation.

But I don't think we need to go that far (yet). I can't think off the top of my head of any ORM mapping "sterotypes", i.e. annotations that I typically use in combination. Well, I can think of one combination—@Id @GeneratedValue(strategy=)—but beyond that I'm struggling to think of anything.

Other than that, it seems to me that if we can just let you stick @Convert on an annotation, then that's pretty much perfect and we should just allow it.

[gavinking]

Well, arguing against myself. Here's a usecase:

@Target({METHOD, FIELD})
@Retention(RUNTIME)
@Id
@GneneratedUUID
@Convert( converter = UUIDToString.class )
@interface Uuid {}

which combines:

• the @Id declaration,
• a converter, and
• a generation strategy, along the lines of what I'm proposing here.

Still, I would leave this idea for later.

[sebersole]

Given we are here because of sins of the past, can we please propose new annotations as composable...

@Inherited
@Target({METHOD, FIELD, ANNOTATION_TYPE})
@Retention(RUNTIME)
@Id
@GneneratedUUID
@Convert( converter = UUIDToString.class )
@interface Uuid {}

[sebersole]

Anyway, I rolled back the specific annotations here.

They, along with the static reference issues we've discussed a few times, were causing failures on Oracle because the overridden BOOLEAN JavaTypeDescriptor was not being used.

We can come back to this later

[beikov]

One common aspect that maybe even the JPA spec should care to model is mutability of types. Not sure if this is best modeled in the AttributeConverter contract or as annotations, but at least Hibernate supports a @Mutability annotation to capture this, which could also end up on such stereotype annotations. Another annotation that comes to mind is the @JdbcType/@JdbcTypeCode which could be used to define the default JDBC type code to use when a converter is applied. Again, that could end up on a stereotype annotation.

[gavinking]

@sebersole can this one be closed now?

[beikov]

I'll close this for now as I also had the impression that we decided to stick with the converter approach. If that is not correct, I'm sorry, but we can easily reopen.