# AR.base.connection.execute Not Working **URL:** \ **Category:** Rails\ **Created:** [October 18, 2009, 8:34am UTC](https://www.ruby-forum.com/t/ar-base-connection-execute-not-working/177466 "2009-10-18T08:34:25Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![S-gw](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@S-gw](https://www.ruby-forum.com/u/S-gw)\ **Post date:** [October 18, 2009, 8:34am UTC](https://www.ruby-forum.com/t/ar-base-connection-execute-not-working/177466/1 "2009-10-18T08:34:25Z")
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 ---
**Author:** ![S-gw](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@S-gw](https://www.ruby-forum.com/u/S-gw)\ **Post date:** [October 18, 2009, 1:54pm UTC](https://www.ruby-forum.com/t/ar-base-connection-execute-not-working/177466/2 "2009-10-18T13:54:39Z")
On Oct 18, 7:34 am, Greg W. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > 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 ---
**Author:** ![S-gw](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@S-gw](https://www.ruby-forum.com/u/S-gw)\ **Post date:** [October 18, 2009, 6:56pm UTC](https://www.ruby-forum.com/t/ar-base-connection-execute-not-working/177466/3 "2009-10-18T18:56:47Z")
Frederick C. wrote: > On Oct 18, 7:34�am, Greg W. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > wrote: > > > 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 Thanks, I just needed some kind of comment to inspire me to try something different, and it worked. Your comments gave me an idea to try one thing. That one thing caused the code to finally spit out an error. The error is what I suspected, but had no way to prove, but now realize is obvious. Why the error shows up after this change makes no sense to me, but nevertheless I know what’s wrong now. 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. However, this code is in a general-purpose acts\_as\_pessimistic plugin I’ve written (which does it better than the built-in way IMO), and I don’t see any way it can know about the multi-db goings on, so I need to solve the task a different way. I need to avoid validation, so I can do that with save(false), and I need to avoid changing lock\_version if it exists. You gave me and idea for the latter last year, so I’ll give that a go here too. – gw ---
**Author:** ![S-gw](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@S-gw](https://www.ruby-forum.com/u/S-gw)\ **Post date:** [October 18, 2009, 7:52pm UTC](https://www.ruby-forum.com/t/ar-base-connection-execute-not-working/177466/4 "2009-10-18T19:52:54Z")
On Oct 18, 5:56 pm, Greg W. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 ? Fred ---
**Author:** ![S-gw](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@S-gw](https://www.ruby-forum.com/u/S-gw)\ **Post date:** [October 18, 2009, 8:14pm UTC](https://www.ruby-forum.com/t/ar-base-connection-execute-not-working/177466/5 "2009-10-18T20:14:01Z")
Frederick C. wrote: > On Oct 18, 5:56�pm, Greg W. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > 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