Hello Sergey, I'm not sure what the annotations are needed for? The current meta model should have all information in the DataType<T> property? Having said so, your notion of a type handler might be implemented with a custom DataType<T>, where T can bind to anything. Existing functionality, such as this method here would then help converting standard JDBC data (probably String) into custom data types, and vice versa:
http://www.jooq.org/javadoc/latest/org/jooq/DataType.html#convert(java.lang.Object) That way, your idea might indeed be viable in a second step (not for jOOQ 2.0.1) I prefer not to introduce new annotations, but that's a personal objection, as you can see me ranting here :-) http://lukaseder.wordpress.com/tag/annotatiomania/ Maybe Hibernate/JPA have existing functionality that goes in a similar direction? At least for fetchInto() methods, supporting such annotations might be useful. Cheers Lukas 2011/11/29 Sergey Epik <[email protected]>: > Hello Lukas, > > Congratulations with 2.0 release! > > Regarding discussion about jooq-codegen type mapping: attribute in generated > record can be annotated with typehandler class (if we want to change type) > and optionally with column name, for example: > > generator.generate.field.DealerState=MY_SCHEMA\.DEALER\.STATE > generator.generate.field.DealerState.type=com.example.proj.DealerStateEnum > generator.generate.field.DealerState.typeHandler=com.example.proj.EnumTypeHandler > > generator.generate.field.IsEnabled=IS_ENABLED > generator.generate.field.IsEnabled.type=boolean > generator.generate.field.IsEnabled.name=enabled > generator.generate.field.IsEnabled.typeHandler=com.example.proj01.YNBooleanTypeHandler > > Generated record field: > > @Filed(typeHandler=EnumTypeHandler.class) > private DealerStateEnum state; > > > @Filed(typeHandler=YNBooleanTypeHandler.class, column="IS_ENABLED") > private boolean enabled; > > Another way - do not use annotations at all and generate separate classes > (one per table?), that implement mapping customizations. > > What do you think? > > > > On Mon, Nov 21, 2011 at 8:41 PM, Lukas Eder <[email protected]> wrote: >> >> Hello Sergey, >> >> > We use char 'Y'/'N' for encoding boolean values. >> > Probably we have to define custom type handler that converts values from >> > boolean to string and vice versa (both resultset and procedure >> > paramaters). >> >> Reading these characters as boolean is already possible. You can >> convert them using various methods, for instance >> >> List<Boolean> list = result.getValues(field, Boolean.class); >> Boolean value = record.getValue(field, Boolean.class); >> >> I realise just now, that this is not publicly documented, though! >> >> Besides, there is >> http://www.jooq.org/javadoc/latest/org/jooq/Field.html#isTrue%28%29 >> http://www.jooq.org/javadoc/latest/org/jooq/Field.html#isFalse%28%29 >> >> But writing 'Y' / 'N' from a Java boolean is a bit more difficult. I >> agree that adding Y/N, YES/NO, ON/OFF boolean types might be useful. >> I'll add it to the feature roadmap: >> https://sourceforge.net/apps/trac/jooq/ticket/968 >> >> > Here is example how this problem can be resolverd in mybatis: >> > http://jroller.com/RickHigh/entry/ibatis_how_do_you_map >> >> I'll consider that, thanks. >> >> > Is it possible to map simple char - encoded enumerations (for example >> > 'E - >> > Enabled, 'D' - Disabled, 'S' - Suspended) type to java enum (without >> > master >> > table)? >> >> Currently, enum types are only supported where they exist natively, >> i.e. in MySQL and Postgres. I had previously thought about reading >> check constraints for enum types, although that is a bit tricky as >> they are usually not formally available in a non-source-code form. >> Parsing a check constraint's source code might not be trivial. But >> when custom type mapping is available, custom enum types could easily >> be mapped, too. Maybe, they would need to implement org.jooq.EnumType: >> http://www.jooq.org/javadoc/latest/org/jooq/EnumType.html >> >> Of course, this would resolve the 'Y' / 'N' boolean feature, too. >> >> I'll give this a thought for jOOQ 2.0.1. API and Implementation ideas >> are welcome, of course! >> >> Cheers >> Lukas > >
