hzrd149 @hzrd149 - 3mo
#asknostr does anyone know of a generic collection of pre-built SQL queries that can be used to store events in a SQLite database? I'm not looking for an implementation I just want the queries or ways of building the queries. I'm trying to figure out the best way for noStrudel to use sqlite-wasm in the web and then native sqlite on mobile and possibly better-sqlite3 for node.js. all of these implementations are different and Id like to avoid having to re-write all the SQL myself bonus points if it supports FTS5
If there aren't any better options Ill probably go take apart nostr:npub1v0lxxxxutpvrelsksy8cdhgfux9l6a42hsj2qzquu2zk7vc9qnkszrqj49's @snort/worker-relay package
sqlite anything is 100x times faster than indexeddb. I don't think anyone could build a database slower than indexeddb... That said kierans worker relay package is really great for web apps https://www.npmjs.com/package/@snort/worker-relay
I'm using it now and it sucks, indexeddb is so slow it somehow manages to fail to be a key value store
I've managed to make it work and it can hold about 10k events without freezing the browser. but it just bugs me that its taken so long for web apps to get a decent database implementation
Found this article after digging around a lot https://jlongster.com/future-sql-web It shows its faster ( for 100k+ entries ) to load a wasm of sqlite into memory and then run it off an in-memory file system than it is to use indexeddb https://priceless-keller-d097e5.netlify.app/
No but it looks a lot like another package I made last year :) https://github.com/hzrd149/nostr-idb Ill give it a try and I hope its faster, but it wont make me stop hating indexeddb
Wait, so storing strings is faster than objects? Did you test this anywhere and is that the reason your implementation is faster? Also how many events did you test it with. The most I was able to get with my implementation was 100k
semisol @semisol - 3mo
also have you tried multithreaded with page locks?
multi-threading in the browser doesn't make sense most of the time. if something is causing the page to lock up then its better to optimize it than offload it to a background thread That said I've thought about trying to offload the database part of the app to its own thread, but then you run into bottlenecks with transferring objects between threads 😞
