On 10/15/05, Andre Parmeggiani <aap-KSrkq06vtGZfJ/NunPodnw@public.gmane.org> wrote:> > > Hi All, > > Following the DRY principle of Rails, would it be possible to "import" > database''s relationships to Rails'' models ? > > I mean, read the primary_key/foreign_key(s) from the database and > generate the appropriate has_one/many and belong_to(s) in the > models once the database adapter is known in the config ? >This is not what you are asking for, but you can design your database with DBDesigner4, and then use the dbmodel gem to create your models and relationships. This is simply a reminder for those that use DBDesigner and don''t know about dbmodel gem.
Hi All, Following the DRY principle of Rails, would it be possible to "import" database''s relationships to Rails'' models ? I mean, read the primary_key/foreign_key(s) from the database and generate the appropriate has_one/many and belong_to(s) in the models once the database adapter is known in the config ? Many thanks, Andre _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
I think the reason given for _not_ doing this was that not all databases support foreign keys. Most notably MySQL with MYISAM tables. It agree it would be very cool though. On 10/15/05, Rodrigo Alvarez Fernández <papipo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > On 10/15/05, Andre Parmeggiani <aap-KSrkq06vtGZfJ/NunPodnw@public.gmane.org> wrote: > > > > > > Hi All, > > > > Following the DRY principle of Rails, would it be possible to "import" > > database''s relationships to Rails'' models ? > > > > I mean, read the primary_key/foreign_key(s) from the database and > > generate the appropriate has_one/many and belong_to(s) in the > > models once the database adapter is known in the config ? > > > This is not what you are asking for, but you can design your database > with DBDesigner4, and then use the dbmodel gem to create your models > and relationships. This is simply a reminder for those that use > DBDesigner and don''t know about dbmodel gem. > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > >_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
In article <d682befa0510150624ocb4849dj4ba8a0dfbf7a4b40-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>, john.knott-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org says...> I think the reason given for _not_ doing this was that not all databases > support foreign keys.Actually, DHH made a blog post a few weeks ago that made it clear that, in fact, the real reason had nothing to do with foreign-key support. I''m paraphrasing, but his stance was: "Rails is opinionated software. One opinion is that, for application databases (where your app is the -only- conduit to the database), relationship data belongs in the application, not in the database, since the app can better understand the model. Therefore, Rails already IS DRY - just don''t specify the foreign keys in the database!" Now, I''m not sure I agree, but I''m not sure I can put up a coherent argument either. Certainly, IF Rails''s relational integrity is bug- free, then there''s no need to duplicate it at the database level, any more than we need to use app-level checksums to verify the contents of the filestore. But I''m not sure we''re there yet. Also, I know nothing of query optimizers, but I''d assume that the foreign-key info gives them helpful hints. Maybe not. Dunno. -- Jay Levitt | Wellesley, MA | I feel calm. I feel ready. I can only Faster: jay at jay dot fm | conclude that''s because I don''t have a http://www.jay.fm | full grasp of the situation. - Mark Adler
Jay Levitt wrote:> > Also, I know nothing of query optimizers, but I''d assume that the > foreign-key info gives them helpful hints. Maybe not. Dunno. >I doubt it actually. The optimizer should just be looking at indices. That said, I still can''t get over putting FKs into my db schema. Maybe I''ll outgrow it some day (and just "leave it to Rails"), but in my ideal world, FKs could be grokked from the DB. Do the new migrations support FKs? --Steve
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Oct 15, 2005, at 6:00 AM, Andre Parmeggiani wrote:> Following the DRY principle of Rails, would it be possible to "import" > database''s relationships to Rails'' models ? > > I mean, read the primary_key/foreign_key(s) from the database and > generate the appropriate has_one/many and belong_to(s) in the > models once the database adapter is known in the config ?Andre, yes you can. Perform a query that pulls foreign key metadata from your database''s information schema (or equivalent) then declare the appropriate has_many on your model class. In pseudocode: connection.foreign_keys_for_table(''items'').each do |foreign_key, referenced_table, referenced_column| Foo.has_many foreign_key.sub(/_id$/, '''').pluralize, :class_name => referenced_table.classify, :foreign_key => foreign_key end You''d need to implement foreign_keys_for_table for your database connection. Best, jeremy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (Darwin) iD8DBQFDUS53AQHALep9HFYRAoeTAJ99mhX6h+NLQZTJOc15dNAR9N+IjQCeNM8k /TmBX4T8+pNeqGN9Z6kFl64=i36C -----END PGP SIGNATURE-----
> Date: Sat, 15 Oct 2005 09:51:30 -0400 > From: Jay Levitt <jay-news-WxwZQdyI2t0@public.gmane.org> > Subject: [Rails] Re: Importing database''s relationships> relationship data belongs in the application, not in the database, since > the app can better understand the model. Therefore, Rails already IS > DRY - just don''t specify the foreign keys in the database!"Yes, that solves the problem in one way. But if you already have the foreign keys, why not just use them ?? If you already have 20 tables designed with some CASE tool with the proper relationships, should you just discard the generated foreign keys and go throughout the model to express them in Rails ?> Now, I''m not sure I agree, but I''m not sure I can put up a coherent > argument either. Certainly, IF Rails''s relational integrity is bug- > free, then there''s no need to duplicate it at the database level, any > more than we need to use app-level checksums to verify the contents of > the filestore. But I''m not sure we''re there yet.Wouldn''t the referential integrity expressed by the keys/foreign_keys be a double guarantee, just in case ? On hybrid systems, Rails might not be the only one accessing the database. Should i discard the seat belt just because my car have an airbag ? Regards, Andre
Does anyone have an steps on how to use the dbmodel gem to generate the controller/models from the design that comes out of DBDesigner4? Ron -----Original Message----- From: Rodrigo Alvarez Fernández [mailto:papipo@gmail.com] Sent: Sat 10/15/2005 8:46 AM To: rails@lists.rubyonrails.org Cc: Subject: Re: [Rails] Importing database's relationships On 10/15/05, Andre Parmeggiani <aap@howto.com.br> wrote: > > > Hi All, > > Following the DRY principle of Rails, would it be possible to "import" > database's relationships to Rails' models ? > > I mean, read the primary_key/foreign_key(s) from the database and > generate the appropriate has_one/many and belong_to(s) in the > models once the database adapter is known in the config ? > This is not what you are asking for, but you can design your database with DBDesigner4, and then use the dbmodel gem to create your models and relationships. This is simply a reminder for those that use DBDesigner and don't know about dbmodel gem. _______________________________________________ Rails mailing list Rails@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails