Hello, I am beginner to Ruby on rails doing a rails project with postgreSQL as back-end. I want to have two tables Table1 and Table2. Table1 has a column named say SUPPLIERNAME which is of string type, which should be referenced in table2 as FOREIGN KEY. Can any one please help me out to create migration and use one-to-many associations.
Hello, I am beginner to Ruby on rails doing a rails project with postgreSQL as back-end. I want to have two tables Table1 and Table2. Table1 has a column named say SUPPLIERNAME which is of string type, which should be referenced in table2 as FOREIGN KEY. Can any one please help me out to create migration and use one-to-many associations.
The foreigner gem comes up as an answer to this question quite a lot. I haven't used it, but it's what I've heard people mention in that same breath.
Basically, Rails (actually this is ActiveRecord) doesn't have the notion of foreign keys, except in a special limited sense. For example, if two models have a belongs_to / has_many relationship between them, then the [child name plural] table will have a [parent name singlular]_id column, which will be an integer column, and which will contain the primary key(id) attribute of the related [parent] object. That's just one example, but it's pretty consistent between all the different associations. I think I'm pretty safe to say that the only foreign keys that are used automatically in Rails reference these integer IDs.
That's not to say you can't have a completely different set of foreign keys in your database, enforced at the DB level. Foreigner (I believe) exists to map that layer back into ActiveRecord, where Rails can do all its usual magic with migrations and so forth while being totally cognizant of these relationships. I'm still not sure that it's going to use those extra foreign keys the way you seem to be wanting to use them. You might want to read the Rails Guide about ActiveRecord, and see if there's a way to do things that honors your design while still "skiing the fall line" of AR.
Walter
Firstly you will find life much easier if you stick to the rails conventions, so table names should be plural, lower case with underscores separating the words, and should match the model class names which are CamelCase. Column names should be lowercase. I don't understand what you say about the foreign key. Have you read the Rails Guide on ActiveRecord Associations (and the other guides for that matter)? It describes the conventional methods of relating tables. Also if you are a beginner I suggest working through some tutorials. Make sure they are Rails 3 tutorials. railstutorial.org is good and is free to use online.
Colin
Thank you Walter and Colin for giving such a good idea. I ll try with foreigner gem and will go through rails guide. 1.)Actually i wanted to confirm whether rails has support for non-integer primary_key? 2.)Can default naming convention of primary_key in a model (modelname_id) can be overridden? 3.)Can we use Composite_keys in Rails?
Thank you Walter and Colin for giving such a good idea. I ll try with foreigner gem and will go through rails guide. 1.)Actually i wanted to confirm whether rails has support for non-integer primary_key?
It can be done, but don't do it unless you have no choice. Google for rails legacy database to give pointers on how to do it. Particularly as a beginner you really don't want to get into this sort of complication unless you have a legacy database and cannot change the db layout.
2.)Can default naming convention of primary_key in a model (modelname_id) can be overridden?
Yes, but see above
3.)Can we use Composite_keys in Rails?
I am not sure about that one. I expect so. Rails does not prevent you doing anything, you just get less and less benefit from rails the more you stray from its conventions.
Colin
I highly recommend against composite keys. The composite gem breaks in every new rails version, and has broken edge cases.
Stick with an integer primary key, and an integer for foreign keys.
I wrote the foreigner gem. It expects that you are following the Rails conventions. It has no effect on your application’s logic, it simply prevents bad data from getting into the database. The primary feature of it is that it creates a correct schema.rb, which is essential for my testing.