Schema migrations

[alacret]

Is your feature request related to a problem? Please describe. Happens that when you are working with several developers changes in the Database Schema breaks the application or code of the other developers.

So, when we need to change the type of a relationship or the name of a field, we can't, because that will break the code of someone else and it forces us to have to synchronize efforts which are very inefficient.

Another workaround that we have tried is to add the new field and start using it without deleting the old one, but we loose data doing that, and this could be even more sensitive in production ready apps.

We have also tried to just keep using the same field with the same name, or the same type, but that workaround makes everything more complicated really fast.

This request is proposing a workaround to achieve this in a faster and more efficient way

Describe the solution you'd like I think that if you add a way to duplicate a field on a Table it would solve many scenarios. It would allow to clone a field and rename it to start rolling out the Update on the Schema.

[andr11111]

@alacret do you mean cloning a field and its data?

[alacret]

@andrei-anisimov yes

[andr11111]

@alacret. Got you, this sounds like a good quick solution. I’ll discuss with the team.

In the long term, could this be solved if there was a way for each developer to have their own “branch” that they work against and can later push changes to a common environment? Or do you see issues with that?

[alacret]

well @andrei-anisimov definitely there is an advantage on branching, forking or versioning workspaces to have your own version and do experiments.

However, the problem with production databases remains. The problem is that when you have a deployed product, changes in the schema breaks clients that are not up to date. We have solved that by using strategies for schema and data migrations. This is achieved Usually with files that are along with the commits to be applied to the production databases when the update is rolled out. In addition to this, we use backward compatibles changes, trying to avoid breaking clients as much as possible.

We haven't faced this challenge with platforms like 8base because we haven't used them extensively, just at the top of my head this is maybe a challenge: Renaming a field, or changing a field type will break existing clients that are not up to date, those maybe be other developers or existing apps version that are not up to date. In development we have solved that by creating new fields instead of renaming an existing one, it will keep not up to date clients unbroken or at least semi-functional.

The problem with this approach is that the new field does not contain the values of the field that wants to be replaced, that's why I suggested the 'cloning field' feature. This I think that it also may be fulfilled by versioning the API, but there should be a way to keep previous versions of the schema to keep adding data the newest version.

[andr11111]

@alacret understood, added to roadmap