Critical error report! resulting in data loss

[mideruit]

Hi,

I’m posting this here because I am unable to create a new topic in bugs.
I’ve already shared this with Ryan, but he redirected me to the forum.
I am unable to share my entire project here, but I’ll try to explain the bug anyway.

The bug happened when checking out an older commit with a totally outdated database schema, and then switched back my latest commit. It might also be because a new branch has been created in the meantime.
The problem is that I can either select the right schema, but then when I edit the code, I get an error message saying " You’re viewing an old version of the app - you shouldn’t be able to edit it! This page will now refresh." This keeps popping up in an infinite loop.
I could resolve this by selecting an older schema, but then I lose all of my database schema changes and corresponding data.

The state of the system is now even more bugged since I’m getting a “Schema mismatch” error. When selecting the appropriate schema here, the next popup proposes to delete these columns while they are actually supposed to be kept. It seems like the system completely lost track of the selected schema since they are reversed.

This is the schema mismatch error:

When clicking “The app is correct”, it actually proposes to delete these fields, rather than adding them!

[Album] imgur.com

(I’m not able to upload more than one media file on this forum…)

For me personally it’s not a big issue to fix this problem manually, but imagine the consequences if this issue wouldn’t be solved, the consequences could be devastating! If there is a dev around here that would like to take a look on teamviewer or whatever, be my guest.

[gabriel.duro.s]

Hi @mideruit ! Welcome to the forum!

When you check an older version of your app, your app will think that the database still is like it was in that time, but it’s not.

In your case it seems that you only added columns during the time, but it could be that columns or entire tables were deleted from your database.

So to prevent errors from trying to use a column that is not in the database, you should match both before continuing.

I think that 99,9% of the time you will match your app (that is, the files that tell your app the schema stored in your datatables) to the actual database. What this will cause is just a change of Settings that will create another branch starting from the old commit you checked out.

If you wish to continue further changes from that commit, you can normally. In that case I would recommend you merging with a more recent commit first.
If you do not wish, than you can ignore and continue your life normally back to your newest commit / branch.

[stefano.menci]

I would add to what @gabriel.duro.s says that checking out a commit without a branch will allow you to see that commit in read only mode.

If you want to change something you can create a new branch on that commit, then check it out, and you will be able to make changes.

When an app has two branches and both the branches use the same database and the database schema has changed at some point between the two branches, checking out one of the two branches will trigger the complaint that the database schema doesn’t match the app settings.

Now it’s up to you NOT to change the database.

I agree that the UI should make it more difficult to change the database.

[mideruit]

Creating a new branch and then merging it back actually resolved my issue, thumbs up.

Anyways, the " You’re viewing an old version of the app" loops that keep popping up after I checked out an old commit and selected the right schema, is still a bug. I can’t imagine user unfriendly loops being part of the intended behaviour. Also the “Schema mismatch” loop is also very user unfriendly.

[gabriel.duro.s]

@stefano.menci

I would add to what @gabriel.duro.s says that checking out a commit without a branch will allow you to see that commit in read only mode.

If you want to change something you can create a new branch on that commit, then check it out, and you will be able to make changes.

Yes, you’re right. Thank you for correcting/completing that, specially about the difference between checking out the commit rather than creating a new branch from that commit.

@mideruit

I can’t imagine user unfriendly loops being part of the intended behaviour

I kinda agree about that “loop”. I think it protects the dev most of the time by preventing a unintended change to the database just by viewing an old commit.

@mideruit

Also the “Schema mismatch” loop is also very user unfriendly.

@stefano.menci

I agree that the UI should make it more difficult to change the database.

However I also agree that the diff page for schemas (and the UI for merging conflits) is somewhat not user-friendly. I think there’s already a Feature Request for that, if I’m not mistaken.

[hugetim]

@gabriel.duro.s

I also agree that the diff page for schemas (and the UI for merging conflits) is somewhat not user-friendly. I think there’s already a Feature Request for that, if I’m not mistaken.

Here’s one (not as clear as it could be):

[Beta] Migrating Databases issues

In a trial run of this functionality: I initially found the direction of the arrows in the “big blue buttons” confusing. I clicked on the button pointing to the correct, updated schema (whereas the intention seems to be that the arrow points in the direction of the migration?). The auto-migration suggested was wrong–that is, different from what I intended. I had renamed one column and deleted a second column. The migration proposed deleting both columns and creating a new one (which would …

I’m not sure whether there are others.