OK, I thought it was fixed (and is fixed for the collector) but I guess
a workaround was just put in for collectors because other batches are
still limited to 200... should be safe to remove it and close some
zope.org bugs.
On Thu, 2003-10-23 at 22:09, Brian Lloyd wrote:
> Er - this one's my fault
Er - this one's my fault :) When I first started triage on nzo
there were a number of places where it was doing totally unbounded
searches and them sorting them for good measure. I put that in as
a stopgap so it would quit dying while I was trying to find the
culprits and forgot to remove it.
I see it's already fixed, thanks...
On Thu, 2003-10-23 at 16:39, Chris McDonough wrote:
> Aha! This is likely due to the monkey-patched searchResults method of
> the catalog tool. It is patched from within the ZopeOrg product's
> __init__.py:
>
> if not kw.has_key('sort_limit'):
> k
Aha! This is likely due to the monkey-patched searchResults method of
the catalog tool. It is patched from within the ZopeOrg product's
__init__.py:
if not kw.has_key('sort_limit'):
kw['sort_limit'] = 200
I'm sure this was put into there to foil some sort of DOS, but I think
it shou
On the new collector instances the high size of a collection of objects
seems to be limited to 200. Aha! Here we have evidence that someone
has hardcoded the number "200" as the upper limit for the number of
catalog results returned from the portal catalog on zope.org. This
happens with howtos a
