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

DROP TABLE seemingly not working #157

Closed
egrimmius opened this issue Dec 20, 2016 · 8 comments
Closed

DROP TABLE seemingly not working #157

egrimmius opened this issue Dec 20, 2016 · 8 comments
Labels

Comments

@egrimmius
Copy link

egrimmius commented Dec 20, 2016

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()

    // v26
    migrator.registerMigrationWithDisabledForeignKeyChecks("v26", migrate: { db in
        
        // Create test table...
        try db.create(table: "tblTest") { t in
            t.column("testID", .integer).primaryKey(onConflict: nil, autoincrement: true).defaults(to: 1)
        }
    })

    // 27
    migrator.registerMigrationWithDisabledForeignKeyChecks("v27", migrate: { db in
        
        // Drop...
        try db.drop(table: "tblTest")
    })

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.

@egrimmius egrimmius changed the title DROP t DROP TABLE seemingly not working Dec 20, 2016
@egrimmius
Copy link
Author

I also tried to drop a table outside of DatabaseMigrator in the same database queue (there's only one, initialized from a singleton):

do {
try MySingletonStore.sharedStore.grdbQueue.inDatabase { db in
try db.drop(table: "tblTest")
}
}

No error was thrown, but tblTest was not dropped either.

@groue
Copy link
Owner

groue commented Dec 21, 2016

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.

@groue groue added the support label Dec 21, 2016
@groue
Copy link
Owner

groue commented Dec 21, 2016

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?

@groue
Copy link
Owner

groue commented Dec 21, 2016

@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.

@groue groue added bug and removed support labels Dec 21, 2016
groue added a commit that referenced this issue Dec 21, 2016
@groue groue closed this as completed in 4670026 Dec 21, 2016
@groue
Copy link
Owner

groue commented Dec 21, 2016

@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.

@egrimmius
Copy link
Author

I sure can @groue, thanks for finding and publishing a fix so quickly!

@egrimmius
Copy link
Author

@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.

@groue
Copy link
Owner

groue commented Dec 21, 2016

I'm sure you can see the FMDB heritage in GRDB. Happy coding, @egrimmius :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants