-
-
Notifications
You must be signed in to change notification settings - Fork 760
Expose reading errors #148
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
Conversation
let cursor = try Row.fetchCursor(db, "SELECT * FROM persons) while let row = try cursor.step() { ... }
…nce DatabaseCursor.step() has returned nil, all subsequent calls return nil. (addresses #147)
…w database errors
…ds on fetchCursor.
…ible & TableMapping).fetchCursor(_:)
…DatabaseCursor.enumerated since it can't be implemented yet
…nce` and `DatabaseIterator`.
…now throw database errors.
@kdubb, @swiftlyfalling This PR looks ready. Errors from FetchedRecordsController and DatabaseStorage are not handled yet, but this is not a regression: we can deal with those errors in future PRs. See: |
… bug that needs to be fixed.
…ement) should not throw
…g the fetch request statement right from the initializer and the setRequest() method.
All right, folks! GRDB v0.91.0 has shipped :-) Thanks again @kdubb for the kick! |
@kdubb @swiftlyfalling I'm currently writing an app that needs to properly handle database errors on a locked device. I can not tell you how much GRDB owes to you ❤️ |
@groue: Yes, that's (unfortunately) an all-too-frequent issue if one wants to support background execution & Data Protection on an iOS device. These changes are fantastic and make it all possible. 🎉 |
This pull request addresses #147 and changes GRDB so that it exposes reading errors.
Until now, GRDB would assume that both SQLite and the database file(s) were fundamentally trustable. Well, the file system is not trustable. Applications have to be able to deal with I/O errors.
The fetching methods have thus been updated:
Usage: