I don't think this targets embedded systems. I believe the term "embedded" is used to signal that the db is embedded inside your app, and not an external server daemon that you need to talk to over some protocol.
I love things like this. I generally work with JSON anyway when I'm doing one-off things like cron jobs, and I usually just keep my data in JSON flat files, so to have options like these really makes my life easier. Great job!
This looks awesome, but I find it odd how similar things on HN seem to pop up in bunches. It's as if once one thing hits HN, a very similar thing is automatically submitted and promoted to front page. It's a fairly strange social dynamic to be sure.
I posted this link because I saw the post on the HN front page to unQlite and I thought I saw an embedded JSON database recently that's more interesting, so I posted a link to it. Whoever decides what goes on the front page of HN likes open source stuff with no commercial agenda with buzzwords around recent and interesting tech, so they bumped it to front page.
A lot of that is one post starting a train of thought in others. "Oh, I saw something like that recently" or "I think I know a better whatever" and so forth - that train of thought either is or leads them to something on the subject that they feel worth posting. Sometimes this happens repeatedly.
Sometimes it is blatant "karma whoring" (check parts of reddit for many examples of this getting out of hand), but usually (here at least) it is genuine people thinking that if you were interested in X, you might find Y informative/useful/amusing too.
I discovered this a few weeks ago and realized it might be a great fit as a data store for a 'local, self-contained' web application. That is, a web app that is meant to run locally & in the browser (like IPython Notebook) but needs a database for local persistence, without the complexity of using the filesystem for storage. It's basically the benefits of SQLite with a simpler, NoSQL interface/design.
It is based on Tokyo Cabinet (which is under LGPL).
On the homepage of Tokyo Cabinet, it says:
"BTW, do you know Kyoto Cabinet? Actually, it is more powerful and convenient library than Tokyo Cabinet. At this distance of time, Kyoto Cabinet surpasses Tokyo Cabinet in every aspects. I strongly recommend you to use Kyoto Cabinet."
I wonder why that isn't used. Maybe because Kyoto Cabinet is under GPL.
Indeed, this is probably the reason. The company that developed ejdb (Softmotions) apparently uses ejdb in their own proprietary software, and they wouldn't be able to if it contained any GPL components.
Just off my basic understanding of how the database works, I don't believe a production web app would be a very appropriate use-case, since considering it's an embeddable database you'll be bound by the slow filesystem. Mysql/postgres or mongodb would be better options. This is more for self-contained applications such as cron jobs or utilities.
Again, I must offer a disclaimer that I only read a fraction of the total source code, but I would assume it would involve similar use-cases to sqlite . For example, IIRC, the Firefox web browser uses (used?) sqlite for storage. However, reading over the list I just referenced, I must correct myself and say that for most websites, you would probably be ok in using it; however, this seems to be an embeddable replacement for mongodb, which is typically used for high-traffic environments anyway. I'm coming more from a background of high-traffic sites with large datasets, so I typically rely upon more tailored solutions, but I should be careful not to see everything through my own narrow perspective!
Embeddable databases are nice and portable. It's like Sqlite versus Postgres - the latter may be more robust, but requiring it as a dependency greatly increases the effort needed to deploy your software. If an embedded database can do the job, it may be worth it as a matter of convenience.
Same reason why one might use SQLite over MySQL. Ease of configuration, no need to have a full blown DB server, lighter weight which makes it great for things like Raspberry Pi type hardware. For hackathons I've found it simpler to just use SQLite so I don't have to deal with MySQL configuration headaches that come up when IP addresses inevitably change.
Outside of NodeJS, I can see this being pretty handy for iOS development. I'm not a huge fan of taking JSON from an API, converting it into an NSDictionary, and then placing it into Core Data and RESTKit doesn't always fit my needs. I think this might work well for local persistence of API data for an offline mode.
Since the storage engine is a modified version of Tokyo Cabinet, I am assuming that you can have simultaneous readers, but a writer will lock everyone else out. From the Tokyo Cabinet specs :
'Tokyo Cabinet provides two modes to connect to a database: "reader" and "writer". A reader can perform retrieving but neither storing nor deleting. A writer can perform all access methods. Exclusion control between processes is performed when connecting to a database by file locking. While a writer is connected to a database, neither readers nor writers can be connected. While a reader is connected to a database, other readers can be connect, but writers can not. According to this mechanism, data consistency is guaranteed with simultaneous connections in multitasking environment.'
I'd switch to a full DB server for a production Web App. If you're using an ORM it should be pretty trivial (the one time I've done it, Perl's DBIx::Class made it as easy as changing the connection info hash). I'm not sure how many people hand code their SQL at hackathons but I am not one of them ;).
I use SQLite in small and medium-traffic web apps (the largest one getting about 80000 hits daily) all the time with no concurrency issues whatsoever. My rule of thumb is that if you don't expect your app to require more than one server, sqlite will work just as fine as postgres or mysql.
This looks interesting.. I have used nedb on a small project, That is another file based database, uses the same API as mongoDB. nedb is just an npm, so its only nodejs supported right now, and the feature list of EJDB looks more impressive anyway.
> there is a universe outside of PHP, and PHP is not at the center of that universe.
There is only one universe and PHP is a part of it. A big part. That's the reality.
Some of us have to work on multiple platforms with multiple languages and it's truly a disappointment when the authors clearly put in an effort to cater to the community where multiple platform support is prioritized ... but then exclude a platform due to personal bias.
I would say start treating the authors with the respect that they, as human beings, deserve. I too would like PHP support, but, if it's not there, I can still appreciate the hours and hours of labor that go into the support they do have. There's an expression "if you don't have anything nice/constructive to say, then don't say it," and claiming that it's a "disappointment" that they don't include your feature, and even going so far as to presume it's out of personal bias, is just rude.
Edit: Besides, if you're running php, you're probably developing a web app, in which case you should be using a database like mysql or mongodb anyway, not an embeddable db.