Ed, Please review this chat, and see if:
1) you agree with my assessment as to the source of the problem 2) you have any other ideas on how to go about implementing a fix Thanks! (11:40:46 AM) johnf_: paulmcnett: Please check for Larry's post on the list - I think he has found a solution to my problem. (12:18:35 PM) paulmcnett: I saw it but am wary of it. Ed's really the one to talk to with changes to the biz layer. (12:19:34 PM) paulmcnett: I think that potential changes would be missed if you don't requery all the children. (12:19:47 PM) paulmcnett: not requery, but scan. (12:20:36 PM) johnf_: Sure scan but scan only the ones that have changed. If you scan each of the records then you get what we have now. (12:21:12 PM) johnf_: BTW Larry is re-thinking his change. (12:48:04 PM) paulmcnett: We need to scan to find out if there are any changed rows. (12:48:50 PM) paulmcnett: We are talking about the method to find out if there are changes. In order to find out if there are changes, each row must be scanned (because there could be changes in child bizobjs). (12:50:00 PM) paulmcnett: Now, if we are scanning to find out if there are changes and the row in question hasn't ever been requeried yet, then we can assume that there aren't any changes, so there's definitely optimizations to be made. I just don't think Larry's original change will work. (12:50:07 PM) johnf_: Apparently, you have kept a list of the changes as they occur. At least that's what Larry is saying at the moment. (12:50:17 PM) johnf_: He agrees with you (12:50:50 PM) paulmcnett: Each cursor has a _memento (a dict of original values kept as a change occurs) (12:51:24 PM) paulmcnett: The problem is that the outer bizobj has to scan each row to find out if any cursor, child cursor, grandchild cursor, etc. has any changes. (12:56:14 PM) johnf_: Ok but it takes a long time to complete that task if one has 1500+ records. Why is it asking for new cursors and getFields? (01:04:35 PM) paulmcnett: It shouldn't be, so there's definitely a problem, as I've said. (01:05:26 PM) johnf_: I hope this get fixed fast because this form will never work as it is now. (01:19:42 PM) paulmcnett: The problem boils down to the fact that when any code queries biz._CurrentCursor, the cursor will be created if it doesn't already exist. This implicit behavior is relied upon everywhere in dBizobj, but it isn't desired if we are scanning to find changed rows. In that case, if any rows in the biz don't have their cursor created, we want to bypass it because it is irrelevant and just return False for isChanged() in that case. Making this fix will speed up everyone's code, not just yours. (01:19:51 PM) paulmcnett: The question is, how to implement the change. (01:20:35 PM) paulmcnett: 1) Make a flag so that scan() and _moveToRowNum and _getCurrentCursor() don't create a cursor implicitly (01:20:56 PM) paulmcnett: 2) Don't use scan() from getChangedRows(), but do it manually without scan() (01:21:04 PM) paulmcnett: 3) Some other way? (01:21:18 PM) paulmcnett: I think we should copy/paste this chat to dabo-dev so that Ed sees it. (01:22:17 PM) paulmcnett: So I'm not sure if this will get fixed fast or not, but I am sure this warrants a good hard look and a good fix. (01:25:09 PM) johnf_: that's not good to hear. I have to deliver soon. At least for the demo stuff. 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]
