Hi James, There are java.sql.Clob and java.sql.Blob interfaces that would be the standard mapping in JDBC. This is useful only for very large clob's and blob's. Usually it's easier to use String and byte[] directly. I'll be back from vacation in a week, so I'll try to see what is causing the datatype mismatch between MySQL and H2 generated source code.
Thanks for your feedback. I'll keep jOOQ evolving at the same pace in 2011, as I can see that JPA's criteria query is still not progressing into a similar direction... even with JPA 2.1, criteria query will remain quite verbose and far from SQL. Another solution you might want to check out is QueryDSL. It is quite active as well, and similar to jOOQ. If you have some time: I'm curious about the problems you've experienced when inheriting from the jOOQ classes. What was the use-case that caused problems? Which classes did you try to inherit from? Cheers Lukas 2011/1/25 James Moger <[email protected]> > I think your approach of mapping Clob and Blob to String and byte [] is the > way to go. Actually, not being an SQL expert, I'm not sure what else they > would map to. > > I haven't tried any of your proposed changes - mostly because of the jOOQ > class hierarchy requirement. I was trying to fit this into an existing > project where I already have dozens of model classes that I serialize and > pass between VMs. Inheriting from the jOOQ classes is problematic for me. > I like that jOOQ is active and making progress where things like JaQu seem > to be inactive... but with JaQu all I need is an interface dependency. I've > stopped jOOQ eval - and actually also stopped JaQu eval at the moment as > more pressing projects have come to the foreground. > > I'll keep lurking around jOOQ and see what evolves. :) > Thanks for your help. > > -J >
