"R. David Murray" wrote:

http://zope.nipltd.com/public/lists/dev-archive.nsf/ByKey/C15EB30D0FAF1057

If you can't find the message in the mailing list archives, I can probably did out a copy I saved somewhere...

The message is the one I linked :-) cheers, Chris

"R. David Murray" wrote:

It had better be <grin>. It's also a one line fix to Lexicon.py. Mike posted a note explaining the fix and how to retrofit it into an existing site (you have to clear and rebuild the Lexicon, so it becomes a little more than a one line fix). If you can't find the message in the mailing list archives, I can probably did out a copy I saved somewhere...

Last I heard, this bug fix did NOT fix the key-error problem. We are still getting lots of them (but it may have been fixed since in CVS. Michel?) -- Itamar S.T. itamar@maxnm.com

Itamar Shtull-Trauring wrote:

Last I heard, this bug fix did NOT fix the key-error problem. We are still getting lots of them (but it may have been fixed since in CVS. Michel?)

This is weird... the bit of code in question was: lib/python/SearchIndex/Lexicon.py line 132: else: self._lexicon[intern(word)] = self.counter self.counter = self.counter + 1 return self.counter Now Michel's patch was to change this to: else: self.counter = self.counter + 1 self._lexicon[intern(word)] = self.counter return self.counter However, in the CVS I see it is now: else: if not hasattr(self, 'counter'): self.counter = 0 self._lexicon[intern(word)] = self.counter self.counter = self.counter + 1 return self.counter - 1 I'm not even going to try and guess which is right, all I know is that I haven't made either change yet and I'm getting an unacceptable number of incorrect search results in stock 2.1.6 and would like to sort it out... Any ideas? cheers, Chris

Itamar Shtull-Trauring wrote:

You're using 2.1.6? That's something different. The KeyErrors bug only appeared in CVS ZCatalog - the partial searching version. So it must be something else - and for all I know this bug is fixed in CVS.

Yeah, this is happening on 2.1.6 as part of Squishdot 0.4.0 which I was hoping to release today, but this is going to put that back a bit :( What I'm experiencing is documents being returned that don't match the search criteria, usually only one per search, which is why I thought it was that same error... It'd be nice to have some way of checking what text ZCatalog is actually indexing although I'm 80% sure my code is doing what it should... I'd love to hear comments from anyone who's experienced the same thing, or from Michel to say it's something I'm doign wrong as this is driving me nuts :( cheers, Chris

Michel Pelletier wrote:

I'm looking into this right now...

Many thanks :-) As you may have gathered from my posts, I've been having a bit of a ZCatalog/SiteAccess (not to mention MIME) nightmare today... ...I took a day off work to try and get Squishdot 0.4.0 out and have spent the day tryign to figure out whether or not it's my that that's $"£$ed All I'd like to know is: Is ZCatalog in 2.1.6 likely to return incorrect search results, or is it my python code that's broken? In either case, how do I fix it? ;-) cheers, Chris PS: My code, that may be broken... data is an IOBTree for id-->Posting objects. Could there be any untoward aquisition going on here? Posting acquires from Implicit. def recatalogPostings(self,REQUEST=None): """ Clear the Catalog and then Index all the postings. """ self._catalog.clear() for id in self.data.keys(): obj = self.data[id] self.catalog_object(obj,self.absolute_url(1)+ obj.thread_path()+ '/' + `id`) return self.manage_postings(self, REQUEST) The index which is causing the problem is 'textToSearch' which is supplied by the following function: def textToSearch(self): """# returns the text to search for a ZCatalog""" text='' for line in self.summary: # strip out HTML and append a newline to each line. text = text+tagRegex.sub("",line)+'\n' for line in self.body: # strip out HTML and append a newline to each line. text = text+tagRegex.sub("",line)+'\n' return text

On Wed, 24 May 2000, Chris Withers wrote:

This is weird... the bit of code in question was: lib/python/SearchIndex/Lexicon.py line 132: [...] Now Michel's patch was to change this to: else: self.counter = self.counter + 1 self._lexicon[intern(word)] = self.counter return self.counter

I patched my 2.1.4 site with the above code, and my key errors and wrong-results went away. My site has 60K records being searched, so this constitues a fairly good test.

However, in the CVS I see it is now: else: if not hasattr(self, 'counter'): self.counter = 0 self._lexicon[intern(word)] = self.counter self.counter = self.counter + 1 return self.counter - 1

This *looks* like it might also work. We'll just have to wait for Michel's pronouncement. --RDM