[ZODB-Dev] n-way join algoritms

[Steve Alexander]

>>Fine. I'd be happy with:
>>
>>   class IIntegerTreeModule(IBTreeModule):
>>       "This interface is provided by the IIBTree and IOBTree
>>modules."
>>
>>       def multiunion(list args):
>>           "Explain what and why and whatever"
> 
> 
> I'll add something like that, then, but only in Zope3/ZODB4.

Thanks!


> There are
> currently variations of the BTree code on 6 active branches, and I'm
> spending too much of my life trying to update everything in half a dozen
> diverging places.

I do hope this situation will improve as Zope 2 and Zope 3 converge.


> BTW, it's hard to explain the truth about how to use multiunion, because it
> accepts a sequence of objects each of which is convertible to an integer set
> using the internal BTrees set iteration protocol.  That's actually true of
> lots of arguments to lots of BTree methods.  The concept isn't covered by
> the current interfaces, though -- which in one sense just begs your original
> question ("how do you find out what isn't documented?"; my question is more
> "how do you document something when there isn't a manual to hold any docs?"
> <0.9 wink>).

I'd be satisfied if the btrees/interfaces.py module said "To understand 
what these things mean, see the ZODB docs at 
http://www.zope.org/Wikis/ZODB/guide/node6.html#SECTION000630000000000000000" 
or whereever the canonical location is.


>>The zope.interface package provides the means to say that a module
>>provides an interface, so you could use that if you like.
> 
> I don't know exactly what to do so am inclinced to skip this part.  Note
> that the btree code is supposed to be usable independent of Zope.  As is,
> Jeremy already had to comment out the classImplements() calls in the btrees
> interfaces.py module because of intractable circular import problems.

If the classImplements calls are important, I'd add them to the C code 
that initialises the modules, or (for convenience) put them in the 
__init__.py of the btrees package.


>>Ok. What about refactoring it...
> 
> Na, it sounds more like busy work than something useful, especially since
> you already find the interface file useful as-is.

Ok.

--
Steve Alexander