Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Observing changes from two tables and merging into a single array #2090

Open
lukasb opened this issue Nov 5, 2024 · 3 comments
Open

Observing changes from two tables and merging into a single array #2090

lukasb opened this issue Nov 5, 2024 · 3 comments

Comments

@lukasb
Copy link

lukasb commented Nov 5, 2024

I'm working on an app that has a main data table and a table of queued updates. I have a single in-memory array of items, which combines entries from the main table and the queued updates in sort of a complicated way (pull everything from main table, if an item has an entry in the queued updates table replace with that, unless the update is a deletion, in which case remove. If there's an entry in the queued updates table that isn't in the main table, include that as well.)

I want to observe both tables and modify the in-memory array appropriately.

As far as I can tell, I can't use liveQuery, because I don't want to have a second copy of my main table in memory. However, I know use of Dexie.Observable is discouraged. Any recommendations?

@dfahlander
Copy link
Collaborator

I still think you should be using liveQuery and use the {cache: 'immutable'} option in Dexie constructor. Within the callback of liveQuery you could query both tables according to your algorithm and return a final result.

By using {cache: 'immutable'}, the cache will not have to maintain a deeply cloned copy of the queries.

In the end, your RAM will maintain both the intermediate results and the derived result (the return value from your liveQuery callback), but this only regards to the array of references to objects - the objects themselves would not be duplicated unless you clone them when computing the result. Probably the arrays of references would take negligible RAM.

If your goal would be to heavily optimize RAM even more, you could use the option { cache: 'disabled' } and the intermediate query results won't be cached at all - only the result of your querier callback.

@lukasb
Copy link
Author

lukasb commented Nov 7, 2024

Thanks. The querier I provide to useLiveQuery can only observe a single table though, right? So I'll need two useLiveQuery statements, each one will look at both tables and modify my in-memory array. The querier will basically be equivalent for both.

@dfahlander
Copy link
Collaborator

Thanks. The querier I provide to useLiveQuery can only observe a single table though, right? So I'll need two useLiveQuery statements, each one will look at both tables and modify my in-memory array. The querier will basically be equivalent for both.

No, there's no such limitation in the querier. You can query multiple tables in loops or however you want, even possible to query multiple databases. The only restrictions are that your queries are read-only (no add, put or update) and that you don't await non-dexie promises (such as fetch() etc).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants