Better support for Feast database upgrades

[pmjacinto]

Is your feature request related to a problem? Please describe.

#655 (feast 0.5.0) introduced several changes in the DB schema. Some are easier to handle (new columns) but some are harder, for instance the PK of feature_sets changed datatypes from VARCHAR to a BIGINT.

Describe the solution you'd like

As a first approach, could we have a manual DB upgrade script linked, per release, in the changelog? It would make life easier for operators, as we wouldn't need to check multiple issues for DB changes.

I think having something like Flyway integrated into the project, as suggested by @ches, would really help in making this process as painless as possible.

Describe alternatives you've considered

Additional context

[woop]

Is your feature request related to a problem? Please describe.

#655 (feast 0.5.0) introduced several changes in the DB schema. Some are easier to handle (new columns) but some are harder, for instance the PK of feature_sets changed datatypes from VARCHAR to a BIGINT.

Describe the solution you'd like

As a first approach, could we have a manual DB upgrade script linked, per release, in the changelog? It would make life easier for operators, as we wouldn't need to check multiple issues for DB changes.

I think having something like Flyway integrated into the project, as suggested by @ches, would really help in making this process as painless as possible.

Describe alternatives you've considered

Additional context

Thanks for raising this @pmjacinto. We meant to get around to this. In fact, we should have an upgrade process from 0.4 to 0.5 that describes all the steps needed, which doesnt just include the data model changes but also the steps to upgrading online clients.

[woop]

We're adding Flyway support over here to make this a bit simpler #809

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.