http://dev.rubyonrails.org/ticket/1117 I''ve attached a patch to ticket 1117 which fixes it so that booleans are escaped as booleans, not integers. Specifically, this situation will now work find_all(["send_date=? and sent=?", Date.today, false]) Which matches peoples expectations, but it causes some problems with the postgresql unit tests. Specifically, the use of smallint as a boolean approved smallint DEFAULT 1, This means the adapter tries to compare ''t'' and an integer, which psql barfs on. Now it''s probably a few lines to fix our unit tests, but we may be breaking other peoples applications. What are people''s thoughts on this? I personally like the patch, naturally, and I figure the change is easy enough for people to implement. We could always create a cattr_accessor which lets people turn this off, but that''s a lot of software... -- Cheers Koz
On Oct 3, 2005, at 2:34 AM, Michael Koziarski wrote:> http://dev.rubyonrails.org/ticket/1117 > > I''ve attached a patch to ticket 1117 which fixes it so that booleans > are escaped as booleans, not integers. Specifically, this situation > will now work > > find_all(["send_date=? and sent=?", Date.today, false]) > > Which matches peoples expectations, but it causes some problems with > the postgresql unit tests. Specifically, the use of smallint as a > boolean > > approved smallint DEFAULT 1, > > This means the adapter tries to compare ''t'' and an integer, which psql > barfs on. Now it''s probably a few lines to fix our unit tests, but > we may be breaking other peoples applications. > > What are people''s thoughts on this? I personally like the patch, > naturally, and I figure the change is easy enough for people to > implement. > > We could always create a cattr_accessor which lets people turn this > off, but that''s a lot of software...I''m personally in favor of adding the boolean quoting. I think most people using booleans in pg will be using boolean fields, not integers. I''d rather see the test changed to either treat the field as an integer, or as a boolean, and be consistent. - Jamis
> I''m personally in favor of adding the boolean quoting. I think most > people using booleans in pg will be using boolean fields, not > integers. I''d rather see the test changed to either treat the field > as an integer, or as a boolean, and be consistent.ok, I''m going to tidy this up, fix the last failing test and commit some time today. It will include an option like MysqlAdapter.emulate_booleans, to handle the postgresql state. I''ll post again once I''ve done this so someone who uses psql regularly can re-run and fix the unit tests. -- Cheers Koz
On 10/4/05, Michael Koziarski <michael@koziarski.com> wrote:> > I''m personally in favor of adding the boolean quoting. I think most > > people using booleans in pg will be using boolean fields, not > > integers. I''d rather see the test changed to either treat the field > > as an integer, or as a boolean, and be consistent. > > ok, I''m going to tidy this up, fix the last failing test and commit > some time today. It will include an option like > MysqlAdapter.emulate_booleans, to handle the postgresql state. > > I''ll post again once I''ve done this so someone who uses psql regularly > can re-run and fix the unit tests.I''ve committed this (yay) now. http://dev.rubyonrails.org/changeset/2474 The changes are now required in postgresql as the tests will be failing at present. -- Cheers Koz