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

[Tres Seaver]

-----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)
doesn't justify throwing out 'None' as a legitimate indexable value in
all cases.

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


Tres.
- --
===================================================================
Tres Seaver          +1 202-558-7113          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFXgOb+gerLs4ltQ4RAqnYAJ9r/o4E5ptIHeW29rlDcj97qeabUACfe8yr
8T2gWGEpmkXGEb07qEq/hFQ=
=IHm7
-----END PGP SIGNATURE-----