Re: [Zope-dev] bug in zpatterns-0.4 ?
"Phillip J. Eby" wrote:
When Philipp wake up (I guess he's asleep right now :-)), he might give his opinion about that. I've been on vacation. I knew it. But it's always funny to play with timezone issues.
I'm basically with Mike on this one, with a slight amplification on my intention here. IMHO, what you should be doing with your SQL is making it an AttributeProvider, and using the "virtual" mode of the Rack which does not store the item in the ZODB, only its propertysheets. Then you will not need to override *anything* in any of the ZPatterns classes. If you need to store persistent attributes, this may be an issue. I'm planning to create a "Persistent External Attribute Provider" to allow one to store attributes persistently even when the object itself isn't stored in the ZODB.
In any case, my intention for mixed-database objects in racks is that one should not need to override any of the built-in methods of Rack. In earlier versions of ZPatterns, such overriding seemed like it would be necessary, but as of 0.4 there is really no reason at the framework level to mess with any of Rack's implementation details unless you need to create a special hand-tuned version for some critical bit of efficiency. Almost anything you could do by overriding those methods can now be done through Generic Attribute Providers or other plug-ins.
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? Shouldn't it be Rack.retrieveItem instead? That's why I asked the question in the first place. 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. 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) I guess I have good reasons to mess with all that stuff :-) There might be another mean to deal with it. Once I have a bit more 'zenpatterns' ;-) btw, the genericattributeprovider has saved me a great deal of time. thanks very much! regards, jephte.clain@univ-reunion.fr
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?
"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
participants (2)
-
Jephte CLAIN -
Phillip J. Eby