2015-12-30 20:16 GMT+01:00 Witold Szczerba <[email protected]>: > See my comments in-line: > > On Wed, Dec 30, 2015 at 6:16 PM, Lukas Eder <[email protected]> wrote: > >> Hi Witold, >> >> Thank you very much for your feedback! >> >> 2015-12-30 15:46 GMT+01:00 Witold Szczerba <[email protected]>: >> >>> Hi, >>> since we have a special chance to have our say :) I would like to >>> mention about the thing which makes a little trouble now. Let's say I have >>> a class WalletId. It's just a wrapper around String, VARCHAR in SQL. The >>> trouble is, if I want to do a custom mapping for some columns in tables to >>> use WalletId, I have to split the project to have two artifacts. So, >>> instead of one POM, we need now 3: one for the WalletId class, second for >>> the rest of the project and third, a parent for those two. In >>> Microservices, when all the modules are really small, it is even more >>> annoying. >>> >>> Question is: is it possible to mix the process of code generation with >>> the project's compilation phase, so we could get the auto-generated code to >>> use the types from that module itself? >>> >> >> Sure, those types don't need to be compilation-ready while you generate >> your code. Unless, of course, you want to load the types in your own, >> custom code generator enhancement. But the code generator config only >> refers to types as fully qualified names (strings), so there's no >> dependency. >> >> The correct Maven phase for this would be generate-sources, or >> generate-test-sources. >> >> Or am I misunderstanding something? >> > > Well, maybe I am misunderstanding something :) > You say, that as of now, there is no need to create two separate > artifacts? Let's say I have a project with two classes: > WalletId and some MessageConsumer (it's just an example). MessageConsumer > is intercepting a message and doing an SQL operation using code generated > by jOOQ. This code, generated by jOOQ is supposed to use WalletId, so I > customize the codegen mapper. Now codegen mapper wants WalletId class, but > it is not available (it's not on any classpath), because the project was > not build yet. On the other hand, the project cannot build, because it uses > code generated by mapper. > My current knowledge is that, as of now, I have to split my project to > separate WalletId from MessageConsumer. At least this is how it was when I > was starting using jOOQ few years ago. Has it changed? >
I'm assuming here that my claim "unless, of course, you want to load the types in your own, custom code generator enhancement" applies. If your customised "codegen mapper" really needs to *load* the WalletId class, then you'll need more Maven projects / modules. At least one for your custom mapper, and another one to pre-compile the WalletId class. I think there's nothing jOOQ could do here, that's how Maven's build lifecycle works - see also Ben's comment. Well, yes. It was not my intention to mix that with code generator "story" > described earlier. > No worries, there are existing discussions on the user group about async/reactive SQL where you could join in, or you start a new thread. I'm always willing to discuss ideas! My biggest concern is that Clojure is a dynamic typing language and, this > is only my initial though, it might not benefit that much from using code > generator. Maybe I am wrong, because I am just at the very beginning of my > "Clojure journey" :) I am still learning basics. It has a power, though! > Those immutable (and only immutable, with no excuses) data structures are > so... cool! > Of course, jOOQ is not only a code generator. It's just a very nice API. > It's JDBC as it meant to be! > Well, even if the target language is a dynamically typed language, jOOQ's runtime library still offers lots of functionality - e.g. SQL dialect abstraction, SQL transformation capabilities (e.g. for row-level security, or multi tenancy), ease of building dynamic SQL, etc. We do have users that use jOOQ with Nashorn, for instance. It would be interesting to learn more about how jOOQ's mutable Query types, Record types, etc. work with Clojure, though. And how/if that could be dealt with in the code generator, perhaps. -- 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.
