Thanks Ted, I've observed this behaviour, by accident actually. My original logic overrode the #adapter method of DataMapper::Repository, and sent "SET sql_mode = '....'" only if it didn't have the adapter in the list of already seen adapters (just a hash). The change worked provided that I continued to click around, but if I left to make a cup of tea or something that takes a minute or two and came back, my logic wasn't executing, but the adapter was erroring because the settings were reverted, which would indicate that there's a keep-alive timeout somewhere. That bug doesn't exist now since I'm sending SET sql_mode before every query, in effect. Looking at the logs, it appears just a one-off SET SESSION sql_mode could do the trick, since that's what DO is doing:
~ SQL (0.140ms) SET sql_auto_is_null = 0 ~ SQL (0.212ms) SET SESSION sql_mode = 'ANSI,NO_BACKSLASH_ESCAPES,NO_DIR_IN_CREATE,NO_ENGINE_SUBSTITUTION,NO_UNSIGNED_SUBTRACTION,TRADITIONAL' ~ SQL (0.112ms) SET sql_mode = 'REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,NO_UNSIGNED_SUBTRACTION,NO_DIR_IN_CREATE,ANSI,NO_BACKSLASH_ESCAPES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION' That last line is my override, and it's not ideal that it executes before every single query. Grep'ing the whole DataMapper/DataObjects directories, neither of them are sending those first two statements, but something is. Weird. This should be a sysadmin concern, since it's configurable in my.cnf. The library effectively ignores user preferences and sets its own. I'll have to move my logic to somewhere a bit smarter. For a start, it's only relevant on writes, not reads, so I'm probably wasting performance putting it where I have it. It also would be much better if I only sent that statement if the connection was fresh... not sure where I'd establish this, I'll have a poke around after I finish what I'm working on. Chris El 06/05/2011, a las 12:18, Ted Han escribió: > Re 3) DataMapper and DataObjects maintain distinct connection logic, so as > DataMapper opens and closes connections, that is distinct from the connection > pooling which DataObjects performs. So there's no extra connection > construction/teardown when DataMapper reconnects to DataObjects (which > maintains the connection to dbs). > > -T > > On Thu, May 5, 2011 at 7:02 AM, Chris Corbyn <[email protected]> wrote: > Hi, > > I hope you don't mind my asking here but I have a few questions about > something I'm doing. > > The MySQL adapter sets sql_mode in MySQL to an extremely strict set of > options, somewhere at a low level beyond the adapter's control. The > solution is to "undo" that change by setting a less strict mode. The > only way I could see to make this application-wide was to redefine the > #open_connection method. > > =begin > DataMapper Mixin to force sql_mode to allow our lack of use of default > values > > This can go away eventually, when we migrate out our incompatible > fields in MySQL. > =end > module Flippa > module DataMapper > > class ::DataMapper::Adapters::MysqlAdapter > def open_connection > connection = super > > statement = "SET sql_mode = ?" > bind_values = > [Flippa::Application.config.data_mapper_sql_mode] > command = connection.create_command(statement) > command.execute_non_query(*bind_values) > > puts "Sending SET sql_mode" # DEBUG!! > > connection > end > end > > end > end > > Just a few questions (excuse my Rails newbiness): > > 1. I'm including this by putting a file in initializers called > data_mapper.rb, which simply has a require line for my module. Is > this the right place to do this? > 2. Is it weird that I've put the file at flippa/data_mapper, when in > fact the file only exists to decorate the MysqlAdapter class? It > feels weird, but maybe I'm just not so open minded with what I'm > doing, being new to Ruby. > 3. It looks like a connection is opened and closed for every single > query executed. Is this right? Isn't that expensive? > > If I knew how to do it I'd contribute back any changes I make to > improve support, by creating a plugin or whatever. This is a pretty > simple modification though ;) > > Cheers, > > Chris > > PS: Absolutely loving DataMapper. I'm seriously in awe of the > elegance of it all. It makes every other ORM I've worked with in the > past (and I've worked with a few) look pitiful ;) Kudos to you guys. > > -- > You received this message because you are subscribed to the Google Groups > "DataMapper" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/datamapper?hl=en. > > > > -- > You received this message because you are subscribed to the Google Groups > "DataMapper" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/datamapper?hl=en. -- You received this message because you are subscribed to the Google Groups "DataMapper" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/datamapper?hl=en.
