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

wip; Store some client settings #1167

Draft
wants to merge 16 commits into
base: main
Choose a base branch
from
Draft

wip; Store some client settings #1167

wants to merge 16 commits into from

Conversation

PIG208
Copy link
Member

@PIG208 PIG208 commented Dec 17, 2024

Work towards #97.

@PIG208 PIG208 force-pushed the pr-settings branch 3 times, most recently from 370a328 to e91e9d5 Compare December 17, 2024 00:28
@gnprice
Copy link
Member

gnprice commented Dec 17, 2024

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.

Copy link
Member

@gnprice gnprice left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've skimmed now through more of this code. A few other high-level comments below.

Comment on lines +142 to +125
from2To3: (m, schema) async {
await m.createTable(schema.globalSettings);
},
from3To4: (m, schema) async {
await m.addColumn(
schema.globalSettings, schema.globalSettings.browserPreference);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's give this a .g.dart name, so it's clear in a more uniform way that it's generated.

Comment on lines +7 to +10
# Generated code from drift can contain unused local variables.
- lib/model/database.g.dart
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Filed simolus3/drift#3384 for that.

Comment on lines 46 to 52
/// 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 {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

PIG208 added 16 commits January 22, 2025 13:22
Signed-off-by: Zixuan James Li <[email protected]>
… 2.23.0

We will start requiring the more recent features added in releases
since 2.5.0.

Signed-off-by: Zixuan James Li <[email protected]>
The tests are adapted from the test template generated from
`dart run drift_dev make-migrations`.

This saves us from writing the simple migration tests between schemas
without data in the future. For the test that upgrade the schema with
data, with the helper, while it ended up having more lines than the
original, the test becomes more structured this way.

Signed-off-by: Zixuan James Li <[email protected]>
An alternative to this is `dart run drift_dev make-migrations`, which is
essentially a wrapper for the `schema {dump,generate,steps}`
subcommands.  `make-migrations` let us manage multiple database schemas
by configuring them with `build.yaml`, and it dictates the
which subdirectories the generated files will be created at.

Because `make-migrations` does not offer the same level of customizations
to designate exactly where the output files will be, opting out from it
for now.

We can revisit this if it starts to offer features that are not
available with the subcommands, or that we find the need for managing
multiple databases.

See also:
  https://drift.simonbinder.eu/migrations/step_by_step/#manual-generation

Signed-off-by: Zixuan James Li <[email protected]>
We previously missed tables that are not known to the schema.  This
becomes an issue if a new table is added at a newer schema level. When
we go back to an earlier schema, that new table remains in the database,
so subsequent attempts to upgrade to the later schema level that adds
the table will fail, because it already exists.

Testing for this is blocked until zulip#1172.

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]>
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]>
Signed-off-by: Zixuan James Li <[email protected]>
Signed-off-by: Zixuan James Li <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants