I may be completely out of line here... but "WTF? Don't you use migrations? That's what they're for."
made me think that migrations aren't the be all and end all. There are ALOT of things you cant do with migrations when it comes to database specific deployment. eg. triggers, user defined functions, even views... and even things like index creation is limited when using Postgres and MySQL or even SQLServer. I know and realize Rails is opinionated software... but IMHO the community could benefit from using the power these dbms solutions offer. How about a DSL type plugin - not only enhancing migrations, but extending activerecord to embrace the DBMS rather than treating it as "just a storage mechanism". Sorry for hijacking here, just my two cents... On Tue, Dec 29, 2009 at 7:41 PM, Marnen Laibow-Koser <[email protected]>wrote: > Hassan Schroeder wrote: > > On Tue, Dec 29, 2009 at 8:32 AM, Marnen Laibow-Koser > > <[email protected]> wrote: > > > >>> That didn't work but got me thinking in a workable direction, thanks. > >> > >> Why didn't it work? �That should be foolproof, unless I screwed up the > >> syntax. > > > >>> User.max(:id) + 10 > > NoMethodError: undefined method `max' for #<Class:0x101e8f060> > > OK, syntax goof. Sorry. > > > > >> Data integrity checking isn't business logic in the usual sense -- and > >> it really is the job of the database. > > > > I'll disagree. In this case, requiring a valid user to be associated > > with > > an object *is* a business decision; tomorrow, I could decide to allow > > anonymous object creation, or anonymous creation in some specific > > circumstances only. > > Then you can change your schema at that point. Till then, YAGNI. > > > > > Committing a code fix to that effect is a lot better to my thinking than > > requiring everyone involved to make the comparable changes in all > > their DB instances (if it's even possible to handle that logic in the > > DB). > > WTF? Don't you use migrations? That's what they're for. > > Anyway, crippling your current app because of a future situation that > may not ever occur is extremely bad practice. Develop for what you have > *now*. > > Sorry, Hassan. Normally I respect your posts here very much, but in > this case I think you're coming up with increasingly tenuous > justifications for a very bad design decision. > > > > > YMMV, > > -- > > Hassan Schroeder ------------------------ [email protected] > > twitter: @hassan > > > > -- > > > > 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 [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<rubyonrails-talk%[email protected]> > . > > For more options, visit this group at > > http://groups.google.com/group/rubyonrails-talk?hl=en. > > Best, > -- > Marnen Laibow-Koser > http://www.marnen.org > [email protected] > -- > Posted via http://www.ruby-forum.com/. > > -- > > 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]<rubyonrails-talk%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/rubyonrails-talk?hl=en. > > > -- 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
