Build a secondary table usable for SQL aggregates #2

New Issue

p · 2020-10-10T22:32:27+02:00

p commented

2020-10-10 22:32:27 +02:00

The main table is append-only and consists of raw events. It cannot be used for aggregates, as an iterative aproach is necessary to extract time spans of activity.

The GUI will build a secondary table when necessary. This is a relatively rare action, and SQLite aggregate functions can finally build on top of this. Retain the schema version in the user_version field.

This table will have indexes over times and an FTS5 index over window titles and window classes. (I've checked that FTS5 is enabled in Arch since 2016.)

It is an open question whether string normalisation would make sense. Avoid doing this at first, as it adds complexity.

The main table is append-only and consists of raw events. It cannot be used for aggregates, as an iterative aproach is necessary to extract time spans of activity. The GUI will build a secondary table when necessary. This is a relatively rare action, and SQLite aggregate functions can finally build on top of this. Retain the schema version in the user_version field. This table will have indexes over times and an FTS5 index over window titles and window classes. (I've checked that FTS5 is enabled in Arch since 2016.) It is an open question whether string normalisation would make sense. Avoid doing this at first, as it adds complexity.

p self-assigned this 2020-10-10 22:32:28 +02:00

Sign in to join this conversation.

No Label

WIP

easy

priority

No Milestone

No Assignees

1 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: p/wdmtg#2