Re: [Zope-dev] skinscript and URL traversal question

2001-01-21 Thread Aaron Payne
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

[Zope-dev] Specialist/Rack scalability

2001-01-21 Thread Michael Bernstein
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.

[Zope-dev] ZCatalog scalability

2001-01-21 Thread Michael Bernstein
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,

Re: [Zope-dev] Specialist/Rack scalability

2001-01-21 Thread Steve Alexander
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

Re: [Zope-dev] ZCatalog scalability

2001-01-21 Thread Steve Alexander
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 ''.

Re: [Zope-dev] ZCatalog scalability

2001-01-21 Thread Michael Bernstein
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

Re: [Zope-dev] ZCatalog scalability

2001-01-21 Thread Michael Bernstein
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?

Re: [Zope-dev] Specialist/Rack scalability

2001-01-21 Thread Michael Bernstein
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

Re: [Zope-dev] Specialist/Rack scalability

2001-01-21 Thread Steve Alexander
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

Re: [Zope-dev] ZCatalog scalability

2001-01-21 Thread Erik Enge
[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

Re: [Zope-dev] Specialist/Rack scalability

2001-01-21 Thread Michael Bernstein
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

Re: [Zope-dev] Specialist/Rack scalability

2001-01-21 Thread Steve Alexander
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

Re: [Zope-dev] CSS file serving

2001-01-21 Thread richard
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:

Re: [Zope-dev] ZCatalog scalability

2001-01-21 Thread Chris Withers
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

Re: [Zope-dev] ZCatalog scalability

2001-01-21 Thread Steve Alexander
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 :-) --

[Zope-dev] dtml-in batching

2001-01-21 Thread richard
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

Re: [Zope-dev] dtml-in batching

2001-01-21 Thread richard
[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

Re: [Zope-dev] dtml-in batching

2001-01-21 Thread richard
[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

Re: [Zope-dev] Specialist/Rack scalability

2001-01-21 Thread Phillip J. Eby
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