New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Meta.migrateTo(Meta):Queries to generate a migration script between two Meta versions #9425
Comments
I think it could also be interesting to allow the user to "guide" the diff, in case it gets something wrong. E.g. when the diff results in a I suppose the user could already achieve this using |
Yes, clearly the "heuristics" I've mentioned should be configurable
Not sure if I understand this? |
To guide the rename heuristics the user could for instance take the I was first thinking that a new Possibly |
So a utility method like this is what I had in mind: public Meta apply(Query... queries) {
return dsl().meta(ddl().concat(dsl().queries(queries)).queries());
} |
Ah yes, that's something I also had in mind. In fact, I even thought of the same name as you for the method 👌 public Meta apply(Query... queries) { ... }
Well, we already do that when we apply several information_schema XML files, but I agree I'm not convinced of the usefulness of this. We'll see if we need it for |
In fact, I had already implemented |
|
I'm running a poll about method naming, which is probably too confusing: A better name for the method will be discussed soon |
We'll use the term |
After careful thought, I've decided that this is going to be a very central feature of the new migration APIs. Adoption of these APIs depends on the success of this feature, which is why we'll be open sourcing it. The distinction between editions will be done on a more fine-grained level. |
org.jooq.Meta
instances are becoming increasingly important representations of runtime schema meta information. Historically, they were implemented purely using JDBC'sDatabaseMetaData
, which queries the actual database dictionary views directly. But we now also have implementations taking:Catalog
,Schema
,Table
InformationSchema
object, which can be read from XMLThe above implementations are all immutable and do not depend on a live database connection. With those immutable implementations, we can now compare two versions of the meta model, and try to derive a migration script between the two versions
Things that can be detected automatically:
Catalogs(moved to Continue work on Meta.migrateTo(Meta):Queries #13654)Identities(moved to Continue work on Meta.migrateTo(Meta):Queries #13654)Collations(moved to Continue work on Meta.migrateTo(Meta):Queries #13654)Character sets(moved to Continue work on Meta.migrateTo(Meta):Queries #13654)Column reorderings (only if(moved to Continue work on Meta.migrateTo(Meta):Queries #13654)respectColumnOrder
is set)Types(moved to Continue work on Meta.migrateTo(Meta):Queries #13654)Things that can be detected using some heuristics (based on likeliness):
Renaming(moved to Continue work on Meta.migrateTo(Meta):Queries #13654)Moving(moved to Continue work on Meta.migrateTo(Meta):Queries #13654)MigrationConfiguration
Just like the
DDLExportConfiguration
, we should have aMigrationConfiguration
that governs the style of produced queries. Some examples:alterTableAddMultiple
: To add multiple columns and constraints in one single statement (default:false
)alterTableDropMultiple
: To drop multiple columns and constraints in one single statement (default:false
)dropSchemaCascade
: To use theCASCADE
syntax when dropping schemas (default:false
)dropTableCascade
: To use theCASCADE
syntax when dropping tables (default:false
)createOrReplaceView
: Whether modified views should be replaced, or dropped and created (default:false
)More have been moved to #13654
Out of scope for 3.13
Some more advanced things are out of scope for 3.13 and will be implemented later, tracked as #9656
The text was updated successfully, but these errors were encountered: