Hi, How does Sage solve the following situation? A user stores objects pickled in Sage version X.1. Then a developer changes internal logic and data structure of the class of the objects for Sage version X.2. If we assume the developer's patch is merged to Sage X.2, then typically the user's objects fail to be unpickled in Sage X.2. Of course, this is undesirable situation. I think this situation is unavoidable as Sage evolves for the better.
As I understand, the standard pickle jar contained in Sage was created for the purpose of preventing such a situation. But I could not understand how effective it is in what way. I think what happens is: The old pickled objects prevent the patch to be merged to Sage X.2 by unpickling failures. Then it is up to the developer to find a tricky way to avoid the unpickling failures. I think we should provide some infrastructure for the developer. My proposal is to make each objects have an attribute containing the Sage version in which it is created. Then of course the object will be pickled with the information. On the other hand, the class of the objects should contain relevant codes, written by the developer, "translating" the object pickled in Sage X.1 to an object of Sage X.2. Sage's unpickling procedure, comparing the version of the object and the current Sage version, automatically use the translating code to unpickle the objects belonging to previous versions to Sage X.2 Simon answered to my similar question earlier. However, his answer was not sufficient for me to be satisfied. It might be the case that I was not understood. So I ask the same question, a bit polished, again. Kwankyu -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
