Strategies for backwards compatibility when using pickle?

[duncan]

I am working on an application that currently uses a simple pickle to
save a project to disk.

Every time we make a significant change to our object model we tell our
beta users to delete all of their old projects.

Does anyone have any advice on how to balance the conflicting interests
of the developers who want to keep evolving the object model and users
who need stable project persistance?

It has been suggested that there may be a way to override pickle to deal
with an evolving object model but it would be nice to hear from others
who have tried to handle this problem.

Thanks

Duncan

 

[Chris Liechti]

I am working on an application that currently uses a simple pickle to
save a project to disk.

Every time we make a significant change to our object model we tell our
beta users to delete all of their old projects.

Does anyone have any advice on how to balance the conflicting interests
of the developers who want to keep evolving the object model and users
who need stable project persistance?

i sometimes use .ini files and the config parser o store program settings,
but thats no option if you need to store entire object hierarchies.
the ini files are at least tolerant to new or removed values and easy to
edit by hand, sometimes i pickle and hexlify objects to store them in the
ini file too, but then i only do that with built in types to avoid such
problems you mention above.

It has been suggested that there may be a way to override pickle to deal
with an evolving object model but it would be nice to hear from others
who have tried to handle this problem.

yep, especialy __getstate__ and __setstate__ are interesting for you. by
implementing __setstate__ you can filter and update the pickled dictionary
before you assign it to the new instance. thats a good way to convert old
data to new objects.

http://python.org/doc/lib/pickle-inst.html

chris