[Zope-dev] Generic filtering of objects

[Kent Polk]

Phillip J. Eby wrote:
> Ty Sarna and I have come up with a concept for this, which we have not yet
> implemented, as we are still finalizing design details.  We believe that it
> could be made quite general.  The basic idea is that you have a "Predicate"
> interface, for objects which can be combined with "and", "or", and "not" to
> result in more complex predicates.  The Predicate interface would also
> include functions to return a Generator or a Filter.  A Generator is an
> object which can return a list of objects matching the Predicate, while the
> Filter is a callable object which may be passed an object and returns true
> if the object matches the Predicate.  Generators and Filters have to also
> provide a small amount of metadata indicating their cost to filter or
> generate information.

Phillip... Putting relational operations directly into Python will
have substantial repurcussions.  The Python community may not
appreciate having Guido run over by the Distributed Database Bus,
not to mention the 'interesting' vision of relational db people
converting to Zen.  Pandora, in her wildest dreams...

However, since you have opened the box, let us proceed...

I have a few problems with the SubMine datamining concept, however
I think the basic concept is very encouraging. In our situation,
the existing databases are 'alive' (including the schemas). The
schemas are defined in each query using a few relatively simple
rules.  One of the reasons they still use a file-systemed database
is that in this environment (population genetics research), simply
not enough is known to structure a traditional relational database
and almost everything is volatile. The problem is that you have to
browse the database in order to formulate a query.

Submines allow our scientists and data analysts to browse the
databases and determine the relationships they need to impose
interactively. They love it because it acts somewhat like a
statistical analysis package but acts directly on the database
tables (not to mention via the web). The big problem with current
SubMines is that the filters are inseparable from their data objects.
They are not pythonic and can only exist in the context of a
__bobo_traverse__.  I've been trying to determine a way to reference
them from another object in order to perform joins etc., and I had
pretty much decided that their non-pythonic nature is a show-stopper
here.

What you propose might pythonize Submine filters if there is a way
to traverse them without using __bobo_traverse__. Even if they
can't be traversed, I think the predicate concept stands to transform
how we do things.

Me.sitting.bus_stop.waiting.impatiently.beside.self.for(Phillip.explain)