Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid dumping sqlite system tables into schema #735

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

mattbnz
Copy link

@mattbnz mattbnz commented Jun 30, 2022

If you create a sqlite3 database with an integer ID column using AUTOINCREMENT, pop ends up with a broken migrations/schema.sql file that prevents at least tests which try to initialize databases with it, and I'm guessing perhaps other actions that use it as well from functioning correctly.

The schema is broken, because sqlite includes includes some of its system tables in the .schema output by default (in particular sqlite_sequence, which is only created in the DB when an AUTOINCREMENT column is created, which explains why this bug is probably not hit often in pop, given the default usage of UUID IDs), but you're not allowed to recreate those tables yourself. So if you dump schema with .schema and then pipe that back into sqlite (as LoadSchema attempts to do) you get an error.

The -nosys option can be used to prevent this behaviour.

mattbnz added 2 commits July 1, 2022 00:26
sqlite includes some of its system tables in the .schema output by
default, which means it cannot be imported back directly into sqlite (as
LoadSchema attempts to do), as you're not allowed to recreate these
tables.

The -nosys option can be used to prevent this behaviour.

Particular issues have been seen with the sqlite_sequence table, which
appears if you use an AUTOINCREMENT column as an ID for example.
@sio4
Copy link
Member

sio4 commented Jul 2, 2022

Thanks for the issue reporting with PR!

I quickly checked the option but I found that the option was added from version 3.34.0 on 2020-12-01, and I don't think all users are using this version or higher yet. Actually, the current ubuntu-latest of Github Action environment also still on 20.04 LTS [1] and it uses version 3.31.1 yet.

I think using that option is very reasonable if we can make sure the version is mostly popular but could you please suggest alternative way to archive the goal? Otherwise, let's keep this PR open until we can move forward.

[1] https://github.com/actions/virtual-environments#available-environments

@sio4 sio4 self-assigned this Jul 2, 2022
@sio4 sio4 added breaking change This feature / fix introduces breaking changes s: hold This PR shouldn't be closed, but should wait for further work. enhancement New feature or request labels Jul 2, 2022
@mattbnz
Copy link
Author

mattbnz commented Jul 2, 2022

If we can't use the option then we'll have to resort to parsing the schema dump and removing the tables prefixed sqlite_ manually, which doesn't sound particularly attractive to me.

@sio4
Copy link
Member

sio4 commented Jul 2, 2022

If we can't use the option then we'll have to resort to parsing the schema dump and removing the tables prefixed sqlite_ manually, which doesn't sound particularly attractive to me.

Yeah, I totally agree with your comment. It is not convenient for your condition with AUTOINCREMENT and your patch with the option is totally reasonable (as I already said) for users who use the new version of sqlite3. However, since it is a breaking change for users who still use buffalo with the old version of sqlite3, their workflow will be broken if we just apply this patch.

Let's try to find an alternative way both within the code and workaround externally.

@sio4 sio4 added this to the Backlog milestone Sep 16, 2022
@sio4 sio4 self-requested a review November 3, 2022 09:13
@sio4 sio4 modified the milestones: Backlog, v6.1.1 Jan 12, 2023
@sio4 sio4 changed the base branch from main-original to main January 13, 2023 13:50
Copy link
Member

@sio4 sio4 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @mattbnz, Thank you for your patience!
I think we had enough time and now it is time to merge this PR into the main! (time flies, also Ubuntu 22.04 is now the latest image for Github Action, and I believe most developers already migrated to the newer development environment along with sqlite3 3.34.0 or later.)

I rebased the PR to the recent main branch and reviewed your change, and I would like to ask for small changes. Please let me know if you have opinions on my comment.

Thanks again!

dialect_sqlite.go Show resolved Hide resolved
executors.go Outdated Show resolved Hide resolved
@sio4 sio4 modified the milestones: v6.1.1, v6.2.0 Jan 18, 2023
@mattbnz mattbnz requested a review from sio4 January 29, 2023 06:34
@mattbnz
Copy link
Author

mattbnz commented Jan 29, 2023

please take another look - addressed those comments and rebased my fork to the current head.

Copy link
Member

@sio4 sio4 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's try it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking change This feature / fix introduces breaking changes enhancement New feature or request s: hold This PR shouldn't be closed, but should wait for further work.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants