[Zope-dev] Re: Interest in "AdvancedQuery" and/or "ManagableIndex"?

whit d.w.morriss at gmail.com
Mon Feb 12 11:22:13 EST 2007


Philipp von Weitershausen wrote:
> Dieter Maurer wrote:
>> yuppie wrote at 2007-2-3 11:44 +0100:
>>> ...
>>> Unfortunately integrating a product into the Zope core means more 
>>> than just adjusting the coding style:
>>>
>>> - As already mentioned in this thread, monkey patches and code like 
>>> fixPluginIndexes.py have to be resolved. AdvancedQuery contains a 
>>> monkey patch for CMF - that should not be shipped with Zope core.
>>
>> "fixPluginIndexes" fixed (maybe meanwhile resolved) bugs in
>> "Products.PluginIndexes.common.util.parseIndexRequest".
>>
>> The mentioned CMF monkey patch gives the "CatalogTool" the new method
>> "evalAdvancedQuery", provided CMFCore is installed.
>> I do not see why this monkey patch should not be applied.
>>
>> I am sure that I want to be able to use "AdvancedQuery" even
>> with a "CatalogTool", if both are installed.
> 
> Monkey patches should be avoided when they can. I think that's something 
> we don't need to discuss. Integrating a product into Zope is the perfect 
> opportunity to get rid of monkey patches and consolidate the fixes into 
> the main product lines. Therefore, the CMF should rather grow that 
> method itself than having it patched in by Zope.
> 
> Either way, I think this point is mute since all the Plone community 
> really wants is a public subversion repository with access to the code 
> and "control over the code", which I would think is asking for a lot 
> (you've indicated that reformatting the code would mean you wouldn't be 
> available for maintenance anymore).
> 
> Whoever is asking for AdvancedQuery and other things to be in 
> svn.zope.org or even Zope 2 itself ought to weigh the amount of 
> maintenance work against the little potential (not actual!) benefits. I 
> think we can leave everything as it is and if Plone needs it in an svn 
> repo, heck, why not do vendor imports? (not in svn.zope.org, of course, 
> since the contributor agreement forbids that)
> 

I'm not sure this warranted this much discussion or getting panties in a 
bunch, but maybe something was learned here.  As phrased early on, it 
would be *nice* for those of us using svn:externals to manage certain 
build processes to have AdvancedQuery in svn somewhere(not life or death).

did we reach some sort of conclusion in all this?  Having a AQ egg would 
be the same difference imho.

I would be happy to help maintain AdvancedQuery(though I hardly feel 
qualified), though I would prefer to leave it in a form that Dieter 
would actually want to work on it.

What might be more worthwile is to package AQ up to be an egg(I 
volunteer for this).  That way we could manage the dependency that 
way(zope could too if it chose to ship with AQ), dieter could continue 
maintaining AQ, and everything would be peachy.

one last point re: Zope: From a marketing perspective(to parrot slinkp), 
I would think Zope 2 would want to include AdvancedQuery since it is a 
go-to answer for lots of "how do I do sqlish query X in the ZODB" type 
questions.  Granted, hurry.query and the z3 catalogs have similar 
capabilities, but AQ works right now with existing z2 catalogs.

-w


-- 

------ d. whit morriss ------
- senior engineer, opencore -
- http://www.openplans.org  -
- m: 415-710-8975           -

"If you don't know where you are,
  you don't know anything at all" 


Dr. Edgar Spencer, Ph.D., 1995



More information about the Zope-Dev mailing list