You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Does anyone have experience or an example to share of how to implement @square/svelte-store on an IndexedDB that has multiple tables and indices?
From what I can gather, to implement IndexedDB using this library, one would not just create an INDEXED_DBStorageType but rather a StorageType for each individual table. Additionally, due to the restrictive interface of the getter/setter/deleter functions, if there were multiple indices, there would need to be a StorageType for each desired index within a table. TABLE1_KEYPATH1 ... TABLE1_KEYPATH2 ... etc, which other than having some maintenance issues, would likely face some performance issues as well (potential for duplicate, dereferenced data)
For example with Dexie, where a "key" can be a object
From what I can see, this is not compatible with the existing interfaces of getStorageItem/setStorageItem/deleteStorageItem, forcing what might be considered an anti-pattern on an implementation (storage types for each index as mentioned above, or wrap this library to JSON.stringify arguments and then JSON.parse the arguments in the functions)
Please let me know if I am missing something.
The text was updated successfully, but these errors were encountered:
Does anyone have experience or an example to share of how to implement
@square/svelte-store
on an IndexedDB that has multiple tables and indices?From what I can gather, to implement IndexedDB using this library, one would not just create an
INDEXED_DB
StorageType
but rather aStorageType
for each individual table. Additionally, due to the restrictive interface of the getter/setter/deleter functions, if there were multiple indices, there would need to be aStorageType
for each desired index within a table.TABLE1_KEYPATH1 ... TABLE1_KEYPATH2 ... etc
, which other than having some maintenance issues, would likely face some performance issues as well (potential for duplicate, dereferenced data)For example with Dexie, where a "key" can be a object
Interface for
Table.get()
From what I can see, this is not compatible with the existing interfaces of
getStorageItem/setStorageItem/deleteStorageItem
, forcing what might be considered an anti-pattern on an implementation (storage types for each index as mentioned above, or wrap this library toJSON.stringify
arguments and thenJSON.parse
the arguments in the functions)Please let me know if I am missing something.
The text was updated successfully, but these errors were encountered: