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? > > >> Other things on my hypothetical wish list would be to support non-JDBC >> drivers. As we know the JDBC is a blocking API, but there are alternative >> drivers for some databases using async techniques. There is a lack of >> standardization in this area, but in my imaginary, perfect world :) the >> projects like jOOQ could try to change the JVM world in this area! OK, I >> was just thinking loudly :) >> > > This is on my wishlist, too :-) But it doesn't have anything to do with > the code generator. > Well, yes. It was not my intention to mix that with code generator "story" described earlier. > >> I won't even mention support for Clojure. Such a feature would cost a lot >> of time and I guess it would be doable by a 3rd parties if such a desire >> would emerge. >> > > Why not? It might be worth looking into. There is Suricatta, a third-party > library that builds on top of jOOQ. Perhaps, the jOOQ code generator can be > enhanced to also generate Clojure artefacts. > 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! Thanks, Witold Szczerba -- 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.
