[Zope-dev] bug in zpatterns-0.4 ?

Phillip J. Eby pje@telecommunity.com
Tue, 04 Jul 2000 02:18:46 -0500


At 10:33 AM 7/4/00 +0400, Jephte CLAIN wrote:
>
>Back to my first question: is it intended that Rack.createItem (a IMHO
>low level method) calls Rack.getItem (a IMHO higher level method) to
>check the existence of the item?

Yes.  It is perfectly valid OO design (and common framework-building
practice) for a private method to call a public one, and that is all that
is taking place here.


> Shouldn't it be Rack.retrieveItem
>instead? That's why I asked the question in the first place.

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.


>About my applications now. The primary keys in the SQL database may be
>integers, or tuple of integers, or strings (depending on the project, I
>have several to deal with right now). I want to merge results from
>several databases from a single rack.
>For example I have a Site table (with SiteKey as the primary key) and a
>Subdivision table (with SubdivisionKey as the primary key) which I want
>to merge into the LocationRack (with the key being the tuple (SiteKey,
>SubdivisionKey))
>This is why I mess with the implementation of the rack.

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.


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