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 -- Posted via http://www.ruby-forum.com/.
On Oct 18, 7:34 am, Greg Willits <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> 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> 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 > -- > Posted viahttp://www.ruby-forum.com/.
Frederick Cheung wrote:> On Oct 18, 7:34�am, Greg Willits <rails-mailing-l...-ARtvInVfO7m5VldFQK4jKA@public.gmane.orgt> > 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 thisThanks, 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 -- Posted via http://www.ruby-forum.com/.
On Oct 18, 5:56 pm, Greg Willits <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> 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> 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 > -- > Posted viahttp://www.ruby-forum.com/.
Frederick Cheung wrote:> On Oct 18, 5:56�pm, Greg Willits <rails-mailing-l...-ARtvInVfO7m5VldFQK4jKA@public.gmane.orgt> > 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 -- Posted via http://www.ruby-forum.com/.