View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007609 | Taler | wallet-core | public | 2023-01-27 11:31 | 2023-02-21 15:39 |
| Reporter | Florian Dold | Assigned To | sebasjm | Resolution deadline | |
| Implementer | Reviewer | ||||
| Release signed by | Deployed by | ||||
| Verifier | Communicator | ||||
| Data protection authority notification required | No | ||||
| CSIRT notification required | No | ||||
| Estimated effort (hours) | Actual effort (hours) | 0 | |||
| Fast-track | No | ||||
| Work package | none | ||||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Target Version | 0.9.2 | Fixed in Version | 0.9.2 | ||
| Summary | 0007609: document how DB migration and schema changes work | ||||
| Description | Currently that info is only there in the code. | ||||
| Tags | No tags attached. | ||||
| document here: https://git.taler.net/docs.git/tree/design-documents/034-wallet-db-migration.rst Right now a migration can fail for multiple reasons, like a new field or a problem in the fixup. If that happen the wallet can't be used. We can have a "recovery mode" that will try to restore stores individually in order to save what it can from an old database. For example: * backup providers (host and keys) * coins * exchange urls and pub key * auditors urls and pub key * transactions It may end in data loss, but luckily not in money loss. This may be useful for situations someone need to use the wallet and can wait for a fix to be deliver. Also, maybe we want to clarify what happen to ongoing process when the wallet is upgrading: * if there is an withdrawal operation in progress and the wallet is restarted with an upgrade, how can we guarantee that no upgrade will make them fail and loss money? * if we can't, should make the wallet upgrade non-automatic and tell the user "click here to upgrade, is not recommended to upgrade if you have ongoing transfer in progress" | |
| I think having a "recovery mode" is something that could be useful. I've filed a separate issue for this recovery mode: 0007677 Also, ongoing withdrawal operations should never be affected badly by a DB upgrade, unless we screw up really badly. So there should never be the need to ask the user before an upgrade. We'd be better off just storing a copy of the database when doing a major upgrade, but the design we've documented already requires this. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2023-01-27 11:31 | Florian Dold | New Issue | |
| 2023-01-27 11:31 | Florian Dold | Status | new => assigned |
| 2023-01-27 11:31 | Florian Dold | Assigned To | => Florian Dold |
| 2023-01-31 21:01 | sebasjm | Note Added: 0019726 | |
| 2023-02-11 13:40 | Florian Dold | Assigned To | Florian Dold => sebasjm |
| 2023-02-11 13:40 | Florian Dold | Status | assigned => feedback |
| 2023-02-11 13:40 | Florian Dold | Note Added: 0019802 | |
| 2023-02-13 20:26 | sebasjm | Status | feedback => informing |
| 2023-02-13 20:26 | sebasjm | Resolution | open => fixed |
| 2023-02-21 15:39 | Christian Grothoff | Fixed in Version | => 0.9.2 |
| 2023-02-21 15:39 | Christian Grothoff | Status | informing => closed |
| 2023-04-13 18:36 | Florian Dold | Category | wallet (TS core) => wallet-core |