[Zope3-dev] Zope 3 Alpha 1 in 2002

[Jim Fulton]

Chris Withers wrote:
> Jim Fulton wrote:
> 
>> I think before we assume this, someone should put some effort into 
>> describing the
>> rational for this. The meta-data in ZCatalog is a historical 
>> accident.  It's
>> real benefit is as an optimzation for search results, but I think it's 
>> worth
>> considering how important this optimization *really* is, before 
>> inventing yet-another
>> service to support it.
> 
> 
> Well, I agree from a newbie perspective. It's hard trying to explain to 
> Squishdot users that the things they get back from searches aren't the 
> actual thing they look like.
> 
> That said, waking up large objects and/or performing complex 
> calculations to show search results seems silly.

I've learned that premature optimization is extremely silly.

There's nothing that guarentees that the objects you wake up
in the cached data will be smaller than the original objects.
The ZCatalog object cache stores quite a bit of data in each database
record.


> I like the way Lucene does this. When you specify an attribute name, you 
> specify if it's indexed, if it's store and if it's fed through a 
> lexicon/splitter.

I think that this is a little different because Lucene doesn't store the
original data.


> Now, here I'd say we want to specify for each name:
> 
> 1. What type of index to use
> 
> 2. Whether or not to store/cache the value
> 
> 3. Maybe a chain of processors to pre-process the attribute value before 
> indexing. I'm thinking lexicons, splitters, filters and the like here.
> 
> That way, the whole kaboodle is all part of the Indexing Service.

You may create different index on the same name or use multiple names for
a single index, so this shouldn't be name centric.

Jim


-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (888) 344-4332            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org