Branch copy has old schema version
Hi 👋
I have an issue that a new branch does not include all columns of the base branch.
Workspace ID:
5713tr
New branch: test-template
Base branch: dev
test-template has previously existed, and I recreated it soon after deleting it. Could it be that it was restored instead of recreated?
Edit: This is a postgres enabled database.12 Replies
Hi Michael, thanks for reaching out. We'll take a look.
Which database is this branch on?
Nevermind, found it 👍
Which tables are affected? I see there are some tables missing as well. I'll keep digging.
Oh, sorry, didn't mention that.
column eventSeries.languages does not existNo worries. Could be a restore given the number of tables that are missing between
dev and test-templateInteresting. I've just created
test-template2 and it had the same issues. Then I've tried a completely new name, I'm sure never existed something-new and both those branches are missing the new columns. It seems that it's not about the target's branch name, but there's an issue reading the base branch.
FYI: I will now directly alter the schema for test-template2 using PSQL while you are investigating (to work on what i need to work on :P). OK?Yes that's fine Michael, thanks for the added info. I can create branches through the support access myself so we can continue to investigate. I'll keep you posted.
Identified the issue, we're working on a fix, thanks for bearing with us, Michael.
Hi Michael, thanks for bearing with us. We've pushed a fix for this issue (I tested it there with the
support-test-1 branch). One slight caveat, however; the dev branch has a long migration history, so branches created off it take time to complete. When you create a branch off of dev you may notice a timeout and an initial discrepancy in the tables. If you wait a few minutes and refresh the page, the branches will match. We're looking to improve this experience moving forward but the root issue has been resolved.Okay, thanks!
Is there a way to squash the migration history? I think I've read this somewhere in a pgroll issue, but am not sure if it's applicable or even possible.
Can we maybe just create a new dev branch where we create the schema ourselves, e.g. by using DBeaver or Drizzle? Or would this have a similar issue?
We're looking into improving the experience. Currently there's no way to squash the migration history but something like a progress indicator rather than having half the tables appear then another half later would be better 😆 as for creating a new schema on a "blank" branch this wouldn't be possible. You'd have to use a new database and maybe dump and import the schema.
Thanks for the info. 👍
A quick follow-up question.
You'd have to use a new database and maybe dump and import the schema.What's the simplest way to achieve this so we don't generate too many migrations again? Someone in our team changed the schema too soon, using the ui, making the branch stay in a bad state. So we want to tackle this issue rather sooner than later.
This should be achievable with pg_dump for a postgres-enabled database (or similar tool that introspects the schema). If you export from the database with the long migration history, then import that
.sql file into a brand new database you shouldn't have the same issues with a long migration history, so branch creation should be quicker.
Of course, this isn't an ideal workaround. We're still working on improving pgroll to handle long migration histories better and with more transparency.
For the moment, you should still be able to create branches off of the dev branch, it just takes a few minutes for all the tables to appear.Okay, thanks! We'll see what we do.
I'll just double check with the team, Michael, but I think the migration history (the views created by pgroll within the schema) will be exported by
pg_dump so I'll do some testing to see if there's an easy way not to export them. That should give you a "fresh" database from a migrations history point of view. I'll keep you posted.That would be great! Thank you 🙏