On 29.06.09 12:48, yuppie wrote:
Hi!
I did plan to work on a small catalog improvement, but after looking at
the code I'd like to do some cleanup first:
1.) remove the deprecated TextIndex
The deprecation warning says:
'Using TextIndex is deprecated (will be removed in Zope '
'2.12).
Hi Andreas!
Andreas Jung wrote:
On 29.06.09 12:48, yuppie wrote:
3.) remove security declarations from ZCTextIndex and DateRangeIndex
All the other indexes don't have security declarations. AFAICS there is
no way to access indexes from untrusted code without having the 'Manage
On 29.06.09 19:33, yuppie wrote:
Hi Andreas!
Andreas Jung wrote:
On 29.06.09 12:48, yuppie wrote:
3.) remove security declarations from ZCTextIndex and DateRangeIndex
All the other indexes don't have security declarations. AFAICS there is
no way to access indexes from untrusted
Hedley Roos wrote:
Since memcached is distributed only a single Zope client needs to
perform that query and the result is available to all other Zope
clients.
This is where you'll get the big win: no need to load all the
catalog-related objects into the zodb cache on all the clients which
On Sun, 2008-10-26 at 14:07 -0400, Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Roché Compaan wrote:
On Sat, 2008-10-25 at 09:20 +0200, Hedley Roos wrote:
Have you measures the time needs for some standard ZCatalog queries
used with a Plone site with the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 27, 2008, at 13:08 , Roché Compaan wrote:
On Sun, 2008-10-26 at 14:07 -0400, Tres Seaver wrote:
- Plone uses too many indexes, and in particular, uses multiple text
indexes. Having extra indexes around just in case is a sure lose
a
On Mon, 2008-10-27 at 13:23 +0100, Jens Vagelpohl wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 27, 2008, at 13:08 , Roché Compaan wrote:
On Sun, 2008-10-26 at 14:07 -0400, Tres Seaver wrote:
- Plone uses too many indexes, and in particular, uses multiple text
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 27, 2008, at 13:32 , Roché Compaan wrote:
On Mon, 2008-10-27 at 13:23 +0100, Jens Vagelpohl wrote:
When it comes to integrating anything in Zope itself I'd choose the
latter.
Sure, we're not trying to get this into Zope, we're just
On Mon, 2008-10-27 at 13:41 +0100, Jens Vagelpohl wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 27, 2008, at 13:32 , Roché Compaan wrote:
On Mon, 2008-10-27 at 13:23 +0100, Jens Vagelpohl wrote:
When it comes to integrating anything in Zope itself I'd choose the
On Mon, Oct 27, 2008 at 12:33 PM, Andreas Jung [EMAIL PROTECTED] wrote:
On 27.10.2008 16:28 Uhr, Rudá Porto Filgueiras wrote:
I will sugest a package called zope.memcached (like zope.sqlalchemy
does for SQLAlchemy integration).
That way any application who need to talk memcached can do it
On 27.10.2008 17:18 Uhr, Rudá Porto Filgueiras wrote:
On Mon, Oct 27, 2008 at 12:33 PM, Andreas Jung[EMAIL PROTECTED] wrote:
On 27.10.2008 16:28 Uhr, Rudá Porto Filgueiras wrote:
I will sugest a package called zope.memcached (like zope.sqlalchemy
does for SQLAlchemy integration).
That way
On 26.10.2008 18:43 Uhr, Roché Compaan wrote:
On Sat, 2008-10-25 at 09:20 +0200, Hedley Roos wrote:
I suspect specific indexes are just performing suboptimally and needs to
be improved. ExtendPathIndex in Plone seems to be one of them.
Path indexes and fulltext indexes have a much more
Hi Roché,
I can see your funkload profile?
On Sun, Oct 26, 2008 at 3:43 PM, Roché Compaan
[EMAIL PROTECTED]wrote:
On Sat, 2008-10-25 at 09:20 +0200, Hedley Roos wrote:
Have you measures the time needs for some standard ZCatalog queries
used with a Plone site with the communication
Hi Fabio
The funkload tests were project specific. I plan to write up my findings
and to do benchmarks on a standard Plone instance and blog about it.
This will unfortunately have to wait since I'm on holiday this week :-)
--
Roché Compaan
Upfront Systems
On Sun, 2008-10-26 at 18:50 +0100, Andreas Jung wrote:
On 26.10.2008 18:43 Uhr, Roché Compaan wrote:
On Sat, 2008-10-25 at 09:20 +0200, Hedley Roos wrote:
I suspect specific indexes are just performing suboptimally and needs to
be improved. ExtendPathIndex in Plone seems to be one of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Roché Compaan wrote:
On Sat, 2008-10-25 at 09:20 +0200, Hedley Roos wrote:
Have you measures the time needs for some standard ZCatalog queries
used with a Plone site with the communication overhead with memcached?
Generally spoken: I think the
Very Nice.
Have a nice holiday :-)
On Sun, Oct 26, 2008 at 3:58 PM, Roché Compaan
[EMAIL PROTECTED]wrote:
Hi Fabio
The funkload tests were project specific. I plan to write up my findings
and to do benchmarks on a standard Plone instance and blog about it.
This will unfortunately have to
On 26.10.2008 19:05 Uhr, Roché Compaan wrote:
On Sun, 2008-10-26 at 18:50 +0100, Andreas Jung wrote:
On 26.10.2008 18:43 Uhr, Roché Compaan wrote:
On Sat, 2008-10-25 at 09:20 +0200, Hedley Roos wrote:
I suspect specific indexes are just performing suboptimally and needs to
be improved.
The usual Plone catalogs (portal_catalog, uid_catalog,
reference_catalog and membrane_tool) all run above 90% hit rate if the
server is up to it. portal_catalog is invalidated the most so it
fluctuates the most.
If the server is severely underpowered then catalogcache is much less
effective.
On 25.10.2008 8:48 Uhr, Hedley Roos wrote:
The usual Plone catalogs (portal_catalog, uid_catalog,
reference_catalog and membrane_tool) all run above 90% hit rate if the
server is up to it. portal_catalog is invalidated the most so it
fluctuates the most.
If the server is severely underpowered
Have you measures the time needs for some standard ZCatalog queries
used with a Plone site with the communication overhead with memcached?
Generally spoken: I think the ZCatalog is in general fast. Queries using a
fulltext index are known to be more expensive or if you have to deal with
large
Hedley Roos wrote:
As for standard queries on a Plone site the typical folder contents
query is a good example. The query will be fast unless it sorts on
sortable_title (a ZCTextIndex) right? Not sure right now.
sortable_title is a field index and shouldn't be slower than any other
index.
Hi,
On Fri, 2008-10-24 at 15:41 +0200, Hedley Roos wrote:
The product is a monkey patch to Catalog.py. I'd love some feedback and
suggestions.
I'd love if this wouldn't be a monkey patch.
Also, there is nothing that makes this integrate correctly with
transactions. Your cache will happily
I'd love if this wouldn't be a monkey patch.
So would I, but I couldn't find another way in this case.
Also, there is nothing that makes this integrate correctly with
transactions. Your cache will happily deliver never-committed data and
also it will not isolate transactions from each
In addition, you need to include a serial in your cache keys to avoid
dirty reads.
The cache invalidation code actively removes items from the cache. Am
I understanding you correctly?
H
___
Zope-Dev maillist - Zope-Dev@zope.org
On 25.10.2008 14:53 Uhr, Hedley Roos wrote:
I'd love if this wouldn't be a monkey patch.
So would I, but I couldn't find another way in this case.
Also, there is nothing that makes this integrate correctly with
transactions. Your cache will happily deliver never-committed data and
also it
On Sat, 2008-10-25 at 14:53 +0200, Hedley Roos wrote:
I'd love if this wouldn't be a monkey patch.
So would I, but I couldn't find another way in this case.
Also, there is nothing that makes this integrate correctly with
transactions. Your cache will happily deliver never-committed
On Sat, Oct 25, 2008 at 2:57 PM, Andreas Jung [EMAIL PROTECTED] wrote:
On 25.10.2008 14:53 Uhr, Hedley Roos wrote:
I'd love if this wouldn't be a monkey patch.
So would I, but I couldn't find another way in this case.
Also, there is nothing that makes this integrate correctly with
If you catalog an object, then search for it and then abort the
transaction, your cache will have data in it that isn't committed.
Kind of like how I came to the same conclusion in parallel to you and
stuffed up this thread :)
Additionally when another transaction is already running in
Additionally when another transaction is already running in parallel, it
will see cache inserts from other transactions.
A possible solution is to keep a module level cache which can be
committed to the memcache on transaction boundaries. That way I'll
incur no performance penalty.
H
On Sat, 2008-10-25 at 14:55 +0200, Hedley Roos wrote:
In addition, you need to include a serial in your cache keys to avoid
dirty reads.
The cache invalidation code actively removes items from the cache. Am
I understanding you correctly?
I wasn't even talking about invalidation as your
--On 10. Juli 2008 15:06:53 +0200 Martijn Jacobs [EMAIL PROTECTED]
wrote:
Wat denk je hiervan?
Hello.
In zope 2.10.5 (and probably 2.10.6 and 2.11 and, as I've read, all
releases above 2.7) we've encountered a sorting bug in a dtml-in call
when querying the catalog. I don't think it's
Maurits van Rees wrote at 2008-3-5 23:57 +:
...
I have an item in the portal_catalog of my Plone site that has some
string as description. The real object meanwhile has had a code
change so the description field now returns unicode. When I now
recatalog that object it throws an error:
Dieter Maurer wrote:
sys.setdefaultencoding is only available at startup.
Thus, setting defaultencoding must happen in a sitecustomize
or site module.
Or if you're sufficiently devious, it's available any time (not that
actually using it is a good idea, but...):
import sys
[EMAIL PROTECTED] wrote at 2006-9-3 18:06 -0400:
Thank you so much for following-up with me, here. I think you're right
about this having to do with the indexes on the ZCatalog.
The catalog has:
1. Seven FieldIndex indexes.
2. A DateIndex index
3. Three ZCTextIndex indexes
I have not seen
[EMAIL PROTECTED] wrote at 2006-9-1 13:29 -0400:
Traceback for my Key Error (Dieter, thank you for alerting me on where
to find this):
Traceback (innermost last):
...
- Physical Path: /nephron_links/news_dtml
Module DocumentTemplate.DT_String, line 476, in __call__
Module
Dieter Maurer wrote at 2006-9-3 19:22 +0200:
[EMAIL PROTECTED] wrote at 2006-9-1 13:29 -0400:
Traceback for my Key Error (Dieter, thank you for alerting me on where
to find this):
Traceback (innermost last):
...
- Physical Path: /nephron_links/news_dtml
Module DocumentTemplate.DT_String,
Thank you so much for following-up with me, here. I think you're right
about this having to do with the indexes on the ZCatalog.
The catalog has:
1. Seven FieldIndex indexes.
2. A DateIndex index
3. Three ZCTextIndex indexes
I actually create these from python in a function that accepts the
--On 1. September 2006 02:54:26 -0400 [EMAIL PROTECTED]
wrote:
I have a Zope product that relies heavily on a ZCatalog to search for
objects within a folder matching certain criteria. The ZCatalog
frequently becomes corrupt, and on searching the catalog, the catalog
gives me key errors.
Read or Write conflict errors?
I'm getting the Key Error traceback on Reads, but my guess is that the
actual error happens sometime before the Key Error, when the
ZCatalog itself is corrupted. I am not sure what that is, because it
does not generate an error.
However, I see the error when I
[EMAIL PROTECTED] wrote at 2006-9-1 02:54 -0400:
I have a Zope product that relies heavily on a ZCatalog to search for
objects within a folder matching certain criteria. The ZCatalog
frequently becomes corrupt, and on searching the catalog, the catalog
gives me key errors. I'm trying to figure
Traceback for my Key Error (Dieter, thank you for alerting me on where
to find this):
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module
Guys,
Dieter Maurer [EMAIL PROTECTED] wrote:
Roché Compaan wrote at 2005-2-25 17:22 +0200:
Last year in March the following checkin was made that changed
ZCatalog's getObject to use restrictedTraverse instead of
unrestrictedTraverse. See:
--On Donnerstag, 10. März 2005 12:49 Uhr +0100 Florent Guillaume
[EMAIL PROTECTED] wrote:
Guys,
Dieter Maurer [EMAIL PROTECTED] wrote:
Roché Compaan wrote at 2005-2-25 17:22 +0200:
Last year in March the following checkin was made that changed
ZCatalog's getObject to use restrictedTraverse
Roché Compaan wrote at 2005-3-3 22:36 +0200:
On Thu, 2005-03-03 at 19:36 +0100, Dieter Maurer wrote:
Roché Compaan wrote at 2005-3-3 09:53 +0200:
...
-return self.aq_parent.restrictedTraverse(self.getPath(), None)
+obj = self.aq_parent.unrestrictedTraverse(self.getPath(),
Roché Compaan wrote:
+obj = self.aq_parent.unrestrictedTraverse(self.getPath(), None)
+if obj and securityManager.validate(obj, obj, None, None):
+return obj
+else:
+return None
Urm, Roche, doesn't the above seek to do exactly what...
return
On Thu, 2005-03-03 at 14:56 +, Chris Withers wrote:
Roché Compaan wrote:
+obj = self.aq_parent.unrestrictedTraverse(self.getPath(), None)
+if obj and securityManager.validate(obj, obj, None, None):
+return obj
+else:
+return None
Roché Compaan wrote at 2005-3-3 09:53 +0200:
...
-return self.aq_parent.restrictedTraverse(self.getPath(), None)
+obj = self.aq_parent.unrestrictedTraverse(self.getPath(), None)
+if obj and securityManager.validate(obj, obj, None, None):
I think this is not correct:
On Thu, 2005-03-03 at 19:36 +0100, Dieter Maurer wrote:
Roché Compaan wrote at 2005-3-3 09:53 +0200:
...
-return self.aq_parent.restrictedTraverse(self.getPath(), None)
+obj = self.aq_parent.unrestrictedTraverse(self.getPath(), None)
+if obj and
--On Mittwoch, 2. März 2005 9:56 Uhr + Chris Withers
[EMAIL PROTECTED] wrote:
Roché Compaan wrote:
Maybe, a bug report to the collector will help?
http://www.zope.org/Collectors/Zope
Well, I posted just such an issue a few months back. I'm working offline
so can't give you the exact
On Fri, 2005-02-25 at 21:06 +0100, Andreas Jung wrote:
--On Freitag, 25. Februar 2005 20:21 Uhr +0100 Dieter Maurer
[EMAIL PROTECTED] wrote:
Roché Compaan wrote at 2005-2-25 17:22 +0200:
Last year in March the following checkin was made that changed
ZCatalog's getObject to use
Roché Compaan wrote at 2005-2-25 17:22 +0200:
Last year in March the following checkin was made that changed
ZCatalog's getObject to use restrictedTraverse instead of
unrestrictedTraverse. See:
http://mail.zope.org/pipermail/zope-checkins/2004-March/026846.html
In my opininion this is wrong,
I
--On Sonntag, 30. Januar 2005 19:17 Uhr +0100 Dieter Maurer
[EMAIL PROTECTED] wrote:
- some indexes show the number of indexed objects vs the number of
indexes terms
within the ZMI which is totally inconsistent. I think the ZMI should
show the number
of indexed objects. Index specific
Andreas Jung wrote at 2005-1-31 18:50 +0100:
...
[AJ]
- some indexes show the number of indexed objects vs the number of
indexes terms
within the ZMI which is totally inconsistent. I think the ZMI should
show the number
of indexed objects. Index specific information e.g. the number of
--On Montag, 31. Januar 2005 20:20 Uhr +0100 Dieter Maurer
[EMAIL PROTECTED] wrote:
I am not with you with respect to number of indexed objects
versus size of the index. In fact *BOTH* as index specific
(otherwise, it would not make any sense to list it in an index
specific column).
Maybe, a
Andreas Jung wrote at 2005-1-30 15:30 +0100:
...
Outstanding issues:
- some indexes show the number of indexed objects vs the number of indexes
terms
within the ZMI which is totally inconsistent. I think the ZMI should
show the number
of indexed objects. Index specific information
Jason Spisak wrote:
Zopistas,
My ZCatalog is fast as admin, but dog slow as anonymous and other users.
Anyone had this same experience? Details:
This is certainly to do with queries which run against FieldIndexes only
for anonymous users. This is something the CMF does (e.g. expires and
Seb,
thanks! i'll give that a shot. i also thought of adding daterange
indexes for the calendar portion or things. does that also garner any
speed improvement?
Seb Bacon wrote:
Jason Spisak wrote:
Zopistas,
My ZCatalog is fast as admin, but dog slow as anonymous and other
users.
Seb,
I've replaced the following date indexes that werer FieldIndexes with
DateIndexes
Date
effective
expires
modified
i'll let you know what kind of speed improvement I get.
Jason Spisak wrote:
Zopistas,
My ZCatalog is fast as admin, but dog slow as anonymous and other
users. Anyone had
Dieter Maurer wrote:
But overall, unless you have special (non DC derived) indexes,
That can well be the case...
Anyway, what are we going to do about this crawling tab?
Chris
___
Zope-Dev maillist - [EMAIL PROTECTED]
Chris Withers wrote at 2003-7-21 08:22 +0100:
Dieter Maurer wrote:
#objects suggests that it is the number of objects indexed by
this index. Who is interested in this information?
Well, it's been useful to be on several occasions when I've seen one index has
less objects in than
Dieter Maurer wrote:
#objects suggests that it is the number of objects indexed by
this index. Who is interested in this information?
Well, it's been useful to be on several occasions when I've seen one index has
less objects in than another...
Unless one has inhomogeous objects, almost all
Casey Duncan wrote:
Actually I regard the current behavior as a feature. Using a stopwatch and a
slide-rule I can estimate to within 100 objects, how many values are indexed
in a catalog by measuring the time it takes to draw the indexes page.
Please do not remove this most valued feature!
I
Dieter Maurer wrote:
I suggest to change the title to # index terms and
revert for the indexes to the old behaviour.
If that'll make it quicker, cool :-)
Others pointed out, that also the size determination for an
index may be expensive. However, it is at most linear in the number
(rather than
Anthony Baxter wrote:
if there's no counter present:
create one, do a count of the docs, initialise the counter
display counter
Sounds good, what needs to happen to make this happen?
Since this is a bug fix, can it go on the 2.6 branch?
cheers,
Chris
--On Freitag, 18. Juli 2003 13:52 Uhr +0100 Chris Withers
[EMAIL PROTECTED] wrote:
Dieter Maurer wrote:
I suggest to change the title to # index terms and
revert for the indexes to the old behaviour.
If that'll make it quicker, cool :-)
I am usually not interested in the number of index terms
--On Freitag, 18. Juli 2003 13:53 Uhr +0100 Chris Withers
[EMAIL PROTECTED] wrote:
Anthony Baxter wrote:
if there's no counter present:
create one, do a count of the docs, initialise the counter
display counter
Sounds good, what needs to happen to make this happen?
Since this is a bug fix,
On Friday 18 July 2003 01:29 pm, Dieter Maurer wrote:
Anthony Baxter wrote at 2003-7-18 15:14 +1000:
Andreas Jung wrote
I agree but the current implementation sux. Switching to a counter
based
solution would solve the problem. The only problem I see is to keep the
code fully
Anthony Baxter wrote at 2003-7-18 15:14 +1000:
Andreas Jung wrote
I agree but the current implementation sux. Switching to a counter based
solution would solve the problem. The only problem I see is to keep the
code fully backward compatible.
if there's no counter present:
so... would anyone mind?
Well, I've often been interested to note the numbers. It gave me
a feeling for which indexes are heavily used. Sure, I could figure
this out without looking at this page, but the (lack of) speed
hasn't bugged me ..
--
Jean Jordaan
http://www.upfrontsystems.co.za
--On Donnerstag, 17. Juli 2003 12:26 Uhr +0200 Jean Jordaan
[EMAIL PROTECTED] wrote:
so... would anyone mind?
Well, I've often been interested to note the numbers. It gave me
a feeling for which indexes are heavily used. Sure, I could figure
this out without looking at this page, but the (lack
--On Donnerstag, 17. Juli 2003 12:29 Uhr +0100 Chris Withers
[EMAIL PROTECTED] wrote:
The problem is caused by calling len() on the indexes btrees. Instead
a counter implemented btree.Length should be used in the future.
Which Index types are currently guilty of this?
I think all except
Chris Withers wrote at 2003-7-17 11:12 +0100:
Has anyone noticed that the ZCatalog Indexes tab crawls if you have loads of
objects indexed.
My guess is that some types of index take way too long to figure out how many
objects are indexed. Anyone know which index types those could be?
Actually I regard the current behavior as a feature. Using a stopwatch and a
slide-rule I can estimate to within 100 objects, how many values are indexed
in a catalog by measuring the time it takes to draw the indexes page.
Please do not remove this most valued feature!
-Casey
On Thursday 17
--On Donnerstag, 17. Juli 2003 18:22 Uhr -0400 Casey Duncan
[EMAIL PROTECTED] wrote:
Actually I regard the current behavior as a feature. Using a stopwatch
and a slide-rule I can estimate to within 100 objects, how many values
are indexed in a catalog by measuring the time it takes to draw
Andreas Jung wrote
I agree but the current implementation sux. Switching to a counter based
solution would solve the problem. The only problem I see is to keep the
code fully backward compatible.
if there's no counter present:
create one, do a count of the docs, initialise the counter
On Tue, 2002-06-04 at 15:38, Vincenzo Di Somma wrote:
Hi all,
I have a product with a main class (registeredin the __init__.py) and
some utility classes I don`t want to register, does the ZCatalog have
problem finding istances of not registered classes ?
I`m not able to index them.
I`ve
The problem with this solution is that you must wake up every object
found, thus negating the performance/memory advantaged of ZCatalog's
lazy result sets.
Since you said (in your other message) that the restriction is by role,
couldn't you just index the roles allowed to view a given object
Igor Stroh writes:
That means, users that don't have the permission
to View or Access Content Information can see the brains as well...
You can look how the CMF (Content Management Framework) solves this problem.
Look for allowedRolesAndUsers and the implicit query extension
what do you mean by fuzzy? Do you mean with wildcards, NL, or something
else?
-Original Message-
From: Dirk Datzert [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 06, 2001 1:03 PM
To: [EMAIL PROTECTED]
Subject: [Zope-dev] ZCatalog
Hi,
I'm looking for a howto or a hint for fuzzy
the search engine htdig has a fuzzy feature which automatically search for
different endings or alternative spelling of a word, based on the ispell
algorithm
[EMAIL PROTECTED] schrieb:
what do you mean by fuzzy? Do you mean with wildcards, NL, or something
else?
-Original Message-
: [EMAIL PROTECTED]
Subject: Re: [Zope-dev] ZCatalog
the search engine htdig has a fuzzy feature which automatically search for
different endings or alternative spelling of a word, based on the ispell
algorithm
[EMAIL PROTECTED] schrieb:
what do you mean by fuzzy? Do you mean with wildcards, NL
Are you using any virtual hosting setup of any kind? If so, switching from
using a base class of CatalogAware.CatalogAware to
CatalogPathAware.CatalogAware might solve this problem...
Sean
-Original Message-
From: Jean Jordaan [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 03, 2001
On Fri, 16 Nov 2001 13:19:20 + Steve Alexander [EMAIL PROTECTED]
wrote:
Now your users see only those hits in a query which apply to objects
they are allowed to View.
However, you will be loading each object that is a potential query
result into memory for every query. That could be a
Igor Stroh wrote:
Hi all,
I don't know if it's the right list to post to, but I have the following
problem:
I have several objects (documents, folders etc) that are accessible only
by a certain user role, this objects are cataloged. Now if I query the
catalog the brains of these objects
We've installed Kavio's CatalogQuery product and are very happy with it.
Haven't looked at the ZOQLMethod from iuveno yet, but both look like
great steps in the right direction.
Thanks.
I actually need to look at Casey's code and see what I can reuse. The
efficiency of my version is not that
Having an exists function would be great. I was trying to do the same
using CatalogQuery, but I found no way to check for Missing.Value, which
is the repr() of what's in the catalog's metadata field for objects that
don't have that attribute/function. I also ran into problems doing more
complex
:33
To: Bjorn Stabell
Cc: [EMAIL PROTECTED]
Subject: RE: [Zope-dev] ZCatalog searching for missing values
I just tried out ZOQLMethod as well. Couldn't get it to work, but it
looks like really solid craftsmanship. I like the
user-friendly way of
selecting base object and the complete
E. Seifert wrote:
Hi list,
as I'm not very familiar with the internals of ZCatalog I have a question to
all you API experts:
Why does ZCatalog.py (under Zope 2.4.1) specify a 'addIndex' permission for
a method called 'manage_delIndexes' although there is no such method? The
only method
- Original Message -
From: Shane Rowatt [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, October 03, 2001 00:54
Subject: [Zope-dev] ZCatalog: path summary indices not generated
Unfortunately I tried the same with the 'path' index by adding the
following
to DTMLMethod.py
On Wednesday 03 October 2001 12:54 am, Shane Rowatt allegedly wrote:
Zope Version: 2.4.1 on linux.
When I tried to add a ZCatalog followed by finding objects to index using
the default indices provided (path, summary, id, title etc), the 'path' and
'summary' indices are never generated. The
E. Seifert wrote:
Hi list,
as I'm not very familiar with the internals of ZCatalog I have a question to
all you API experts:
Why does ZCatalog.py (under Zope 2.4.1) specify a 'addIndex' permission for
a method called 'manage_delIndexes' although there is no such method? The
only method
Thanks for the fast reply Casey.
Casey Duncan wrote:
On Thursday 27 September 2001 12:48 pm, Oliver Bleutgen allegedly wrote:
Hi,
I'm resending this to zope-dev because on zope
nobody answered, it would be very nice if someone
could step up with a small hint.
Can somenone briefly
Steve Alexander wrote:
I'm getting a strange problem with ZCatalog, using python 2.1, Zope from
CVS.
I get all the results I expect with this:
ul
dtml-in Catalog(process_step=['start','mailed'])
li dtml-subject_name; -- dtml-relationship_name; - dtml-rater_name;
/dtml-in
/ul
Steve Alexander wrote:
This gives partial results:
dtml-in Catalog(process_step=['start','mailed'],
sort_on='subject_name')
...because this returns a LazyCat instance, for which len() is broken.
This gives full results:
dtml-in Catalog(process_step=['start','mailed'],
Steve Alexander wrote:
Patch coming up soon...
Patch against Catalog.py, from CVS:
*** lib/python/Products/ZCatalog/Catalog.py.original
--- lib/python/Products/ZCatalog/Catalog.py.patched
***
*** 673,679
if (type(so) is type('') and
Paulo M. Goncalves wrote:
I'm a Zope and Python newbie and I'm trying to work with Zope's ZCatalog
in a Product coded in python. Can anyone give some intro or point to
some links with info in this subject.
Maybe have a look at the SquishSite.py file in Squishdot?
The search method of the
Hi Paulo..
I can't give you any real specific advice on where to get
info besides the Zope Book, but you may want to take a look
at the ZCatalog.py and Catalog.py source code (in the
ZCatalog product). Also, the (always forgotten) help system
has documentation on the Catalog's interfaces.
- C
On Sat, 30 Jun 2001 20:47:02 +0100, you wrote:
I'm trying to work with Zope's ZCatalog in a Product
coded in python. Can anyone give some intro or point
to some links with info in this subject.
There is a ZCatalog tutorial on
http://www.zope.org/Documentation/How-To/ZCatalogTutorial/
The
Chris McDonough wrote:
This purpose aligns well with those of the ArmoredCatalog proposal as well..
see http://dev.zope.org/Wikis/DevSite/Proposals/ArmoredCatalog .
But even using such a lazy catalog awareness, you might get into
trouble. Using the ZCatalog's find objects function, I
1 - 100 of 270 matches
Mail list logo
