AR.base.connection.execute Not Working

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...

-- gw

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

Fred

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 ?

Fred

Frederick Cheung wrote:

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.

-- gw