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
i.e. assume that base schema corresponds to version X instead of "0". otherwise i'm not sure how should this be integrated with an application that has extant migrations.
my thought was to create migrations record table filled with initial data in the base schema but it seems hackish somehow.
a few additional thoughts:
it seems to me that having base schema at version 0, always, and running all migrations all the time would quickly
become unwieldy
more importantly, over the years database syntax may change and older migrations may become incompatible with newer database server releases (this happened to me both with postgres and mysql).
therefore, i normally keep base schema at latest version and support migrations from older installed schemas as needed.
thanks for any advice.
The text was updated successfully, but these errors were encountered:
Hello, it is possible to have a base from different versions. Basically, the system uses the base.sql here and we start from "0" here.
So, it means, if we manage getBaseSql() to get a base.sql file in the format "base-nnnnn.sql" (where nnnnn is the version) we can trick the system to start the migration from that version.
i.e. assume that base schema corresponds to version X instead of "0". otherwise i'm not sure how should this be integrated with an application that has extant migrations.
my thought was to create migrations record table filled with initial data in the base schema but it seems hackish somehow.
a few additional thoughts:
become unwieldy
therefore, i normally keep base schema at latest version and support migrations from older installed schemas as needed.
thanks for any advice.
The text was updated successfully, but these errors were encountered: