Hey, Josh Peek suggested I ping Rails Core about this.
I'm at the point that I really need true bind variable support in AR.
Currently we make heavy use of Oracle and PostgreSQL. Both databases,
especially Oracle, get big performance gains from bind variables.
This is important enough that I can devote time and energy to getting
it implemented in AR so that it works across multiple adapters.
I've looked thru the AR code and it seems like much of it boils down
to sanitize_sql and friends. The reasons Josh suggested that I ping
Rails Core are:
1) Make sure my approach to a potential patch sounds good.
2) Make sure there aren't any pending AR changes coming up that would
cause a huge refactor of any patches.
Regarding #1, here are my thoughts:
Start out by reorganizing AR so sanitize_sql is an adapter method. It
could live in AbstractAdapter so that existing adapters that rely on
the current behavior wouldn't have to change. This would make
sanitize_sql and friends a bit of an API, so maybe there would be a
minor refactor beyond just moving the methods, perhaps into a
SanitizeSql class similar to the PrimaryKey class that just hit
Then, run the tests and ensure that moving sanitize_sql maintains
existing adapter functionality. For people using
AR::Base.sanitize_sql, we can follow the same pattern as other adapter
methods to make sanitize_sql available in AR::Base but have it be
taken from the adapter (like the existing column/table methods).
Next, take an adapter, for example OracleEnhanced, and modify it so
that it accepts the unmodified SQL and list of bind parameters from
the AR Base layer. For standard :conditions this should be pretty easy
looking at AR. The slightly more complex/sticky cases of lazy fetch
and :include will need a bit of refactoring, but nothing that seems
crazy. Basically a string that's concatenated repeatedly and an array
of bind << params works in most cases. I've talked to Raimonds a bit
about this, so seems like OracleEnhanced could be a good guinea pig.
This approach is basically the same approach DataMapper has taken with
their DataObjects layer. AR already has much of the same structure in
place, just named AR Base and AR Adapters. We can't jump ship to
using DM because it doesn't support DB views/sprocs well, and we have
tons and tons of AR code too.
So, I guess my questions are:
1) Thoughts on this approach?
2) Any AR changes in the works that would affect this?