POOP / Python (Object Oriented Persistence) ?

[Martijn Faassen]

"Tony J Ibbs (Tibs)" <tony at lsl.co.uk> wrote:
[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?

Yes, though it uses ExtensionClasses which hook into some arcane part of
Python. But it runs with vanilla Python, yes.

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

It'd be a major project to make it work with JPython, I think. I don't
know if anyone actually seriously looked into this yet, though -- it may
be quite doable.

> This is obviously a disadvantage for the PJama people, not least because
> of the licensing terms around Java (i.e., why they can't call their
> variant pJava, even though they have had funding from Sun).

Right -- open source is cool. :)

[snip]
> How easy is it to write a storage manager?

I haven't tried myself, but given that there are various storage managers
already there and some in the making, it is definitely doable. Someone's 
working on a storage manager on top of ReiserFS, for instance.

> 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.

Hm, I'm not quite sure what you mean here. What's a GIS?

Note that the ZODB *does* depend on the Python-specific pickle protocol,
so building it on top of say, a relational database, only gives you
minimal advantages. SQL queries and such aren't very useful, as it's just
pickled data in the fields. For the same reason I think taking advantage
of versioning and locking of some underlying system is hard -- ZODB itself
is perhaps too low level for that. I may be wrong, though.
 
> Snags.
> Well, it's obviously a bit of a pain if __getattr__ and __setattr__ are
> unavailable for easy use - although I can't say I've used them for anything
> significant myself, they're useful tools for the back pocket.

I actually heard a while back that in the 2.2 release of Zope 
__getattr__ and __setattr__ are available again. I haven't checked into
that yet.

> Also, the "lists and dictionaries aren't classes so we have to prod the
> persistence when they're altered" thing is a slight pain.

Agreed. Easiest thing to do is something like this though:

mylist = self.mylist # put in local variable (speed benefit in some cases!)
mylist.append("change the list")
self.mylist = mylist # prod persistence

[snip]
> So, why isn't this better known?

I think because the Python and Zope worlds are quite a bit apart in some
ways. Of course there's lots of overlap, but your average Zope user isn't
necessarily well aware of the Python community and vice versa. Of course
AMK's article is probably specifically an attempt to make the ZODB more
well known.

It'd also help if the ZODB could be easily downloaded as a package by itself.
There's a packaging wiki (discussion hypertext thing) on www.zope.org to
deal with such issues. I'm not sure how active it is, though.

> Is it just that Python is too good at too
> many things? Maybe we need a page of "clever things Python does that other
> people think are hard", or "important buzzword compliances by application",
> on the PythonLabs site...

> [It would help if this was all more evident from the Zope site, as well,
> though. Talk about hard to navigate round.]

You should get in touch with the Zope folks if you want the Zope site
improved -- tell them about your problems. They're actively looking at
ways to improve that site.

Regards,

Martijn
-- 
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?