Prev: Amazing Video on How Computer Fashion Is Changing, Nice Work !!
Next: macro to expand into function body with declare at top
From: Nicolas Neuss on 4 Mar 2010 09:13
Hello,

I am looking for a simple persistent storage mechanism for some Common
Lisp data. AllegroCache would probably be the ideal choice, but I would
like to have it available also for other CL implementations. Does
anyone here have experiences with Elephant[*]? Or is there something
else which I should look at?

Thank you,
Nicolas

[*] I tried installing Elephant, but it does not work yet. Before I put
more work into making it work (or give up and simply use a standard
CLSQL database), I thought I'll ask here.
From: Erik Winkels on 4 Mar 2010 11:21
On 2010-03-04, Nicolas Neuss <lastname(a)kit.edu> wrote:
>
> I am looking for a simple persistent storage mechanism for some Common
> Lisp data. AllegroCache would probably be the ideal choice, but I would
> like to have it available also for other CL implementations. Does
> anyone here have experiences with Elephant[*]? Or is there something
> else which I should look at?

I used it for a couple of simple webapps about 1.5 years ago and it did
what was advertised on the tin. I found it easy to use and install.

Before that I used Rucksack but it wasn't actively supported (at the time)
and I managed to corrupt the database due to my not very well engineered
webapp. I never found out the exact cause and Elephant didn't give me
any problems.

The webapps only got light usage so I can't comment on performance.

There's an abandoned source tree here: http://www.aerique.net/software/
which might be useful. From memory at least cleve-memberlist used
Elephant.
From: vanekl on 4 Mar 2010 12:14
On Mar 4, 9:13 am, Nicolas Neuss <lastn...(a)kit.edu> wrote:
> Hello,
>
> I am looking for a simple persistent storage mechanism for some Common
> Lisp data.  AllegroCache would probably be the ideal choice, but I would
> like to have it available also for other CL implementations.  Does
> anyone here have experiences with Elephant[*]?  Or is there something
> else which I should look at?
>
> Thank you,
> Nicolas
>
> [*] I tried installing Elephant, but it does not work yet.  Before I put
> more work into making it work (or give up and simply use a standard
> CLSQL database), I thought I'll ask here.

If your needs are modest, it doesn't get simpler and more portable
than this:

(defun save (tuple filenm)
(setf *PRINT-READABLY* t)
(with-open-file (stream filenm :direction :output
:if-exists :append :if-does-not-exist :create)
(prin1 tuple stream)))

(defun restore (filenm)
(with-open-file (stream filenm :direction :input)
(read stream)))

I get 2,000+ save/restores per second on 7-year-old equipment, faster
than a mysql system I've worked on.
From: Alex Mizrahi on 4 Mar 2010 12:27
NN> I am looking for a simple persistent storage mechanism for some Common
NN> Lisp data. AllegroCache would probably be the ideal choice, but I
NN> would like to have it available also for other CL implementations.
NN> Does anyone here have experiences with Elephant[*]?

Yep, I'm one of Elephant's developers (although I worked mostly on a freaky
"postmodern" backend rather than on Elephant's core and main bdb backend).

From my experience, Elephant mostly works as advertised. You didn't mention
your requirements, but if you say it's simple, it should work.
I recommend using BDB backend, it is, basically, the only one which is
really solid and it is most supported.

Right now Elephant version 1.0 is not yet released, and old version is not
supported.
But I'd say verion 1.0 alpha is stable enough if you won't use new fancy
features which aren't polished yet.

NN> Or is there something else which I should look at?

Some people say cl-perec is rather good. It is called hu.dwim.perec now.
http://dwim.hu/project/hu.dwim.perec
(But I would personally never use anything from people who make websites
like that...)

From: Alex Mizrahi on 4 Mar 2010 17:32
v> I periodically prune old forms out. The extra time is inconsequential.
v> The time is spent mainly reading disk, not processing it in CL. My
v> data files usually fit within one disk cluster. Reading one byte or 4K
v> takes the exact same time.

If I'd be dealing with <4K of data, I would probably not even bother with
save/restore functions: just copying printed representation into a file in
Emacs would be fine, I think.

v> That's too bad. I never would have implemented such a system in the
v> first place. You seem like an intelligent guy -- I'm surprised you
v> didn't understand the shortcomings of that design earlier.

We did not consider this use case, and we were under pressure to release a
version ASAP.
Honestly, I don't think we'd be allowed to spend monthes on writing our own
database until we demonstrate that other solution would be *really* slow.

??>> Well, a feature of a database is that you can update it incrementally,
??>> avoiding large latencies.

v> A well-architected system should always take that into account. If you
v> think you need a database to achieve this than we will have to
v> disagree on this point.

v> Rushing to find the largest hammer in your toolbox may solve your
v> problem, but if you understand how the other tools work you can
v> usually do better.

Well, by database I meant any structured storage. I don't see a lot of
options here -- either storage is ad-hoc, like a bunch of files, or it is
structured. It can be as simple as key-value store.

Elephant was started as a very simple layer on top of BDB key-value store.
You can still use it in that mode.
It also has CLOS persistence layer.

It is very easy to use, you just define some of your classes (if you use
CLOS, that is) as persistent -- just change defclass to defpclass, and
optionall add :index t on fields you want to have indices on.

Then you open a store with a single command --
(ele:open-store '(:bdb #p"mydb/"))

And then it just works -- all objects you create are persisted,
automatically. You don't need to worry about anything, there are just a
handful of functions to use to retrieve your objects back from indices.

So I'd say using Elephant is even simplier than dealing with those text
files, well, at least when you want to use CLOS anyway.

 |  Next  |  Last
Pages: 1 2 3 4 5 6 7
Prev: Amazing Video on How Computer Fashion Is Changing, Nice Work !!
Next: macro to expand into function body with declare at top