Ensure consistency between in-memory and database state #120

New Issue

wojtek · 2024-02-04T22:13:18+01:00

wojtek commented

2024-02-04 22:13:18 +01:00

Currently the in-memory state is slightly disconnected from the database. One needs to explicitly reload and changes are only saved on exit. This is because the idea seemed to be to edit in-memory and then save to disk. This is okay for text editing, but perhaps not so much for a collection manager.

As a database, the interaction between the in-memory state and the filesystem should be closer. Every change to the state that corresponds to a change in the database should be written. Ideally, database first, and only on success, the in-memory state is updated.

This will make some of the other changes easier to implement as it will no longer be necessary to think too much how to manage the in-memory and database states. The in-memory state will only be allowed to represent the combined library/database on-disk state.

Currently the in-memory state is slightly disconnected from the database. One needs to explicitly reload and changes are only saved on exit. This is because the idea seemed to be to edit in-memory and then save to disk. This is okay for text editing, but perhaps not so much for a collection manager. As a database, the interaction between the in-memory state and the filesystem should be closer. Every change to the state that corresponds to a change in the database should be written. Ideally, database first, and only on success, the in-memory state is updated. This will make some of the other changes easier to implement as it will no longer be necessary to think too much how to manage the in-memory and database states. The in-memory state will only be allowed to represent the combined library/database on-disk state.

wojtek added this to the v0.2.0 milestone 2024-02-04 22:13:18 +01:00

wojtek added the

chore

label 2024-02-04 22:13:18 +01:00

wojtek removed this from the v0.2.0 milestone 2024-02-04 22:17:36 +01:00

wojtek added a new dependency 2024-02-04 22:17:55 +01:00

#118 Limit the information stored in the database

wojtek removed a dependency 2024-02-10 09:32:26 +01:00

#118 Limit the information stored in the database

wojtek added a new dependency 2024-02-10 10:44:37 +01:00

#118 Limit the information stored in the database

wojtek removed a dependency 2024-02-10 10:45:11 +01:00

#118 Limit the information stored in the database

wojtek referenced this issue

2024-02-18 22:28:56 +01:00

Stale album information remains in TUI #136

wojtek added a new dependency 2024-02-18 22:29:25 +01:00

#136 Stale album information remains in TUI

wojtek commented

2024-02-19 21:08:42 +01:00

Some thoughts:

All changes go into the database first and must be committed to the backing store.
Once the database confirms the transaction, the in-memory collection can be updated.
Depending on performance needs, this can just try to re-read the database or try some short circuit.
It would be nice if the short-circuits were kept inside the database code itself.

Some thoughts: 1. All changes go into the database first and must be committed to the backing store. 2. Once the database confirms the transaction, the in-memory collection can be updated. 3. Depending on performance needs, this can just try to re-read the database or try some short circuit. 4. It would be nice if the short-circuits were kept inside the database code itself.

wojtek commented

2024-02-20 07:36:50 +01:00

The database should ideally only contain metadata not included in the library.

However, there are some tricky cases:

Add artist that is not in the library
Do not add any additional metadata
Artist is added to library
The database now contains information that it could have entirely gotten from the library.

The database should ideally only contain metadata not included in the library. However, there are some tricky cases: 1. Add artist that is not in the library 2. Do not add any additional metadata 3. Artist is added to library 4. The database now contains information that it could have entirely gotten from the library.

wojtek added this to the v1.0.0-alpha milestone 2024-02-20 13:00:16 +01:00

wojtek commented

2024-02-20 22:15:03 +01:00

The right solution may be just to use https://crates.io/crates/rusqlite

wojtek changed title from ~~Figure out database philosophy~~ to Establish a proper database interface

2024-02-22 19:29:08 +01:00

wojtek referenced a pull request that will close this issue

2024-02-22 19:30:16 +01:00

WIP: Ensure consistency between in-memory and database state #144

wojtek added reference 120---establish-a-proper-database-interface

2024-02-22 19:30:23 +01:00

wojtek changed title from ~~Establish a proper database interface~~ to Ensure consistency between in-memory and database state

2024-02-26 19:38:29 +01:00

wojtek commented

2024-02-26 19:41:56 +01:00

A quicker short-term solution that will most likely work well for quite some time - save to file after every update

wojtek changed reference from ~~120---establish-a-proper-database-interface~~ to 120---ensure-consistency-between-in-memory-and-database-state

2024-02-26 19:43:01 +01:00

wojtek referenced a pull request that will close this issue

2024-02-26 19:43:23 +01:00

Ensure consistency between in-memory and database state #146

wojtek added

enhancement

and removed

chore

labels 2024-02-26 19:43:55 +01:00

wojtek closed this issue

2024-03-01 09:00:53 +01:00

wojtek referenced this issue from a commit