"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.


Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to