Full disclosure: PremiseObservation.get_premise_observations()
constructs its data through a (massive) find_by_sql() query, but whose
SELECT takes pains to match the PremiseObservation schema. I could
understand if obs[0] was tagged readonly as a result, but it's not:
irb(main):062:0> obs[0].readonly?
=> false
How can save! complete without error and yet not save anything? Either
I've overlooked some key piece of documentation or else this is a bug.
Which is it?
- ff
ps:I'm sure I can work around this by creating a virgin
PremiseObservation and copying each field over into it. That's a PITA,
but manageable.
pps: bash$ rake about
(in /Users/ff/Developer/dev)
About your application's environment
Ruby version 1.9.2 (x86_64-darwin10.4.0)
RubyGems version 1.3.7
Rack version 1.2
Rails version 3.0.0.rc
Active Record version 3.0.0.rc
Action Pack version 3.0.0.rc
Active Resource version 3.0.0.rc
Action Mailer version 3.0.0.rc
Active Support version 3.0.0.rc
Application root /Users/ff/Developer/bd
Environment development
How can save! complete without error and yet not save anything? Either
I've overlooked some key piece of documentation or else this is a bug.
Which is it?
You've got it out of find_by_sql so rails thinks its an existing row.
Furthermore rails doesn't think the object has changed since you
retrieved it from the database, so it shortcircuits the save (since
from its point of view there is nothing to save)
You've got it out of find_by_sql so rails thinks its an existing row.
Furthermore rails doesn't think the object has changed since you
retrieved it from the database, so it shortcircuits the save (since
from its point of view there is nothing to save)
Fred
Fred:
Your explanation makes sense. If this is not a bug in ActiveRecord,
then there IS a bug in the documentation -- it has to be one or the
other. This is new territory for me: is there a writeup on how to
properly report a documentation bug?
A second (and lesser) question: is there a way to force a save? That
would save me creating and copying a new one.
Frederick Cheung wrote:
> You've got it out of find_by_sql so rails thinks its an existing row.
> Furthermore rails doesn't think the object has changed since you
> retrieved it from the database, so it shortcircuits the save (since
> from its point of view there is nothing to save)
> Fred
Fred:
Your explanation makes sense. If this is not a bug in ActiveRecord,
then there IS a bug in the documentation -- it has to be one or the
other. This is new territory for me: is there a writeup on how to
properly report a documentation bug?
I'm not sure that's true - you're doing something that is really
rather strange.
I'd get in touch with the docrails folks - ask around in #rails-
contrib
A second (and lesser) question: is there a way to force a save? That
would save me creating and copying a new one.
in this particular case you don't just need to mark the record as
dirty, you need to mark the record as being a new record. As far as I
know the only way to do that is to set the new_record instance
variable. Personally I'd take the need to muddle with AR internals as
a hint not to do this.
Saves the record with the updated_at/on attributes set to the current time. If the save fails because of validation errors, an ActiveRecord::RecordInvalid exception is raised. If an attribute name is passed, that attribute is used for the touch instead of the updated_at/on attributes.
Examples:
product.touch # updates updated_at
product.touch(:designed_at) # updates the designed_at attribute
