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