[Zope-dev] bug in zpatterns-0.4 ?

[Jephte CLAIN]

"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