On 04/01/2011 08:05 AM, Bryan Crossland wrote:
Except in this case your "record" is an object instance.
Of course.
Since an object instance is not a pointer to the actual record in the database it should not change when you destroy that record.
That doesn't follow. If there is no longer a row 1 in the database, the object should no longer reference row 1. Currently the object is left in an invalid state and save thinks an update is possible when it isn't. The abstraction is leaking.
Keep in mind that there are many different ways to destroy a record in a database that don't involve calling the .destroy method of the object instance.
Not relevant to this case.
What should happen is that the .save method should return false if it can't insert or update the record by that id.
At a minimum, agreed; it should show the affected row count. But success is better than failure and you still haven't acknowledged that a destroyed object is conceptually identical to a new object that hasn't been saved and logically, should behave the same. Save could insert a new record and it would perfectly conceptually elegant and plug the leaking abstraction.
From following the thread it looks like its actually checking for an SQL execution error and it is not receiving one from the database. What its getting back is a successful execution of the SQL statement but a message that states the there was no record to create/update. From this information it then returns the incorrect state of true.
The current behavior is clearly wrong of course. -- Ramon Leon -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
