3 ms·
The data is in memory, and the persistence strategy is kind of up to you. So it would scale reasonably if you put the sync/persist on a different schedule to th
by jamesgpearce 4y ago
The data is in memory, and the persistence strategy is kind of up to you. So it would scale reasonably if you put the sync/persist on a different schedule to the UI - perhaps when the browser is idle.
BUT of course, this is not a library to be used with data sets of billions of rows! I'd recommend a proper RDBMS for that ;)
- mfbx9da4 4y agoYeah but I feel like it could be used for that, if only retrieval and storage could be done incrementally…
- mfbx9da4 4y agoYou’re 80% of the way there now that you have encoded SQL-like syntax now all you have to do is to translate that into raw SQL queries to be executed
- jamesgpearce 4y agoCorrect. I think this could be done, but I would need to think a little about how best to. Thank you for the idea!
- mfbx9da4 4y agoMy pleasure, happy to discuss how to architect if there’s a discord / GitHub issue. I know for a fact the react native community are pining for this.
- mfbx9da4 4y agoThis is how I see it could work: * Queries are encoded into sql and matcher functions * Whenever data is mutated a change set is emitted - eg similar to immer * This change set is used to generate SQL UPDATE statements * The change set is also sent to matcher functions, the matcher functions update the query results accordingly