> What I think?
> I think I'm about to re-implement Hibernate!
True, there is a line to draw somewhere. But if you are ready to map
enums, then you could as well map any type. That would greatly
simplify the user's life if they can define the bridge between their
type and the SQL type and have the jOOQ table fields using that user
type.
> So to put it short, the type-mapping configuration options would look like
> this:
I am not sure why you make a specific distinction between custom enums
and custom types. A custom enum happens to be a custom type in my
view.
It is also unclear in your e-mail how the mapper is defined (in the
generator or by users in their code).
I tend to think that in-code definition is more flexible, allows all
sort of mapping rules (with caching, boxing, etc) than trying to
generate such code. Moreover, the user needs to establish the mapping
rules whatever approach but they do not need to refer to model
generation related files and do not need to re-generate if a
refactoring changes their internal enum/types mapping logic.
jOOQ could provide a default enum mapper for enums that implement a
particular interface and in which mapper a map is built for later
lookup.
With a code approach, their needs to be a clear place where to
establish the mappers. It could be registered in the Settings (like in
my previous e-mail), or it could also be in the field itself:
MyDateMapper myDateMapper = new MyDateMapper();
MyTable1.MyDateColumn.setMapper(myDateMapper);
MyTable2.MyOtherDateColumn.setMapper(myDateMapper);
TypeMapper myEnumMapper = new TypeMapper<com.xx.SomeEnum, Integer>() {
public SomeEnum to(Integer i) {
return xxx;
}
public Integer to(SomeEnum e) {
return xxx;
}
public SQLDataType getDataType(T e) {
return SQLDataType.SMALLINT;
}
}
MyTable2.MyEnum.setMapper(myEnumMapper);
// Assume MyJOOQEnumImpl implements JOOQEnum interface with getLiteral()
MyTable3.MyOtherEnum.setMapper(new JOOQEnumMapper(MyJOOQEnumImpl.class));
The above code would have to be called once when the application
starts and it would be the user's responsibility.
Consider my code where I have about 200-300 enums. I would have
200-300 mapping lines, but they would be the same: I would only have
to create my generic custom enum mapper (similar to the JOOQ enum
described above) and instanciate it for every enum. Very readible in
my view (don't forget that the field and the mapper are typed, so I
cannot plug a wrong mapper on that field).
Hope this helps,
-Christopher