bug in zpatterns-0.4 ?
hello, Rack.createItem (low level method) first calls Rack.getItem (higher level method) to check the existence of the item. This causes infinite loop in certain cases. It should (IMHO) call Rack.retrieveItem instead regards, jephte clain jclain@univ-reunion.fr
Jephte CLAIN wrote:
hello,
Rack.createItem (low level method) first calls Rack.getItem (higher level method) to check the existence of the item. This causes infinite loop in certain cases. It should (IMHO) call Rack.retrieveItem instead
Could you provide an example please? Mike
mike wrote:
Jephte CLAIN wrote:
Rack.createItem (low level method) first calls Rack.getItem (higher level method) to check the existence of the item. This causes infinite loop in certain cases. It should (IMHO) call Rack.retrieveItem instead Could you provide an example please? My data is located in an SQL database. I want to have some associated data in ZODB. ZPatterns is a perfect fit for this. When I first access a SQL record, the corresponding data is created in ZODB:
def getItem(self, key): if self.sql_get(key=key): # ok it exists in the SQL database item = Rack.getItem(self, key) if item is None: # it does not exist in ZODB, create it item = Rack.newItem(self, key) else: item = None return item This causes infinite loop because Rack.newItem calls Rack.createItem which calls my (modified) getItem regards, jephte clain jclain@univ-reunion.fr
Jephte CLAIN wrote:
mike wrote:
Jephte CLAIN wrote:
Rack.createItem (low level method) first calls Rack.getItem (higher level method) to check the existence of the item. This causes infinite loop in certain cases. It should (IMHO) call Rack.retrieveItem instead Could you provide an example please? My data is located in an SQL database. I want to have some associated data in ZODB. ZPatterns is a perfect fit for this. When I first access a SQL record, the corresponding data is created in ZODB:
def getItem(self, key): if self.sql_get(key=key): # ok it exists in the SQL database item = Rack.getItem(self, key) if item is None: # it does not exist in ZODB, create it item = Rack.newItem(self, key) else: item = None return item
This causes infinite loop because Rack.newItem calls Rack.createItem which calls my (modified) getItem
1. Leave getItem untouched. Move all that SQL-related stuff into the retrieveItem method which *is intended* to be overriden. 2. Move newItem stuff into Specialist. You have mixed 'Restaurant' and the 'FoodStore' in this snippet :-) Do this instead: Specialist: def getItem( self, key) : item = self._src().getItem( key) if item is None : item = self._src().newItem( key) return item def _src( self) : return self.rackList[0].__of__( self) Rack: def retrieveItem( self, key) : item = self.sql_get( key) blah blah blah ... return item Mike
mike wrote:
This causes infinite loop because Rack.newItem calls Rack.createItem which calls my (modified) getItem
1. Leave getItem untouched. Move all that SQL-related stuff into the retrieveItem method which *is intended* to be overriden.
2. Move newItem stuff into Specialist. You have mixed 'Restaurant' and the 'FoodStore' in this snippet :-) Do this instead: Good point. I have to remember that getItem/newItem are not for overriding. But the problem remains the same. a low level method (createItem) should not call a high level method (getItem)
regards, jephte clain jclain@univ-reunion.fr
Jephte CLAIN wrote:
mike wrote:
This causes infinite loop because Rack.newItem calls Rack.createItem which calls my (modified) getItem
1. Leave getItem untouched. Move all that SQL-related stuff into the retrieveItem method which *is intended* to be overriden.
2. Move newItem stuff into Specialist. You have mixed 'Restaurant' and the 'FoodStore' in this snippet :-) Do this instead: Good point. I have to remember that getItem/newItem are not for overriding. But the problem remains the same. a low level method (createItem) should not call a high level method (getItem)
There is no problem. Look at protocol: Specialist.getItem -> Rack.getItem -> Rack.retrieveItem <- None Rack.getItem <- None Specialist.getItem -> Rack.newItem -> Rack.createItem -> Rack.getItem -> Rack.retrieveItem <- None Rack.getItem <- None Rack.createItem <- item Rack.newItem <- item Specialist.getItem <- item There is no way to infinite recursion if Rack.getItem is leaved untouched. getItem/newItem are not a high level methods, they are *part of DataSource's protocol* which *implemented* in Rack with retrieveItem and buddies. Mike
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. regards, jephte clain jclain@univ-reunion.fr
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.
Heh, I see Phillip get himsef into big trouble with ZPatterns :-) The fact of existence of such complex (to understand) thing as ZPatterns means there must be a mentor keeping the people on the Way Of Truth :-) He must be a mentor because he involved all us in this game :-)
When Philipp wake up (I guess he's asleep right now :-)), he might give his opinion about that.
Yeah, tell him also the world changed while he was dreaming :-) Mike
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.
participants (3)
-
Jephte CLAIN -
mike -
Phillip J. Eby