Hi Lukas, I think the current design isn't entirely orthogonal to what you are > now planning to think about.
I am merely expanding on the converter idea to see how it can be used, abused, and eventually try to find new usages. I am just thinking out loud in case it triggers ideas for improvements in jOOQ. Yet, I have to re-explain about jOOQ applying some magic with a > central registry. I got it. I just wanted to express valid use cases with regards to the central-registry limitation in case you had ideas to tweak the current design. Solution for your use case, you have several options: > 1) Don't use jooq-codegen > This means using the converter explicitely externally. Of course this can be done, and any conversion mecanic can be used. It means that we explicitely use the raw SQL type. 2) Move that sort of mapping entirely out of jOOQ. Maybe there's a > much simpler solution, as this all feels super-overengineered (at > least to me...) > With the converter feature, you enter the realm of mapping business data to tables automatically. I never said everything could be done! But maybe slight modifications could allow more. You see, enforcing certain rules on the DB API (jOOQ exposed interface to the DB) can be very powerful, because you immediately know what you can do with less possibilities of errors when accessing/modifying data. 3) Create dedicated types for your 3 date types: NullableDate > (null=null), LowerBoundDate (null=-inf), UpperBoundDate (null=+inf). > All three extending some base type. Then you can use a dedicated > converter for each date type. This additional type-safety might even > be useful for your application's Java code > No because the end date can be used as a regular date in other contexts. Like "retrieve data at a date, which happends to be the end date of a particular time series, if not infinity". We don't want conversions because the DB mapping cannot cope with a single unified date with different constraints depending on the columns. 4) (probably not practicable): You can always use a non-null value to > represent -inf/+inf. Just like Integer.MIN_VALUE and Integer.MAX_VALUE > could be used for that. > Yes, there are many possible work arounds. OK, let's sum up where we are. - Central registry is needed because in complex queries we do not have a particular field to work with. - Because registry is central, there cannot be different conversion rules. For enumerations, this is of course not a problem, except if someone wanted to apply data validation in the converter depending on the field. I have one more thought about mapping my date types: what if the to/from method of the converter had the name of the field as a parameter? Is that something you have in your context? The name could be null (in case of VAL), or could be the name of the field (StartDate, EndDate, SomeDate), or even the reference to the field itself (though I doubt this is possible). This could be used by a user to change the conversion strategy depending on the field, provided they defined strict naming rules. In my case for example, all start and end dates have the same name, whatever table is using them, because we have consistent names in our database schema. I want to come back on this: >> 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? > The mappings' scope is not a single schema. Why wouldn't you generate the registry in a particular schema (or in the same package and referenced by a schema) instead of an independant class? That way, all from/to calls get the mappers from the schema and there would not be any risks of collisions. As an analogy, you don't generate tables of a schema in a central registry, but have this linked to a schema. Cheers, -Christopher
