-----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?