On Fri, Apr 1, 2011 at 9:53 AM, Ramon Leon <[email protected]> wrote:
> On 04/01/2011 03:03 AM, Michael Pavling wrote: > >> So yes, it probably would make more sense to have .save return false >> or raise on saving a destroyed record - but it should raise if you try >> to alter a destroyed record, and it makes not much sense to save a >> record you've destroyed and not altered... :-/ >> >> I don't know which way to plump... any thoughts? >> > > Or.. make save work. Why should a deleted record be any different than a > new unsaved record? When a record is destroyed it should lose its id and if > saved again should insert a new row. At least, that's what I'd expect, if > the principle of least surprise means anything. > > Except in this case your "record" is an object instance. Since an object instance is not a pointer to the actual record in the database it should not change when you destroy that record. 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. What should happen is that the .save method should return false if it can't insert or update the record by that id. 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. B. -- 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.
