This repository has been archived by the owner on Jul 23, 2022. It is now read-only.
Support future database version upgrades #80
Comments
taymonbeal
added a commit
to taymonbeal/fledge-shim
that referenced
this issue
May 21, 2021
Up until now, we basically had only one table and it had conceptually only one column, so we didn't have to worry about atomicity guarantees; everything was automatically atomic. As we prepare to store more kinds of data, we need transactional consistency, to avoid a situation where, e.g., one tab does a read-update-write and in doing so overwrites a write made concurrently from another tab with stale data. So idb-keyval is not for us anymore. This change prepares for that migration. Currently, there's no support for database versioning; if the code is deployed as-is and then later the version is upgraded, stuff will break. I'm hoping to fix this later; see google#80.
taymonbeal
added a commit
to taymonbeal/fledge-shim
that referenced
this issue
May 21, 2021
Up until now, we basically had only one table and it had conceptually only one column, so we didn't have to worry about atomicity guarantees; everything was automatically atomic. As we prepare to store more kinds of data, we need transactional consistency, to avoid a situation where, e.g., one tab does a read-update-write and in doing so overwrites a write made concurrently from another tab with stale data. So idb-keyval is not for us anymore. This change prepares for that migration. Currently, there's no support for database versioning; if the code is deployed as-is and then later the version is upgraded, stuff will break. I'm hoping to fix this later; see google#80.
taymonbeal
added a commit
to taymonbeal/fledge-shim
that referenced
this issue
May 21, 2021
Up until now, we basically had only one table and it had conceptually only one column, so we didn't have to worry about atomicity guarantees; everything was automatically atomic. As we prepare to store more kinds of data, we need transactional consistency, to avoid a situation where, e.g., one tab does a read-update-write and in doing so overwrites a write made concurrently from another tab with stale data. So idb-keyval is not for us anymore. This change prepares for that migration. Currently, there's no support for database versioning; if the code is deployed as-is and then later the version is upgraded, stuff will break. I'm hoping to fix this later; see google#80.
taymonbeal
added a commit
that referenced
this issue
May 21, 2021
Up until now, we basically had only one table and it had conceptually only one column, so we didn't have to worry about atomicity guarantees; everything was automatically atomic. As we prepare to store more kinds of data, we need transactional consistency, to avoid a situation where, e.g., one tab does a read-update-write and in doing so overwrites a write made concurrently from another tab with stale data. So idb-keyval is not for us anymore. This change prepares for that migration. Currently, there's no support for database versioning; if the code is deployed as-is and then later the version is upgraded, stuff will break. I'm hoping to fix this later; see #80.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
IndexedDB requires users to be careful about database versioning, or else code can crash or deadlock. We should figure out some form of this before FLEDGE Shim is deployed into production, to avoid having a problem that can't be fixed later.
The text was updated successfully, but these errors were encountered: