In a bit of a pickle here :)

[anton muhin]

Larry goodman wrote:

> I started out using the typical client/server approach starting with
> my data model.  The more i've used python, the more i've gotten to
> think I really dont need a relational data model at all.  All the
> middlware does is serve up pickled python objects to my desktop via
> sockets.  The desktop model contains all of the logic as my app runs
> in an offline briefcase model.  So I came up with the idea of just
> storing all of the python objects in the postgres database pickled in
> a blob field.  Im sure about ten thousand other people came up with
> this idea before me.  The only other data stored in the table will be
> the id of the object and the last time the object was modified.  I may
> also store a CRC for resolution conflict.  For instance, if a client
> tries to change an object that was also changed by someone else since
> they last received it, the server would throw an exception.  Are there
> any holes with this approach?  Is there a better approach?  I have to
> stress that I cannot use remoting like pyro because the laptop will be
> offline most of the day.  They will resync with the server at most a
> few times a day.  

> I have one other question about the pickle system.  If I add new
> attributes to an object and try to unpickle an old version will it
> work?  How do you handle versioning of objects with pickle?
> 
Warning: I have no experience with such a kind of problems.

If I need to synchronize some data, I'd rather look at version control 
systems. IMHO, subversion or cvs seems good enough for this kind of 
work. Subversion even have Python bindings (but I didn't play with them).

hope this helps,
anton.