lightweight database
in [Lisp]
|
From: Raffael Cavallaro on 16 Mar 2010 12:14 On 2010-03-16 10:22:36 -0400, Tamas K Papp said: > I need to use a simple database from CL. I think that cl-prevalence is possibly the simplest, most lightweight database for common lisp. The entire database lives in memory, all transactions are logged, and snapshots are taken. Recovering is simply a matter of reconstructing the in-memory database from the latest snapshot and transaction log. I believe you use sbcl - I just tested it with sbcl on Mac OS X and it seems to pass tests. I've also used it with CCL and LispWorks. warmest regards, Ralph -- Raffael Cavallaro
From: Alex Mizrahi on 16 Mar 2010 13:08 RC> I think that cl-prevalence is possibly the simplest, most lightweight RC> database for common lisp. The entire database lives in memory, all RC> transactions are logged, and snapshots are taken. Recovering is simply RC> a matter of reconstructing the in-memory database from the latest RC> snapshot and transaction log. I believe you use sbcl - I just tested it RC> with sbcl on Mac OS X and it seems to pass tests. I've also used it RC> with CCL and LispWorks. You can as well just write stuff into text files via PRIN1 and read it via READ. cl-prevalence doesn't support queries (last time I've checked), you have to do this stuff yourself.
From: Raffael Cavallaro on 16 Mar 2010 13:28 On 2010-03-16 13:08:12 -0400, Alex Mizrahi said: > cl-prevalence doesn't support queries (last time I've checked), you > have to do this stuff yourself. The whole idea of cl-prevalence is that the database and the in-memory lisp objects are one and the same. You do "queries" using ordinary common lisp introspection - e.g., reading an object slot, doing a (gethash 'some-key *my-hash*), or executing a function that searches your in-memory data according to some predicate, etc. This is what I meant by "lightweight." Could this be done by writing stuff to text files? Yes, but you'd have to write and test the infrastructure to write and read clos objects, hash tables, etc. to text files. This has already been done for you with cl-prevalence, and in an asdf-installable form. Quite convenient if you want fast, lightweight persistence and the ability to have lisp run the show, not a database query language. Is it large scale, industrial strength? Maybe not, but its author, Sven Van Caekenberghe, used it to run a ticketing website for a theater, so it is known to be usable for a small scale commercial system... warmest regards, Ralph -- Raffael Cavallaro
From: Raymond Wiker on 16 Mar 2010 13:55 "Alex Mizrahi" <udodenko(a)users.sourceforge.net> writes: > AP> You might want to look into sqlite. I haven't tried their CL > AP> binding, > > One can use SQLite via CLSQL, I've tried it, it works. There are also one or two alternative sets of bindingss for SQLite. They may be worth looking into, but using CLSQL obviously gives you more freedom to change to some other database at a later point. If you're using Windows, it's also possible to create a thin layer of sanity around the .NET database database classes, using RDNZL (which is absolutely awesome :-). > AP> but the database itself is simple, easy to setup and robust. (And > AP> fast, too.) > > I agree. I'm not 100% sure I agree about the speed of SQLite, but I haven't done enough benchmarking to contradict you :-) .... and the bottleneck (if there is one) may actually lie within the SQLite wrapper that I use.
From: Andrew Poelstra on 16 Mar 2010 14:10
On 2010-03-16, Raymond Wiker <raw(a)RAWMBP-2.local> wrote: > "Alex Mizrahi" <udodenko(a)users.sourceforge.net> writes: > >> AP> You might want to look into sqlite. I haven't tried their CL >> AP> binding, >> >> One can use SQLite via CLSQL, I've tried it, it works. > > There are also one or two alternative sets of bindingss for > SQLite. They may be worth looking into, but using CLSQL obviously gives > you more freedom to change to some other database at a later point. > > If you're using Windows, it's also possible to create a thin > layer of sanity around the .NET database database classes, using RDNZL > (which is absolutely awesome :-). > >> AP> but the database itself is simple, easy to setup and robust. (And >> AP> fast, too.) >> >> I agree. > > I'm not 100% sure I agree about the speed of SQLite, but I > haven't done enough benchmarking to contradict you :-) > > ... and the bottleneck (if there is one) may actually lie within the > SQLite wrapper that I use. FWIW, In the sqlite C FAQ, they mention that by default every single INSERT is its own transaction - so if you want it to be fast, you have to start a transaction, do all your work, then commit. Else every single INSERT is actually a BEGIN-INSERT-COMMIT triplet. -- Andrew Poelstra http://www.wpsoftware.net/andrew |