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@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
