[Zope-dev] Join mix and match queries in Zope (was: Catalog r esult brains not extendable)

[Jay, Dylan]

> -----Original Message-----
> From: Evan Simpson [mailto:evan@4-am.com]
> Sent: Tuesday, 31 July 2001 12:25 PM
> To: Chris McDonough; Jay, Dylan
> Cc: zope-dev@zope.org
> Subject: Re: [Zope-dev] Catalog result brains not extendable
> 
> 
> > "Jay, Dylan" wrote:
> > > I'm trying to get some results from a catalog and add meta_data to
> it.
> 
> In $ZOPE/lib/python/Shared/DC/ZRDB/Results.py find the "class r"
> definition, and add one line to it, like this:
> 
>         class r(Record, Implicit, brains, zbrains):
>             _guarded_writes = 1
> 
> Now you can assign to attributes of result records.

Cool, is there a good reason this can't be activated by default for Catalog
results and SQLMethod results? Alternatively some mechanism to plug in your
own brains into a Catalog query. 
I'm trying to think of ways to generalize solutions to my problem since I
think it can be applicable to others. The problem is joining query results
with other dynamic data in my case data specific to the user making the
query. In particular this user specific data specifies the sort order of the
combined result. 

Perhaps drop-in indexes can provide a mechanizm? If you had an catalog index
which had many indexes, one for each user, then the result would be the
same. However in my case I don't want all that data recorded at one time. I
generate the index dynamically (which is expensive) and then cache it so
that the frequent users have their indexes available. 

So to generalize this you could have a drop-in index that can generate the
index on the fly based on current environmental conditions such as the
logged in user. This would be done in such a way as to allow a caching
manager to sit in between. I don't know enough about the catalog machinery
to know if this is feasible, anyone? or if it would be useful to others?

Another possible solution is to allow the efficient joins of two different
queries. Let say I make a Catalog like result set from my user specific
index. I also get a result set by querying the catalog. I then pipe both
into a joiner tool that efficiently (and lazily) gives me a result of the
two joined on a specified attributes. This could be generalized to
SQLMethods as well. Then relational data can be joined with catalog data or
catalog with catalog or relational for two different sources joined. 

This proposal is similar to one I saw about putting SQL right inside the
zope environment. Using the Gadfly code or similar and doing SQL
functionality on zope objects etc. You could extend the ZSearchable
interface idea to more things and make it work with an SQL interpretter
inside zope. Folders could be ZSearchable as could Find. Arbitrary scripts
could be and thus participate at an equal level. You could have your SQL in
an SQLQuery object. Your Find search in a FindQuery object that is like a
stored search. The sql references it by name. So later when you want it to
be more efficient you replace it with a CatalogQuery or perhaps just use a
standard cache manager to do some caching.

Am I getting to proposals that people see of use to more people than me?