On May 9, 7:41 pm, Fearless Fool <[email protected]> wrote: > Michael Pavling wrote: > >> But since you asked (and since you've impugned my knowledge of SQL :), > > Um, don't get offended... > > No offense taken - that's what the smiley face was for. The first case > was designed as a simple case to demonstrate that there's something > fishy about how SELECT columns are mapped back to AR records -- whether > or not it actually touches the database is (I believe) a red herring. >
There isn't really - there's just a hash of attributes and methods that read/write values in that hash. But active record can't save rows without a primary key and you're not giving it one. > and see that it returns true. Based on the above, what would lead you > to believe that the record is NOT stored? And (most importantly) what > other queries could you make (to the object, not to me!) that would > predict this mis-behavior? record.id being nil despite new_record? returning false would be a good clue. Ruby being ruby it's easy enough to bend things into looking sane when they are actually quite hairy: Active Record assumes that the result of a find is a row that exists, whereas in your case it isn't Fred -- 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.
