[elephant-devel] Mutating slots persistently?

[Ian Eslick]

There are no tricks, this is pretty fundamental to the semantics of
lisp.  The metaclass protocol allows you to override operations on
slots, but not operations on arbitrary lisp objects (like complex
numbers, cons cells, etc) so there's no way to intercede.

Typically, if you're having this problem there is probably an
opportunity to think differently about how you construction your data
and functional abstractions.  Ask what you're trying to manipulate and
why you want it to persist (where ordinarily you'd write a file IO
routine to save/restore the data) and just make sure the functions that
implement the abstraction push data to the persistent store at the
appropriate points by, as Robert said, setf'ing the persistent object slot.

One other thought and something I do often is perform list operations
over a set of persistent objects.  That way if I do operations on the
car of a cons my functions side effect the persistent object (as in
find, replace, etc).  Lists should be stored in elephant only when they
can be done so infrequently.

Elephant is, after all, a persistent 'object' store rather than a
Persistent Lisp.  :) 

Ian


Robert L. Read wrote:
> Yes --- in my opinion (which gets more humble everyday), you just need to
> reset the entire slot with setf.
>
> I can't think of a better solution right now.
>
> One could, of course, store the list as separate persistent data items, or
> use a btree for the entire list.  This would make the change to a
> single item
> of the list more or less automatically saved; however, the great
> advantage of
> Elephant is that that it allows you to use the LISP data-space design
> that
> you prefer more or less directly, and changing that defeats some of the
> advantage of using Elephant.
>
>
>
>
> On Fri, 2006-02-17 at 12:00 +0100, Tayssir John Gabbour wrote:
>> Hi,
>>
>> How do people deal with the following problem... suppose I have a
>> persistent object with a slot that holds a list. And I mutate the list
>> with RPLACA. (Perhaps an innocent-looking SETF which expands into
>> RPLACA.) Well, this won't be stored persistently.
>>
>> How do people deal with this situation? Basically just always use
>> methods which set the entire slot? Are there any tricks to keep from
>> having to do this?
>>
>> Thanks,
>> Tayssir
>>
>> _______________________________________________
>> elephant-devel site list
>> elephant-devel at common-lisp.net <mailto:elephant-devel at common-lisp.net>
>> http://common-lisp.net/mailman/listinfo/elephant-devel
>>     
> ------------------------------------------------------------------------
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel