[rucksack-devel] Stability
Henrik Hjelte
henrik at evahjelte.com
Tue Dec 7 11:32:54 UTC 2010
On Tue, Dec 7, 2010 at 2:44 AM, James Ashley <james.ashley at gmail.com> wrote:
> Howdy!
>
> I blogged yesterday about data persistence in common lisp
> (http://www.dotnetmafia.com/blogs/jamesashley/archive/2010/12/05/4241.aspx
> if anyone cares).
>
One of the members of #lispcafe (schmrkc) convinced me to take another
> look at rucksack. It seems to be *exactly* what I'm looking for.
>
> Before I update the blog entry and recommend it (to all 5 people who
> actually read the blog), I figured I'd check here about its
> status/maturity. I've run across way too many CL libraries where the
> maintainers recommended I ignore it and roll my own.
>
> Is this something I can "safely" (for some value of "safe") recommend
> to end-users? The documentation seems pretty self-deprecating, which
> is why I gave it a pass the first time I noticed it.
>
>
It was some time ago since I experimented with rucksack. The code was very
nice, it has a testsuite and I fixed the only error that was detected by the
stress-test. So I think it is safe in some sort of way: no failing tests in
a decent test-suite. But: I don't think many use it. And why I am not using
it is that it is only for one process at a time. Are you building an
application where only one process will reach the database?
For a web-application we built and use elephant with the postgresql backend.
It is scalable, built for multiple processes (even on different servers) and
multiple threads and has caching so performance is ok. It has nothing to do
with SQL, just uses postgres for storage to get advantage of the
scalability. I read from your blog it is not installable with quicklisp, but
for some applications the easiness of install is not the most important
issue to consider.
Good luck, Henrik Hjelte
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/rucksack-devel/attachments/20101207/3aff8e0e/attachment.html>
More information about the rucksack-devel
mailing list