"Phillip J. Eby" wrote:
Nope. The two levels of methods (get/retrieve and new/create) are there to seperate Rack-level concerns from implementation concerns. getItem() and newItem() handle maintenance of Rack-level invariants such as the retrieval cache, while retrieveItem() and createItem() deal with object-level invariants. If you called retrieveItem() instead of getItem(), the code would bypass the rack-level invariants managed by getItem(), which would mean in this case that the per-transaction cache would be bypassed. yes, this is a bit more clear to me now.
Hm. Seems to me that you should just use two GAP's, one for each DB table, each using "self.id[0]" and "self.id[1]" respectively to determine their primary keys. (cough) why didn't I think about it???
Also, my racks are specialized to have a searchResults method, and a editItem method (until I can find the time to write a decent SQL Attribute setter provider)
A reasonable approach. Although, in the case of SQL attribute setting, see my other e-mail from this evening about the use of Generic Triggers to do SQL attribute setting.
btw, the genericattributeprovider has saved me a great deal of time. thanks very much!
No problem. Did you ever try re-casting your CatalogAwareness replacement to use GenericTrigger instead of a specific Agent plug-in? I did not have the time to do so. I still stick to Zope-2.1.6 for now, and I was afraid of the issues with transaction commit order. and the motto is 'if it ain't break, don't fix it'. I have a contract to upgrade the product in august though. I will look at it at that time.
regards, jephte.clain@univ-reunion.fr