3 ms·

>I have the same impressions as your parent commenter: passing around an sqlite connection handle is thread-safe and always will be faster than application-leve

>I have the same impressions as your parent commenter: passing around an sqlite connection handle is thread-safe and always will be faster than application-level locking. I'm not debating that. It's just that that's not the current bottleneck so no point in dealing with the extra complexity. The current solution can saturate my SSD with low CPU usage. >If you do however have a write-heavy workflow then it's likely time to replace sqlite. That's definitely true. But there's no other SQL database to embed that I know of. That's why I mentioned wanting postgres as a lib. I know of other options that are non-SQL and will require extra rework. If there's an SQL option I'm all ears.

pdimitar 7y ago
I did a research about a month ago and was very disappointed. Basically, outside BerkeleyDB and Firebase semi-embedded mode (since it is still not fully embedded) we're on our own. From then on, you can just use BoltDB or its successor(s) if you don't care about SQL. Which I do, and you seem to as well. At this point I am thinking of developing an Elixir wrapper for sqlite that can also do a best effort strong-typing and be done with it. It seems sqlite made many developers complacent, but then again, the raging consumerism and micro-management economy we live in worldwide does not exactly encourage tinkering and OSS contributions.
- pedrocr 7y ago
  I've been loosely following this: https://github.com/spacejam/sled https://github.com/spacejam/sled Since I'm writing in rust it might be a good fit. It's non-SQL but does have some nice features. I would need to figure out how to adapt all the syncer features to that model though. Right now I should just focus on finishing the merging code to be able to release a 1.0 some time soon.
  - pdimitar 7y ago
    Not to be a complete cynic but IMO you should just use any of the pretty well-done NoSQL K/V stores if you don't mind ditching SQL. There's plenty that are very well done, BoltDB successors and FoundationDB included. BTW I've heard very good things about the widely used sqlite Rust libraries (sorry, don't remember the names).
    - pedrocr 7y ago
      >Not to be a complete cynic but IMO you should just use any of the pretty well-done NoSQL K/V stores if you don't mind ditching SQL. My thought process is that the current solution works so I'd only change to a K/V store with the extra complexity if that got me a better API and more of the stack in Rust. Consuming something in Go seems like a pain, while also adding a GC runtime just for this. >BTW I've heard very good things about the widely used sqlite Rust libraries (sorry, don't remember the names). I'm using rusqlite, seems to work fine.
      - pdimitar 7y ago
        I wonder how a Rust library deals with the fact that sqlite is loosely typed.

pdimitar 7y ago

I did a research about a month ago and was very disappointed. Basically, outside BerkeleyDB and Firebase semi-embedded mode (since it is still not fully embedded) we're on our own. From then on, you can just use BoltDB or its successor(s) if you don't care about SQL. Which I do, and you seem to as well. At this point I am thinking of developing an Elixir wrapper for sqlite that can also do a best effort strong-typing and be done with it. It seems sqlite made many developers complacent, but then again, the raging consumerism and micro-management economy we live in worldwide does not exactly encourage tinkering and OSS contributions.

pedrocr 7y ago
I've been loosely following this: https://github.com/spacejam/sled https://github.com/spacejam/sled Since I'm writing in rust it might be a good fit. It's non-SQL but does have some nice features. I would need to figure out how to adapt all the syncer features to that model though. Right now I should just focus on finishing the merging code to be able to release a 1.0 some time soon.
- pdimitar 7y ago
  Not to be a complete cynic but IMO you should just use any of the pretty well-done NoSQL K/V stores if you don't mind ditching SQL. There's plenty that are very well done, BoltDB successors and FoundationDB included. BTW I've heard very good things about the widely used sqlite Rust libraries (sorry, don't remember the names).
  - pedrocr 7y ago
    >Not to be a complete cynic but IMO you should just use any of the pretty well-done NoSQL K/V stores if you don't mind ditching SQL. My thought process is that the current solution works so I'd only change to a K/V store with the extra complexity if that got me a better API and more of the stack in Rust. Consuming something in Go seems like a pain, while also adding a GC runtime just for this. >BTW I've heard very good things about the widely used sqlite Rust libraries (sorry, don't remember the names). I'm using rusqlite, seems to work fine.
    - pdimitar 7y ago
      I wonder how a Rust library deals with the fact that sqlite is loosely typed.