Hi all,
A solution has been found. woohoo. A not found error was produced with
direct URL traversal.
Steve Spicklemire sent this solution off list.
The process is split into two steps:
Do the query to 'load the object on traversal':
WITH QUERY searchBy_Name(name=self.id) COMPUTE name
Do
After comsidering the fedback I got from the previous
'Massive scalability thread, I decided to split my queries
into two areas: Rack scalability and ZCatalog scalability.
This email deals with the former.
It seems clear that indexing and searching are more of a
botleneck than storage/retreival.
After comsidering the feedback I got from the previous
'Massive scalability' thread, I decided to split my queries
into two areas: Rack scalability and ZCatalog scalability.
This email deals with the latter.
Partial match (wildcard) searches have already been
identified as a resource hog,
Hi Michael,
Michael Bernstein wrote:
It seems clear that indexing and searching are more of a
botleneck than storage/retreival. Nevertheless, so far I
have not heard of anyone trying to store more than 60,000
objects in a rack. I need to know if there is any reason to
suspect that storage
Michael Bernstein wrote:
Also, is there a way to disable wildcards in full text
searches?
Do not allow direct queries to search the catalog. Instead, make
searches go through an external method (or a PythonScript with Proxy
permissions) that uses string.replace to change '*' and '?' to ''.
Steve Alexander wrote:
Michael Bernstein wrote:
Also, is there a way to disable wildcards in full text
searches?
Do not allow direct queries to search the catalog. Instead, make
searches go through an external method (or a PythonScript with Proxy
permissions) that uses
Erik Enge wrote:
[Michael Bernstein]
| I need to know how far the ZCatalog will scale using this indexing
| and search strategy. Does anyone have anectodal or benchmark data to
| suggest if (and when) I will hit a 'wall' regarding the number of
| objects being indexed and searched?
Steve Alexander wrote:
Hi Michael,
Michael Bernstein wrote:
It seems clear that indexing and searching are more of a
botleneck than storage/retreival. Nevertheless, so far I
have not heard of anyone trying to store more than 60,000
objects in a rack. I need to know if there is
Michael Bernstein wrote:
There is some question in my mind if
accessing any attribute (such as the thumbnail version)
causes all attributes to be loaded into memory. If so,
displaying a list of images with thumbnails may result in
many large objects being loaded into memory.
Make sure
[Michael Bernstein]
| I need to know how far the ZCatalog will scale using this indexing
| and search strategy. Does anyone have anectodal or benchmark data to
| suggest if (and when) I will hit a 'wall' regarding the number of
| objects being indexed and searched?
I'm going to try to stuff 27
Steve Alexander wrote:
Michael Bernstein wrote:
There is some question in my mind if
accessing any attribute (such as the thumbnail version)
causes all attributes to be loaded into memory. If so,
displaying a list of images with thumbnails may result in
many large objects being
Michael Bernstein wrote:
Make sure that each large attribute is an instance of a class that
derives from Persistent.
Ok, I'll give that a try. Since Photo is a Python Product,
what will happen to current instances if I make this (and
only this) change?
I don't know. I can think of
Casey Duncan wrote:
[EMAIL PROTECTED] wrote:
I've ended up hacking a version of special_dtml / ClassicHTMLFile that
serves up CSS. Has anyone got a better way of doing it (that detects
changes in the file and serves it up with the correct Content-Type)?
Check out:
Michael Bernstein wrote:
Also, is there a way to disable wildcards in full text
searches?
Do not allow direct queries to search the catalog. Instead, make
searches go through an external method (or a PythonScript with Proxy
permissions) that uses string.replace to change '*' and '?' to
Chris Withers wrote:
Wouldn't using a normal vocabulary as opposed to a globbing vocabulary
prevent this as well?
That would stop globbing searches for everyone.
While I might want to stop users of a site making wildcard searches, I
still want to keep that facility for myself :-)
--
The dtml-in batching mechanisms are quite difficult to debug - the DTML
documentation I have has examples which break it and there's no indication
of why. It turns out the DT_In renderwb() code gobbles all exceptions from
the rendering of the previous and next blocks. I've hacked my code so that
[EMAIL PROTECTED] wrote:
The dtml-in batching mechanisms are quite difficult to debug - the DTML
documentation I have has examples which break it and there's no indication
of why. It turns out the DT_In renderwb() code gobbles all exceptions from
the rendering of the previous and next
[EMAIL PROTECTED] wrote:
The dtml-in batching mechanisms are quite difficult to debug - the DTML
documentation I have has examples which break it and there's no indication
of why. It turns out the DT_In renderwb() code gobbles all exceptions from
the rendering of the previous and next
At 07:12 PM 1/21/01 +, Steve Alexander wrote:
So, storing things in a Rack happens in a number of stages:
Your application interacts with the Rack
The Rack (perhaps) stores the object persistently in its BTree
The BTree is a collection of persistent ZODB objects
The ZODB objects
19 matches
Mail list logo