[Zope3-dev] Heads Up: Problem with queryNextSiteManager

[Jim Fulton]

On Sep 26, 2006, at 3:00 AM, Stephan Richter wrote:

> Hello everyone,
>
> the following helper functions in zope.app.component do not work  
> well with the
> new registry concept of bases: getNextSiteManager,  
> queryNextSiteManager,
> getNextUtility, queryNextUtility.

They work find in the case of a hierarchy, which is the default case.

> Those methods expect a simple lookup tree, where the first base of  
> a local
> registry is the registry its parent's site manager's registry or  
> the global
> registry; in other words, always the first base is selected (line 45).

Yup.  They only support hierarchies.

> Since
> I started using the baseregistry,

Where is this documented?

> I commonly add the base registries at the
> first position, since I want them to override the global and other  
> parent
> registries. Doing so breaks all components that use the above helper
> functions. Here is the solution I am going to check in later today:
>
> - get/queryNextSiteManager
>
> These functions will be deprecated, since they simply make no sense  
> with the
> current design of the registries.I have checked the core code and  
> they are
> not used anywhere except for queryNextUtility. I suspect the same  
> to be true
> for all 3rd-party code as well, so that deprecating them should not  
> really
> hurt anyone.

You can't deprecate them without providing an alternative.  I want to  
see a proposal for that.

>
> - get/queryNextUtility
>
> They are still very useful and their extensive use in the Zope 3  
> core code is
> proof of that. Luckily their fix is simple. Instead of using
> get/queryNextSiteManager to look up the next registry, we simply  
> iterate
> through all the bases of the closest site manager until an answer  
> is found.

That is a solution.  I'm not sure it is the best.  It won't handle  
more complex  object graphs, such as diamonds correctly.

>
> This way the lookup pattern will work as before and supports the  
> new usage
> pattern. I have tested this fix and it works for my code well.
>
> The really big question is:  Is that change worth porting to the  
> Zope 3.3
> branch?

Absolutely not.  It is not a fix, but a new feature.

> It really is a serious bug that will cause people painful error
> messages that are hard to understand. Also, it prevents people from  
> using
> Zope 3.3 and z3c.baseregistry.

I can understand that it is a problem for baseregistry.

> Thanks for reading and any comments you might have!

The right way to address this problem, imo, is probably to implement  
the planned component super concept.  This would provide:

- A more general solution,

- Possibly faster (because it is more general and can be more  
aggressively optimized),

- Handle more complex object graphs of the sort likely to occur when  
multiple base registries are used.

Jim

--
Jim Fulton			mailto:jim at zope.com		Python Powered!
CTO 				(540) 361-1714			http://www.python.org
Zope Corporation	http://www.zope.com		http://www.zope.org