> I guess it's also outside the scope of Jooq itself :-) It clearly is
> Not sure about CTEs (what's that?) and arrays (never used them, too > DB-specific to be comfortable with that). Common Table Expressions, e.g.: WITH x AS (SELECT 1 a FROM DUAL), y AS (SELECT 2 b FROM DUAL) SELECT x.a, y.b FROM x, y You can have CTE's in views, too. > Hm, yes, I see. That was the point where I started to become wary of > Jooq. > Not really Jooq's fault, it's just that the code generation in > Hibernate Tools were such a time sink and nightmare. Yes, too many not-well-designed features are a bad thing. I'm aware of this. This is one reason why I'm removing master data tables from jOOQ 3.0... >> But if you're used to a nasty database schema, then a nasty regex won't >> be such a problem, I guess... > > I guess differently: if the database schema is already nasty, the last > thing you need is yet another nastiness creeping in from elsewhere. I agree. I wouldn't want to deal with a "not-well-designed" database schema, in the first place. The idea we're discussing here is mainly targeted at people dealing with well-designed databases. The "others" are used to finding creative solutions anyway, so I won't take a guess at what the best solution for *them* would be. > It's probably smarter to divide the rule base up: Tables following naming > schemes A, B, or C should apply PK identification scheme X, those > following naming scheme D should apply PK identification scheme Y, etc. > Including schemes that simply use a hardcoded specification. ((A|B|C)\.PK_X|D\.PK_Y) ... works for me ;-) >> Good luck with such an approach :-) >> To me, it's in the same category as parsing the view definition... > > [...] > Unless you mean the "too much work to be worth it for Jooq" category, > of course :-) Yes. It's even too much work to seriously think about it :-) Cheers Lukas
