Skip to Content.
Sympa Menu

pcplantdb - Re: [pcplantdb] technical details, plan, re: synthesis

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: Chad Knepp <pyg@galatea.org>
  • To: john@eco-living.net, pcplantdb@lists.ibiblio.org
  • Cc:
  • Subject: Re: [pcplantdb] technical details, plan, re: synthesis
  • Date: Tue, 3 Aug 2004 14:00:23 -0500

John Schinnerer writes:
> Aloha,
>
> Yikes, I'm suddenly drowning in mail. May take a few days to catch up.
>
> > o Zcatalog is for Zope objects. This still may be what we want, but
> > I really haven't spent much time looking at Zope itself.
>
> A zope product is afaik pretty much whatever you want to do/are able to do
> in python, with some obligatory hooks into the rest of zope. So as far as
> I know about it, if you can create the object in python it can be a zope
> object and be cataloged in zcatalog.
> I've only done a few relatively simple objects so far myself - and, I'm
> not aware of any reason why much more complex ones wouldn't work the same
> in general.

This may be the case, I really don't know yet how Zcatalog interacts
with ZODB and Zope... soon. Mostly I was trying to say I'm not worried.

> The only restrictions I know of for sure are in python script objects
> created directly in zope, and those are very wise restrictions for
> security purposes (basically to keep people from exploiting python via
> zope to do naughty malicious nasty things like take over, lock up and
> otherwise mess with the server...).
>
> > There is a
> > package for ZODB called IndexedCatalog
> > <http://async.com.br/projects/IndexedCatalog/> which should provide
> > the needed functionality independent of Zope. I don't know what we
> > will end up using but I do think that we have the tools in the Zope
> > package to do the job.
>
> Afaik ZODB can itself be used independent of zope...maybe requiring that
> package? Looks like you're already beyond me in researching this one.

Yes, I thought it would be easier to learn if I didn't actually
approach it head on. I'm learning it from the back forward and hoping
that I will have a better understanding of what's happening back there
when I work with the front end. Anyway as a standalone ZODB is
AMAZINGLY simple and I can think of all kinds of uses for it in other
programming situations.

Here is an annotated demo script. Skip it if you are not into techie
stuff.

| #!/usr/bin/env python
|
| import ZODB.FileStorage
| import ZODB.DB
| import Persistence
|
| class simple (Persistence.Persistent):
| data = None

This is just a demo class inheriting from ZODB's Persistence package.

| file = ZODB.FileStorage.FileStorage("/home/pyg/ack/db")
| db = ZODB.DB(file)
| cursor = db.open()

This is all there is to connect to the database. The *cursor* is the
the database connection.

| root = cursor.root()

The *root* of the database is a standard (persistent) python { 'key' :
'value' } dictionary.

| new_simple = simple()
| root["simple"] = new_simple

Add a new simple object to the dictionary with the key 'simple'

| print root

The output would look something like this:

{'simple': <simple instance at 40441770>}

| # more stuff

Do lots of other neat stuff. Actually most of the objects in the
*root* dictionary would be balanced trees or persistent
dictionaries/lists from BTree package and the PersistentMapping/List
packages... also part of ZODB.

| get_transaction().commit()

Commit the transaction. This is pretty important. Otherwise changes
are not committed and if you ran it again it would be empty to start
with.

> > o Schema is more important to ZODB than I initially thought in the
> > sense that when you have a working version and you add an attribute
> > to an object only the newly created objects will have the complete
> > set of attributes. In order to update the schema in
> > preexisting/working objects you need to write custom scripts to
> > traverse the objects in the database and add the attributes to them.
>
> True, I have read a few things about this. There are some examples
> somewhere of how to do this (zopelabs maybe?). The one I saw made it seem
> pretty easy, but I don't recall how complex the underlying system was.

It should be easy so long as you don't have crazy nested nested
objects and such, pluse there are utilities for finding hard to find
objects. I'm not imagining that we will have anything non
straightforward.

> <snip>
>
> > Zope cons:
> > o Big learning curve.
> > o Unknown performance (speed).
>
> It's not always fastest nor slowest I gather that some of the more
> recent versions of 2.x have focused on speed and made some good
> improvements. I know the zcatalog has been speeded up pretty
> dramatically since 2.4.something or so. I found some case studies
> once that seemed to indicate it holds its own with comparable
> platforms. Possibly not with Chad's awesome custom stuff though.
> ;-)

Ha, have you ever used Eden? It is ungodly slow! I believe in
implement first then optimize and I never got around to much in the
way of optimizing it. Like I said before I'm not really worried about
performance because if it's still slow after full optimization we can
always distribute the load to clients w/ZEO.

--
Chad Knepp
python -c 'import base64;print base64.decodestring("cHlnQGdhbGF0ZWEub3Jn")'




Archive powered by MHonArc 2.6.24.

Top of Page