Rodrigo, We're using postgres with structure.sql and a legacy DB that has plenty of constraints (fkey, unique) and in the Rails app using that schema for new migrations we're using foreigner ( https://github.com/matthuhiggins/foreigner ) to add new fkeys, and iirc using add_index for some unique constraints (a la http://stackoverflow.com/a/3370333/178651 ). I've read mixed things about using deferrable for everything, but it might be appropriate in some apps.
AR supports using execute to add/remove constraints, etc. also, and foreigner supports deferrable via specifying new constraints like: add_foreign_key(:employees, :companies, :options => 'deferrable') Rails create_table I think may be the only place that doesn't allow custom SQL for constraint definition, and I got schooled on that yesterday when trying to allow a spot for custom SQL within the parenths of the generated SQL for create table. :) I agree that Rails could be more constraint-friendly, but I think you can accomplish what you are trying to do with what is there? Gary On Thursday, November 29, 2012 5:59:11 AM UTC-5, Rodrigo Rosenfeld Rosas wrote: > > I think I'm late at the party and lost a lot happening here yesterday... > > At least it is good to know what core considers a good fit or not for AR > Migrations. Since constraints are a fundamental piece in my projects I get > the warning "you should avoid AR at all, including AR migrations". > Currently it is not a big deal for me as I don't plan to support any other > database vendor than PG so I can keep using "execute" in my migrations but > I thought that maybe some OSS projects could benefit from some built-in > support in AR migrations when using a popular plugin like this one: > > > https://github.com/collectiveidea/awesome_nested_set/blob/master/lib/awesome_nested_set/awesome_nested_set.rb#L655 > > I don't really believe the method above will always work in PG, for > example, if some OSS project has created an index like: > > add_index :some_table, [:parent_id, :lft], unique: true > add_index :some_table, [:parent_id, :rgt], unique: true > > The Rails community still doesn't seem to be mature enough yet with > regards to database constraints, which is unfortunate, so I believe most > people using awesome_nested_set (I never used, just took some popular gem > as an example) don't have the indices above in their migration. And if it > happens for an OSS project to have an unique index like above it is likely > that it won't always work in PG unless the OSS project uses a custom > "add_unique_index" that would be portable among database vendors to include > the deferrable constraint instead for databases like PG. > > I just suggested that unique constraints/indices should be deferrable by > default to avoid the problem above, which seems to be a very common > use-case. Otherwise the message that comes to me is "if you're not doing > MySql, get away from AR. we just pretend to support PG, but if you need > first-class support, you should be really considering a more robust ORM, > like Sequel". > > Em 28-11-2012 17:15, Rafael Mendonça França escreveu: > > I don't think this is a good fit for the core. > > You are able to use SQL statements inside your migrations, so we already > support this. > > Rafael Mendonça França > http://twitter.com/rafaelfranca > https://github.com/rafaelfranca > > > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/YhSw7VXH1kEJ. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
