Rails 2.3.2, MySQL 5.0.67, mysql-ruby 2.7, ruby 1.8.6
I am using AR.base.connection.execute to handle a particular case where
I want to avoid all AR callbacks and optimistic versioning.
When the code is run, the query statement, an update, makes no changes
to the intended record.
There are no complaints from Rails as to any errors (I've disabled the
begin/rescue wrapper), log lines before & after the statement are
recorded just fine, and the query itself is logged in Dev mode exactly
as I expect it to read. If I copy the statement from the log and paste
it to a MySQL GUI to execute, the statement works as expected.
I've poked & poked, but at this point, I can't even think of how to
debug this.
Thx in advance for any ideas to kickstart my brain in a new direction...
Rails 2.3.2, MySQL 5.0.67, mysql-ruby 2.7, ruby 1.8.6
I am using AR.base.connection.execute to handle a particular case where
I want to avoid all AR callbacks and optimistic versioning.
When the code is run, the query statement, an update, makes no changes
to the intended record.
Does your code look like this :
m = Model.find(...)
AR::Base.connection.execute(...)
m.reload
?
Does it work if you paste it into script/console ?
If so I'd guess that Rails' query cache is the problem. If so,
changing AR::Base.connection.execute to AR::Base.connection.update
would fix this
The model in question requires a specific named connection in order to
use a specific database (multi-db application). Of course, using
AR::Base.connection wasn't using the correct db.
in that case won't some_object.class.connection be a connection to the
correct database for some_object ?
The model in question requires a specific named connection in order to
use a specific database (multi-db application). Of course, using
AR::Base.connection wasn't using the correct db.
in that case won't some_object.class.connection be a connection to the
correct database for some_object ?
I'm already in a class method at that point, so .class isn't needed. It
made sense to me that self.connection.execute should have worked, but it
didn't.
I didn't investigate further as so far it looks like a regular
.save(false) is going to meet my needs. I was originally doing a
straight update of some lock control fields without invoking a save of
any other attributes, validation, or changes to lock_version (because
the latter would cause logic problems if the field existed).
It's apparent now no other attributes will have been modified at the
point of my query, a save(false) will avoid validation, and lock_version
will never exist in my apps, and it really shouldn't exist if the model
is using my pessimistic system anyway. So, I just added some callbacks
where someone can handle lock_version or anything else before/after my
lock/unlock steps.