It was mainly created for P2P systems that need to sync databases across clients. Being that data is stored in JSON it can be sent and received with relative ease.
Yeah, I remember reading about it a couple of months (years?) ago and being very surprised and impressed. The details: https://sqlite.org/threadsafe.html
I think it's use-case is when your data is more structured than what Berkeley DB can handle but doesn't really fit neatly into tables. Not using SQL as a query language is a plus in some scenarios too, particularly if your data manipulation needs are a bit more complex and you don't have the room for importing and using a full ORM (which is a "Vietnam of Computer Science"[1] anyway).
You don't need a full blown ORM here. A rather thin access layer would suffice, as much I can see from the API.
What I can see here, is that the data store is just a big JSON-file. So the implementation does not scale well (every save just writes the whole database and the database must be read in total to access any tiny bit of data). For any even medium sized application, it would be better to use a more sophisticated basis.
Maybe as configuration database -- but even for that, I guess there are already better choices in existence.
Edit: Upvoted the OPs post, because of the Vietnam-Link -- good read. Still, I would not throw RDBMSes totally out of the window. I think, we have learned a lot from them and in many, many cases they are just right. There are some cases of course, where object oriented schemes are more appropriate.
Precisely my point, you don't need an ORM with this LanderDB, but you'd need it with SQLite (unless you like using raw SQL, which is a fine preference too, of course).
> What I can see here, is that the data store is just a big JSON-file.
I'm not saying LanderDB is the best option and as smt88 wrote there certainly are many alternatives. I'm just noting that LanderDB doesn't seem to occupy the same niche as SQLite.
EDIT: oh, and I'm in no way involved with LanderDB, I just saw it a couple minutes ago :)
18 comments
[ 2.9 ms ] story [ 44.8 ms ] thread[1] http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Compute...
- UnQLite: http://charlesleifer.com/blog/python-bindings-for-unqlite-an...
- tinydb: https://pypi.python.org/pypi/tinydb/
- Blitz: https://github.com/adewes/blitzdb
What I can see here, is that the data store is just a big JSON-file. So the implementation does not scale well (every save just writes the whole database and the database must be read in total to access any tiny bit of data). For any even medium sized application, it would be better to use a more sophisticated basis.
Maybe as configuration database -- but even for that, I guess there are already better choices in existence.
Edit: Upvoted the OPs post, because of the Vietnam-Link -- good read. Still, I would not throw RDBMSes totally out of the window. I think, we have learned a lot from them and in many, many cases they are just right. There are some cases of course, where object oriented schemes are more appropriate.
Precisely my point, you don't need an ORM with this LanderDB, but you'd need it with SQLite (unless you like using raw SQL, which is a fine preference too, of course).
> What I can see here, is that the data store is just a big JSON-file.
One possible use-case for this I recently discovered is storing bookmarks in Chrome (https://klibert.pl/output/jq_and_chrome_bookmarks.html).
I'm not saying LanderDB is the best option and as smt88 wrote there certainly are many alternatives. I'm just noting that LanderDB doesn't seem to occupy the same niche as SQLite.
EDIT: oh, and I'm in no way involved with LanderDB, I just saw it a couple minutes ago :)
No ACID, doesn't even attempt a filename flip (that would be an easy addition). As it stands, get interrupted during an update and your data's gone.