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

On Oct 18, 7:34 am, Greg W. [email protected]
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

Frederick C. wrote:

On Oct 18, 7:34�am, Greg W. [email protected]
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

On Oct 18, 5:56 pm, Greg W. [email protected]
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

Frederick C. wrote:

On Oct 18, 5:56�pm, Greg W. [email protected]
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

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs