[elephant-devel] Mutating slots persistently?

[Ian Eslick]

Hmmmm....

Out of curiosity, I just looked at BDB and it appears that the
underlying database allows partial writes into key and data fields. 
With a whole bunch of low level API changes it would theoretically be
possible to support rplaca, (setf aref) and other such subfield sets
(and gets) at the DB level.  The API wouldn't allow that today.  Is the
same thing true of SQL?  Can you do a partial write into a blob field
(or whatever rep we're using to store serialized data) in a SQL table?

The immediate problems to think about relate to figuring out how to
maintain the consistency of the serialized target.  There's also an even
bigger problem in how to hook into the lisp APIs in a tasteful way (setf
(aref (get-value key btree) 5) 10) couldn't be overloaded due to aref
not being a generic function.  You might be able to have a parallel
syntax (setf (paref (get-value key btree) 5) 10) that would work...

Just something to archive for a very ambitious hack that someone else
would have to do.  ;)

Ian


Tayssir John Gabbour wrote:
> Yeah, I was hoping for something off-the-wall like, say,
> (differently-named) SETF and DEFINE-SETF-EXPANDER replacements. But I
> guess that's just too weird and maybe would give people the wrong
> impression. ;)
>
> Thanks,
> Tayssir
>
>
>
> Ian Eslick wrote:
>   
>> 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
>>>       
>> _______________________________________________
>> elephant-devel site list
>> 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
>