You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The full API of this is pending, but the gist is that the DeployMethod currently is in charge of where it gets the migrations, which is Not Great. Factoring out a MigrationStorage will allow us to easily get migrations from somewhere else, for example version control.
One of the interesting things that this can do for us is that the two different options right now for MigrationStorage can become subclasses or reimplementations of the MS instead of the DM. So for example, the first basic option is ignore_ddl, which really means any DDL that SQLT would have generated, ignore and regenerate. Well what would happen now is that ignore_ddl uses a special MS class that takes a coderef that knows how to "get" deployments from SQLT and skip the ones that would have been generated.
The next option is the ::Deprecated DM, which is more or less a straight subclass as it currently is, with the benefit that the actual DM will now stay exactly the same.
Another goal of this is that the MigrationStorage should be "queryable" in that the user can ask it what Migrations it has stored etc.
The text was updated successfully, but these errors were encountered:
The full API of this is pending, but the gist is that the DeployMethod currently is in charge of where it gets the migrations, which is Not Great. Factoring out a MigrationStorage will allow us to easily get migrations from somewhere else, for example version control.
One of the interesting things that this can do for us is that the two different options right now for MigrationStorage can become subclasses or reimplementations of the MS instead of the DM. So for example, the first basic option is
ignore_ddl
, which really means any DDL that SQLT would have generated, ignore and regenerate. Well what would happen now is that ignore_ddl uses a special MS class that takes a coderef that knows how to "get" deployments from SQLT and skip the ones that would have been generated.The next option is the ::Deprecated DM, which is more or less a straight subclass as it currently is, with the benefit that the actual DM will now stay exactly the same.
Another goal of this is that the MigrationStorage should be "queryable" in that the user can ask it what Migrations it has stored etc.
The text was updated successfully, but these errors were encountered: