POOP / Python (Object Oriented Persistence) ?

[Jim Fulton]

"Tony J Ibbs (Tibs)" wrote:
> 
> OK - I spent some of my "spare" time last night reading
> 
> http://starship.python.net/crew/amk/python/writing/zodb-zeo.html
> 
> and also Jim Fulton's Introduction to the Zope Object Database (referenced
> therefrom, although I found it by other means first), and also with a quick
> look at the ZODB How-To.
> 
> Gosh. Damn time machines have been at it again. Ask for something and it
> will have been there.
> 
> The PJama (persistent Java) people regard a mainstream persistent language
> as a killer-app, allowing a major revolution in how people program.

I happen to agree with this point of view. :)
I really think ZODB/Python has a huge potential 
independent of Zope.

(snip)
> The persistent Java effort requires quite a lot of work in the innards of
> Java (i.e., C++ programming). This is presumably because Java doesn't expose
> its insides to introspection in the same way Python does (Zope does use
> vanilla Python, doesn't it?

Uh, yes, for some definition of vanilla. You don't need to patch
Python, but you do end up using ExtensionClass. 

> Can it work with JPython? (I assume not)).

It can't today, but I suspect it would be possible if someone worked 
hard enough at it.

I *really* hope that Python 3K allows the things that ExtensionClass
allows and makes ExtensionClass obsolete.

(snip)
> How easy is it to write a storage manager?

It depends on the level of service and your definition of easy. ;)
If you don't support undo and versions, it's fairly easy, although
you do need to support some transactional semantics.  A full storage
is straightforward, but not like falling off a log.

There are a number of example storage implementations in the 
Zope distribution.  I plan to release an Oracle-based storage
very soon.

> It sounds to me as if this would
> be a useful thing to layer on top of a COM or CORBA interface to (for
> instance) an existing GIS, taking advantage of whatever versioning, locking,
> etc., that that existing software provides.

I'm not so sure about that.
 
> Snags.
> Well, it's obviously a bit of a pain if __getattr__ and __setattr__ are
> unavailable for easy use -

This restriction has gone away.  You can not define your own 
__set/get/delattr__ methods pretty easily.

(snip)

Jim

--
Jim Fulton           mailto:jim at digicool.com   Python Powered!        
Technical Director   (888) 344-4332            http://www.python.org  
Digital Creations    http://www.digicool.com   http://www.zope.org    

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
address may not be added to any commercial mail list with out my
permission.  Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for
repeats.