Prev: beggining lisp
Next: Let Over Lambda (ISBN 978-1-4357-1275-1)
From: John Thingstad on 3 Jan 2008 07:41
P� Thu, 03 Jan 2008 10:42:54 +0100, skrev levy
<levente.meszaros(a)gmail.com>:

>
> 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.
>

If all you need is persistence wouldn't a simple file based solution work
better?
Seems to me to make use of a database you should have a large dataset and
random access by many simultaneous users. Similarly it is not clear to me
you would want a mapping from a RDBMS and CLOS. CLOS creates a graph.
(assuming you consider directed graphs, trees and lists a subset of
graph) RDBMS creates tables. Two orthogonal means of representation. In
particular many to many relations are grossly inefficient in a RDBMS. I
have seen examples of using a CLOS mapping to records using clsql and it
struck me as a ugly cluge so I stuck with the functional form.
Perhaps you have different experiences?

--------------
John Thingstad
From: attila.lendvai on 3 Jan 2008 09:12
> If all you need is persistence wouldn't a simple file based solution work
> better?


maybe because persistence is not all that we need? (hint: google for
ACID)


> Seems to me to make use of a database you should have a large dataset and
> random access by many simultaneous users. Similarly it is not clear to me


we use it as a backend of a webapp with a few thousand users.


> you would want a mapping from a RDBMS and CLOS. CLOS creates a graph.
> (assuming you consider directed graphs, trees and lists a subset of
> graph) RDBMS creates tables. Two orthogonal means of representation. In


so? it's easier to work with the OO representation and therefore we
created an automated mapper. how much better would it be to do the
mapping by hand? would you write stuff in assembly just because both
lisp and asm are turing complete?


> particular many to many relations are grossly inefficient in a RDBMS. I
> have seen examples of using a CLOS mapping to records using clsql and it
> struck me as a ugly cluge so I stuck with the functional form.
> Perhaps you have different experiences?


no, all the OO -> SQL mappers are kludges in a way, but we've seen a
few kludges keeping the world in motion... sometimes you must make
compromises to get something useful done.


- attila
From: vtail on 4 Jan 2008 00:13
On Jan 3, 3:42 am, levy <levente.mesza...(a)gmail.com> wrote:

> On jan. 2, 18:22, vtail <victor.kryu...(a)gmail.com> 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.
From: vtail on 4 Jan 2008 00:21
On Jan 3, 6:14 am, "Leslie P. Polzer" <leslie.pol...(a)gmx.net> wrote:
> On Jan 2, 8:54 am, vtail <victor.kryu...(a)gmail.com> wrote:

>
> Elephant is probably the most popular.
> By the way, have you looked at cl-prevalence?

I did - and made a mental note to study its sources some day - but I'm
not easy to store my data in production with the library that has it's
last serious commit almost 2 years ago...

> > For elephant
> > in particular, I'm also interested in performance of Postgresql
> > backend vs BerkeleyDB.
> > My use case is a multi-user web-based app (I'm porting existing Perl/
> > MySQL application), and I would need performance that is not far worse
> > then that of a existing system.
>
> IIRC the Elephant docs say that performance is best with BDB and
> others are slower by a factor of three (check them out to verify
> this). The only way to find out whether a given library satisfies your
> performance needs is to try it. IMO the only disadvantage of Elephant
> is the one cited by levy: Elephant abuses relational databases as flat
> key-value-databases. But there's also a native SEXP backend in
> development for Elephant.

Thanks for the info. I also noticed that they have mentioned
significant performance increase with Postgres after switching to
postmodern. I should indeed give it a try and measure the performance
for different backends.

Their objest<->database mapping is very simple, indeed. I still have
to find how to implement many-to-many relationship in elephant
effectively. Also, I don't like the fact that "Garbage collection is
only supported via an offline migrate interface which will compact the
database by only copying reachable instances", and that every reading
of the slot-value is reading from the database (you "cannot" cache an
object instance in memory).

Regards,
Victor.

From: vtail on 4 Jan 2008 00:24
On Jan 3, 6:41 am, "John Thingstad" <jpth...(a)online.no> wrote:
> På Thu, 03 Jan 2008 10:42:54 +0100, skrev levy
> <levente.mesza...(a)gmail.com>:
>
>
>
> > 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.
>
> If all you need is persistence wouldn't a simple file based solution work
> better?

If I won't need to support multiple threads/transactions, I would used
something like cl-store indeed.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: beggining lisp
Next: Let Over Lambda (ISBN 978-1-4357-1275-1)