[Zope] Understand ZODB Query?

[J Cameron Cooper]

>
> you're right, i'm still thinking tabularly.

It can be a hurdle. In a relational system, your data is pretty much 
global, and you relate it by keys and the other tricks of the RDB. In an 
object system like Zope, you (can) store information hierarchically. 
It's containment (sometimes with reference) and context that do the work 
here.

(There are middle grounds like EJBs, where there are objects, but 
they're all really in the same pile, and have no real containment.)

>  I'm basically looking for ways how to do database query (select, 
> update, create, etc).
> Of course i'm still thinkin in 'relation database' way as I'm just 
> starting with OODB.

There are analogues:

"select" basically means "find these records". In an object system, you 
can either contain things so that this is intrinsic or nearly so (by 
design) and do some simple filtering on the results or do some sort of 
search (see below).

"update" is just a method called on an object you already have a handle on.

"create" is a method called on an object that can contain other objects. 
You must have a handle on it, too.

>  From my latest reading, the ZODB works like a 'dictionary':
> -In this way, I can save any objects into this dictionary.
> -the key for the dictionary is the 'unique key' while the value is the 
> object.
> -In order to perform any query, I need to parse through the dictionary

If you're working low-level at the ZODB, that's right. But since you're 
probably getting at it through Zope, it's better to think of it as an 
object tree (almost like a filesystem, but don't get too wrapped up in 
that metaphor.) Even forget the fact that there's storage behind it and 
pretend like you're looking at the guts of a running program (which you 
are!) To find things in this environment, you can walk the tree 
yourself, or get someone else (like ZCatalog) to do it for you.

>  My questions:
> -wouldn't it be too slow?

Not if you do it right. If all your relevant records are contained in 
some object, then you merely need ask it for its contents. ZCatalog is 
an index based system, which is pretty darn fast since all the hard work 
is done ahead of time.

> -How if I don't need any key?
> -How if I have multiple keys?

The whole key question is kind of orthogonal to Zope. All objects really 
have one and only one unique key: their path. Everything else is 
application-level.

> This doesn't seem so easy.

It's probably too easy. You just aren't used to thinking about it this way.

I'll do a little summary since the above is so scattered:

Zope is really a live object system which happens to have a persistent 
backing. But forget that, and think like you're in a program and not a 
database. You can add your data by

1) creating a Product whose instances store a single record, and adding 
a heap of these in one or more folders, perhaps hierarchically. These 
can be seen and edited via the ZMI and are catalogable (automatically if 
you do it right.) This is what the default Products do. You might have a 
Person product, and folders for each Office, with instances of Persons 
in them.

2) creating a Product with attributes that store your data and retrieve 
it. Say a products People which has a dictionary of all the people you 
add to it, and methods for adding, finding, and changing people. You may 
have to tell the persistence machinery when things have changed. This 
data can't be cataloged, and you have to take care of the machinery 
yourself. If you implement by dictionary, this can be very relational; 
if you implement by objects, not so much.

3) Using existing products to do this for you, by either method above.

You can relate data by

1) parent-child relationships

2) containment of attributes, possibly by unique key

3) holding references to objects, paths to objects, or by using the 
Relationship product.

There. That's a little less scattered. Should be helpful, but please 
don't pretend it's authoritative.

          --jcc