Forum: Ruby on Rails Migrations bug with Rails 1.0, PostgreSQL 8.1?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Tom M. (Guest)
on 2005-12-15 09:34
(Received via mailing list)
Filed a ticket for bogus Ruby produced via:

rake db_schema_dump

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

I'd appreciate it if someone could verify against
PostgreSQL 8.0.x

--
-- Tom M.
Charles M. Gerungan (Guest)
on 2005-12-15 10:52
(Received via mailing list)
On 14-dec-2005, at 22:06, Tom M. wrote:

> Filed a ticket for bogus Ruby produced via:
>
> rake db_schema_dump
>
> http://dev.rubyonrails.org/ticket/3232

This is expected behavior.

If you want to set default values, the Rails way is to use a filter:

class Model < ActiveRecord::Base

protected
   before_create :set_default_values

   def.set_default_value
     self.updated_at = Time.now
   end
end

However, in the case of updated_at/on created_at/on, Rails will
automagically populate those if present.

--
Regards, Charles.
Tom M. (Guest)
on 2005-12-15 11:38
(Received via mailing list)
What does this have to do with:

rake db_schema_dump

producing non-functional Ruby code that breaks tests
and doesn't correctly instantiate the database?

I find it rather hard to believe that broken code
generation is expected behavior, or that the basis
for the new DB migrations functionality is supposed
to misassign default column value settings?

--
-- Tom M.
Charles M. Gerungan (Guest)
on 2005-12-15 20:19
(Received via mailing list)
On 15-dec-2005, at 10:35, Tom M. wrote:

> What does this have to do with:
>
> rake db_schema_dump

Right. I missed that.

--
Regards, Charles.
This topic is locked and can not be replied to.