I am dreaming up something I would like to see, it is perhaps obvious and I haven't thought out all details but anyway:<br><br>Schemas are stored in the elephant database. Each class has an associated schema class that stores a number of class-versions. Each class-version has a number and a list of slot definitions.
<br><br>Each persistent class instance has a way to identify the schema and actual class-version. For example a class-version-nr, and the schema can be identified from the class-name. (Optional feature: it would be nice if there was a way to rename classes and keep the persistent data, so link the version 1 of my-renamed-class to version 7 of my-old-class)
<br><br>When a class definition is updated, a new class-version is created. New instances get the latest class-version-nr.<br>For each retrieval of an instance, or slot-value of an instance, the version-nr of the instance is checked. If it is outdated, a generic function is called to update it. Something along class-evolve, but I like long names like update-persistent-instance-for-class-redefinition. It is up to the user to keep code to update between versions. If you want to do lazy updates, you will have to keep the old update code in your system for ever.
<br><br>There could be a convenience function called update-all-instances that takes a class-name and does upgrades, after calling it the class-versions objects of older versions may get a known-to-be-obsolete value so<br>
you will be able to know that you can drop update code safely.<br><br>With this schema, you would never actually read from old versions. Every time you query an instance of an old version, the whole instance should be updated slot for slot. So the slot-value-using-class suggested would be unnecessary, there would be no need to upgrade slot types in this function, it should already be done using update-persistent-instance-for-class-redefinition.
<br><br>But, since I personally don't have the time to do this grand plan (now at least), I don't object to the slot-value-using-class updates Leslie proposes. It does not feel like a complete and perfect solution, but won't do no big harm either. But for me, until Elephant gets a complete and proper schema evolution facility I won't trust it to handle lazy updates to slots or objects. So a performance switch to turn it off will be nice. Proper schema handling is perhaps elephants greatest weakness?
<br><br>Best wishes, <br>Henrik Hjelte<br><br><br><br><div class="gmail_quote">On Jan 4, 2008 11:43 AM, Leslie P. Polzer <<a href="mailto:leslie.polzer@gmx.net">leslie.polzer@gmx.net</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>> to clarify one of the points that are important to me,<br>> I have prepared this working sketch:<br>><br></div>> [...]<br><br>Any reason why no one commented on this?<br>I'd appreciate some feedback.
<br><div><div></div><div class="Wj3C7c"><br> Leslie<br><br>--<br>My personal blog: <a href="http://blog.viridian-project.de/" target="_blank">http://blog.viridian-project.de/</a><br><br>_______________________________________________
<br>elephant-devel site list<br><a href="mailto:elephant-devel@common-lisp.net">elephant-devel@common-lisp.net</a><br><a href="http://common-lisp.net/mailman/listinfo/elephant-devel" target="_blank">http://common-lisp.net/mailman/listinfo/elephant-devel
</a><br><br><br></div></div></blockquote></div><br><br clear="all"><br>-- <br>Henrik Hjelte<br><a href="mailto:henrik.hjelte@stix.to">henrik.hjelte@stix.to</a><br>+46703993945<br><a href="http://stix.to">http://stix.to</a>
<br>Lästmakarg 18-20 (IQube)<br>Box 7438<br>S-103 91 Stockholm<br>Sweden