[Zope-DB] Cataloging DTML with many ZSQLMethods

Kent Hoxsey khoxsey at earthlink.net
Mon Nov 10 13:33:54 EST 2003


You mention several things that I'm going to tie together with assumptions:
a database, cataloging results of ZSQL methods, and the excellent HowTo
by RBickers on using ZCatalogs to catalog anything in Zope. Based on these
points, I'm assuming you have a database full of interesting information that
you would like to publish on the web.

You might be looking to use Zope as a sophisticated caching and metadata layer,
offloading query volume from the database. Or you might be abstracting your
business logic from your data layer. Or any number of other things. But the key
here is that you are trying to catalog (and cache) the results of ZSQL queries.

Oversimplifying a bit, there are two ways to do this: store the results of queries
as indexes and metadata in a ZCatalog (or multiple ZCatalogs),  or compose the
results of queries into objects and store them directly in Zope in the ZODB. Of
course, there are combinations of these two strategies as well, but I'll not go into
that here.

The first strategy, storing results in a ZCatalog, is quite easy. It is well-documented
in RBickers' HowTo, and problems following those instructions tend to be "user error".
If you are trying to catalog multiple database tables in Zope, you will likely need to
create individual ZCatalogs for each table. This is not strictly necessary, but might
be a good first step to try.

By following this strategy, you can cache query results in a group of catalogs, update
the catalogs as you see fit, and use catalog queries within your DTML or PT to extract
results and display them to users. Relatively easy, relatively fast, but lacking a bit
in design elegance and upgradeability.

The second strategy, creating "proxy objects" in Zope, is a bit more complicated, with
associated benefits. In essence, this strategy has you define a Zope Product that you
instantiate from a query to the database. The query result data simply provides the
initiation values for the object you are creating. The Product can be coded to retain
some knowledge of its origins, allowing for future refreshing or other manipulation of
the persistent data stored in the database. The object stored in Zope's ZODB is a 
"proxy" of the database data.

By following this strategy, you are essentially performing a relational->object mapping
of the database into Zope. There are costs and benefits of any such OR strategy, which
need to be considered in your own context. Proxy objects do bring a number of benefits
in more complex applications, because they allow you to encapsulate object behavior in
an intuitive manner, but at the same time they can cause a lot of grief with DBAs and
database programmers who don't really "get" the point of object encapsulation or don't
think business logic belongs anywhere but inside the database.


-----Original Message-----
From: serdyserdy at tin.it
Sent: Nov 10, 2003 4:46 AM
To: zope-db at zope.org
Subject: [Zope-DB] Cataloging DTML with many ZSQLMethods

Hi there!
I would appreciate any suggestion about my problem.

Well, I'm new to Zope and Python.

The environment I'm working on is:

A database and DTML Method-s each one invoking several different Z SQL methods.

The problem is how to catalog the results of those (multiple) Z SQL methods
called from within each DTML Method.

I tried the solution proposed in "Cataloging SQL Data and Almost Anything
Else" by "RBickers". Unfortunatly it seems that it would require a big effort
adapting it to my case.

More information about the Zope-DB mailing list