RE: [Pythoncard-users] ZODB Persistence

And it seems to me that we can build the solution without taking 
class changing into account, then retrofit it later. If we do a good 
job of OO design, we shouldn't paint ourselves into any inextricable 
corners. We can't anticipate all the issues we're liable to 
encounter, right?

I'm not sure how often class changes are made. When they are, some 
mechanism that monitors the out-of-synch situation and even alerts 
the user that s/he has to do something explicit to bring things back 
into alignment would be an OK first pass solution, wouldn't it?

>Not entirely true. With ZODB there is a standard method (can't remember the
>name) called on each object as it is retrieved from storage. So if the class
>has changed you build into that standard method the code required to deal
>with the change (add default values to new properties, etc.). Or you write a
>batch program that touches every single instance of the changed class and
>update existing values as necessary.
>
>Not necessarily ideal, but at least there are mechanisms.
>
>---
>Patrick K. O'Brien
>Orbtech
>
>  > -----Original Message-----
>  > Kevin Altis wrote:
>  >
>
>[snip]
>
>  > 7. One of my biggest concerns with ZODB as our general mechanism is also
>  > valid for Shelve, but Shelve would be easier to deal with.
>  > Namely, there are
>  > no good ways of dealing with data stuffed into an object database when you
>  > go and change the classes. Perhaps versioning and careful attention to
>  > backward compatible class changes will help, but this is a pretty
>  > fundamental issue.

-- 
Dan Shafer, Personal Creativity Trainer and Consultant
Trained Hartman Value Profile Analyst
http://www.danshafer.com/valueprofile.html