>> This one was left unanswered. I reckon that the other mail where you >> suggest a patch for the code generator takes care of this? > > Yes, that's a feature I implemented using the new code generator. The new > code allows me to write extra code when the FK setters are generated.
I have merged your pull request for 2.4.0. Relevant tickets are: https://sourceforge.net/apps/trac/jooq/ticket/1509 https://github.com/jOOQ/jOOQ/pull/23 No integration tests failed, and the generated integration test source code didn't change, so I'm guessing that change is OK. Now, you're manually extending the code generator I assume? That is why you made all those newly refactored methods protected? So far, the generator was provided AS IS and does not really follow semantic versioning as introduced with jOOQ 2.1.0. This means that I do not give any strong API guarantee for jooq-codegen between minor releases. I guess you're suggesting otherwise? The current generator is not fit for this. If you wish to have a fully extensible generator with API guarantee between minor releases, I'm afraid it would have to be heavily re-written first. This will be part of jOOQ 3.0: https://sourceforge.net/apps/trac/jooq/ticket/1464 >> I'm wondering, by what mechanism (heuristics?) do you get from >> "LANGUAGE_ID" to "Language"? In what context does this take place? >> Regular foreign key relationships, or master data tables? > > Yes, it's a FK relation. Since you generate code to the FK, I was wondering > why you didn't generate a setter that accepted an FK record instance. That would be a nice feature. I'll track this as #1510: https://sourceforge.net/apps/trac/jooq/ticket/1510 Still, the setter name has some problems: - Re-using LANGUAGE_ID (column name) won't work if the foreign key is a multi-column FK - Using Language (referenced table name) won't work if there are several foreign keys referencing the same table - Using the FK name is probably not very user-friendly (they tend to have weird names) and the name could collide with a column name Of course, end users could handle naming of these setters themselves using custom strategies. But what would be the best default? In my opinion, it would be the referenced table name with an optional suffix containing the FK name, in case there are several FK's referencing the same table. Cheers Lukas
