RE: [Pythoncard-users] What Do We Call These Things?

I think one of the fundamental questions needs to be whether we want the
data storage to support multiple concurrent users. If not, then just about
any mechanism that can serialize Python objects to and from disk should be
good enough. That would include pickle, shelve, CSV, xml_objectify/pickle,
etc. But if you want multiple users accessing the same data at the same
time, you need to deal with update conflicts. That pretty much rules out the
previous options and gets us into ZODB, MetaKit, Gadfly, MySQL, PostgreSQL,
Oracle, etc.

Now, if we focus on the notion that Python objects are supreme, and we
simply want to persist them as they are (as opposed to accessing an existing
relational database or doing object/relational mapping), then we can
probably create a generic persistence mechanism that could be made to work
with all of these various backends. I mean, the operations may have diffent
names for each backend, but they all have similar functionality: open the
database, connect to it, get a set of objects, create a new object, update
the object, delete the object, save the object, display the first object,
display the next object, display the previous object, display the last
object, commit the transaction, rollback the transaction, resolve update
conflicts, etc.

---
Patrick K. O'Brien
Orbtech

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of
> ke...@sp...
> Sent: Friday, February 08, 2002 10:40 AM
> To: pythoncard-Users
> Subject: Re: [Pythoncard-users] What Do We Call These Things?
>
>
> Howdy,
>
> As a persistance mechanism is xml_objectify and xml_pickle being
> considered?
> comparison to XML-RPC
> http://www-106.ibm.com/developerworks/library/x-matters15.html#resources
>
> introduction;
> http://www-106.ibm.com/developerworks/xml/library/xml-matters1/index.html
>
> follow up;
> http://www-106.ibm.com/developerworks/xml/library/x-matters11.html
>
> Seems lightweight, transparent, and very easy to use.
> The objects live in XML, keeping options open.
>
> The latest IBM article mentions that the code is currently
> being enhanced.
>