Tho ya you also will have to export and import the db.. which I imagine will take a while on damus.. so not the easiest upgrade to pull off.. you can do it with minimal downtime by starting the new version side by side and running an initial export, then importing to the new while the old one runs, and then running a stream to catch up .. but yea, all very time consuming heh. 🤙
Discussion
Uhhhh yeah that will probably take a long time if I have to migrate
Ya the export can be run on a live strfry and is fast, the import is what takes a really long time.
The strfry database seems super complex. Why just not go with a “conventional” DB, like SQLite, or SQL server (with ODBC connection)? Me, I use a JSON array of Nostr events as “database”, with linear search :-) . This is a database with one record. Simple (also happens to be my first ever Nostr post) https://github.com/pedro-vicente/nostr_client_relay/blob/main/database/database.json
Damus used to run on sqlite but it couldn’t handle the load, even with optimized queries. lmdb is the only thing that doesn’t fall over atm.
Got it. I just created a fork of your new database and will try to do that CMake build and Windows port soon. Curious about the performance, and it seems so simple (I like simple things). Cheers. https://github.com/pedro-vicente/nostrdb
windows patches are welcome. Right now i just have the data structure that I’ve already mapped to data types within Swift/damus. The lmdb bit is coming soon.
Here you go. Started with just a CMake script that defines a library used by ‘test’ and ‘bench’. Tested in Linux and made a pull request. The ‘test’ program fails with an assertion by the way. CMake is just a must have build tool for cross compiling https://github.com/damus-io/nostrdb/pull/1
Hey, I made a new pull request that has more CMake support for the secp256k1 lib, do you have time to merge it? Thanks (Sent from Nostur for Mac, neat desktop client) . https://github.com/damus-io/nostrdb/pull/2