Hi Hanno, thanks for your reply. Hanno Schlichting wrote:
yuppie <y.2015 <at> wcm-solutions.de> writes:
I'd say it is no longer possible to store None values in the index, but it's a different question if the attempt to index them is silently ignored or if an error is raised.
AFAICS migrating existing code and persistent objects is much easier and in most cases unnecessary if None values are silently ignored.
As the one who wrote that patch: My idea was only to raise a more meaningful TypeError from the catalog code, instead of a the very general "object has default comparision" TypeError raised by BTrees.
Yes. The regression was caused by upgrading to BTrees 4, not by your patch. Your patch just blessed it somehow as intended behavior.
Silently ignoring None values would also be a good approach. Or maybe one could change the 3.1.x releases to log a deprecation warning when None is indexed, and create a 4.0 release series where None is silently ignored.
That way people have a chance to find the places where None is indexed and review whether or not this makes a difference in each specific case.
Not sure if I did get you right: Products.ZCatalog 3.1 raises an error, so people will notice if None is indexed. An additional deprecation warning doesn't make sense to me. Changing the behavior would make a regression in 3.x less disruptive, so I think a 3.2 release would be fine. But I don't care much how it is called. Anyway I have no ambitions to implement the change I proposed. The issue is now in the issue tracker and I hope someone else will resolve it. Cheers, Yuppie