"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" and "self.id" 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
> 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.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -