Hi Lukas, 1. I'm calling this type Converter rather than Mapper
I don't mind, I am fine with Converter. I will use mapper in the rest of this e-mail though to differentiate from type conversions performed by the RDBMS. You may need to think about it too to see if using converter is not going to confuse users and cause ambiguous discussions when troubleshooting user issues. The general sequence of a call to the RDBMS is: x -> type mapping -> y -> type conversion -> z 2. I found that it is necessary for jOOQ's internals to get a hold of > both Java types involved in type conversion What about my case where I have 2 back-ends (SQLServer and Oracle)? Let's say I have a BIT in one (Boolean) and a Number in the other (Short). For fields, you said that this would work because there is type conversion. But is this going to work with type mapping if I generate a model against one of the RDBMS and run on the other? 3.1. The "custom type" (e.g. MyEnum and MyEnumConverter) > Out of curiosity, can we augment an already existing MyEnum to implement the Converter interface so all code is located at a single place if we want it to? Would jOOQ allow it? > 3.2. The "forced type" (e.g. MyEnum and a regular expression matching > all columns upon which this forced type should be mapped). "Forced > types" can be used for other purposes, too. For example, forcing a > NUMBER(1) column to be java.lang.Boolean. Somehow this seems to answer my question above, but I just want to be sure :) A sample configuration can be seen here: > > https://github.com/lukaseder/jOOQ/blob/f53818504ef1d0345a8aae40fd29b7a9ccd6976a/jOOQ-test/configuration/org/jooq/configuration/lukas/hsqldb/library.xml > <literals>y,"n"</literals> <literals>"Y",N</literals> Don't you mean: <literals>"y","n"</literals> <literals>"Y","N"</literals> > For now, there is EnumConverter, which can be extended by manually > written custom converters (overriding the to() method): > > https://github.com/lukaseder/jOOQ/blob/master/jOOQ/src/main/java/org/jooq/impl/EnumConverter.java > This looks good and very easy to use. > 5. Generated tables will use the custom type as bound for <T>. A > sample table can be seen here: > > https://github.com/lukaseder/jOOQ/blob/f53818504ef1d0345a8aae40fd29b7a9ccd6976a/jOOQ-test/src/org/jooq/test/hsqldb/generatedclasses/tables/TMappedTypes.java > This also looks good! 6. There is a central custom type registry providing a mapping between > MyEnum -> MyEnumConverter. This is the registry: > > https://github.com/lukaseder/jOOQ/blob/master/jOOQ/src/main/java/org/jooq/impl/DataTypes.java > What would happen if one generated schema defines certain mappings, and another generated schema defines other mappings but for the same types (especially calendars or dates)? Running with one would be fine but could running with two result in collisions in the registry? > It is used by jOOQ to know how to bind and inline custom types in > SQL. A custom type can only be converted by a single converter, > globally. i.e. it is currently not possible to have MyEnum -> > Converter1 in one place, and MyEnum -> Converter2 in another. The > reason for this is, jOOQ needs an unambiguous registry in > "context-less" cases like this: > create.select(MyEnum.VAL).fetch(); > It is context-less when talking about columns, but the schema is still something to consider (cf. my previous remark). That being said, for a given schema I agree with you (and in practice, I don't know if multi-schema collisions for different mapping definitions would occur that often). This will be an open point. I'm curious about your feedback on > this topic. You suggested to use the Factory's Settings as an > (additional) Converter registry. This might be a viable workaround for > a future release, if several converters are really needed for the same > custom type. I feel it might be a bit overkill, though. > I fully agree with you. I don't think it is needed... 7. Fields (Parameters) hold direct references to their > "ConvertedDataType". This means that when fetching data from a > ResultSet (CallableStatement, SQLInput), this information is available > directly from the Field. > Very good! > I feel this is on a good track! > Indeed! Now I need to find the time to actually generate a model with some custom mapping. I will try to do that during the week-end or begining of next week. I'll let you know when I get there if I have any particular remarks. Keep up the good work! :) -Christopher
