-
Notifications
You must be signed in to change notification settings - Fork 194
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
Add optional callback functions when opening database #182
Add optional callback functions when opening database #182
Conversation
Please, add |
Done. |
Travis seems to be down or something... |
Travis is not feeling well :/ but the code now passes tests if you do it offline: |
As I see in CI log, you need to run |
Ugh, thanks for the tip. Retrying... |
Travis stopped? |
Codecov Report
@@ Coverage Diff @@
## develop #182 +/- ##
===========================================
+ Coverage 77.52% 77.76% +0.24%
===========================================
Files 49 49
Lines 1366 1381 +15
===========================================
+ Hits 1059 1074 +15
Misses 307 307
Continue to review full report at Codecov.
|
Hi @noordawod thanks for your contribution! What's the reasoning for allowing these additional functions? I see some problems with opening the possibility of hooking into the migration ( |
Co-Authored-By: Vitus <[email protected]>
Hi @vitusortner. My use case: I needed to know when the database is first created (so show an onboarding screen), then when an upgrade is going to happen (show a progress indicator), and when the database is up to speed -- and then rush the user to the main screen. I see many people wanting this use case, but maybe it's just me :) About the callbacks: exposing the database instance could potentially be a problem if it isn't exposed in the first place, but I believe it is. If you do think this may cause trouble, then maybe just allow callbacks without the database instance? (new typedefs) Let me know what you think. PS: I wonder what problems do you see with this? |
Would you like having callbacks without access to the SQLite database? I can do this modification if it fits better with the architecture you want. |
I gave it a second thought and now think, that there is completely valid use cases for exposing the database. ImplementationI would prefer passing the callbacks via the generated The callback parameters final callback = Callback(
onCreate: (database, version) {},
onOpen: (database) {},
onUpgrade: (database, startVersion, endVersion) {},
);
final database = await $FloorTestDatabase
.addCallback(callback)
.build();
class Callback {
final FutureOr<void> Function(Database database, int version) onCreate;
final FutureOr<void> Function(Database database) onOpen;
final FutureOr<void> Function(
Database database,
int startVersion,
int endVersion,
) onUpgrade;
Callback({this.onCreate, this.onOpen, this.onUpgrade});
} Using What made you decide on executing the passed functions before the migrations and table creations happen? |
This should work nicely too! What's your eta for this? The decision stems from old habbits (from the JavaScript/jQuery world): the handler may return a |
If you'd find time for the implementation, I'd welcome your contribution! Based on the changes you've done, you know which places of the code base to touch. Let's try with putting the callbacks after the initialization has happened. |
On it. I'll push to this pr. |
@vitusortner |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes deployed.
Looking good so far. I'll add some documentation to the project's README files on the new callbacks and merge the PR after that. Thanks for your assistance! |
Sounds good! Maybe also add a test for the new functionality? |
Yes, it would be beneficial to verify that each callback is invoked when it should be. Unluckily, I currently see no simple way of doing that. |
Coming to |
Is now released. |
This is backward-compatible.