No way! ;-) I've been fixing such bugs recently because of large schemas (many tables in Tables.java, [Schema-name].java, many references in Keys.java, etc.). E.g., there's also a limit of 64k constants in a class's constant pool. You can read up on the subject here: http://stackoverflow.com/q/10841732/521799
But many columns in a table? I mean, we're talking about some 10k columns, right? Doesn't sound very normalised ;-) Anyway, I'll register an issue for this, but I don't know if this can be fixed sensibly: https://github.com/jOOQ/jOOQ/issues/2284 For now, I guess I'll just refer to the disclaimer here, where excluding such artefacts from code generation is the way to go: http://www.jooq.org/doc/3.0/manual/code-generation/codegen-large-schemas/ Cheers Lukas 2013/2/28 Kent Smotherman <[email protected]> > I came across an interesting "bug" - I have a very wide table, and the > generated table class has so many fields that I get a compilation error for > the class indicating that the constructor has more than 64k of code. I > didn't even realize that was a compilation limit! > > For now, I don't need this particular table in my application (not sure I > will ever), so I'm just taking it out. > > Kent > > > On Wednesday, February 27, 2013 2:29:23 PM UTC-6, Kent Smotherman wrote: >> >> I have a very early version working now. I'll still be doing lots of >> testing to see what holes I have even in the basic functions I'm trying to >> support at the moment. I haven't yet tried generating the schema related >> classes to replace the hard-wired SQL ones I have currently - I need to get >> my app converted to using this from JPA first. >> >> Thanks for pointing me in the right direction, and I'll keep the group >> posted. >> >> On Tuesday, February 26, 2013 3:57:52 PM UTC-6, Kent Smotherman wrote: >>> >>> I've perused the source, and have poked through a lot of messages here, >>> but I still am quite lost in trying to figure out how to start doing an >>> implementation for iSeries DB2. The fairly terse text on the site seems to >>> imply that I can use the code generator to help with some of this, and the >>> sample DB2 implementation I see also is full of auto-generated code. >>> However, how can generate code if I don't have an implementation that >>> understands the schema etc for iSeries, since it is greatly different than >>> standard DB2? >>> >>> Forgive me if I am just overlooking something obvious! >>> >>> Kent Smotherman >>> >> -- > 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/groups/opt_out. > > > -- 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/groups/opt_out.
