2014-03-26 9:38 GMT+01:00 Gérald Quintana <[email protected]>:
> Thanks,
>
> If you modify documentation, you should also document what matches
> the<expression>: is it COLUMN or TABLE.COLUMN or SCHEMA.TABLE.COLUMN?
>
The documentation reads:
<!-- Add a Java regular expression matching *fully-qualified columns.*
Use the pipe to separate several expressions.
If provided, both "expressions" and "types" must match. -->
<expression>*.**\.DATE_OF_.*</expression>
Do you think that can be improved? How?
> and indicate this case sensitivity.
>
Yes, the (?i:...) "trick" should be explained.
> Is the SQL type returned (and matched by <types>), normalized (as
> described in java.sql.Types) or database specific?
>
It's database-specific at that point.
> Moreover, to figure out why my <forcedType> rule didn't apply, I had to
> override the JavaGenerator.getType method to introduce a log of type
> definition. This is why I still dream of being able to implement my own
> function (column definition) --> Java type. This is only my personal
> feeling on customising Java types in code generator, at the end it does the
> job. Thanks
>
Yes, that would be great. Unfortunately, the data type model in jOOQ-Meta
is currently not very extensible. I'm afraid that there is not too much
room for improvement in a minor release...
--
You received this message because you are subscribed to the Google Groups "jOOQ
User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
