Is there some magic that''s required to have db/schema.rb contain various execute() methods that exist in the migrations files? For example, suppose in a migration I have the following: ### BEGIN create_table ''foo'' do |t| t.text :name, :null => false end execute "ALTER TABLE public.foo ADD CHECK(trim(name) = name AND length(name) > 2)" ### END Is there a way to preserve this extra DDL foo so that it''s preserved in db/schema.rb? As is, the rake test framework is arguably broken for PostgreSQL because the db/schema.rb is always recreated without the other DDL required to make a functional schema for the application. Is that a fair assessment? -sc --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 25 Apr 2008, at 03:36, Sean Chittenden wrote:> > Is there some magic that''s required to have db/schema.rb contain > various execute() methods that exist in the migrations files? >Unfortunately not. Switching to the sql schema dumper should help (in environment.rb) Fred> For example, suppose in a migration I have the following: > > ### BEGIN > create_table ''foo'' do |t| > t.text :name, :null => false > end > > execute "ALTER TABLE public.foo ADD CHECK(trim(name) = name AND > length(name) > 2)" > ### END > > Is there a way to preserve this extra DDL foo so that it''s preserved > in db/schema.rb? As is, the rake test framework is arguably broken > for PostgreSQL because the db/schema.rb is always recreated without > the other DDL required to make a functional schema for the > application. > > Is that a fair assessment? > > -sc > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
I''d also suggest that what you''re proposing to do is not a
very
''Rails'' thing to do. One of the "strong opinions"
of Rails is that
you should consolidate your coding into a single language, and DB
management should, if at all possible, take place in the application,
_not_ the db. You could accomplish what you''re asking about as
follows:
class Foo < ARec::Base
validates_length_of :name, :minimum=>3
before_validation :trim_name
protected
def trim_name
name.strip
end
end
Certainly you''re free to do it as you''ve suggested and that
may be
most appropriate for your solution. However, some things that are
difficult to do in Rails are difficult on purpose.
On Apr 25, 3:24 am, Frederick Cheung
<frederick.che...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:> On 25 Apr 2008, at 03:36, Sean Chittenden wrote:
>
>
>
> > Is there some magic that''s required to have db/schema.rb
contain
> > various execute() methods that exist in the migrations files?
>
> Unfortunately not. Switching to the sql schema dumper should help (in
> environment.rb)
>
> Fred
>
> > For example, suppose in a migration I have the following:
>
> > ### BEGIN
> > create_table ''foo'' do |t|
> > t.text :name, :null => false
> > end
>
> > execute "ALTER TABLE public.foo ADD CHECK(trim(name) = name AND
> > length(name) > 2)"
> > ### END
>
> > Is there a way to preserve this extra DDL foo so that it''s
preserved
> > in db/schema.rb? As is, the rake test framework is arguably broken
> > for PostgreSQL because the db/schema.rb is always recreated without
> > the other DDL required to make a functional schema for the
> > application.
>
> > Is that a fair assessment?
>
> > -sc
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
Setting: Rails::Initializer.run do |config| config.active_record.schema_format = :sql end in environment.rb did the trick... that and granting superuser privs to the test user. Thanks!> I''d also suggest that what you''re proposing to do is not a very ''Rails'' thing to do.Oooh.. yeah, I fundamentally reject that premise. In fact, Rails should default to using `pg_dump --schema-only` for generating schema for PostgreSQL, and likely doing the same for all database vendors. Rails'' schema dump isn''t complete and relying on it for completeness should horrify people.> One of the "strong opinions" of Rails is that > you should consolidate your coding into a single language, and DB > management should, if at all possible, take place in the application, > _not_ the db.I know that''s the opinion of Rails, but unfortunately MySQL brain rot has been successful in negatively impacting the design of Rails. validates_* is an organic hack to workaround MySQL deficiencies. I like that ruby checks data, but ruby can''t provide data guarantees - only the database can.> However, some things that are > difficult to do in Rails are difficult on purpose.Grr... "''mother, may I,'' anti-foot shooting" is a design argument of convenience, not because of correctness, elegance, or completeness. Just some outside perspective. -sc --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Wow. Can I add you to my Christmas card list? On Apr 25, 12:46 pm, Sean Chittenden <s...-j/0HeFEw4eOX6QiC4yPwbg@public.gmane.org> wrote:> Setting: > > Rails::Initializer.run do |config| > config.active_record.schema_format = :sql > end > > in environment.rb did the trick... that and granting superuser privs > to the test user. Thanks! > > > I''d also suggest that what you''re proposing to do is not a very ''Rails'' thing to do. > > Oooh.. yeah, I fundamentally reject that premise. In fact, Rails > should default to using `pg_dump --schema-only` for generating schema > for PostgreSQL, and likely doing the same for all database vendors. > Rails'' schema dump isn''t complete and relying on it for completeness > should horrify people. > > > One of the "strong opinions" of Rails is that > > you should consolidate your coding into a single language, and DB > > management should, if at all possible, take place in the application, > > _not_ the db. > > I know that''s the opinion of Rails, but unfortunately MySQL brain rot > has been successful in negatively impacting the design of Rails. > validates_* is an organic hack to workaround MySQL deficiencies. I > like that ruby checks data, but ruby can''t provide data guarantees - > only the database can. > > > However, some things that are > > difficult to do in Rails are difficult on purpose. > > Grr... "''mother, may I,'' anti-foot shooting" is a design argument of > convenience, not because of correctness, elegance, or completeness. > > Just some outside perspective. -sc--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---