[Zope-dev] bug in zpatterns-0.4 ?

[Phillip J. Eby]

At 11:54 AM 6/27/00 +0400, Jephte CLAIN wrote:
>mike wrote:
>> There is no way to infinite recursion if Rack.getItem is leaved
>> untouched. 
>Ah ah. But people will touch it. Like me for example :-)
>There is no way to prevent overriding getItem from a ZClass for example.
>And it *will* recurse infinitely, making Zope dumping core.
>
>> getItem/newItem are not a high level methods, they are *part
>> of DataSource's protocol* which *implemented* in Rack with retrieveItem
>> and buddies.
>getItem/newItem are not meant to be overrided. retrieveItem/createItem
>are to overrided. This is different level for me.
>
>When Philipp wake up (I guess he's asleep right now :-)), he might give
>his opinion about that.
>

I've been on vacation.  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.