On 5/8/02 6:53 PM, "Tim Hoffman" <timhoffman@cams.wa.gov.au> wrote:

Hmm

I shall investigate why <mybrains> instances can't be pickled as it strikes me that they are probably one of the more likely objects one would like to cache (despite their taste ;-) ie results of expensive catalog searches that will be batched.

=== time elapsed =====

And now I know why I can't pickle brains

in Products.Catalog.Catalog

The following method declare the class mybrains inside it.

def useBrains(self, brains): """ Sets up the Catalog to return an object (ala ZTables) that is created on the fly from the tuple stored in the self.data Btree. """

class mybrains(AbstractCatalogBrain, brains): pass

scopy = self.schema.copy()

scopy['data_record_id_']=len(self.schema.keys()) scopy['data_record_score_']=len(self.schema.keys())+1 scopy['data_record_normalized_score_']=len(self.schema.keys())+2

mybrains.__record_schema__ = scopy

self._v_brains = brains self._v_result_class = mybrains

And looking at the doc's seb pointed too, it says that picklable classes must be top level classes. So two questions are raised from this

1. has mybrains been declared within the method for a specific reason such as data hiding, and/or to prevent pickling it?

It's specific reason is that the brains to attach to catalog results are basically created on the fly by mixing one known (AbstractCatalogBrain) and one unknown (value of 'brains') element together. The results of this meshing are cached in the volitile attributes '_v_result_class'

2. What would be the danger of caching brains ?

Brains themselves are just classes, and not chachable. I take it you mean Brained Result objects... And I can't answer that one. I think there's a general issue of caching result sets and knowing to which search query and user they apply to. -- Jeffrey P Shell www.cuemedia.com