🚀🚀
а идея механизма работы транзакций использован в эффекторе для поддержки вызова эффектов внутри других эффектов при форке)
Size: a a a
2020 November 14
🚀🚀
типа, пока ты вызываешь асинхронно только эффекты (запросы к idb) — то можно сохранять и восстанавливать скоуп (транзакцию) в котором это происходит
NF
кстати больше всего в indexeddb впечатляют композитные ключи (по нескольким полям в совокупности), прям киллер фича, полноценных аналогов особо нет
это же вроде просто обычные индексы, такие же как в реляционных бд
R
наткнулся на то, что attach не принимает стор после effector-storage
R
2020 November 15
🚀🚀
это же вроде просто обычные индексы, такие же как в реляционных бд
я про аналоги на фронте своими силами, а на бэке понятное дело такое есть, потому и интересно было заюзать на фронте). это не индексы, это именно композитные ключи — когда ключ сущности зависит от значения нескольких полей вместо одного
IndexedDB supports composite or array keys, a key comprises two or more fields. This could be useful when you have an object, but none of the properties alone is uniqueIndexedDB supports composite or array keys, a key comprises two or more fields. This could be useful when you have an object, but none of the properties alone is unique
https://golb.hplar.ch/2017/09/A-closer-look-at-IndexedDB.html
IndexedDB supports composite or array keys, a key comprises two or more fields. This could be useful when you have an object, but none of the properties alone is uniqueIndexedDB supports composite or array keys, a key comprises two or more fields. This could be useful when you have an object, but none of the properties alone is unique
https://golb.hplar.ch/2017/09/A-closer-look-at-IndexedDB.html
🚀🚀
store: storageStore as Store<...> типа форсим упрощение типа без потери реальной корректности
NF
я про аналоги на фронте своими силами, а на бэке понятное дело такое есть, потому и интересно было заюзать на фронте). это не индексы, это именно композитные ключи — когда ключ сущности зависит от значения нескольких полей вместо одного
IndexedDB supports composite or array keys, a key comprises two or more fields. This could be useful when you have an object, but none of the properties alone is uniqueIndexedDB supports composite or array keys, a key comprises two or more fields. This could be useful when you have an object, but none of the properties alone is unique
https://golb.hplar.ch/2017/09/A-closer-look-at-IndexedDB.html
IndexedDB supports composite or array keys, a key comprises two or more fields. This could be useful when you have an object, but none of the properties alone is uniqueIndexedDB supports composite or array keys, a key comprises two or more fields. This could be useful when you have an object, but none of the properties alone is unique
https://golb.hplar.ch/2017/09/A-closer-look-at-IndexedDB.html
я был бы больше рад если бы было read only (ну или почти read only) хранилище, вроде кликхауса
NF
с очень быстрой записью в конец и хорошей компрессией
NF
ведь чаще всего нам это и нужно, вести историю операций, сохранять действия пользователя и позволять их откатить(компенсировав новой записью)
🚀🚀
я был бы больше рад если бы было read only (ну или почти read only) хранилище, вроде кликхауса
такое тоже есть. если тебе не нужна запись в хранилище, то работаешь через транзакции с параметром readonly, для таких транзакций нужно радикально меньше синхронизаций и блокировок, чем для readwrite
🚀🚀
ток для меня в итоге всё упирается в отсутствие подписки на апдейты, даже в localstorage есть 😒
NF
хранить объекты тоже круто, но пользователю выгоднее хранить объекты собранные из лога его действий совершенных над ними
🚀🚀
хранить объекты тоже круто, но пользователю выгоднее хранить объекты собранные из лога его действий совершенных над ними
ну это всё же object storage а не column db)
🚀🚀
по сути column database это же для аналитики, а от типичного запроса аналитики на фронте, девайс помрёт раньше чем его indexeddb))
NF
такое тоже есть. если тебе не нужна запись в хранилище, то работаешь через транзакции с параметром readonly, для таких транзакций нужно радикально меньше синхронизаций и блокировок, чем для readwrite
их всё равно достаточно много, и если ты начнешь писать из разных вкладок одновременно, это будет лок лок лок
🚀🚀
аа, ну так да
🚀🚀
можно сплавлять всё одному воркеру, чтобы писал только он
🚀🚀
это по крайней мере хотя бы так решаемо, в отличии от невозможности подписаться на апдейты)
NF
по сути column database это же для аналитики, а от типичного запроса аналитики на фронте, девайс помрёт раньше чем его indexeddb))
Программы не несут ответственности. Это проблема которую сейчас трудно решать, я бы даже сказал слишком трудно. А это чуть ли не главное в UX.