[Zope-dev] Efficient and flexible object references

Gary & Karyn Gary & Karyn" <garykaryn@earthlink.net
Sun, 19 Aug 2001 00:59:30 -0400


----- Original Message -----
From: "Joachim Werner" <joe@iuveno-net.de>
To: "Gary & Karyn" <garykaryn@earthlink.net>; <zope-dev@zope.org>
Sent: Saturday, August 18, 2001 1:52 PM
Subject: Re: [Zope-dev] Efficient and flexible object references


> Hi!
>
> some ideas ...

Thank you!

> With the catalog approach, how exactly are planning to do it? If I get it
> right, you store the RID of the related object (let's say the Composer)
with
> your object (let's say the composition) and if you need the information,
you
> get the related data from the catalog. You do this because you don't want
to
> reference the object itself. It would have to be woken up to get the
> metadata (Name, date of birth whatever) from it.

Yes, that's it exactly.

> One thing that comes to my mind is cataloging a unique id (or the physical
> path, which is the standard id in the catalog anyway) with the entry and
use
> that one as the key. I don't know if it is much slower than retrieving the
> catalog entry by its RID, and your custom id would not change when the
> object is re-cataloged.

Yes, that sounds like a good idea.  I'll try it and the ZPatterns idea I
think.

<snip my description>

> All that sounds very much like you maybe need an RDBM. After all, you have
a
> lot of relations! If you still want to have "real" objects in Zope instead
> of tabular data, you might use the DBObjects framework. I have no
> benchmarks, but I guess retrieving your data from PostgreSQL should be
quite
> as efficient as using the catalog. With DBObjects, you normally have real
> persistent objects that have their data stored in PostgreSQL but can be
used
> from Zope like a ZODB object. The good thing in your case is that you
could
> then write your own methods like "getMyComposers()" that do the hard work
in
> SQL and return the results as attributes of the object.

Yes, true, I have a lot of relations.  :-)  I'll check out the DBObjects
framework but I'm actively trying to move away from an RDBM approach for
this project.  My incomplete ER diagram for this looked like spaghetti, and
I kept on finding that I wanted to make my entities objects...this is a bit
of an exploration of ODBs in general to see if I can make a simpler, more
graceful design model the same information.  If all else fails, I'll pull
the ER diagram out again. :-)

> I am not really sure what approach is the most efficient, and whether you
> really need massive caching or just a very efficient just-in-time
retrieval
> and then maybe late caching of the rendered pages using the available
> caching tools. I guess you'll need to test that with actual data ...

Understood, and agreed; while I don't want to cache whole pages for flexible
display reasons, perhaps I could cache rendered "baked" page
components...metadata caching seems easier to keep fresh though...I don't
have unlimited time, of course, so I hope to land on a reasonable solution
out of the first two or three I try.  I'll try to remember this option when
I plan my prototype building.

Thank you very much!

Gary