Changing database in query options hash has no effect

[gstaubli]

Table:

prod.final_product

Re-creating bug:

client = Mysql2::Client.new(
{
  :host => "127.0.0.1", 
  :username => "username", 
  :password => "password", 
  :database => ""
}) # => #<Mysql2::Client ... :database => ""}, @read_timeout=nil>
client.query("SELECT * FROM final_product") # => Mysql2::Error: No database selected
client.query_options[:database] = "prod" # => "prod"
client # => #<Mysql2::Client ... @query_options = { ... :database => "prod"}, @read_timeout=nil>
client.query("SELECT * FROM final_product") # => Mysql2::Error: No database selected

Workarounds to manipulating query_options hash

Using #select_db

client = Mysql2::Client.new(
{
  :host => "127.0.0.1", 
  :username => "username", 
  :password => "password", 
  :database => ""
}) # => #<Mysql2::Client ... :database => ""}, @read_timeout=nil>
client.select_db("prod") # => "prod"
client.query("SELECT * FROM final_product") # => #<Mysql2::Result ... :database => "prod"}>

Using options hash on client initialization

client = Mysql2::Client.new(
{
  :host => "127.0.0.1", 
  :username => "username", 
  :password => "password", 
  :database => "prod"
}) # => #<Mysql2::Client ... :database => ""}, @read_timeout=nil>
client.query("SELECT * FROM final_product") # => #<Mysql2::Result ... :database => "prod"}>

[sodabrew]

This is intended behavior.

[gstaubli]

Why?

Changing the query_options (which is exposed, intentionally or not) and not actually using the options in the forthcoming query does not seem logical to me.

Either I should not be allowed to modify the query_options directly or the query_options should be used in forthcoming queries, but the current behavior is deceptive.

[brianmario]

@gstaubli what version of mysql2 are you using? Each query should be using the options defined on the Mysql2::Client instance. So if you're changing that hash it seems like it should pickup the behavior.

@sodabrew I'm probably missing something (it's halloween in GitHub HQ and I may or may not have had some beer before typing this), but it appears as though we're doing this already? Not sure why it's not being picked up.

[sodabrew]

We copy all of the options into the query_options hash here:
https://github.com/brianmario/mysql2/blob/master/lib/mysql2/client.rb#L22

But the ones used for connecting are just these:
https://github.com/brianmario/mysql2/blob/master/lib/mysql2/client.rb#L67

Even upon reconnect, the original values are used because libmysql has them inside the client struct, we never pass the args back to mysql after that first connect.

At one point I was working on a refactor that would remove the connection parameters from the query options hash, but wasn't sure if there would be fallout for people expecting them to be there. It'd have to be a 0.4.0 thing.

[gstaubli]

Version: 0.3.13
Appreciate the clarifications.

While the client connection parameters (re: query_options hash) can be modified, mysql2 should not support on-the-fly modifications to it. Do I have that right?

It sounds like this issue could be handled in at least three ways:

1. Eliminate the ability to make on-the-fly changes to the client connection parameters
2. Support changing the query options' :database by making a call to #select_db
3. Do nothing

What is the reasoning for calling the client connection parameters hash "query_options," which implies the options pertain to the query and not the client?

[brianmario]

@sodabrew oh shit yeah totally missed that it happened to be the :database key that was being changed which only changes the values in the options hash not calling select_db and telling libmysql about it.

What is the reasoning for calling the client connection parameters hash "query_options," which implies the options pertain to the query and not the client?

This is sortof a legacy thing but mostly it's like this because I was being lazy a long time ago when I added this functionality. Hash#dup is way easier than trimming off the non-connection options for the query_options hash. Having you bring this up definitely makes me think query_options and connect_options should be different things. Where query_options would still be inherited down the object tree and connect_options would only be on the Mysql2::Client instance itself.

[gstaubli]

@brianmario Separating connect_options and query_options is a desirable abstraction given the behavioral differences of client versus query-level options.

[sodabrew]

Milestone 0.4.0, since it will change contents of accessible instance variables.