[Rails-core] RFC: Remove support for "% style"(printf style) prepared statement from ActiveRecord

[spiketeika]

Now `ActiveRecord::Base.sanitize_sql_array` supports two formats (example 
codes are quoted from test/cases/sanitize_test.rb)

1. "% style"(printf style)

```
assert_equal "name='#{quoted_bambi}'", Binary.send(:sanitize_sql_array, 
["name='%s'", "Bambi"])
```

2. "?" as placeholder

```
assert_equal "name=#{quoted_bambi}", Binary.send(:sanitize_sql_array, 
["name=?", "Bambi"])
```

I want to deprecate and remove "% style", there are three reasons why I 
will do it

1. I think in normal use case, almost "%" placeholder can be replace to 
"?". If there are any use case where we can not replace them, please teach 
me:)

2. Usage of both are different, and sometime this difference creates 
insecure query

When we use "?", we should not quote "?". But when we use "%", we should 
quote "%s" by ourselves. This is confusing and dangerous.
There were unquoted "%s" in Rails test 
codes https://github.com/rails/rails/pull/21758/files .

3. In Rails guide, only "?" is 
explaind 
http://guides.rubyonrails.org/active_record_querying.html#array-conditions.

Regards
yui-knk

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

[Rails-core] Support nativ json datatype for mysql

[Mario Chavez]

Support was added a month ago https://github.com/rails/rails/pull/21110

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] ActiveRecord connection pool management

[Aaron Patterson]

On Thu, Sep 24, 2015 at 10:42:39PM -0700, Michael Vigilante wrote:
> Hi, just a small question on the way connections are managed in 
> ActiveRecord.
> 
> From the best I can gather reading the code (and based on behaviour), 
> ActiveRecord will check a connection out of the pool the first time a 
> thread asks for one, then that thread will continue to hang on to the 
> connection until it is closed. What is the reasoning behind this approach 
> as opposed to checking out a connection for each DB operation and letting 
> go of it once the operation is completed?

Constantly checking out a connection then checking it back in seems like
it would cause a performance bottleneck.  The assumption is that lock
contention will become the bottleneck if we have to constantly check in
/ check out connections.  The other side of that is it will cause more
complexity throughout AR as we'll have to change every place that
touches the connection.

Doing it once per thread, and giving the user control over checking in
connections (see `release_connection` on the connection pool) seemed
like a good compromise for performance and code complexity.

> My team has had a couple of issues with this (leading to us needing to use 
> a connection pool equal to the number of threads being used by our server, 
> which is not really a big problem, but feels a bit counter-intuitive).

Is it counter-intuitive? If you're doing database intensive work, then
you'd probably want the same number of connections as you have request
threads in order to maximize throughput, otherwise you'll still be
blocking other requests at some point (see Amdahl's law).

> This pos 
> t 
> is on much the same subject. I'm really just curious about the way this 
> works.

If we can prove that the concerns above are unwarranted, then it would
be fine to change.

-- 
Aaron Patterson
http://tenderlovemaking.com/

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.


pgpWTRByGxySM.pgp
Description: PGP signature

[Rails-core] ActiveRecord connection pool management

[Michael Vigilante]

Hi, just a small question on the way connections are managed in 
ActiveRecord.

>From the best I can gather reading the code (and based on behaviour), 
ActiveRecord will check a connection out of the pool the first time a 
thread asks for one, then that thread will continue to hang on to the 
connection until it is closed. What is the reasoning behind this approach 
as opposed to checking out a connection for each DB operation and letting 
go of it once the operation is completed?

My team has had a couple of issues with this (leading to us needing to use 
a connection pool equal to the number of threads being used by our server, 
which is not really a big problem, but feels a bit counter-intuitive). This 
pos 
t 
is on much the same subject. I'm really just curious about the way this 
works.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.