-
-
Notifications
You must be signed in to change notification settings - Fork 727
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
DROP TABLE seemingly not working #157
Comments
I also tried to drop a table outside of DatabaseMigrator in the same database queue (there's only one, initialized from a singleton): do { No error was thrown, but tblTest was not dropped either. |
Hello @egrimmius. Drop table works, it is tested. Use Xcode breakpoints to check if the code you expect to run actually runs. Print the list of applied migrations, to check if they are the ones you expect: try print(Row.fetchAll(db, "SELECT * FROM grdb_migrations")) Investigate: so far, you have claims, but no evidence. |
BTW, congrats for using registerMigrationWithDisabledForeignKeyChecks: your major migration is certainly not trivial. I know that complex migrations are not easy to write and test. I hope you have a snapshot of your old database that you can use and reuse until the migration works. Do you? |
@egrimmius My deep apologies... v0.99.0 has indeed broke something. I don't know how I could missed it. Please come back to v0.98.0, and a proper fix will ship shortly. |
@egrimmius: Could you please upgrade to the new version 0.99.1? It has fixed this egregious bug. Sorry I didn't run the full test suite for 0.99.0. |
I sure can @groue, thanks for finding and publishing a fix so quickly! |
@groue, I just tried it out, and it works great, thank you. This migration is all part of my complete transition to GRDB from FMDB. So far so good. |
I'm sure you can see the FMDB heritage in GRDB. Happy coding, @egrimmius :-) |
I had a relatively major migration tested and working a few days ago. This morning, when I went to test again, it now seems it cannot successfully drop a table. Here's my test code in migration:
var migrator = DatabaseMigrator()
I then run the migrator:
// Ready to run
do {
try migrator.migrate(grdbQueue)
} catch {
print("error occurred in grdb: (error.localizedDescription)")
}
The databaseQueue it runs on is set up like this:
// GRDB setup
var config = Configuration()
config.readonly = false
config.trace = { print($0) } // prints all sql treatments
grdbQueue = try? DatabaseQueue(path: dbPath, configuration: config)
grdbQueue.setupMemoryManagement(in: UIApplication.shared)
Then, in the output, it says the migration's transaction is committed:
PRAGMA foreign_keys = ON
CREATE TABLE IF NOT EXISTS grdb_migrations (identifier TEXT NOT NULL PRIMARY KEY)
SELECT identifier FROM grdb_migrations
PRAGMA foreign_keys
PRAGMA foreign_keys = OFF
BEGIN IMMEDIATE TRANSACTION
CREATE TABLE "tblTest" ("testID" INTEGER PRIMARY KEY AUTOINCREMENT DEFAULT 1)
INSERT INTO grdb_migrations (identifier) VALUES ('v26')
PRAGMA foreign_key_check
COMMIT TRANSACTION
PRAGMA foreign_keys = ON
However, upon rechecking, tblTest is still there. What am I missing? I first found this issue when trying to do more extensive table remodeling. Thanks.
The text was updated successfully, but these errors were encountered: