Hi Patrick, In addition to what Samir said, here's further feedback:
2016-03-25 0:03 GMT+01:00 Patrick Armstrong < [email protected]>: > Actually, the more I think about it, I’m not sure keeping around the > compat version is necessary, I think the process would be like: > > For removing a column: > > 1. Drop column > 2. Run migration locally to generate schema > 3. Generate code from modified schema > 4. Deploy Code > 5. Deploy migration > If by "1. Drop column" you mean dropping it on dev from where you generate the schema, then yes, that might work. But of course, there are many other caveats. For instance: If the column is NOT NULL, and once you "4. Deploy code" you stop inserting values for that column, you will get constraint violation exceptions until you reach "5. Deploy migration" What is the difference between "2." and "3."? For adding a column: > > 1. Add column > 2. Run migration locally to generate schema > 3. Deploy migration > 4. Generate code from modified schema > 5. Deploy Code > Here, the inverse is happening when the column is NOT NULL. After "3. Deploy migration", your application will not yet insert any values for that column, and you will get again constraint violation exceptions until you reach "5. Deploy Code". So, you may only add NULLABLE columns at first, and then run "6. Generate data where column IS NULL", and "7. ALTER TABLE .. ADD CONSTRAINT .. NOT NULL" Things get even more complicated if you're adding new foreign key relationships. But in principle, your approach seems correct. Give or take the occasional caveat :) Also, I don't know MySQL well enough, but you'll have to worry about all things online DDL: https://dev.mysql.com/doc/refman/5.6/en/innodb-online-ddl.html The worst thing you can run into is an accidental table lock on a large table. If that happens, you'll wish you had a maintenance window, instead... Will jooq ignore extra columns? In that case it would be simpler and the > add case could be deployed all at once. > jOOQ does exactly what you tell it to do. For instance, if you write: ctx.insertInto(TABLE) .columns(TABLE.COL1, TABLE.COL2) .values(1, 2) .execute(); ... then, jOOQ will insert exactly into these two columns. jOOQ doesn't know that perhaps, in the meantime, your table was changed and COL2 was dropped or renamed to COL3. This is a bit less obvious when you do something like: ctx.selectFrom(TABLE) .fetch(); In this case, jOOQ will select all columns that are available from TABLE.fields(), regardless if those columns actually exist in the database. I hope this helps, 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.
