Best practices: merging branches that use different databases

[stefano.menci]

@jshaffstall

Think of the schema as a sanity check, a way of answering the question, “Is Database A compatible with the code?”

I don’t agree.
All my apps have mismatching schemas, and all my apps work just fine.
The apps work well, the auto-completion works well, the only thing that doesn’t work is the UI that in some apps, the ones with multiple databases, can’t get rid of the mismatch warning on both.

There is a warning, I have no way to remove it… it doesn’t help my sanity at all.

@jshaffstall

My previous post describes the steps.

I don’t see those steps. I see them in your previous answer to my previous question, but… I’m still in the dark.

I can think of the following workflow that would make sense:

1. check out dev
2. click on the button to fix the schema mismatch and make sure the app schema matches the database
3. check out prod
4. click on the button to fix the schema mismatch and make sure the app schema matches the database
5. merge dev into prod
6. click on the button to update the database to match the schema

Unfortunately this workflow doesn’t work, because step 2 breaks the schema of prod and step 4 breaks the schema of dev, so it’s impossible to have the app schema matching the database on both dev and prod.

At this point what do I do?
Do I trust that button that says it will modify my production database, making decisions based on two schemas, one of which is wrong?
I can’t trust it!

@stefano.menci

It would be much simpler to have one button that asks you to pick one database to modify and one database to use as template. Simple and clear. No need for a schema.

This one I would understand what it does, I wouldn’t need a workflow filled with checkouts and merges and I would trust it.