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

Saving objects using web workers #1212

Open
2 of 3 tasks
tintin10q opened this issue Apr 21, 2023 · 4 comments
Open
2 of 3 tasks

Saving objects using web workers #1212

tintin10q opened this issue Apr 21, 2023 · 4 comments
Labels
question Further information is requested

Comments

@tintin10q
Copy link
Sponsor Contributor

Describe the feature

I have a sync operation. This is an insert of a couple thousand objects with multiple relationships. When I call .save this freezes the browser for a couple seconds. I have tried splitting up the saving. This seems to be a balance act between inserting enough objects that the syncing doesn't take forever and that the screen doesn't freeze too much. I was thinking, maybe the inserting/saving could happen in a web worker instead of the main thread.

So the feature request is stop save a large amount of saves of blocking the main thread by doing this work in a web worker.

Do you think this might be possible? Also do you have any further ideas to stop blocking the main thread.

Additional information

  • Would you be willing to help implement this feature?
  • Could this feature be implemented as a module?

Final checks

@tintin10q
Copy link
Sponsor Contributor Author

tintin10q commented Apr 21, 2023

Also the objects I am inserting have composite primary keys. Is this much slower than a non list primary key?

@tintin10q
Copy link
Sponsor Contributor Author

Actually inserting 1000 object at a time fixed my issue. But this is still worth thinking about.

@CodeDredd
Copy link
Owner

Hey @tintin10q ,
have to think about it...i don't if there has to be done something in pinia-orm to make this work.

@CodeDredd CodeDredd added question Further information is requested and removed pending triage labels Apr 28, 2023
@tintin10q
Copy link
Sponsor Contributor Author

tintin10q commented May 2, 2023

Hey @CodeDredd,

I also have thought about it more. One thing that might be a cool thing to explore is storing all the store data into IndexedDB (instead of web workers). Right now, I am using pinia-plugin-persistedstate-2 along with localstorage but this just stores a stringified version of the models into one field in one object store. I think this could be much better by making a problem specific solution.

I get what your saying. Is persistent storage a feature that should belong to pinia-orm? I think yes in this case because it might be very cool to try leverage the native features from indexedDB to get super fast orm performance. This doesn't really make sense for normal pinia but I think it makes a lot of sense for pinia orm. Each modal could be a seperate objectStore which you could then query using under the hood using the IDBKeyRange. For this to work it would need to be closely connected to how pinia-orm works. I can also picture it as a plugin for pinia-orm (instead as a plugin for pinia as a whole).

Some cool features for instance from IndexedDB.

  • IndexedDB allows storing objects as is and there is no need to 'parse them from a stringified version.
  • It also supports indexes and primary keys and unique constraints.
  • Another great thing is that the indexedDB operations run off the main thread. So inserting and saving won't interrupt drawing on the screen.

I have made this repo (simple-indexedDB) recently to simplify working with indexedDB so you can get a feel for how it works if your not so familiar with it. Altough this project does not include the index stuff. IndexedDB is quite complicated to learn but I think this could be very cool.

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

No branches or pull requests

2 participants