Hi Witold, Hmm, looks like I had removed that paragraph from my E-Mail... I was actually suggesting the same thing :-)
Regards, Lukas 2014-04-14 9:53 GMT+02:00 Witold Szczerba <[email protected]>: > Hi Lukas, > I think, maybe it would be worth mentioning the issue in the documentation > or faq or somewhere else (best practices?) on the project page. It seems to > be causing a lot of confusion. > > Regards, > Witold Szczerba > --- > Sent from my mobile phone. > On Apr 14, 2014 9:12 AM, "Lukas Eder" <[email protected]> wrote: > >> Hi Roger, Witold, >> >> From our own experience with customers, integration testing will >> eventually require being run against an actual database anyway, so moving >> away from the previous decade's we-must-unit-test-everything / >> we-must-get-100%-coverage hype towards a more 80 / 20-ish strategy where CI >> and integration testing is in the center of QA might lead to what we really >> want in the end: Higher quality. >> >> It's very nice to see that you have both found solutions to integrating >> this code generation step into your build / CI process. There isn't a >> one-size-fits-all solution, but it's good to see that working with actual >> databases makes sense to both of you :-) >> >> Now, I don't fully want to exclude the usefulness of another, >> intermediary step where the database schema is duplicated (generated, >> hopefully!) into another external data format, which could be used to >> produce jOOQ code. Vlad Mihalcea - a very active blogger - has recently >> shown this by example: >> >> http://vladmihalcea.com/2013/12/06/jooq-facts-from-jpa-annotations-to-jooq-table-mappings/ >> >> He's using JPA-annotated entities to generate a (temporary) HSQLDB >> schema, which he uses to generate jOOQ code. A clever solution, if you're >> building an CQRS-style application, where JPA is used for the Command (C) >> part and jOOQ for the Query (Q) part. >> >> Another solution would have been to let Hibernate generate .hbm.xml >> files, which could be read from a custom jOOQ-Meta "Database" >> implementation. >> >> The options are endless :-). I think that the most important aspect of >> all of this is to be able to automate each of these steps, without needing >> to manually patch different representations of your database schema. There >> should be only one "source of truth", and all other objects should be >> generated, derived objects, like jOOQ's generated tables. In more complex >> projects, the "source of truth" will inevitably be DDL as you're writing >> triggers, stored procedures, views, storage clauses, etc. So again, like >> Roger and Witold have shown, embracing database-centric designs will not be >> a bad choice in the long run, when your project evolves. >> >> Cheers >> Lukas >> >> 2014-04-13 2:42 GMT+02:00 Roger Thomas <[email protected]>: >> >>> First off I'm making no claims to have done all the work you have >>> already done, but I'm involved in a project where the final aim will be >>> to do the CI cycle that you describe and post the resulting JOOQ output >>> into a Maven repository. >>> >>> The logic being that the schema will be coded in Liquibase or Flyway and >>> have its own unit test cycle, with the output being a JOOQ >>> library that can then be consumed by developers. >>> >>> From my point of view this looks like a nice R&D project with the value >>> add of a fully tested schema and JOOQ library that can be >>> by developers. Just to complicate things I also plan to use Gradle >>> rather than Maven as Maven XML does my head in :( and Gradle >>> may remove this problem. >>> >>> >>> >>> >>> On Saturday, April 12, 2014 10:07:44 PM UTC+1, Witold Szczerba wrote: >>> >>>> In my previous project I was thinking about this and finally I have >>>> came to conclusion that the best option is to let CI server access a >>>> real database to build project. My build was prepared for a database >>>> details to be provided easily, so CI builds had theirs own databases >>>> (in fact two, one for deployment and one for integration tests). >>>> >>>> So, the database part of build system worked like this: >>>> 1) destroy databases (let's call them DEV and DEV_TEST) >>>> 2) build database module, this is: >>>> a) Liquibase, as part of mvn build, recreates databases from scratch, >>>> b) JOOQ, as later part of mvn build, generates code, >>>> c) mvn compiles everything, >>>> d) mvn install >>>> 3) compile, run integration tests (using DEV_TEST), >>>> 4) deploy to JEE server, >>>> 5) run e2e tests. >>>> >>>> Staging builds are almost the same, but they do not destroy the >>>> database, Liquibase just upgrades schema to new version. >>>> >>>> At the beginning I was not sure if this is OK to couple the project >>>> building process to a running database, but it really worked well. >>>> Every developer had it's own database (either locally, in virtual >>>> machine or an account on our development server). What's important >>>> here is that developers didn't have to build database module on each >>>> code change, but only when they actually altered the schema. It was >>>> separated from a web application maven project. Building it did not >>>> take long though, I don't remember, but I think it was something like >>>> less than 2 minutes. >>>> >>>> I was thinking: what's wrong with this? And finally came to conclusion >>>> that there is absolutely nothing wrong with this. In fact, it is even >>>> better, because everyone, from developers, CI DEV builds to CI STAGING >>>> and PRODUCTION builds work on the same database engine. There is no >>>> excessive abstraction above database between Liquibase and JOOQ: >>>> what's in there is what gets used to generate schema and it's what >>>> gets used to run integration and e2e tests. I liked it. >>>> >>>> You might think that tying building process to >>>> >>>> Regards, >>>> Witold Szczerba >>>> >>>> 2014-04-12 22:23 GMT+02:00 Mohit Jaggi <[email protected]>: >>>> >> >>>> >> >>>> >> Already today, you can implement your own jOOQ-Meta Database that >>>> supplies >>>> >> schemas, tables, columns, etc. to the code generator. This custom >>>> Database >>>> >> could read any sort of XML file, e.g. an external one by Flywaydb or >>>> >> Hibernate. >>>> >> >>>> >> How you generate that external file would then be entirely up to >>>> you. >>>> >> >>>> >> >>>> > Lukas, >>>> > I did not understand. Could you please point me to an example or >>>> section of >>>> > jooq documentation please? >>>> > >>>> > Rob, >>>> > For the time being I am adding generated code to git repo, which I >>>> don't >>>> > like much. >>>> > >>>> > Thanks, >>>> > Mohit. >>>> > >>>> > -- >>>> > 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. >>>> >>> -- >>> 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. >>> >> >> -- >> 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. >> > -- > 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. > -- 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.
