Rails core - Sep 2005 - Standardized boolean handling, [2335]

Okay, a few things we all need to be aware of with changeset 2335  
(http://dev.rubyonrails.com/changeset/2335):

1. If you use mysql to run the AR tests, you''ll need to recreate your  
unit test tables. The mysql.sql changed (only one column, from tinyint 
(1) to tinyint).

2. Any existing application that uses mysql and has non-boolean  
columns defined as tinyint(1) will break. To fix it, either redefine  
the columns as integer (or tinyint with a limit other than 1), or set  
ActiveRecord::ConnectionAdapters::MysqlAdapter.emulate_booleans =  
false in environment.rb.

This change is important in that it finally allows boolean columns to  
be handled consistently and portably in mysql. For instance, if you  
define a table in a migration with boolean columns:

   create_table :candy_bars do |t|
     t.column :edible, :boolean, :default => true
   end

Then when you dump the column using db_schema_dump, you get an  
identical create table, instead of one with the column being defined  
as :integer with a default of "1". This means you can dump a mysql  
schema and import it into postgresql, for instance, and boolean  
columns will be preserved.

Please, do test your (mysql) applications against this change to make  
sure all is well. The AR tests themselves currently all pass for  
mysql, sqlite, sqlite3, and postgres.

- Jamis

On 9/26/05, Jamis Buck <jamis@37signals.com>
wrote:
> Okay, a few things we all need to be aware of with changeset 2335
> (http://dev.rubyonrails.com/changeset/2335):
>
Looks good for strongspace and secret-project-x.   However,   while
we''re breaking booleans,  any chance we can change the quoting
mechanism to use the correct syntax for each database.   i.e.

http://dev.rubyonrails.org/ticket/1117


--
Cheers

Koz

On Sep 25, 2005, at 3:20 PM, Michael Koziarski wrote:
> On 9/26/05, Jamis Buck <jamis@37signals.com> wrote:
>
>> Okay, a few things we all need to be aware of with changeset 2335
>> (http://dev.rubyonrails.com/changeset/2335):
>>
>>
>
> Looks good for strongspace and secret-project-x.   However,   while
> we''re breaking booleans,  any chance we can change the quoting
> mechanism to use the correct syntax for each database.   i.e.
>
> http://dev.rubyonrails.org/ticket/1117
Actually, as part of 2335, I believe I fixed this accidentally. I  
added a "quoted_true" and "quoted_false" method to abstract
adapter,
which returns "''t''" and
"''f''" respectively. The MysqlAdapter
overrides it to return "1" and "0". I touched a few other
places
similarly, and the upshot is, this should all be working now.

I''ll take a closer look at 1117 tonight and close it if it looks  
really, truly, fixed.

- Jamis

> Actually, as part of 2335, I believe I fixed this accidentally. I
> added a "quoted_true" and "quoted_false" method to
abstract adapter,
> which returns "''t''" and
"''f''" respectively. The MysqlAdapter
> overrides it to return "1" and "0". I touched a few
other places
> similarly, and the upshot is, this should all be working now.
Excellent,   lets see if it has any flow on effects.   It''s definitely
more consistent with user expectations, however some users may
inadvertently be using booleans and expecting them to be encoded as
integers?

> I''ll take a closer look at 1117 tonight and close it if it looks
> really, truly, fixed.
>
> - Jamis
>

--
Cheers

Koz

On Sep 25, 2005, at 3:20 PM, Michael Koziarski wrote:
> On 9/26/05, Jamis Buck <jamis@37signals.com> wrote:
>
>> Okay, a few things we all need to be aware of with changeset 2335
>> (http://dev.rubyonrails.com/changeset/2335):
>
> Looks good for strongspace and secret-project-x.   However,   while
> we''re breaking booleans,  any chance we can change the quoting
> mechanism to use the correct syntax for each database.   i.e.
>
> http://dev.rubyonrails.org/ticket/1117
Okay, I take it back, this is not fixed, and for the same reasons  
Jeremy describes in that ticket. The SQL sanitization process still  
cannot determine the type of a particular column and so cannot know  
how to quote a value.

The questions, then, are these: ought the quote mechanism treat any  
truth value as a boolean column by default? Is the "0"/"1"
quoting
thing particular to MySQL? And how much would we break if we had  
truth values automatically quoted as boolean values?

In particular, MySQL would continue to quote truth values as 0 and 1,  
so I don''t think the change would affect MySQL at all. I don''t
know
how much other DB''s are relying on this behavior, though.

- Jamis

> Okay, I take it back, this is not fixed, and for the same reasons
> Jeremy describes in that ticket. The SQL sanitization process still
> cannot determine the type of a particular column and so cannot know
> how to quote a value.
>
> The questions, then, are these: ought the quote mechanism treat any
> truth value as a boolean column by default? Is the
"0"/"1" quoting
> thing particular to MySQL? And how much would we break if we had
> truth values automatically quoted as boolean values?
The only situation I can see us breaking is where someone is using a
boolean, as an integer, on a database (like pgsql and sqlite) which
quote booleans and integers differently.

Though I could be missing something.
> In particular, MySQL would continue to quote truth values as 0 and 1,
> so I don''t think the change would affect MySQL at all. I
don''t know
> how much other DB''s are relying on this behavior, though.
DB2''s boolean values depends on whether it''s UDB or DB2/390.  
Oracle
doesn''t even have boolean columns.

pgsql and sqlite require booleans to be quoted as ''t'' and
''f''.

Mysql has no boolean, but treats tinyints as booleans if required.

--
Cheers

Koz