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. > It's exactly what I'd expect - you've not requested a "record", you've > requested an aggregation of fields, bypassing the AR model - why on > Earth (and how?) would AR be able to take over again without you > explaining to it what the fields you selected represent? AR doesn't > know about any error, because the fubar query that it generates *does* > run and get reported as successful by the DB. You ask why I think this might work. Let me put it this way: I hand you an object. You call record.class and see that it's an AnalysisDatum object. You call record[:cost] and see that there's a value stored there. You call record.save! 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? > Convinced yet? > :-) Nope! :) :) -- Posted via http://www.ruby-forum.com/. -- 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.
