Greg Ewing wrote:
Michael Haggerty wrote:
A similar effect could *almost* be obtained without accessing the memos by saving the pickled primer itself in the database. The unpickler would be primed by using it to load the primer before loading the record of interest. But AFAIK there is no way to prime new picklers, because there is no guarantee that pickling the same primer twice will result in the same id->object mapping in the pickler's memo.
Would it help if, when creating a pickler or unpickler, you could specify another pickler or unpickler whose memo is used to initialise the memo of the new one?
Then you could keep the pickler that you used to pickle the primer and "fork" new picklers off it, and similarly with the unpicklers.
Typically, the purpose of a database is to persist data across program runs. So typically, your suggestion would only help if there were a way to persist the primed Pickler across runs. (The primed Unpickler is not quite so important because it can be primed by reading a pickle of the primer, which in turn can be stored somewhere in the DB.) In the particular case of cvs2svn, each of our databases is in fact written in a single pass, and then in later passes only read, not written. So I suppose we could do entirely without pickleable Picklers, if they were copyable within a single program run. But that constraint would make the feature even less general. Michael