Ed Leafe wrote:
Fixed a potentially serious bug in the getDataSet() logic. I had assumed that making a copy of a list made a copy of its contents, too. That is wrong. getDataSet() takes a list of dicts, and uses the slice trick ([:]) to make a copy of the list; however, each element in the two lists refer to the same dict, and changing a value in one dict changed it in both. This is, oddly enough, almost exactly like the VFP problem when you ran a fully-optimized SQL-Select, the cursor it returned was not a copy of the data, but the source table USEd AGAIN.
I knew it didn't make a copy, was trying to be more efficient. However, I understand and appreciate why you don't want to let getDataSet() return data that could directly modify the data, and even agree with it. After all, none of my use cases for getDataSet() actually use it to change the values, so I'd be surprised if one day I changed a value and the cursor's values had changed.
Hmm.. I wonder if copy.deepcopy() would be more efficient than the list comprehension.
I also added the replace() methods to the cursor and bizobj classes. I discovered the long-forgotten bizobj method 'replaceFor', which did more or less the same thing. I looked through all the source code, including the demos and IDE stuff, and can't find a single place where replaceFor() is used. If it's OK with you, Paul, I'd like to remove it to avoid confusion.
I'm all for cleaning old stuff up that isn't used. Especially while we can still do so relatively safely (we don't have millions of users yet).
-- Paul McNett http://paulmcnett.com http://dabodev.com _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
