On 8/31/11 2:51 AM, Jacek Kałucki wrote: > Użytkownik Paul McNett napisał: >> Additions to my test function. One problem with this approach is that old >> cursors >> can keep piling up, cursors we have no interest in dealing with because they >> were >> from older parent requeries. If we filter them out, we add overhead, and if >> we >> pop them out of the __cursors dict upon requery(), we add overhead. We could >> add >> an 'unused' flag to all __cursors upon parent requery(), and take away the >> flag >> when the cursor becomes the _CurrentCursor, and then use the flag to speed up >> traversal in isAnyChanged()... > > This is good change, you can implement it in the code. > But I would be careful with removing 'unused' cursors from set. > What does mean 'unused'? > When record pointer in parent changes and we discard child cursors > unconditionally, > while user moves it forth and back one by one, it will generate additional > overhead on backend and network infrastructure. > I think we can add support for ChildCacheInterval=-1 (it's mean cache forever, > for rarely updated lookup data) and then upon requery, remove all unchanged > and expired > cursors from the set.
You are right: we'd only want to discard cursors that are no longer relevant in the entire chain of bizobjs. This, in most cases, would require more overhead than the benefit would be. So I'm dropping the idea of removing "unused" cursors, although, maybe an idle observer in the future, as part of a "vacuum" routine, could clean those away. Well, isAnyChanged() is fast enough now with my change, without discarding old cursors. The issue is, we don't want to account for changed/unchanged records in the set of unused cursors for the answer to isAnyChanged(). So, I guess I need to add some overhead and only iterate the cursor keys that are present in the current parent's data set. I'll test this, but it may be that the result isn't any better performing than the current function, although I bet it will be because scan() is fairly slow. I may not understand ChildCacheInterval but I've tried to use it and have found that it doesn't requery some children when necessary (because parent PK changed), so I can't use it as it stands, although it sounds like a good thing. But I don't think we can use the fact that the cache is expired to determine if it is a good cursor to keep or not. When the parent requeries is a separate issue from answering "are there any changed records". Paul _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev Searchable Archives: http://leafe.com/archives/search/dabo-dev This message: http://leafe.com/archives/byMID/[email protected]
