-----BEGIN PGP SIGNED MESSAGE-----
Gary Poster wrote:
> On Nov 17, 2006, at 10:23 AM, Adam Groszer wrote:
>> 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
>> 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
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 Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v18.104.22.168 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Zope3-dev mailing list