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
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
