Hi all,
On May 26, 2006, at 10:47 AM, Michael A. Schoen wrote:
IOW, I'd rather that this patch NOT be applied -- in fact I think
my approach should be looked at with good humor, and then thrown
away, in favor of representing an executable sql statement as an
array of statement and bind values. With each connection adapter
handling as appropriate, interpolating in Ruby if necessary or
using native bind variables.
That approach will also mean changing how we generate UPDATE and
INSERT statements, since they are currently generated from scratch
as literal sql, and we'll want all the values to be bound.
For what its worth, this sounds similar to the problem I had when
trying to figure out how to adapt ActiveRecord to non-SQL data
sources. What intrigued me is that the high-level Rails APIs
actually had the right granularity, but since everything got munged
into a single SQL string it all had to be re-parsed out again. :-(
My approach was to define a new Query object, return by the
connection, that preserved that abstraction. My "ActiveData"
subclass then overrode the sql-manipulation methods to use that
instead, e.g.:
def update_all(updates, conditions = nil)
sql = connection.new_query()
sql.add("UPDATE", table_name)
sql.add("SET", sanitize_sql(updates))
add_conditions!(sql, conditions)
sql.execute(:update, "#{name} Update")
end
Of course, this would fail with user-generated SQL, but otherwise it
seemed like it should handle everything correctly.
http://www.opendarwin.org/~drernie/C499496031/E20060222133959/index.html
Haven't done much since, and not sure how relevant it is, but it
seems like a similar enough problem to be worth mentioning. I'd
certainly be interested in whatever the "right" solution to Michael's
problem is, to see if that helps me with mine.
-- Ernie P.
_______________________________________________
Rails-core mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails-core
