wip; Store some client settings #1167
Conversation
PIG208
force-pushed
the
pr-settings
branch
2 times, most recently
from
d5c014e to
370a328
Compare
This has been addressed in Greg's upstream PR: https://git hub.com/simo lus3/drift/pull/3022 Signed-off-by: Zixuan James Li <[email protected]>
Signed-off-by: Zixuan James Li <[email protected]>
Signed-off-by: Zixuan James Li <[email protected]>
|
Thanks for taking this on! Looking forward to it. One first high-level comment: in the branch we merge, let's have at least one of these two settings get added as its own separate commit, complete with a migration. That way we have a nice demonstration of what it'll look like to add each new setting in the future. |
Signed-off-by: Zixuan James Li <[email protected]>
Signed-off-by: Zixuan James Li <[email protected]>
Signed-off-by: Zixuan James Li <[email protected]>
The name "unset" was chosen instead of "default" because the latter is a keyword. We could write a custom `TypeConverter` to use "default" instead, but `textEnum` is more convenient. Signed-off-by: Zixuan James Li <[email protected]>
Signed-off-by: Zixuan James Li <[email protected]>
These were supposed to be updated in commit fc80be1 where we replaced loadGlobalStore with getGlobalStore. `LiveGlobalBindings.load` is the only thing left analogous to the previously referred to `loadGlobalStore` method. To avoid direct referencce to this specific implementation on `GlobalStore`, mention that loading it for the first time is expected to be asynchronous instead. Signed-off-by: Zixuan James Li <[email protected]>
Signed-off-by: Zixuan James Li <[email protected]>
| from2To3: (m, schema) async { | ||
| await m.createTable(schema.globalSettings); | ||
| }, | ||
| from3To4: (m, schema) async { | ||
| await m.addColumn( | ||
| schema.globalSettings, schema.globalSettings.browserPreference); |
There was a problem hiding this comment.
db: Start generating step by step migration helper
https://drift.simonbinder.eu/migrations/step_by_step/#manual-generation
Hmm, interesting. Yeah, this seems useful — I think this migration to 4 is already an example where this structure lets the new migration get added as just a separate thing, and with the more manual structure we'd have to have logic for it to interact with the migration to 3.
| import 'package:drift/drift.dart' as i1; | ||
| import 'package:drift/drift.dart'; // ignore_for_file: type=lint,unused_import | ||
|
|
||
| // GENERATED BY drift_dev, DO NOT MODIFY. |
There was a problem hiding this comment.
Let's give this a .g.dart name, so it's clear in a more uniform way that it's generated.
| # Generated code from drift can contain unused local variables. | ||
| - lib/model/database.g.dart |
There was a problem hiding this comment.
This should be reported as a bug in Drift — it's fine for the generated code to do this but then it should contain an ignore comment for it.
There was a problem hiding this comment.
Filed simolus3/drift#3384 for that.
| /// The visual theme of the app. | ||
| /// | ||
| /// See [zulipThemeData] for how themes are determined. | ||
| /// | ||
| /// Renaming existing enum values will invalidate the database. | ||
| /// Write a migration if such a change is necessary. | ||
| enum ThemeSetting { |
There was a problem hiding this comment.
Let's put these enum definitions in a new file lib/model/settings.dart.
Then that can also be the home of other logic we add in the future for individual settings.
Work towards #97.