[elephant-devel] Status of Leslie's question and Sean's patch?

[Ian Eslick]

 From what I can tell you are proposing that we make a hook into the  
instance creation process to clean up these redefinition and change- 
class issues.  It sounds like you aren't concerned with fitting within  
the existing MOP framework (a source of much of my concern).  The  
'toolkit' proposal is essentially this; create a mechanism outside  
(but not conflicting with) the MOP that solves these problems cleanly.

A few questions to consider:
- What code is going to generate and keep track of the schema number  
for any persistent instance?
- Where are schema 'numbers' going to be stored?
- What happens if a persistent class is redefined, but the resulting  
database is not connected or is never connected (so you can't persist  
the information that this class was redefined)?
- How does the system know which of these conversion functions to call  
during instantiation?
   (What code is mapping schema 'numbers' to functions, whether stored  
in the
    DB or stored in a file?)
- When is the conversion function called?  When the pid is read into  
memory and a placeholder
   object created, or when the first slot value is accessed?
- How does this mechanism interact with user-defined MOP conversion  
functions such as update-instance-for-redefined-class?  Are they the  
same interface or separate?
- What are the potential error cases we should warn the user about?

I wish we had a developer who was passionate about this area of the  
code in general.  There are a set of important open issues that all  
effect the same mechanisms (numbers refer to Trac tickets on http://trac.common-lisp.net/elephant/)

1) Schema evolution for persistent instances and non-persistent  
objects (#25 - Leslie)
2) Lazy object instantiation for persistent instances; clean up  
instance initialization to
    support both 'on creation' and 'on deserialization' pathways.   
(#39/49 - Pierre & Sean)
3) Referential integrity (#3 - Ian)
4) Online garbage collection (#21) and migration (#46)
5) 64-bit OIDs (#29)

As before, I'm happy to support but probably can't take the lead on  
this for a very long time.

Ian


On Dec 21, 2007, at 2:12 PM, Leslie P. Polzer wrote:

>
>> For example.  In order to convert an instance of A to an instance  
>> of B
>> we have to have a persistent function.
>
> Let's stop right here. Why that?
>
> What I had in mind was that the programmer keeps around, say, a file
> full of those conversion functions, thereby providing legacy support
> for her data structures.
>
>
>> Perhaps rather than an implicit feature, we provide a toolkit for
>> making user schemas easy to build.    This could make it easy to
>> create, compare and perform operations on schemas from classes and to
>> hook into the MOP to extract them and use them in class redefinition
>> and creation.  We could provide an inherited slot for class instances
>> that keeps a pointer to the schema.  Users that are afraid of this
>> functionality can just choose to update manually so that consistence
>> is guaranteed.  Trading off performance for a strong guarantee  
>> strikes
>> me as the better default behavior.
>
> I don't understand what you have in mind here. Perhaps it would help
> if you explained the idea of a “user schema” in more detail.
> Then again, I don't think this is a thing that is of interest to me
> right now, so you might not want to explain this further and save
> your time.
>
>
>> I'm happy to support this effort if you or someone else are  
>> interested
>> in taking it on, though.
>
> Thanks a lot. I'll do what I can. I must balance between the needs of
> my project and Elephant, though.
>
>  Leslie
>
> -- 
> My personal blog: http://blog.viridian-project.de/
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel