Hi Joseph, 2016-01-04 23:37 GMT+01:00 <[email protected]>:
> Sure, but actually I stumbled upon the Corporate Contributor Information > part: my employer indeed works in software but has no policy I know of > regarding Open Source and my contract is totally free of such restriction. > I'll try to get some answer internally but I don't expect much (nor > fast)... > If it doesn't work out, you can still outline the general idea, and we'll take it from there. There are no copyright issues from simply talking about ideas :-) 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... 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 :-) Still, while working on it and thinking how we currently do migrations at >>> work, with sql files, I felt like the approach taken in the documentation >>> was a bit "incomplete": each time a new migration is added, the model is >>> generated again and then one should look for compilation error. Don't get >>> me wrong, it's already pretty and for sure needed. Yet the complete >>> disparition of the previous model bothers me. At work we do like this and >>> from times to times it bits us back. How was it before? Why did we change >>> this stuff this way? Is it really the correct name for the old Foo columns? >>> >> >> That's true. It would be useful to maintain versions of the schema also >> in the "current" Java code, not only in version control. Sure, version >> controlling generated sources is one way to tackle the problem (there are >> some discussions around that on this list). But having all versions at >> runtime in some form might also be useful. We have a pending feature >> request for this, but haven't thought this through yet: >> https://github.com/jOOQ/jOOQ/issues/4232 >> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2FjOOQ%2FjOOQ%2Fissues%2F4232&sa=D&sntz=1&usg=AFQjCNGHO3vLhEMuejluyQ28ZTKXDKMuHQ> >> > > Well, I'm unsure about annotation there. What if I deleted some columns, > what to annotate? And changes could be subtler, like some type change, and > then how to reflect this ? What if multiple changes were done over time ? > You're right. Not so fast ;) > > Actually we have the issue currently in our production code : changes over > time are only visible in the migration files. > Which has two main drawbacks : > - migrations aren't typesafe (and in 10+ years of ongoing dev, typo were > made, actually they happen something like twice a year) > - in case of issue, figuring out what was before isn't always easy > (especially when some migration actions were done, like altering data to > fit into the new schema) > Yes, the migration is only a delta. Having actual snapshots is much better. That's what you get when you check in jOOQ generated code, but that still doesn't give you access to more than one version at a time. > Interesting, could you give an example about this subclassing that you're >> doing? >> > > Well, that's pretty simple, for example: > package org.jooq.example.model.tables; > > public class Author extends > org.jooq.example.model.previous.v3.tables.Author { > > } > 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: AUTHOR.as("t"); Also, the UpdatableRecord in Author is o.j.e.m.p.v3.tables.records.AuthorRecord, not a subtype of it. In addition to this, we might add formal support for table inheritance some time in the future (Oracle / PostgreSQL ORDBMS feature). In that case, we'll make further assumptions about inheritance in generated code. This might not apply to you directly, but the changes that will be required may. 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. I'm thinking of doing it for every stuff from the generated model which is > used at least once outside of the migration steps. > > So when a new migration is done, I simply have to change the extend to v4 > and then typesafety kicks in and tells me of any issue. > How about actually referencing v4 from all of your code, and simply search-replace package names upon migration? 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 while doing it I was wondering about the verbosity of this > approach. I end up with all tables/sequences/whatnot defined whereas only > the delta really matters. That's why I'm unsure about it. On the other > hand, type safe migration rocks :) > Yep. See my suggestions above that are limited to package names instead. Specifically, if you find anything missing from jOOQ's DDL support, I'd >> love to know - there's still lots of room for improvement! >> > > Well, one little issue was the lack of unique support at table creation, I > had to add the constraint later on: > create.createTable(AUTHOR) > .column(AUTHOR.ID, SQLDataType.INTEGER.nullable(false)) > .column(AUTHOR.FIRST_NAME, SQLDataType.VARCHAR.length(50)) > .column(AUTHOR.LAST_NAME, > SQLDataType.VARCHAR.length(50).nullable(false)) > .column(AUTHOR.DATE_OF_BIRTH, SQLDataType.DATE) > .column(AUTHOR.YEAR_OF_BIRTH, SQLDataType.INTEGER) > .column(AUTHOR.ADDRESS, SQLDataType.VARCHAR.length(50)) > .execute(); > > create.alterTable(AUTHOR).add(constraint("PK_T_AUTHOR").primaryKey( > AUTHOR.ID)).execute(); > Yes, that would indeed be useful. It's a pending feature request: https://github.com/jOOQ/jOOQ/issues/4050 > On the way I spotted as well that the constraint name isn't put in the > generated stuff (at least as far as I've seen), which I guess could be an > issue sometime (when changing it mainly, by dropping/create). Having it as > well in the generated class would be sweet. > You're right, I had missed this feature too, in the past, but forgot to create a feature request for it. Here it is, now: https://github.com/jOOQ/jOOQ/issues/4901 Let me know if you come to think of another missing feature. Best, Lukas -- 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.
