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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4