D_store; There it is ... a new database!
Whow, it has taken me quite some time, but it is finally here: d_store. A new kind of database for your applications.
More then a year ago I started experimenting with was then only a faint idea. In june I had a better understanding of wat could and could not be done, and how it might look. A few months later, I finally had a proof of concept, 0.1 of d_store. All the basics were there, and it scaled to more then just a few items.
Today I'm releasing d_store version 0.2, A pretty complete API and plenty of functionality. See the official web pages.
(It took me so long, because I'm working on this in my free time, which is scarce already. But I'm sure glad I got rid of this braincrack and turned it into something real.)
Highlights of d_store.
D_store is an alternative database alike storage library. It is very good at tagging, live searching, hierarchies and any other kind of relationships that your data has. Its primary goal is an enabler for applications like iTunes; lots of related data to be explored and manipulated by the user, with live search fields, and still fast with lots of items.
D_store works like a programatic spreadsheet: there are rows and rows store values in columns (called fields in d_store). D_store stores every value only once, and each value knows in which rows it appears. This enables queries like: give me the rows where that field has this value.
Every query operates on a set of rows, and results in a set of rows. So you can query the result set again and again. You can also perform set operations on the results, like AND, OR, XOR, NOT, or you can mutate the stores by adding or removing rows.
I'm claiming that this makes d_store is just as powerful as SQL queries, even though d_store does not come with a query language. Actually, not having a query language is a good thing, it brings the result sets much closer to what you want to do with the data, like displaying it in the UI.
However, d_store can not handle more data then you have ram available, this is by design and will stay. So d_store is not a magical replacement for SQL. D_store is only suited where data doesn't grow unbounded. Luckily d_store is pretty efficient in memory usage, having up to 250.000 rows should not be a problem in the current version.
Missing in the current version
There is no file backend, which is definitely planned, for persistency and with journaling for data integrity. Today there is only loading and saving .csv files, which works though.
There is no error reporting. The API is completely void of errors. Is also planned for a next version. (Today the only possible error is out of memory, or maybe 'internal integrity error' but that just asserts and aborts currently.)
Speed, the current version is pretty fast, but I have lots of plans to make it way faster. Up until now optimizing was an anti-goal, in order to keep the code simple and malleable.
So there it is ...
There is still a lot more to do. But I hope people will find d_store useful already today. It will probably take me a long time to a 1.0 release. But not to worry, I hope to keep the 0.2 release bug fixed and stable for a long time.
The first real application written for d_store is maemo-todo. A todo list manager for the Nokia 770 or N800 with tagging and live searching, check it out.
And I would love to hear from you, I would love feedback on the API, on missing features, and on whatever else makes d_store more useful.
From now on I'll blog about d_store very day, HAHAHA ;)
Oh, you can download it from here.
Last modified: 2007-11-19 20:17 GMT