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?