Keyword index search
Hi all I have a ZCatalog object with a keywordindex called keywords I would like to search some objects with keywords ['k1', 'k2', k3', 'k4'] for that I use: return context.catalog({'keywords': {'query': ['k1', 'k2', k3', 'k4'], 'operator': 'and'}}) but these query returns objects with keyword = ['k2', 'k3'] (for me incorrect, I would like to find objects with *all* keywords How can I make these kind of querys? Thanks! -- Mis Cosas http://blogs.sistes.net/Garito/
On Fri, 2005-05-20 at 12:41 +0200, Garito wrote:
Hi all
I have a ZCatalog object with a keywordindex called keywords
I would like to search some objects with keywords ['k1', 'k2', k3', 'k4'] for that I use:
return context.catalog({'keywords': {'query': ['k1', 'k2', k3', 'k4'], 'operator': 'and'}})
but these query returns objects with keyword = ['k2', 'k3'] (for me incorrect, I would like to find objects with *all* keywords
Do you mean you'd like to find objects that have *all* of the keywords in the query list or do you mean you'd like to find objects with *any* of the keywords in the query list? Can you give an example of two or three objects, their keywords, a query, and the desired results? - C
Garito wrote at 2005-5-20 12:41 +0200:
... I have a ZCatalog object with a keywordindex called keywords
I would like to search some objects with keywords ['k1', 'k2', k3', 'k4'] for that I use:
return context.catalog({'keywords': {'query': ['k1', 'k2', k3', 'k4'], 'operator': 'and'}})
but these query returns objects with keyword = ['k2', 'k3'] (for me incorrect, I would like to find objects with *all* keywords
How can I make these kind of querys?
A long standing bug in "KeywordIndex"... Maybe, you give my "Managable KeywordIndex" a try (part of "ManagableIndex"). I cannot promiss you that "ManagableIndex" is free of bugs but I definitely can promiss you that a bug resulting in wrong search results is fixed much much more quickly than in the Zope core :-) <http://www.dieter.handshake.de/pyprojects/zope> -- Dieter
Dieter Maurer escribió:
Garito wrote at 2005-5-20 12:41 +0200:
... I have a ZCatalog object with a keywordindex called keywords
I would like to search some objects with keywords ['k1', 'k2', k3', 'k4'] for that I use:
return context.catalog({'keywords': {'query': ['k1', 'k2', k3', 'k4'], 'operator': 'and'}})
but these query returns objects with keyword = ['k2', 'k3'] (for me incorrect, I would like to find objects with *all* keywords
How can I make these kind of querys?
A long standing bug in "KeywordIndex"...
Maybe, you give my "Managable KeywordIndex" a try (part of "ManagableIndex").
I cannot promiss you that "ManagableIndex" is free of bugs but I definitely can promiss you that a bug resulting in wrong search results is fixed much much more quickly than in the Zope core :-)
Hi Dieter! I can't understand the lack of concern you talk about unresolved bugs in Zope It seems Zope is not a serious tool. Imagine you want to buy a car but the seller says: in these model there are a bug on the brake system but I you put these extra no problem How can I convince my customers to use Zope with these kind of searchable information? I think the bigger problem of applications like SO, Application servers and so on are they only think to put more and more funcionality rather that make it's code better and simple Zope has a very good plug-in machinery. Why don't we use it instead of put more and more funcionality? Why I need, for example, five on 2.8 if I don't use it? I know that five is on 2.8 because you need to integrate it on zope to migrate to Z3 but I think its better for all us if zope still remain simple, quickly and bugs free instead of a very big application server with a lot of features and a lot of lines of code (that they can fail) Do you know basecamp? They build simple applications that work del.icio.us? The same rules Flirck? idem, and so on Less is more Thanks a lot PD: sorry but these mail is only an opinion. Zope development team could do what they want, logically -- Mis Cosas http://blogs.sistes.net/Garito/
--On Samstag, 21. Mai 2005 13:29 Uhr +0200 Garito <garito@sistes.net> wrote:
A long standing bug in "KeywordIndex"...
Hi Dieter! I can't understand the lack of concern you talk about unresolved bugs in Zope It seems Zope is not a serious tool. Imagine you want to buy a car but the seller says: in these model there are a bug on the brake system but I you put these extra no problem
This bug is indeed a very old bug: collector.zope.org/Zope/889 So it is up to *someone* to fix it - this means writing additional tests for the fix. If you volunteer to write additional test then I volunteer to fix the bug. So bugs become fixed as needed. Maybe there was no need to fix this bug so far :-) -aj
Garito wrote at 2005-5-21 13:29 +0200:
... Dieter Maurer escribió: ...
A long standing bug in "KeywordIndex"...
Maybe, you give my "Managable KeywordIndex" a try (part of "ManagableIndex"). ... I can't understand the lack of concern you talk about unresolved bugs in Zope
I am a big Zope user who also files occational bug reports and patches. However, I cannot fix bugs in Zope directly (due to excessive demands with respect to patents, I am not willing to sign the contributors agreement). I am not very concerned about unresolved bugs because: * Zope is open source. I can fix any bug which seriously hampers my work -- not in the public Zope sources but in our sources of Zope. To keep upgrades possible despite local modifications, we maintain Zope in a source code control system (CVS currently). * I am a pragmatist. When I know there is a problem and I know how to avoid it, I just avoid it. Especially, I am no longer concerned with bugs in Zope's indexes since I have "ManagableIndex". I believe "ManagableIndex" it is more flexible, more efficient and has less bugs than the stock Zope indexes.
It seems Zope is not a serious tool. Imagine you want to buy a car but the seller says: in these model there are a bug on the brake system but I you put these extra no problem
The keyword index bug is far less serious than a bug in the brake system of a car. I think, I wrote about 5 times "a long standing bug" in the last two to three years. There are apparently not that many people concerned about this bug.
How can I convince my customers to use Zope with these kind of searchable information?
You tell them that you can fix serious problems yourself because Zope is open source -- if there is not already a fix around (I told you that "Managable KeywordIndex" does not have this problem). -- Dieter
Dieter Maurer escribió:
Garito wrote at 2005-5-21 13:29 +0200:
... Dieter Maurer escribió: ...
A long standing bug in "KeywordIndex"...
Maybe, you give my "Managable KeywordIndex" a try (part of "ManagableIndex").
... I can't understand the lack of concern you talk about unresolved bugs in Zope
I am a big Zope user who also files occational bug reports and patches. However, I cannot fix bugs in Zope directly (due to excessive demands with respect to patents, I am not willing to sign the contributors agreement).
I am not very concerned about unresolved bugs because:
* Zope is open source. I can fix any bug which seriously hampers my work -- not in the public Zope sources but in our sources of Zope.
To keep upgrades possible despite local modifications, we maintain Zope in a source code control system (CVS currently).
Poor. 1 Zope developer, 1 Zope version, 1000 Zope developers, 1000 Zope versions?
* I am a pragmatist. When I know there is a problem and I know how to avoid it, I just avoid it.
If I know where the problem is I report it to fix the bug
Especially, I am no longer concerned with bugs in Zope's indexes since I have "ManagableIndex". I believe "ManagableIndex" it is more flexible, more efficient and has less bugs than the stock Zope indexes.
Why 2 ways?: 1.- Official one doesn't work 2.- Unofficial one who needs some duplicated dependency (OFolder seem very similar to Ordered folder don't you thing?) If I can't maintain my system clear and simple I change my application server: easy
It seems Zope is not a serious tool. Imagine you want to buy a car but the seller says: in these model there are a bug on the brake system but I you put these extra no problem
The keyword index bug is far less serious than a bug in the brake system of a car. I think, I wrote about 5 times "a long standing bug" in the last two to three years. There are apparently not that many people concerned about this bug.
Perhaps but *your product doesn't work properly* any diference if you was a brake system producer (here I'm talking with the keyword index original developer)
How can I convince my customers to use Zope with these kind of searchable information?
You tell them that you can fix serious problems yourself because Zope is open source -- if there is not already a fix around (I told you that "Managable KeywordIndex" does not have this problem).
Anyway (I see I can't do anything to change your way of life) Another question for the main Zope developers group Did you plan to make some make-up to simplify Zope? In my opinion Zope has at least one competitive advantage: the fresh concept about objects but these kind of advantage is lost when the code grows and grows Thanks PD: I don't want to create controversy. I'm developing some code and the *MAIN* feature is **MINIMUM** -- Mis Cosas http://blogs.sistes.net/Garito/
--On Sonntag, 22. Mai 2005 16:54 Uhr +0200 Garito <garito@sistes.net> wrote:
Poor. 1 Zope developer, 1 Zope version, 1000 Zope developers, 1000 Zope versions?
People do often backport port from their private repository back to the official one. This is true for Dieter, myself and other developers. But not every extension from private repositories will make it back into the official repository either because the extensions are too specific or just because people don't have time (and interest) to perform backporting work.
If I know where the problem is I report it to fix the bug
As I wrote this bug is already in the Zope collector.
Anyway (I see I can't do anything to change your way of life)
Another question for the main Zope developers group
Did you plan to make some make-up to simplify Zope?
What do you have in mind with "make-up to simplify Zope"? -aj
Andreas Jung escribió:
--On Sonntag, 22. Mai 2005 16:54 Uhr +0200 Garito <garito@sistes.net> wrote:
Poor. 1 Zope developer, 1 Zope version, 1000 Zope developers, 1000 Zope versions?
People do often backport port from their private repository back to the official one. This is true for Dieter, myself and other developers. But not every extension from private repositories will make it back into the official repository either because the extensions are too specific or just because people don't have time (and interest) to perform backporting work.
If I know where the problem is I report it to fix the bug
As I wrote this bug is already in the Zope collector.
Anyway (I see I can't do anything to change your way of life)
Another question for the main Zope developers group
Did you plan to make some make-up to simplify Zope?
What do you have in mind with "make-up to simplify Zope"?
-aj
Identify and acotated the duplicate classes (I know you are a fan of DTML, for example, but I think they aport a duplicate functionality with python scripts and page templates) to unify in one Change obsolete classes to the new and better builds (For example, Dieter says Managable Index is better for keyword index. Why don't change it and put on the main distribution?) Those kind of things In my opinion, I persist, Zope has a main advantage: the OOP paradigm is implemented in a very fresh way and it's very simple but If it lost these advantages we have nothing to defend Why don't use Ruby for example (with Ruby on Rails or without it)? It's modern (if you compare it with python) and clear I need simple things because less code means less failure posibility and means quick code Thanks! -- Mis Cosas http://blogs.sistes.net/Garito/
--On Sonntag, 22. Mai 2005 17:21 Uhr +0200 Garito <garito@sistes.net> wrote:
Identify and acotated the duplicate classes (I know you are a fan of DTML, for example, but I think they aport a duplicate functionality with python scripts and page templates) to unify in one Change obsolete classes to the new and better builds (For example, Dieter says Managable Index is better for keyword index. Why don't change it and put on the main distribution?)
Integrating third-party code requires (at least): - the license of the third-party code must be compatible with the ZPL - the code should follow certain coding-styles - someone must invest (personal) time to get it integrated *But* since you can download and install ManageableIndexes within one minute there should be not be problem for you to use MI. You can not put everything into the core that might be of interest for somebody at some time. MI is a good piece of software but most people should be fine with the indexes in the Zope core. If not they can grab Dieters software.
Those kind of things
In my opinion, I persist, Zope has a main advantage: the OOP paradigm is implemented in a very fresh way and it's very simple but If it lost these advantages we have nothing to defend
Why don't use Ruby for example (with Ruby on Rails or without it)? It's modern (if you compare it with python) and clear
Why is Ruby modern and Python is not? At one point you have to decide for a set of tools and language which you are using for your daily work. I am using Python since 1993 or so and it still solves my problems mostly in the field I am working. There is always something better in some tool or language than in another tool but this is not an argument to change your tools on a daily basis as you change your socks (hopefully). -aj
On 5/22/05, Garito <garito@sistes.net> wrote:
Identify and acotated the duplicate classes (I know you are a fan of DTML, for example, but I think they aport a duplicate functionality with python scripts and page templates) to unify in one
You have a good point. But... if we do things like that, we kill all backwards compatibility, so i don't think that is a feasible way forwards for Zope2. Also loads of things need to be reimplemented, in that case. However, one project HAS done just that kind of thing: Zop3.
Why don't use Ruby for example (with Ruby on Rails or without it)? It's modern (if you compare it with python) and clear
I hear many Ruby-people claiming ruby is superiour ty Python. None has yet been able to show me one superiority that is not simply matters of taste. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
Garito wrote at 2005-5-22 16:54 +0200:
... Dieter Maurer wrote
... I am a big Zope user who also files occational bug reports and patches. ... * I am a pragmatist. When I know there is a problem and I know how to avoid it, I just avoid it.
If I know where the problem is I report it to fix the bug
I told you above that I do, too, provided that * I have the problem (I do not have a "KeywordIndex" problem because I have "Managable KeywordIndex") * I see some chance that the problem gets addressed. But, if the problem is pressing, then my pragmatist part says: avoid or fix in our version.
I believe "ManagableIndex" it is more flexible, more efficient and has less bugs than the stock Zope indexes.
Why 2 ways?:
Because of different decision makers...
1.- Official one doesn't work 2.- Unofficial one who needs some duplicated dependency (OFolder seem very similar to Ordered folder don't you thing?)
Indeed: "ManagableIndex" required order support -- before there was such support in the Zope core. Thus, I took one which provided this functionality: "OFolder". Now Zope has built in order support and "ManagableIndex" could (in principle) use this. But why should I invest work into this change? What it would help *me*? It might save about 5 minutes of installation time for "ManagableIndex". But, truely, it that worth any effort? If you answer yes, send me a check about 100 EUR and I will change "ManagableIndex" to use "Ordered Folder".
... Perhaps but *your product doesn't work properly* any diference if you was a brake system producer (here I'm talking with the keyword index original developer)
The "and" operator is a rare use case for "KeywordIndex". That's the reason why this problem occurs comparatively rarely (a few times in some years). And that's probably an essential cause why this bug still exists.
... Anyway (I see I can't do anything to change your way of life)
At least you should carefully read my responses to your questions: As I wrote earlier, I can not change the official Zope code! -- Dieter
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Garito wrote:
Dieter Maurer escribió:
Garito wrote at 2005-5-20 12:41 +0200:
... I have a ZCatalog object with a keywordindex called keywords
I would like to search some objects with keywords ['k1', 'k2', k3', 'k4'] for that I use:
return context.catalog({'keywords': {'query': ['k1', 'k2', k3', 'k4'], 'operator': 'and'}})
but these query returns objects with keyword = ['k2', 'k3'] (for me incorrect, I would like to find objects with *all* keywords
How can I make these kind of querys?
A long standing bug in "KeywordIndex"...
Maybe, you give my "Managable KeywordIndex" a try (part of "ManagableIndex").
I cannot promiss you that "ManagableIndex" is free of bugs but I definitely can promiss you that a bug resulting in wrong search results is fixed much much more quickly than in the Zope core :-)
Hi Dieter! I can't understand the lack of concern you talk about unresolved bugs in Zope It seems Zope is not a serious tool. Imagine you want to buy a car but the seller says: in these model there are a bug on the brake system but I you put these extra no problem
How can I convince my customers to use Zope with these kind of searchable information?
The bug you encountered is sufficiently an "edge case" that it has not gotten any attention from the people who could fix it. Agitating for it on the list is likely to be less productive than contributing: - Write one or more unit tests which demonstrates the failure (e.g., they fail with the current implementation). - Implement the fix, such that the new tests pass without causing any others to fail. - Submit the patch, including both the test and the patched implementation, as an attachment to the collector issue Andreas pointed to: http://www.zope.org/Collectors/Zope/889 Such bug reports get quicker attention, because: - they demand less effort from the person with commit access to understand the problem (even without the fix, writing the test case would be valuable here). - they show that the bug matters enough to somebody to have invested the effort. I have checked in a number of patches from Dieter in this way, which means that Dieter is contributing to the "core" Zope code, even without checkin access (which Dieter doesn't want to obtain). Tres. - -- =================================================================== Tres Seaver tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCkMrZ+gerLs4ltQ4RAl14AJ4xmHMk6PKCJrTv3hJQ/xeCOqNYsgCglSiP KSHy7IctCFqHBoOmxwSTMws= =HCJO -----END PGP SIGNATURE-----
Tres Seaver escribió:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Garito wrote:
Dieter Maurer escribió:
Garito wrote at 2005-5-20 12:41 +0200:
... I have a ZCatalog object with a keywordindex called keywords
I would like to search some objects with keywords ['k1', 'k2', k3', 'k4'] for that I use:
return context.catalog({'keywords': {'query': ['k1', 'k2', k3', 'k4'], 'operator': 'and'}})
but these query returns objects with keyword = ['k2', 'k3'] (for me incorrect, I would like to find objects with *all* keywords
How can I make these kind of querys?
A long standing bug in "KeywordIndex"...
Maybe, you give my "Managable KeywordIndex" a try (part of "ManagableIndex").
I cannot promiss you that "ManagableIndex" is free of bugs but I definitely can promiss you that a bug resulting in wrong search results is fixed much much more quickly than in the Zope core :-)
Hi Dieter! I can't understand the lack of concern you talk about unresolved bugs in Zope It seems Zope is not a serious tool. Imagine you want to buy a car but the seller says: in these model there are a bug on the brake system but I you put these extra no problem
How can I convince my customers to use Zope with these kind of searchable information?
The bug you encountered is sufficiently an "edge case" that it has not gotten any attention from the people who could fix it. Agitating for it on the list is likely to be less productive than contributing:
- Write one or more unit tests which demonstrates the failure (e.g., they fail with the current implementation).
- Implement the fix, such that the new tests pass without causing any others to fail.
- Submit the patch, including both the test and the patched implementation, as an attachment to the collector issue Andreas pointed to: http://www.zope.org/Collectors/Zope/889
Such bug reports get quicker attention, because:
- they demand less effort from the person with commit access to understand the problem (even without the fix, writing the test case would be valuable here).
- they show that the bug matters enough to somebody to have invested the effort.
I have checked in a number of patches from Dieter in this way, which means that Dieter is contributing to the "core" Zope code, even without checkin access (which Dieter doesn't want to obtain).
Tres. - -- =================================================================== Tres Seaver tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCkMrZ+gerLs4ltQ4RAl14AJ4xmHMk6PKCJrTv3hJQ/xeCOqNYsgCglSiP KSHy7IctCFqHBoOmxwSTMws= =HCJO -----END PGP SIGNATURE-----
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
All you say (Andreas, Dieter, Tres and Lennart) is very reasonable, in my opinion with all your choices, I prefer try to solve the bug I don't know if my python/zope skill is enought but if I don't try it I never know my real skill Thanks! -- Mis Cosas http://blogs.sistes.net/Garito/
participants (6)
-
Andreas Jung -
Chris McDonough -
Dieter Maurer -
Garito -
Lennart Regebro -
Tres Seaver