[elephant-devel] Learning about Elephant

[John]

Hi Ian,

Thank you for your prompt response. Some comments below

On Tue, Jan 27, 2009 at 1:32 PM, Ian Eslick <eslick at media.mit.edu> wrote:

>
> Such a thing would be possible, but you would need to have a local
> copy of the value in memory and this could create more problems than
> it solves.  It's also unclear to me how common this case.  I don't
> write the same value to the same slot very often!


My question came from thinking of web applications. A user chooses to edit a
record. After s/he submits the form, I wouldn't want to incur the DB write
"costs" unless the data was actually changed by the user.


> The weak hash is simply used to speed up the 'recreation' of a
> persistent reference when it is deserialized from the underlying
> storage medium (BDB in this case) so fits into this model.  I've
> looked several times at building-in the support to enable a full
> replication model for BDB, but it's a fair bit of work to deal with
> the single-master requirement for replication and distributed
> transactions for global coherence. The write performance and
> contention performance may decline noticeably, but conflict-free read
> performance should be the same as in the non-replicated case.  I don't
> fully understand all these issues yet and am prioritizing a lisp-only
> Prevalence style backend in my development roadmap.


I'm not too familiar with BDB replication myself and was just googling
around. After reading that document in more detail and your explanation,
makes me realize that replication or the distributed BDB model is not such a
simple task. Since I don't think that my application(s) would really
out-scale the single machine Elephant/BDB deployment, I would certainly not
want to encourage investing time in this and rather concentrate on a
lisp-only prevalence  backend. Maybe one that covers these issues in the
future.


> Psets today are a convenience API around the BTree that can be
> overridden by data stores later for more efficient implementation
> (e.g. hash vs. tree) as appropriate for that store.  BTrees are cheap
> for BDB to create and use so use of them at any size is fine.  You
> might want to wrap an abstraction around the BTree directly since the
> pset API is an un-ordered set.  If you want to do range extraction or
> set intersection you'll want the btree's support for ordered objects.
>
> The query system currently doesn't support psets, although it should
> eventually.
>
> Slot-associations currently don't deal with reflexive references
> (associations among instances of a single class), but that would also
> address the 'friends-of' problem.


I haven't looked too much into the code, but your response seems positive
overall. I haven't read anything about slot-associations in the manual, so I
guess I'll have to learn about them in the code and the tests themselves.

I hope you enjoy elephant!  If you want to add/implement or spec out
> some of these changes you are thinking about, I'd be happy to support
> you.


I'll see if there is anything I can contribute. I first need to familiarize
myself more with it and start getting my feet wet.

Thank you again and best regards,
JD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20090127/2d11a78d/attachment.html>