Hi Lukas > > Or, you could write a blog post, in case of which the content belongs to > you and we don't have to transfer it. That might be even better, because we > won't need to review formatting, etc... >
let's see this matter when we're done ^^ Latter always sounds good isn't it ? ;) > > well, actually I changed the way migration are triggered to have them done >> from a main method. It feels closer from "real life" to me, yet it makes >> the example a bit more complex. Is still fine for you ? >> > > Ehm, I don't know :-) > Ok, there you're : https://github.com/cluelessjoe/jOOQ-java-flyway-example It's pretty rough around the edges, and not only the edges ^^ Hopefully you'll still manage to make sense out of it. So, what do we have there ? An ApplicationRunner as the production entry point, starting an Application, in which it all starts by some migrations. These migrations are written in Java. As I'm not a big fan of maven install's time stuff generation, I also switched to Java model generation in the test resources, namely in ModelGenerator No model versioning there, and actually I encountered a funny issue : inserting data actually requires the model to be there already AFAIK. So actually I'll have to add an extra migration step : in the third I update the schema, then generate the model, then in a fourth step I can data into the DB. Unless I'm missing something for sure. > > Hmm, I see. That's certainly an interesting approach, although I suspect > that you will be missing out on a couple of features, then. For instance, > what happens if you want to reference or alias such a table? You'll get a > reference to o.j.e.m.p.v3.tables.Author: > Well, you convinced me: I switched to copy twice the latest generated model, which should resolved the subclassing issue. Fine for you ? > In the other thread that we're having in parallel, I was discussing why it > might be a good idea (from our point of view) to make all generated classes > "final": > https://groups.google.com/forum/#!topic/jooq-user/Kz6KsJFim6Y > > The assumptions that you make right now when you subtype Author may break > any time in a future release, even in a patch release, because you > implicitly depend on internal API. It certainly works right now, but I'd be > wary of this solution, and had better solved it more thoroughly, with an > out-of-the-box feature. > fine for me too (now) > > > How about actually referencing v4 from all of your code, and simply > search-replace package names upon migration? > Feels weak to me. What about code being written in feature branches at the same time? Later merge and the likes? Code in projects depending on the current one I can't reach ? That could be pretty nasty. But keep on reading, another way poped up in my mind ;) > The effect would be the same, although the diff would be much bigger. > Another option: Generate a "latest" package and always refer to that from > code, adding version numbers only to historic versions. > actually when thinking more about it, in real life I would do it through different maven projects. One for the migration only, one for business code and one for running the app. I would put the models with version in the migration project and the current one in the application code. Then I would assemble all this in the "application" project. So no risk whatsoever of using some older model in business code. Sounds pretty strong to me. > > Let me know if you come to think of another missing feature. > That's all for now, but I'm only prototyping, no real production code yet. By the way, a side question: do you speak at conference ? I'm actually member of the ElsassJug, in Strasbourg, so next door to you so to say. If ever you had something to say/share, I would happily organize an event for you. What do you think of it ? ++ joseph -- 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.
