Hi,
I''m using SQL Server. I have a BIT field. I have a fix and a question.
This is a patch for a bug in the SQL Server adapter that causes any insert or 
update to fail:
lib/active_record/connection_adapters/sqlserver_adapter.rb
@@ -239,2 +239,2 @@
-          when TrueClass             then (column && column.type ==
:boolean ?
"''t''" : "1")
-          when FalseClass            then (column && column.type ==
:boolean ?
"''f''" : "0")
+          when TrueClass             then "1"
+          when FalseClass            then "0"
Should that be posted to Trac?
Now my question. The Active Record Helper generates for :boolean fields a 
InstanceTag#to_boolean_select_tag, which gives you the options "true"
and
"false". The problem then is that ActiveRecord::Base#update_attributes
leaves it
as a string, and the DBMS gives me an "error converting the varchar value 
''false'' to a column of data type bit." I got as far as
tracing the strings into
Base#update (or Base#create).
Where should the attributes be converted to the correct type, and why
aren''t
they?
Is it an adapter issue? Does anyone else use BIT fields?
(aside:) Why not have a checkbox by default on a boolean field, Mr. Active 
Record Helper?
Cheers,
Dave
----- Original Message ----- 
From: <rails-request-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org>
To: <rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org>
Sent: Friday, March 04, 2005 4:18 PM
Subject: Rails Digest, Vol 6, Issue 21
> Send Rails mailing list submissions to
> rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.rubyonrails.org/mailman/listinfo/rails
> or, via email, send a message with subject or body ''help''
to
> rails-request-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
>
> You can reach the person managing the list at
> rails-owner-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Rails digest..."
>
>
> Today''s Topics:
>
>   1. Re: optimization (Bob Aman)
>   2. Re: bug in postgresql ''now'' time handling??
(Ara.T.Howard)
>   3. Part 2 of ONLamp.com Rails article is online (Curt Hibbs)
>   4. Rails and SCM Best Practices (Patrick Franz -- ML)
>   5. Re: Rails and SCM Best Practices (John Wilger)
>   6. Re: Rails and SCM Best Practices (Scott Barron)
>   7. Re: Rails and SCM Best Practices (evan)
>   8. Re: Rails and SCM Best Practices (Patrick Franz -- ML)
>   9. Re: Rails and SCM Best Practices (Patrick Franz -- ML)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 3 Mar 2005 22:42:31 -0500
> From: Bob Aman <vacindak-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Subject: Re: [Rails] optimization
> To: Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> Message-ID:
<599af4e20503031942795cfea-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
> Content-Type: text/plain; charset=US-ASCII
>
> In the interests of making clear exactly what I''m trying to do, I
> suppose I should just hand out a link.  It''s running on my home
> machine, so anybody looking at the archives 10 years from now:
don''t
> expect this to work.
>
> http://67.138.254.231:3000/person/show/1
>
> Takes around 10 secs render time + 0.6 sec DB time on my Athlon 64
> 3500 with Webrick.
> I don''t know how much of the "render" time is actually
being spent on
> pulling data from flickr.  None of that is cached yet.  Working on
> that.
>
> Ideally, I''d like every page to get generated and served in less
than
> 0.5 secs.  Is this an unreasonable goal for the content I''m trying
to
> deliver?
> --
> Bob Aman
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 3 Mar 2005 20:49:15 -0700 (MST)
> From: "Ara.T.Howard"
<Ara.T.Howard-32lpuo7BZBA@public.gmane.org>
> Subject: Re: [Rails] bug in postgresql ''now'' time
handling??
> To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> Message-ID:
<Pine.LNX.4.60.0503031957040.12047-G+JZiH4CBwMC9INiCSZi8+1ftBKYq+Ku@public.gmane.org>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
> On Thu, 3 Mar 2005, Dave Steinberg wrote:
>
>> That seems to be slightly outside the scope of the issue though -
except with
>> the possibility of Time.now *not* being in UTC if you were expecting it
to
>> be.
>
> <snip point conceded>
>
>> Well, how often do you generate reports based on
>>
>> a) unsaved objects
>> b) objects that you *just* saved?  Again, if we can get some kind of
>> :reload_after_save business going on, the question becomes moot.
>
> neither really works.  again, the problem is that not so much that you are
> doing reports on the unsaved objects, but that you may have contrainsts set
up
> in the db that rely on the ''now'' field actually being
''now'' and not some ruby
> string plugged in instead.  i know it''s hard to imagine use cases
but trust me
> there is a whole world of them, read
> http://www.codeforpeople.com/lib/ruby/btpgsql/btpgsql-0.2.4/doc/ for some
> ideas why.  i''d like to re-implement this in rails.
>
>> I don''t agree.  I think if we can have a usable approximation
for the case
>> where the record is unsaved, then are able to reload the object and
make it
>> all line up, then we''ve come to an amicable compromise.  I
would not want to
>> code my apps to explicitly deal with the string ''now''
where they might
>> normally encounter a date object.  I think that''d be a step
backwards in
>> terms of making rails database agnostic.
>
> and how do you approximate this schema in rails?
>
>   [ahoward@localhost ~]$ cat a.sql
>   create table prices(
>       id int,
>       price float,
>       valid_starting_at timestamp not null default ''now'',
>       valid_ending_at timestamp not null default
''infinity''
>   );
>   insert into prices values (0, 42.0);
>   select * from prices where valid_ending_at >=
''2005-03-03'';
>
>   [ahoward@localhost ~]$ psql -f a.sql
>    id | price |     valid_starting_at      | valid_ending_at
>   ----+-------+----------------------------+-----------------
>     0 |    42 | 2005-03-03 20:07:08.128051 | infinity
>   (1 row)
>
> here you''ll get the string ''infinity'' (valid
postgresql for time) mapped back
> as the default value instead of a time object.  btw, these strings could
come
> back as well:
>
>   epoch
>   infinity
>   -infinity
>   now
>   today
>   tomorrow
>   yesterday
>   allballs
>
> (yes - that last one is for real)
>
> why chose ''now'' as the only one to approximate?  the
others come back as
> strings instead of a time objects under the current mapping anyhow - yet
all
> but the infinities can be. (and maybe they should be)
>
> also, even if you do some sort of reload after insert the current setup 
> totally
> blows up if you do
>
>   price_beer = Price::new                              # using default of 
> Time::now here!
>   price_wine = Price::new ''valid_starting_at'' =>
''now'' # but not here!
>
>   # begin transaction
>   # insert price_beer
>   # caluclate the distance to the region producing your wine - takes 1
second
>   # insert price_wine
>
> now the price of beer and the price of wine will have different
valid_starting
> times even though both were inserted under a transaction with a time of
''now''!
>
> later, when generating the report of which prices you updated last week -
> you''ll miss one.
>
> the problem is not the approximation in ruby-land, it''s that the
value used in
> subsequent inserts from ruby-land into the db is not the one specified by
the
> schema nor one specified by the user/code - it''s some random time
that''s
> ''pretty close'' to those ones.  i agree that in 97%
percent of case it''ll be
> pretty damn close - but we all those kind of bugs are days *
number_of_users
> in
> the unmaking.
>
>> Thinking about this just a little bit more, I would argue that this
should
>> simply be a FAQ / Wiki entry.  This whole issue is resolved by doing:
>>
>> class Foo < ActiveRecord::Base
>>  protected
>>    def after_create ()  reload end
>> end
>
> i suppose one answer is, in fact, to say : if you want it right specify
your
> times as ''now'' and do not rely on default mappings... 
you still have to code
> around the other strings though...  previously i''ve handled
infinite time
> using
>
>   class Time
>     INF   = INFINITY          =  1.0 / 0
>     NINF  = NEGATIVE_INFINITY = -1.0 / 0
>     EPOCH = Time.at(0)
>
>     class << INFINITY
>       include Comparable
>       def <=> o;id == o.id ? 0 : 1;end
>     end
>
>     class << NEGATIVE_INFINITY
>       include Comparable
>       def <=> o;self.id == o.id ? 0 : -1;end
>     end
>
>     def coerce(x)
>       case x
>       when Float
>         return [x, to_f]
>       when Integer
>         return [x, to_i]
>       else
>         super
>       end
>     end
>   end
>
> so at least i could have an object that compared larger/smaller than all
other
> times - the to_s method might be nice to override too...
>
>> Creating a new symbol to save a 4 word function seems excessive, but
I''m
>> willing to do it if there''s a desire.  DHH - comments?
>
> at this point in half-agreement with Dave Lee; i don''t think
''now'' should come
> back as a string - rather it should come back as a string like the rest of
of
> the special time values.  this is the simplest solution that is totally
> correct IMHO.
>
> hopefully i''ve made my point clear enough at this point and will
defer to the
> powers that know more.
>
> kind regards.
>
> -a
> -- 
>
==============================================================================>
| EMAIL   :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
> | PHONE   :: 303.497.6469
> | When you do something, you should burn yourself completely, like a good
> | bonfire, leaving no trace of yourself.  --Shunryu Suzuki
>
==============================================================================>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 3 Mar 2005 22:00:46 -0600
> From: "Curt Hibbs"
<curt-fk6st7iWb8MAvxtiuMwx3w@public.gmane.org>
> Subject: [Rails] Part 2 of ONLamp.com Rails article is online
> To: "ruby-talk ML"
<ruby-talk-X+L+6nJQZ58h9ZMKESR00Q@public.gmane.org>, "Rails-ML"
> <rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org>
> Message-ID:
<EAENKKNOJPMNCDMLDOMLEEDEIBAA.curt-fk6st7iWb8MAvxtiuMwx3w@public.gmane.org>
> Content-Type: text/plain; charset="iso-8859-1"
>
> ONLamp.com has finally published part 2 of my Rails article! You can find
it
> here:
>
>  http://www.onlamp.com/pub/a/onlamp/2005/03/03/rails.html
>
> It would be really nice if we could get this slash dotted again before the
> weekend.
>
>>From what I understand, you''re more likely to get accepted when
multiple
> people submit something. So, to anyone who has the inclination: if you
would
> submit this to slash dot I would greatly appreciate it.
>
> Thanks,
> Curt
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 03 Mar 2005 20:42:45 -0800
> From: Patrick Franz -- ML
<patrick-LkoapWg8zFbQT0dZR+AlfA@public.gmane.org>
> Subject: [Rails] Rails and SCM Best Practices
> To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> Message-ID:
<4227E745.7040100-LkoapWg8zFbQT0dZR+AlfA@public.gmane.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>
> Hi all--
>
> I''m starting a new Rails project and I''m preparing to
import it into my
> local Subversion repository. In the past, I''ve just imported the
entire
> set of files generated by ''rails'', but I''m
starting to wonder if that is
> the best way to approach things.
>
> For instance, it makes sense to add the log/ directory, but probably not
> the actual log files (unless you have some perverse need to keep
> versioned copies of them around). Does anyone else have any suggestions
> for what to keep and discard when importing a brand new project?
>
> Thanks,
> Patrick
>
> -- 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Patrick J. Franz
>
> patrick-LkoapWg8zFbQT0dZR+AlfA@public.gmane.org
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 3 Mar 2005 23:52:55 -0500
> From: John Wilger
<johnwilger-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Subject: Re: [Rails] Rails and SCM Best Practices
> To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> Message-ID:
<a05e51b60503032052156f7544-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
> Content-Type: text/plain; charset=US-ASCII
>
> On Thu, 03 Mar 2005 20:42:45 -0800, Patrick Franz -- ML
> <patrick-LkoapWg8zFbQT0dZR+AlfA@public.gmane.org> wrote:
>> Does anyone else have any suggestions
>> for what to keep and discard when importing a brand new project?
>
> I generally move the database.yml file to database.yml.orig before
> importing into subversion, and then I set the config directory to
> ignore database.yml. This way, you can just make a copy of the file
> when you check out the source, and you don''t have to worry about
> accidentally sending your database password to the repository for
> everyone else to see. This isn''t that big of a deal if you are the
> only one who will ever access the repository, though.
>
> -- 
> Regards,
> John Wilger
>
> -----------
> Alice came to a fork in the road. "Which road do I take?" she
asked.
> "Where do you want to go?" responded the Cheshire cat.
> "I don''t know," Alice answered.
> "Then," said the cat, "it doesn''t matter."
> - Lewis Carrol, Alice in Wonderland
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 03 Mar 2005 23:56:09 -0500
> From: Scott Barron <scott-HDQKq3lYuGDk1uMJSBkQmQ@public.gmane.org>
> Subject: Re: [Rails] Rails and SCM Best Practices
> To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> Message-ID:
<4227EA69.6030101-HDQKq3lYuGDk1uMJSBkQmQ@public.gmane.org>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Patrick Franz -- ML wrote:
>>
>> Hi all--
>>
>> I''m starting a new Rails project and I''m preparing to
import it into my
>> local Subversion repository. In the past, I''ve just imported
the entire
>> set of files generated by ''rails'', but I''m
starting to wonder if that is
>> the best way to approach things.
>>
>> For instance, it makes sense to add the log/ directory, but probably
not
>> the actual log files (unless you have some perverse need to keep
>> versioned copies of them around). Does anyone else have any suggestions
>> for what to keep and discard when importing a brand new project?
>>
>> Thanks,
>> Patrick
>>
>
> I personally keep everything generated by the ''rails''
command, I ignore
> the log files, and I ignore the database config file (but that''s
up to
> you).  Essentially you should be able to check out a copy of your app
> and run it (adding a db config file first, if you don''t store
those).
> That''s how I roll with it, anyway.  Working well for me.  If you
have
> stuff in vendor/ you may or may not want that, or may link that via
> something like svn:externals, that''s up to your situation.
>
> -Scott
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 253 bytes
> Desc: OpenPGP digital signature
> Url : 
>
http://one.textdrive.com/pipermail/rails/attachments/20050303/4eabdfca/signature-0001.bin
>
> ------------------------------
>
> Message: 7
> Date: Thu, 3 Mar 2005 21:15:51 -0800
> From: evan <anarchogeek-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Subject: Re: [Rails] Rails and SCM Best Practices
> To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> Message-ID:
<86ec40c1050303211573cce215-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
> Content-Type: text/plain; charset=US-ASCII
>
> I keep everything in svn except the logs, and database.yml and
> environment.rb. Those to i have in svn but as database.yml.backup and
> environment.rb.backup. I then use xal''s deploy script to pull
those
> out and use them when i do a deployment. When i''m setting up a
> development box for somebody then i manually copy those over and edit
> them.
>
> It works pretty well for us.
>
> -rabble
>
>
> On Thu, 03 Mar 2005 23:56:09 -0500, Scott Barron
<scott-HDQKq3lYuGDk1uMJSBkQmQ@public.gmane.org> wrote:
>> Patrick Franz -- ML wrote:
>> >
>> > Hi all--
>> >
>> > I''m starting a new Rails project and I''m
preparing to import it into my
>> > local Subversion repository. In the past, I''ve just
imported the entire
>> > set of files generated by ''rails'', but
I''m starting to wonder if that is
>> > the best way to approach things.
>> >
>> > For instance, it makes sense to add the log/ directory, but
probably not
>> > the actual log files (unless you have some perverse need to keep
>> > versioned copies of them around). Does anyone else have any
suggestions
>> > for what to keep and discard when importing a brand new project?
>> >
>> > Thanks,
>> > Patrick
>> >
>>
>> I personally keep everything generated by the ''rails''
command, I ignore
>> the log files, and I ignore the database config file (but
that''s up to
>> you).  Essentially you should be able to check out a copy of your app
>> and run it (adding a db config file first, if you don''t store
those).
>> That''s how I roll with it, anyway.  Working well for me.  If
you have
>> stuff in vendor/ you may or may not want that, or may link that via
>> something like svn:externals, that''s up to your situation.
>>
>> -Scott
>>
>>
>> _______________________________________________
>> Rails mailing list
>> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
>> http://lists.rubyonrails.org/mailman/listinfo/rails
>>
>>
>>
>>
>
>
> ------------------------------
>
> Message: 8
> Date: Thu, 03 Mar 2005 21:16:30 -0800
> From: Patrick Franz -- ML
<patrick-LkoapWg8zFbQT0dZR+AlfA@public.gmane.org>
> Subject: Re: [Rails] Rails and SCM Best Practices
> To: John Wilger <johnwilger-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> Message-ID:
<4227EF2E.3020606-LkoapWg8zFbQT0dZR+AlfA@public.gmane.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> John Wilger wrote:
> | On Thu, 03 Mar 2005 20:42:45 -0800, Patrick Franz -- ML
> | <patrick-LkoapWg8zFbQT0dZR+AlfA@public.gmane.org> wrote:
> |
> |>Does anyone else have any suggestions
> |>for what to keep and discard when importing a brand new project?
> |
> |
> | I generally move the database.yml file to database.yml.orig before
> | importing into subversion, and then I set the config directory to
> | ignore database.yml. This way, you can just make a copy of the file
> | when you check out the source, and you don''t have to worry about
> | accidentally sending your database password to the repository for
> | everyone else to see. This isn''t that big of a deal if you are
the
> | only one who will ever access the repository, though.
>
> Thanks, that sounds like a reasonable idea.
>
> Regards,
> Patrick
>
> - --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Patrick J. Franz
>
> patrick-LkoapWg8zFbQT0dZR+AlfA@public.gmane.org
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.0 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFCJ+8unBL/CxPCaScRAl7QAKCUS7m+ZsVPHf4WqkQD3Vu6ghtv4gCfR2FW
> mCq5xxALaFBkNhILuC7V+u4> =uSoD
> -----END PGP SIGNATURE-----
>
>
> ------------------------------
>
> Message: 9
> Date: Thu, 03 Mar 2005 21:18:29 -0800
> From: Patrick Franz -- ML
<patrick-LkoapWg8zFbQT0dZR+AlfA@public.gmane.org>
> Subject: Re: [Rails] Rails and SCM Best Practices
> To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> Message-ID:
<4227EFA5.8040308-LkoapWg8zFbQT0dZR+AlfA@public.gmane.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Scott Barron wrote:
> | Patrick Franz -- ML wrote:
> |
> |>
> |> Hi all--
> |>
> |> I''m starting a new Rails project and I''m preparing
to import it into
> |> my local Subversion repository. In the past, I''ve just
imported the
> |> entire set of files generated by ''rails'', but
I''m starting to wonder
> |> if that is the best way to approach things.
> |>
> |> For instance, it makes sense to add the log/ directory, but probably
> |> not the actual log files (unless you have some perverse need to keep
> |> versioned copies of them around). Does anyone else have any
> |> suggestions for what to keep and discard when importing a brand new
> |> project?
> |>
> |> Thanks,
> |> Patrick
> |>
> |
> | I personally keep everything generated by the ''rails''
command, I ignore
> | the log files, and I ignore the database config file (but that''s
up to
> | you).  Essentially you should be able to check out a copy of your app
> | and run it (adding a db config file first, if you don''t store
those).
> | That''s how I roll with it, anyway.  Working well for me.  If you
have
> | stuff in vendor/ you may or may not want that, or may link that via
> | something like svn:externals, that''s up to your situation.
>
> Right. My goal is to be able to do an ''svn export'' and go
live. Thanks
> for the advice.
>
> Patrick
>
> - --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Patrick J. Franz
>
> patrick-LkoapWg8zFbQT0dZR+AlfA@public.gmane.org
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.0 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFCJ++lnBL/CxPCaScRAjY2AKC7yK/HzxxQAC0Tw5Yibwo/23tmGwCfdI8q
> gw2louBGZFxc7hBUCNMXJJY> =DFVf
> -----END PGP SIGNATURE-----
>
>
> ------------------------------
>
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
>
> End of Rails Digest, Vol 6, Issue 21
> ************************************