3 things that should be part of the main Rails tree: http://www.redhillconsulting.com.au/rails_plugins.html Views? -- Posted via http://www.ruby-forum.com/.
Foreign Key Migratitions I agree with 100%. It says "SQL-92 syntax and as such should be compatible with most databases that support foreign-key constraints", but that should be tested. It needs to work with the major databases that rails supports, MySQL, PostgreSQL, Oracle, SQLite, DB2, etc. Having unique constraints and indexes in there too would be great. Without these features, you must put native SQL in the migrations, which pretty much defeats the purpose. On 5/25/06, Matt P <mail@matthewpainter.co.uk> wrote:> > 3 things that should be part of the main Rails tree: > > http://www.redhillconsulting.com.au/rails_plugins.html > > Views? > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060525/a880c2c2/attachment.html
On Thursday, May 25, 2006, at 11:58 AM, Paul Barry wrote:>Foreign Key Migratitions I agree with 100%. It says "SQL-92 syntax and as >such should be compatible with most databases that support foreign-key >constraints", but that should be tested. It needs to work with the major >databases that rails supports, MySQL, PostgreSQL, Oracle, SQLite, DB2, etc. >Having unique constraints and indexes in there too would be great. Without >these features, you must put native SQL in the migrations, which >pretty much >defeats the purpose. > >On 5/25/06, Matt P <mail@matthewpainter.co.uk> wrote: >> >> 3 things that should be part of the main Rails tree: >> >> http://www.redhillconsulting.com.au/rails_plugins.html >> >> Views? >> >> -- >> Posted via http://www.ruby-forum.com/. >> _______________________________________________ >> Rails mailing list >> Rails@lists.rubyonrails.org >> http://lists.rubyonrails.org/mailman/listinfo/rails >> > > >_______________________________________________ >Rails mailing list >Rails@lists.rubyonrails.org >http://lists.rubyonrails.org/mailman/listinfo/rails >I disagree a bit regarding the foreign key plugin. Not everyone wants or needs such a capability, and one of the criteria for core inclusion is for the feature to be broadly useful to many users. I''m just not convinced that the foreign key plugin meets those criteria. The cascading stylesheet and Js plugins seem to meet that criteria at least. Of course, I would think that it would be worth asking about that on the core list. _Kevin -- Posted with http://DevLists.com. Sign up and save your mailbox.
On May 25, 2006, at 9:39 AM, Kevin Olbrich wrote:> On Thursday, May 25, 2006, at 11:58 AM, Paul Barry wrote: >> Foreign Key Migratitions I agree with 100%. It says "SQL-92 >> syntax and as >> such should be compatible with most databases that support foreign- >> key >> constraints", but that should be tested. It needs to work with >> the major >> databases that rails supports, MySQL, PostgreSQL, Oracle, SQLite, >> DB2, etc. >> Having unique constraints and indexes in there too would be >> great. Without >> these features, you must put native SQL in the migrations, which >> pretty much >> defeats the purpose. > > I disagree a bit regarding the foreign key plugin. Not everyone wants > or needs such a capability, and one of the criteria for core inclusion > is for the feature to be broadly useful to many users. I''m just not > convinced that the foreign key plugin meets those criteria. The > cascading stylesheet and Js plugins seem to meet that criteria at > least. > > Of course, I would think that it would be worth asking about that > on the > core list.I''d love to see better foreign key support in core. There''s a ticket that added schema dumper support seven months ago, but nobody has stepped up with unit tests. http://dev.rubyonrails.org/ticket/2738 jeremy
> I''d love to see better foreign key support in core. There''s a ticket > that added schema dumper support seven months ago, but nobody has > stepped up with unit tests. > > http://dev.rubyonrails.org/ticket/2738I think foreign key support in schema.rb is worthy of core inclusion too, but someone needs to do all the hard work of making sure the tests are bulletproof and that we''re good across all the databases. Make that happen and it makes it in. -- David Heinemeier Hansson http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager http://www.rubyonrails.com -- Web-application framework
I know that there is work that needs to be done in order to make the plugin work across all databases, etc., but I''m curious, how could you not need foreign key support in your application? Do you just not mind the native SQL in the migration or are you building an application without foreign keys? I''m just curious to know what others are doing, because to me, the idea of building an application that doesn''t have foreign keys at the DB level seems insane. On 25 May 2006 16:39:24 -0000, Kevin Olbrich < devlists-rubyonrails@devlists.com> wrote:> > > On Thursday, May 25, 2006, at 11:58 AM, Paul Barry wrote: > >Foreign Key Migratitions I agree with 100%. It says "SQL-92 syntax and > as > >such should be compatible with most databases that support foreign-key > >constraints", but that should be tested. It needs to work with the major > >databases that rails supports, MySQL, PostgreSQL, Oracle, SQLite, DB2, > etc. > >Having unique constraints and indexes in there too would be > great. Without > >these features, you must put native SQL in the migrations, which > >pretty much > >defeats the purpose. > > > >On 5/25/06, Matt P <mail@matthewpainter.co.uk> wrote: > >> > >> 3 things that should be part of the main Rails tree: > >> > >> http://www.redhillconsulting.com.au/rails_plugins.html > >> > >> Views? > >> > >> -- > >> Posted via http://www.ruby-forum.com/. > >> _______________________________________________ > >> Rails mailing list > >> Rails@lists.rubyonrails.org > >> http://lists.rubyonrails.org/mailman/listinfo/rails > >> > > > > > >_______________________________________________ > >Rails mailing list > >Rails@lists.rubyonrails.org > >http://lists.rubyonrails.org/mailman/listinfo/rails > > > > I disagree a bit regarding the foreign key plugin. Not everyone wants > or needs such a capability, and one of the criteria for core inclusion > is for the feature to be broadly useful to many users. I''m just not > convinced that the foreign key plugin meets those criteria. The > cascading stylesheet and Js plugins seem to meet that criteria at least. > > Of course, I would think that it would be worth asking about that on the > core list. > > _Kevin > > -- > Posted with http://DevLists.com. Sign up and save your mailbox. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060525/0d0d1d41/attachment.html
On May 25, 2006, at 1:15 PM, Paul Barry wrote:> I know that there is work that needs to be done in order to make > the plugin work across all databases, etc., but I''m curious, how > could you not need foreign key support in your application? Do you > just not mind the native SQL in the migration or are you building > an application without foreign keys? I''m just curious to know what > others are doing, because to me, the idea of building an > application that doesn''t have foreign keys at the DB level seems > insane.There have been a lot of discussions on this subject, and it comes down to this: Two sets of thoughts: 1) Integration DBs are accessed by several apps, and MUST have lots of inbuilt DB checking to make sure everyone''s on the same page. 2) Application DBs are accessed by a single application. With a good OO layer (like ActiveRecord) providing lots of validation in the application layer, it''s not as critical. I original came from the #1 side of the fence. After listening to many people make many comments on the subject, weighing them in my own mind and experience, I''m now much more comfortable with #2. I personally believe that as we move (quickly) to web services), there will be MANY application DBs, each running a simple application, and speaking to each other via web services (hopefully nice simple REST web services) rather than through the DB. -- -- Tom Mornini
On May 25, 2006, at 1:15 PM, Paul Barry wrote:> I know that there is work that needs to be done in order to make > the plugin work across all databases, etc., but I''m curious, how > could you not need foreign key support in your application? Do you > just not mind the native SQL in the migration or are you building > an application without foreign keys? I''m just curious to know what > others are doing, because to me, the idea of building an > application that doesn''t have foreign keys at the DB level seems > insane.Paul, everyone''s using foreign keys in concept, but many choose not to enforce them and are feeling more pleasure than pain as a result. That''s intriguing, huh? jeremy
If your application is the only access for write/delete operations and you wrote your application correctly you don''t need foreign keys at all, they just slow down your data access ;-) On 5/25/06, Paul Barry <mail@paulbarry.com> wrote:> > I know that there is work that needs to be done in order to make the > plugin work across all databases, etc., but I''m curious, how could you not > need foreign key support in your application? Do you just not mind the > native SQL in the migration or are you building an application without > foreign keys? I''m just curious to know what others are doing, because to > me, the idea of building an application that doesn''t have foreign keys at > the DB level seems insane. > > > On 25 May 2006 16:39:24 -0000, Kevin Olbrich <devlists-rubyonrails@devlists.com> > wrote: > > > > > > On Thursday, May 25, 2006, at 11:58 AM, Paul Barry wrote: > > >Foreign Key Migratitions I agree with 100%. It says "SQL-92 syntax and > > as > > >such should be compatible with most databases that support foreign-key > > >constraints", but that should be tested. It needs to work with the > > major > > >databases that rails supports, MySQL, PostgreSQL, Oracle, SQLite, DB2, > > etc. > > >Having unique constraints and indexes in there too would be > > great. Without > > >these features, you must put native SQL in the migrations, which > > >pretty much > > >defeats the purpose. > > > > > >On 5/25/06, Matt P < mail@matthewpainter.co.uk> wrote: > > >> > > >> 3 things that should be part of the main Rails tree: > > >> > > >> http://www.redhillconsulting.com.au/rails_plugins.html > > >> > > >> Views? > > >> > > >> -- > > >> Posted via http://www.ruby-forum.com/. > > >> _______________________________________________ > > >> Rails mailing list > > >> Rails@lists.rubyonrails.org > > >> http://lists.rubyonrails.org/mailman/listinfo/rails > > >> > > > > > > > > >_______________________________________________ > > >Rails mailing list > > > Rails@lists.rubyonrails.org > > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > > I disagree a bit regarding the foreign key plugin. Not everyone wants > > or needs such a capability, and one of the criteria for core inclusion > > is for the feature to be broadly useful to many users. I''m just not > > convinced that the foreign key plugin meets those criteria. The > > cascading stylesheet and Js plugins seem to meet that criteria at least. > > > > Of course, I would think that it would be worth asking about that on the > > > > core list. > > > > _Kevin > > > > -- > > Posted with http://DevLists.com. Sign up and save your mailbox. > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060525/a8d46d7a/attachment.html
(for most databases) insert/update will be slowed down, but multi- table queries will be sped up (cross table foreign key indexes) - sometimes considerably On 25-May-06, at 4:33 PM, Steve Longdo wrote:> If your application is the only access for write/delete operations > and you wrote your application correctly you don''t need foreign > keys at all, they just slow down your data access ;-) > > On 5/25/06, Paul Barry <mail@paulbarry.com> wrote: > I know that there is work that needs to be done in order to make > the plugin work across all databases, etc., but I''m curious, how > could you not need foreign key support in your application? Do you > just not mind the native SQL in the migration or are you building > an application without foreign keys? I''m just curious to know what > others are doing, because to me, the idea of building an > application that doesn''t have foreign keys at the DB level seems > insane. > > > On 25 May 2006 16:39:24 -0000, Kevin Olbrich < devlists- > rubyonrails@devlists.com> wrote: > > On Thursday, May 25, 2006, at 11:58 AM, Paul Barry wrote: > >Foreign Key Migratitions I agree with 100%. It says "SQL-92 > syntax and as > >such should be compatible with most databases that support foreign- > key > >constraints", but that should be tested. It needs to work with > the major > >databases that rails supports, MySQL, PostgreSQL, Oracle, SQLite, > DB2, etc. > >Having unique constraints and indexes in there too would be > great. Without > >these features, you must put native SQL in the migrations, which > >pretty much > >defeats the purpose. > > > >On 5/25/06, Matt P < mail@matthewpainter.co.uk> wrote: > >> > >> 3 things that should be part of the main Rails tree: > >> > >> http://www.redhillconsulting.com.au/rails_plugins.html > >> > >> Views? > >> > >> -- > >> Posted via http://www.ruby-forum.com/. > >> _______________________________________________ > >> Rails mailing list > >> Rails@lists.rubyonrails.org > >> http://lists.rubyonrails.org/mailman/listinfo/rails > >> > > > > > >_______________________________________________ > >Rails mailing list > > Rails@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > I disagree a bit regarding the foreign key plugin. Not everyone wants > or needs such a capability, and one of the criteria for core inclusion > is for the feature to be broadly useful to many users. I''m just not > convinced that the foreign key plugin meets those criteria. The > cascading stylesheet and Js plugins seem to meet that criteria at > least. > > Of course, I would think that it would be worth asking about that > on the > core list. > > _Kevin > > -- > Posted with http://DevLists.com. Sign up and save your mailbox. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060525/2cf51ed2/attachment-0001.html
On 5/25/06, Paul Barry <mail@paulbarry.com> wrote:> <snip> but I''m curious, how could you not need > foreign key support in your application? Do you just not mind the native > SQL in the migration or are you building an application without foreign > keys?The foreign keys are still there, just not enforced at the database level. While uncomfortable for us J2EE (or any monolithic database types), it really makes a lot of sense with the was SOA / Web Services are going. After all, why define your foreign keys in the database *and* the code if you don''t need to. Not only is it not DRY, it''s also less flexible (with the powerful model support ActiveRecord gives).
I agree foreign keys at the DB level are needed as much for application DBs. I aslo agree we might be seeing more and more applciation DBs. But I don''t think integration DBs are going away. Even if you don''t have a pure integration DB, you might have an application DB where you occasionally need to load data in the back end. It''s easier to use tools that the database already provide (like LOAD DATA for MySQL, SQLLoader for Oracle, etc). This allows a DBA to take care of it and not have to have a developer build a specific interface at the application layer for importing the data. For a regular data feed, it makes sense to have an application level data import, but for ad hoc importing of data from other systems, it''s nice to take care of it at the DB level, which is why you need a DBA. Another reason this is import is if for making rails "Enterprise Ready". I know David''s not really concerned about Rails being mainstream - http://www.loudthinking.com/arc/000584.html - and I take "mainstream" and "enterprise ready" to mean the same thing, which is that non-technical managers involved with IT are comfortable funding a project to be built with Rails. To me this is important, because I think RoR is a great technology and I would love to be able to use it in the projects I work on. But if RoR isn''t viewed as Enterprise Ready by the masses, it will be harder in a political sense to be able to use RoR on many projects. So, my point is that this is one of those things that people could look at and say "RoR doesn''t even support foreign keys, it''s not for the enterprise". I love to be able to eliminate that argument. It seems that David does agree that AR migrations should support foreign keys, so it''s just a matter of finding the time to do it. On 5/25/06, Tom Mornini <tmornini@infomania.com> wrote:> > On May 25, 2006, at 1:15 PM, Paul Barry wrote: > > > I know that there is work that needs to be done in order to make > > the plugin work across all databases, etc., but I''m curious, how > > could you not need foreign key support in your application? Do you > > just not mind the native SQL in the migration or are you building > > an application without foreign keys? I''m just curious to know what > > others are doing, because to me, the idea of building an > > application that doesn''t have foreign keys at the DB level seems > > insane. > > There have been a lot of discussions on this subject, and it comes > down to this: > > Two sets of thoughts: > > 1) Integration DBs are accessed by several apps, and MUST have > lots of inbuilt > DB checking to make sure everyone''s on the same page. > > 2) Application DBs are accessed by a single application. With a > good OO layer > (like ActiveRecord) providing lots of validation in the > application layer, > it''s not as critical. > > I original came from the #1 side of the fence. After listening to > many people make > many comments on the subject, weighing them in my own mind and > experience, I''m now > much more comfortable with #2. > > I personally believe that as we move (quickly) to web services), > there will be > MANY application DBs, each running a simple application, and speaking > to each > other via web services (hopefully nice simple REST web services) > rather than > through the DB. > > -- > -- Tom Mornini > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060525/ba296ba0/attachment.html
On May 25, 2006, at 1:41 PM, Jodi Showers wrote:> (for most databases) insert/update will be slowed down, but multi- > table queries will be sped up (cross table foreign key indexes) - > sometimes considerablyIndexing works as expected whether or not you choose to enforce foreign key constraints. jeremy
> So, my point is that this is one of those things that people could look at > and say "RoR doesn''t even support foreign keys, it''s not for the > enterprise". I love to be able to eliminate that argument. It seems that > David does agree that AR migrations should support foreign keys, so it''s > just a matter of finding the time to do it.I don''t personally care about getting adoption by people who skip Rails because schema.rb didn''t do foreign keys, but I''m not going to stand in the way of others who do care about that. So if you feel that this is important to you, please do find a way to help the effort of getting support in. At the same time, I don''t want to get any false hopes inflated by saying OK to this. I am so most certainly not going to work on it. I doubt anyone else in the Rails core group is interested in doing the leg work either. So this support will only come from someone who needs it himself enough to do the work. So let''s see that code flowing ;) -- David Heinemeier Hansson http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager http://www.rubyonrails.com -- Web-application framework
Fair enough. I understand that there are probably plently of other things you''d personally rather like to see part of rails and your going to focus your efforts on those things. I personally don''t have the time to work on this now, but hopefully I will in the near future. On 5/25/06, David Heinemeier Hansson <david.heinemeier@gmail.com> wrote:> > > So, my point is that this is one of those things that people could look > at > > and say "RoR doesn''t even support foreign keys, it''s not for the > > enterprise". I love to be able to eliminate that argument. It seems > that > > David does agree that AR migrations should support foreign keys, so it''s > > just a matter of finding the time to do it. > > I don''t personally care about getting adoption by people who skip > Rails because schema.rb didn''t do foreign keys, but I''m not going to > stand in the way of others who do care about that. So if you feel that > this is important to you, please do find a way to help the effort of > getting support in. > > At the same time, I don''t want to get any false hopes inflated by > saying OK to this. I am so most certainly not going to work on it. I > doubt anyone else in the Rails core group is interested in doing the > leg work either. So this support will only come from someone who needs > it himself enough to do the work. > > So let''s see that code flowing ;) > -- > David Heinemeier Hansson > http://www.loudthinking.com -- Broadcasting Brain > http://www.basecamphq.com -- Online project management > http://www.backpackit.com -- Personal information manager > http://www.rubyonrails.com -- Web-application framework > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060526/1ee6e2c7/attachment-0001.html
On Thu, May 25, 2006 at 11:58:12AM -0400, Paul Barry wrote: [...] } Having unique constraints and indexes in there too would be great. Without } these features, you must put native SQL in the migrations, which pretty much } defeats the purpose. add_index :table_name, ["column1", "column2"], :name => "arbitrary_index_name", :unique => true --Greg
On Thu, May 25, 2006 at 03:33:20PM -0500, Steve Longdo wrote: } If your application is the only access for write/delete operations and you } wrote your application correctly you don''t need foreign keys at all, they } just slow down your data access ;-) Aye, there''s the rub. If we could dependably code correctly then debuggers wouldn''t exist. Foreign keys are about more than just a constraint in the database. Putting a foreign key constraint on a database column is an explicit statement of an assumption. It prevents you from deleting data on which other data depends, for example, which is quite valuable. Yes, you can handle it at the application layer, but that''s where your efficiency argument falls flat. The database is going to be more efficient at enforcing data integrity constraints if only because it requires less I/O, and that''s ignoring the difference between a database running as native code and interpreted Ruby. Of course, you can simply forego data integrity constraints entirely. While you''re at it, perhaps you''d like to do your own memory management as well. Sure, it''s somewhat error prone and it''s been shown to reduce programmer productivity, but garbage collection is so much less efficient, right? --Greg
On Thu, May 25, 2006 at 01:31:17PM -0700, Tom Mornini wrote: [...] } Two sets of thoughts: } } 1) Integration DBs are accessed by several apps, and MUST have lots of } inbuilt DB checking to make sure everyone''s on the same page. That''s an oversimplification, but we''ll go with it. } 2) Application DBs are accessed by a single application. With a good } OO layer (like ActiveRecord) providing lots of validation in the } application layer, it''s not as critical. Not *as* critical, perhaps. It''s still pretty important. } I original came from the #1 side of the fence. After listening to many } people make many comments on the subject, weighing them in my own mind } and experience, I''m now much more comfortable with #2. I spent most of this past year dealing with a vast application database. There were a couple of frontends, but they all used the same ORM codebase to interact with the database. There were no data integrity constraints in the database, but this ORM did a pretty good job of dealing with it. It didn''t do a good enough job, however. The database was *full* of bad data, dirty data, data that should never have made it into the database and that would have been caught by decent data integrity constraints. Programmers inevitably write buggy code. It happens. Through maintenance, the code gets less buggy. At this point, Solaris has essentially no bugs that will corrupt data being written to disk. Likewise, Oracle has essentially no bugs in its data integrity constraint code. They are codebases that have been actively improved and maintained for years. The same is true of PostgreSQL and InnoDB, among others. If you express your data integrity requirements implicitly in all new Ruby code, you are reinventing the wheel in an error prone manner. If you express them explicitly as a database integrity constraints, you are leveraging well-tested, well-maintained, and well-optimized code. Ask yourself whether it is more likely that you have a bug in the code you''ve written over the last week or that there is a bug in your RDBMS''s integrity constraint enforcement. Which would you rather rely on for your mission-critical data? } I personally believe that as we move (quickly) to web services), there } will be MANY application DBs, each running a simple application, and } speaking to each other via web services (hopefully nice simple REST web } services) rather than through the DB. Web services are only as good as the code implementing them. See above. } -- Tom Mornini --Greg
I''m sorry if i sound stupid. But... Is it that much of a problem really to add foreign keys to migrations? Rails already senses on a application level how these tables connect to eachother using the models. Shouldn''t it be easy to make the migrate command go over the model files and add the fk elements if it senses that it''s using a DB that handles it. I just can''t see how FK''s can hurt. I''ve personally had to use them and i forsee being forced to use them because sometimes there are other software (or even hardware as I''ve experienced) needs to use the same database. On 5/26/06, Paul Barry <mail@paulbarry.com> wrote:> Fair enough. I understand that there are probably plently of other things > you''d personally rather like to see part of rails and your going to focus > your efforts on those things. I personally don''t have the time to work on > this now, but hopefully I will in the near future. > > > On 5/25/06, David Heinemeier Hansson <david.heinemeier@gmail.com> wrote: > > > So, my point is that this is one of those things that people could look > at > > > and say "RoR doesn''t even support foreign keys, it''s not for the > > > enterprise". I love to be able to eliminate that argument. It seems > that > > > David does agree that AR migrations should support foreign keys, so it''s > > > just a matter of finding the time to do it. > > > > I don''t personally care about getting adoption by people who skip > > Rails because schema.rb didn''t do foreign keys, but I''m not going to > > stand in the way of others who do care about that. So if you feel that > > this is important to you, please do find a way to help the effort of > > getting support in. > > > > At the same time, I don''t want to get any false hopes inflated by > > saying OK to this. I am so most certainly not going to work on it. I > > doubt anyone else in the Rails core group is interested in doing the > > leg work either. So this support will only come from someone who needs > > it himself enough to do the work. > > > > So let''s see that code flowing ;) > > -- > > David Heinemeier Hansson > > http://www.loudthinking.com -- Broadcasting Brain > > http://www.basecamphq.com -- Online project management > > http://www.backpackit.com -- Personal information manager > > http://www.rubyonrails.com -- Web-application framework > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >-- -------------- Jon Gretar Borgthorsson http://www.jongretar.net/
Paul Barry wrote:> Foreign Key Migratitions I agree with 100%.While we''re discussing foreign keys in Rails, have you ever wondered why ActiveRecord tries to find the foreign key column just by name (eg. ''post_id'')? Wouldn''t it be more logical that it first queries the table for metadata, finds foreign keys constraints by itself and, if there aren''t any, fallbacks to guessing by name? I don''t think anybody here believes that an application framework should recreate features of relational databases -- yet, we do it? -- Posted via http://www.ruby-forum.com/.
>Programmers inevitably write buggy code. It happens. Through maintenance, >the code gets less buggy. At this point, Solaris has essentially no bugs >that will corrupt data being written to disk. Likewise, Oracle has >essentially no bugs in its data integrity constraint code. They are >codebases that have been actively improved and maintained for years. The >same is true of PostgreSQL and InnoDB, among others. If you express your >data integrity requirements implicitly in all new Ruby code, you are >reinventing the wheel in an error prone manner. If you express them >explicitly as a database integrity constraints, you are leveraging >well-tested, well-maintained, and well-optimized code. > >Ask yourself whether it is more likely that you have a bug in the code >you''ve written over the last week or that there is a bug in your RDBMS''s >integrity constraint enforcement. Which would you rather rely on for your >mission-critical data? > >--Greg >Good points, however... With the current state of the rails codebase, I am probably as likely to introduce a bug into the migration specifying the FK relation as I am to mis-use it in a model. Specifying the contstraints instead of relying on conventions is simply another potential source of bugs. _Kevin -- Posted with http://DevLists.com. Sign up and save your mailbox.
On Friday, May 26, 2006, at 2:12 PM, Mislav wrote:>Paul Barry wrote: >> Foreign Key Migratitions I agree with 100%. > >While we''re discussing foreign keys in Rails, have you ever wondered why >ActiveRecord tries to find the foreign key column just by name (eg. >''post_id'')? Wouldn''t it be more logical that it first queries the table >for metadata, finds foreign keys constraints by itself and, if there >aren''t any, fallbacks to guessing by name? > >I don''t think anybody here believes that an application framework should >recreate features of relational databases -- yet, we do it? > >-- >Posted via http://www.ruby-forum.com/. >_______________________________________________ >Rails mailing list >Rails@lists.rubyonrails.org >http://lists.rubyonrails.org/mailman/listinfo/railsWhy query the database for metadata if you already know that the fk is? If you follow convention, then you can just use it rather than having to look it up every time. _Kevin -- Posted with http://DevLists.com. Sign up and save your mailbox.
> I''m sorry if i sound stupid. But... > Is it that much of a problem really to add foreign keys to migrations? > Rails already senses on a application level how these tables connect > to eachother using the models. Shouldn''t it be easy to make the > migrate command go over the model files and add the fk elements if it > senses that it''s using a DB that handles it. > > I just can''t see how FK''s can hurt. I''ve personally had to use them > and i forsee being forced to use them because sometimes there are > other software (or even hardware as I''ve experienced) needs to use the > same database.Would this help? Plugins - Foreign Key Migrations - Agile Web Development http://www.agilewebdevelopment.com/plugins/foreign_key_migrations
Philip Hallstrom wrote:> Would this help? > > Plugins - Foreign Key Migrations - Agile Web Development > http://www.agilewebdevelopment.com/plugins/foreign_key_migrationsThat''s where the thread started! Matt P wrote: | 3 things that should be part of the main Rails tree: | | http://www.redhillconsulting.com.au/rails_plugins.html | | Views? regards Justin
On May 26, 2006, at 4:24 AM, Gregory Seidman wrote:> I spent most of this past year dealing with a vast application > database.Well, perhaps it should have been many small DBs. :-)> There were a couple of frontends, but they all used the same ORM > codebase > to interact with the database.Couple of frontends? Sounds like an integration DB to me.> There were no data integrity constraints in the database, but this > ORM did > a pretty good job of dealing with it. > > It didn''t do a good enough job, however. The database was *full* of > bad > data, dirty data, data that should never have made it into the > database and > that would have been caught by decent data integrity constraints.Well, hate to break it to you, but I''ve worked on integration DBs with tons of constraints that were full of bad, dirty data that should never have made it into the DB. :-) We''re not really in disagreement. If you read my previous posts, you already know that. Bugs are bugs are bugs. Specifying constraints in the DB doesn''t prevent bugs, because the constraints themselves can have be buggy too. Again, as I mentioned previously, *I came from your side of the argument*. I haven''t lost my mind (yet) or gone senile, but I *did* approach the question with an open mind, as I''m sure you are as well. -- -- Tom Mornini