21–30 of 125 posts
Unless for example, your run a background process which periodically imports data from an external source and inserts into sqlite database, while your web application continues to render pages for visitors based on existing old data. Your web page will fail, as it will time out on database lock because of that background process.
Unless for example, your run a background process which periodically imports data from an external source and inserts into sqlite database, while your web application continues to render pages for visitors based on existing old data. Your web page will fail, as it will time out on database lock because of that background process.
Abstract the persistence layer, document the contract, build a conformance suite, and write your one impl that uses sqlite. I know sometimes there seems to be an impedance mismatch between callers and databases, but often it's not that bad. And no, don't use an ORM or existing DB abstraction to do this. Sure it takes work, but pluggable storage is nice on some of these types of things.
But what is the value add in this specific situation?
Earlier quoted context omitted.
Sorry, put in my no-ORM edit as you may have been writing this. No, I mean higher level than that. ORMs suck as solving your problems specifically. Think more like an API than an ORM. I just started a side project and here's the beginning of an example of the iface I mean [0] and here's the beginning of an example of the sqlite impl I mean [1] (all untested and really early stage of course, but the idea is there). 0…
But they abstract the underlying db very well and have an uniform api that you can rely on. It's also tested, documented and battletested. It has drawbacks but if accepting several db is an important goal, you don't want to handcraft this unless you can measure inaceptable perfs.
I am admittedly unfamiliar with this specific case, but even a cursory glance showed me some sqlite-specific code embedded in the main library portion [0].
0 - https://github.com/beetbox/beets/blob/4f7c1c9beda6c2a5b0705e...
> The idea is that a more complicated DBMS should be faster, especially for huge music libraries. How "huge" are they talking about? I built a tool that imports Apache logs into sqlite for quick analysis and that easily handles several million records.
[0]: https://www.quora.com/How-many-music-albums-are-available-in...
SQLite is a fantastic database for desktop applications. https://www.sqlite.org/appfileformat.html is a great essay on its benefits for this kind of use-case.
Not only desktop, but most mobile platforms as well. Beeing coded in a single C file makes it portable as hell. Their documentation is also a prime example, with great insight.
SQLite is a fantastic database for desktop applications. https://www.sqlite.org/appfileformat.html is a great essay on its benefits for this kind of use-case.
Not only desktop, but most mobile platforms as well. Beeing coded in a single C file makes it portable as hell. Their documentation is also a prime example, with great insight.
>Beeing coded in a single C file makes it portable as hell.
It's not coded in a single C file...
Kudos to this guy. As the maintainer of an open source project, the hardest job is to tell people "your idea is stupid and I won't do it"
- 0h to manage backups ("cp"),
- 0h to manage seeds and tests fixtures ("cp"),
- 0h to configure and secure (void),
- 0h to write the deployment scripts (void),
- 0h monitoring/watchdog jobs (void),
- 1h to rsync for failover ("rsync")
My last projects always spent at least a good 100h to do all of this the right way. Then, if it is not good enough, we'll move to RDS or equivalent.