Hi Christopher, > 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.
I agree, it can be powerful. I have a co-worker saying "jOOQ: A device whose mystery is only exceeded by its power" :-) > 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". [...] Now, this model is confusing me again ;-) But never mind. I begin to realise that you have a subtle type system wrapped around dates that is too hard to handle for jOOQ... That's why it's probably best to be implemented (and validated) on a higher level. > - 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. Exactly. > 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? There is no "field" in the render / bind context. <T> can be bound entirely out of context - recall select(val(MyEnum.A)). Hence, no name available. Note, Fields / names are available in *certain* contexts, but making that a general rule would be unwise. Such an API would appear to be useless in most cases that are not very simple queries. What comes to my mind now: For some well-defined cases, you could actually use CustomCondition and CustomField and other custom types from jOOQ: http://www.jooq.org/manual/JOOQ/Extend/ When you create a CustomCondition, you can add whatever checks and context you want in this condition. > 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? For the same reason. The schema would be referenced by Fields / Tables. Hence, I do not have any schema reference at render / bind time. There is no schema in create.select(val(MyEnum.A)).fetch() Look at custom types to be of an application-wide scope. Not to be confused with user-defined types, which are declared on a schema-level in the database itself... Cheers Lukas
