Just posting this in case anybody with the same problem ever stumbles upon
this. My original fix of putting the sql_mode override in the Adapter was not
the best place to do it, since it executes per-query.
Instead, it's better to put it in the DataObjects connection. Usually the
connection is re-used lots, provided the app isn't idle for long periods, so
this is sent much less frequently, and it always immediately follows the
sql_mode that DataObjects just set.
module DataObjects
module Mysql
class Connection
class << self
alias :original_new :new
# When Mysql::Connection is created,
DataObjects (rightly) gives it strict error checking.
# This breaks our app, because our schema often
doesn't use DEFAULT values
def new(conn_params)
conn = original_new(conn_params)
if sql_mode =
Flippa::Application.config.data_objects_mysql_sql_mode # You'll have to config
your preferred mode somewhere
statement = "SET SESSION
sql_mode = ?"
bind_values = [sql_mode]
command =
conn.create_command(statement)
command.execute_non_query(*bind_values)
end
conn
end
end
end
end
end
Cheers,
Chris
PS: I have some additions to DataMapper for:
1) A Sequence type, which generates primary keys from a sequences table in the
database instead of auto_increment
2) An Adapter with support for replication where reads and writes need to go
to different connections (master/slave)
3) An Adapter with support for load-balancing between a collection of
connections (for use with replication setups when set as either a slave or
master in the above, though they're not coupled)
Are any of these worth contributing directly to you guys, or should I just host
them on my own github account? They're pretty simple, but super-needed for all
those companies using MySQL replication. For some reason I can't get RSpec
working via RVM on my Ubuntu VM, but I'll add specs once I do.
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.