summaryrefslogtreecommitdiff
path: root/plugins/TwitterBridge
diff options
context:
space:
mode:
authorBrion Vibber <brion@pobox.com>2010-03-15 15:41:57 -0700
committerBrion Vibber <brion@pobox.com>2010-03-15 15:58:55 -0700
commit9ec24f59ca61bbbb45667b548a872e724f31ab3e (patch)
tree290080237ec5f0c4286c2598a67e5a8edf83cc33 /plugins/TwitterBridge
parent40cde2f7109cace8f37cd36c31420c38ad475d40 (diff)
Drop result ID from data objects on clone(). This keeps the original object working if it was in the middle of a query loop, even if the cloned object falls out of scope and triggers its destructor.
This bug was hitting a number of places where we had the pattern: $db->find(); while($dbo->fetch()) { $x = clone($dbo); // do anything with $x other than storing it in an array } The cloned object's destructor would trigger on the second run through the loop, freeing the database result set -- not really what we wanted. (Loops that stored the clones into an array were fine, since the clones stay in scope in the array longer than the original does.) Detaching the database result from the clone lets us work with its data without interfering with the rest of the query. In the unlikely even that somebody is making clones in the middle of a query, then trying to continue the query with the clone instead of the original object, well they're gonna be broken now.
Diffstat (limited to 'plugins/TwitterBridge')
0 files changed, 0 insertions, 0 deletions