-----Original Message----- From: Casey Duncan [mailto:c.duncan@nlada.org] Sent: Friday, 5 October 2001 10:55 PM To: Jay, Dylan; 'zope-dev@zope.org' Subject: Re: [Zope-dev] ZTables and/or Catalog plugable brains?
On Thursday 04 October 2001 07:34 pm, Jay, Dylan allegedly wrote:
I tried using ZClasses but it seems to run slow and take up
space. Instead
I'm using Catalog (without ZCatalog) to contain the data. I'm presuming this will be quite efficient (comments welcome).
Yup that should be pretty efficient. Plus you can index and query the thing fairly easily.
Now to my question, How do Catalog plugable brains work?
I've looked but
can't see what the brain class has to look like to work. My first attempts don't seem to work. The classes are created but don't contain the data. Is the record data passed into the constructor?
I'm not an expert on brains per se, but my understanding is that they allow you to wrap functionality from a particular class around data stored in a table (such as a Catalog or an external database) without making each record an instance of the class.
This is how, when the Catalog returns data, you get the getURL and getObject methods for each record (among others). TinyTable and Z SQL Methods also support this functionality, and it is exposed in the management interface.
This would allow you to store the actual data as regular metadata elements in the Catalog, and get objects out when you query it. It would avoid storing the data twice, once in the objects and again in the metadata and all of the disadvantages this causes in terms of storage and synchronization.
But what is the API? I understand that for SQLMethods you just have a class that assumes the existance of attributes that have the same name as you result fields. I tried doing this with the Catalog code but it seem to doesn't work. Am I doing it right or the the Catalog brains work differently?