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.
We’re happy with SQLite and not urgently interested in a fancier DBMS (2016)
11–20 of 125 posts
Re: We’re happy with SQLite and not urgently interested in a fancier DBMS (2016)
#12Abstract 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.
Congratulation, you just rewrote the base for an orm.
Re: We’re happy with SQLite and not urgently interested in a fancier DBMS (2016)
#13Abstract 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.
Congratulation, you just rewrote the base for an orm.
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 - https://github.com/cretz/yukup/blob/eecb3b24b33f40e6a1eefaa5... 1 - https://github.com/cretz/yukup/tree/eecb3b24b33f40e6a1eefaa5...
Re: We’re happy with SQLite and not urgently interested in a fancier DBMS (2016)
#14Unless 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.
Re: We’re happy with SQLite and not urgently interested in a fancier DBMS (2016)
#15[deleted]
Re: We’re happy with SQLite and not urgently interested in a fancier DBMS (2016)
#16Abstract 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?
Re: We’re happy with SQLite and not urgently interested in a fancier DBMS (2016)
#17Earlier quoted context omitted.
Congratulation, you just rewrote the base for an orm.
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.
Re: We’re happy with SQLite and not urgently interested in a fancier DBMS (2016)
#18SQLite 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.
Re: We’re happy with SQLite and not urgently interested in a fancier DBMS (2016)
#19> 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.
Re: We’re happy with SQLite and not urgently interested in a fancier DBMS (2016)
#20Abstract 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.
Congratulation, you just rewrote the base for an orm.
More of a DAO than an ORM.