[Zope3-dev] Re: RFC: should z.a.c.attribute.AttributeIndex index None values?

[Gary Poster]

On Nov 17, 2006, at 1:46 PM, Tres Seaver wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Gary Poster wrote:
>> On Nov 17, 2006, at 10:23 AM, Adam Groszer wrote:
>>
>>> Hello,
>>>
>>> Solutions:
>>>
>>> a: No, do not keep None values in the catalog
>>>    the current implementation works like this
>>>    you are unable to ask the catalog for objects having None
>>>    properties
>>> b: Yes, keep None values in the catalog
>>>    you can ask the catalog for objects having None properties
>>> c: Let's keep the existing one that does not index None and have an
>>>    AttributeIndexAlsoNone class which will index None values
>>
>> Did you see my reply in the other thread?
>>
>> If you make indexes keep track of None, it will need to be done in a
>> separate data structure because of the key homogeneity issues.  This
>> is a less efficient approach than the zc.catalog approach.  It can be
>> done either way.
>>
>> I recommend that you use zc.catalog, rather than reinventing
>> something that solves your problem.
>>
>> I suppose I don't care much, since we don't use the standard zope
>> value and keyword indexes anyway; if you must add the None feature,
>> then I only care, from a "let's not screw up our community software"
>> perspective, that it be implemented in a safe way.  Keep your BTree
>> keys homogenous.
>
> I don't get this -- an OOBTree promises to index *objects* as keys;
> None *does* behave properly as a key when mixed with strings.  You  
> can't
> count on it sorting in a particular way, but it *is* consistent.
> Worrying about consistency across, e.g., a major Python version  
> upgrade
> (the only thing which I can envision changing the partial ordering)

Yes that's the case I'm talking about.  That's also one of the cases  
that key references care about.

> doesn't justify throwing out 'None' as a legitimate indexable value in
> all cases.

If you mean that you think it is ok to have keys in a BTree that do  
not share explicit sorting semantics--typically something you do by  
enforcing homogenous types--then I'm quite surprised that this is  
your position.  This is an unnecessary invitation to an unpleasant  
rear-end biting.

If you simply mean what you say below...

> In general, I don't think the storage mechanism should dictate the
> *policy* choice, which is whether 'None' is a "meaningful" value  
> for the
> index.  In many cases, having 'None' as the value for an attribute is
> *not* the same thing as not having the attribute at all -- I'll agree
> with you that objects who don't have the attribute should not

...then as I said in another email, if people want to implement it  
this way, great.  However, I think saying that an index indexes  
homogenous values is very reasonable.  And if people disagree with me  
enough to pursue this, I still strongly recommend against collecting  
objects together as BTree keys that do not have explicit, reliable  
sorting semantics across major versions.

My only real stake in this is that I don't want the zc.catalog  
indexes changed in this way, nor do I want a revised index interface  
that makes the zc.catalog indexes no longer fulfill the interface  
because of this kind of change.

Gary