Re: CLOS persistence
- From: vtail <victor.kryukov@xxxxxxxxx>
- Date: Thu, 3 Jan 2008 21:13:40 -0800 (PST)
On Jan 3, 3:42 am, levy <levente.mesza...@xxxxxxxxx> wrote:
On jan. 2, 18:22, vtail <victor.kryu...@xxxxxxxxx> wrote:
If it's appropriate to ask - what was the reason for writing cl-perec
in the first place (versus using elephant)? I understand that your
time constraints were pretty tight so you most likely have studied all
the available options before rolling your own thing...
Obviously we have not written cl-perec in that three months but in the
past two years (with many other things in parallel). At that time
elephant was in a very early stage and it's RDBMS mapping was well at
least hard to explain to people. I don't know if that changed by now
but I don't think so. The BDB backend was not an option due to its
licensing and the fact that most people here are happy when they see
their data stored in RDBMS rather than in X.
Interesting. At that point elephant seems to be easier to use, because
it has some pretty good documentation and tutorial, and is asdf-
installable. I have nothing wrong with getting a package via darcs -
in fact, distributing your sources via some distributed SCM is
probably the best way to involve community in development - but I
spent several hours yesterday trying to install all the dependencies
(and it still doesn't run: (asdf:oos 'asdf:load-op 'cl-perec) reports
"The name CL-PEREC does not designate any package" while doing 14:
(COMPILE-FILE #P"/home/victor/.sbcl/site/cl-perec/
configuration.lisp")). On the other hand, I really don't like how it's
misusing database backend for a hash. If cl-perec provides a better
map between objects and database, it's worth a serious
consideration!
I understand that making (good) documentation takes a lot of effort
and reading cases / sources is usually enough, but having good quick
tutorial + API documentation simplify things big way. Have you
considered any tools that automatically extracts documentation strings
(like doc/manual/docstrings.lisp from the sbcl source tree or such)?
Re: BDB - even after reading the "CLOS persistence" topic from
November, I still don't get what is wrong with BDB as a web-site
backend from the licensing perspective :(.
There was clsql and allegrocache too and I evaluated both.
Allegrocache was 1.0 at that time and had some very nice features but
we decided not to use it due to its price and not being RDBMS based.
Using lisp in itself is enough to explain and we didn't want to go
into this other issue. As for clsql we had quite a few problems with
it (and it's not really a CLOS persistence layer), enough to roll our
own RDBMS layer called cl-rdbms.
I tried to use CLSQL too, but I didn't like the fact that it's so low
level - just thin wrapper around SQL - and that one have to manually
control different threads for using different connections etc. - am I
right that cl-rdbms is thread-safe by default?
On the other hand, CLSQL supports sqlite, which is an important
backend IMHO - very easy to install and sometimes faster than
Postgresql due to lower overhead. How hard it is to add sqlite backend
to cl-rdbms?
Overall, you guys have managed to write an impressive number of
impressive libraries!
Regards,
Victor.
.
- Follow-Ups:
- Re: CLOS persistence
- From: levy
- Re: CLOS persistence
- From: Leslie P. Polzer
- Re: CLOS persistence
- References:
- CLOS persistence
- From: vtail
- Re: CLOS persistence
- From: levy
- Re: CLOS persistence
- From: vtail
- Re: CLOS persistence
- From: levy
- CLOS persistence
- Prev by Date: Re: How to debug in Common Lisp?
- Next by Date: Re: CLOS persistence
- Previous by thread: Re: CLOS persistence
- Next by thread: Re: CLOS persistence
- Index(es):
Relevant Pages
|
|