On Tue, 24 Jun 2003, Andre Poenitz wrote: > But in addition to the purely cosmetic issues of 'noupdate 2', there are > now lots of (unfixable) hard crashs. The reason is mainly the current > cursor implementation. The stored row iterators get invalidated pretty > fast -> boom. > > Comments, ideas?
One way forward would be to implement "stable" iterators as discussed earlier. The row iterators are issued from a special kind of list which will remember all issued iterators, and make sure they are always up to date when the list changes. I.e. the cursor iterators will always be valid in the sense that they do not crash when dereferenced. A simple way to do this is to just change all the issued iterators to the first element in the list when the list changes. That should be enough to prevent crashes, although the cursor would jump rather aggressively to the top when the flow is redone. From here, you can go two ways: 1) Fix all list operations to make more intelligent adjustments to all issued iterators. 2) Eliminator all usages of these iterators. As a help, you can extend the list implementation with debug-spew to help you. This way, you can make a local change which will prevent the crashes, but introduce other problems, but you will still be afloat. Then, one by one, you can change the list iterators, cursor scheme, or the other things, and thus address the various problems one-by-one using the salami method: Address the most important, managable problem at each step, and after N steps, you might have succeeded. I think the crucial thing is that you can debug and reasonable complete each step: The program should be in so good shape that you are able to test that each refactoring is complete and working before you proceed to the next step. I.e. in other words, do not leave 200 TODOs in the process, because those will be very hard/next to impossible to fix later. You can not make such a big transformation in the blind, so you have to keep the program working enough to verify each change. Regards, Asger
