Hi, In "Agilge Web D. With Rails" on page 217, an example of foreign keys is shown. I am however unable to find a definition of wheater the naming of the index is significant. On the above mentioned page, this line is shown in the example: constraint fk_items_product foreign key (product_id) references products(id) In "fk_items_product", "items" is pluralized but "product" is not. Is this because it is a one_to_many relationship? If so, how should I read this statement? Does it matter to Rails what the index is called? Thanks, Jakob
on 2006-01-05 20:30
on 2006-01-05 23:11
Hi, Please - somebody must know the answer to this one. Jakob Jakob R. wrote: > Hi, > > In "Agilge Web D. With Rails" on page 217, an example of > foreign keys is shown. > > I am however unable to find a definition of wheater the naming of the > index is significant. On the above mentioned page, this line is shown in > the example: > > constraint fk_items_product foreign key (product_id) references > products(id) > > In "fk_items_product", "items" is pluralized but "product" is not. Is > this because it is a one_to_many relationship? If so, how should I read > this statement? Does it matter to Rails what the index is called? > > Thanks, > > Jakob
on 2006-01-05 23:24
On Jan 5, 2006, at 4:11 PM, Jakob R. wrote: >> the example: >> >> constraint fk_items_product foreign key (product_id) references >> products(id) >> >> In "fk_items_product", "items" is pluralized but "product" is not. Is >> this because it is a one_to_many relationship? If so, how should I >> read >> this statement? Does it matter to Rails what the index is called? I don't believe the name of the index is significant, as I don't believe it's ever referenced in Rails generated DML. As far as how to read it, it reads to me as though it's a foreign key connecting one or more items to a single product, via: items.product_id -> products.id Seems pretty coherent. -- -- Tom M.
on 2006-01-05 23:24
Rails doesn't care. You tell it your relationships in the model files, ie item.rb and product.rb ,using the has_many, has_one, belongs_to relationship. If you read more of that chapter, and I think before what you posted, it mentions that RoR can't really derive the relationship and it provides an example why it would be difficult. Also, have you tried any examples using differently named foreign keys to see if it breaks anything? - Nic. On 1/5/06, Jakob R. <firstname.lastname@example.org> wrote: > products(id) > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > email@example.com > http://lists.rubyonrails.org/mailman/listinfo/rails > -- - Nic
on 2006-01-05 23:24
Jakob R. schrieb: > Hi, > > Please - somebody must know the answer to this one. > > Jakob > According to the documentation (http://wiki.rubyonrails.com/rails/pages/NamingConventions) it is - and I quote: When joining two tables, the foreign ID must be in the format: [tablename]_id. Where tablename is the singular form of the tablename.
on 2006-01-05 23:33
Nic, I have the agile webdev book, and I didn't find it. So what your saying is that the foreign key constraint is NOT a necessity? (as long as your coding is good enough ofcourse .. :-) Regards, Gerard. On Thursday 05 January 2006 22:23, Nic W. tried to type something like: > to see if it breaks anything? > > index is significant. On the above mentioned page, this line is shown in > > > - Nic > _______________________________________________ > Rails mailing list > firstname.lastname@example.org > http://lists.rubyonrails.org/mailman/listinfo/rails -- "Who cares if it doesn't do anything? It was made with our new Triple-Iso-Bifurcated-Krypton-Gate-MOS process ..." My $Grtz =~ Gerard; ~ :wq!
on 2006-01-05 23:39
Naming of indexes should never make any difference to SQL, however it's generated (by Rails, by Hibernate, by human fingers). It's the SQL optimizer's job to figure out what index to use, not the SQL programmer's. You could number your indices from FK_1 to FK_100000, and it wouldn't make a difference to any of your SQL. I've worked places that did indeed do that, at least per table. The name of the index is only important in DDL - creating , or otherwise managing it - it never appears in DML. So worry not. Skott Klebe
on 2006-01-05 23:45
Hi all, Thanks for your answers. I conclude: anything in the database concerning foreign keys are only used by the database to ensure integrety. It has no bearing to RoR what so ever. Right? Jakob
on 2006-01-06 00:30
On Jan 5, 2006, at 4:45 PM, Jakob R. wrote: > I conclude: anything in the database concerning foreign keys are only > used by the database to ensure integrety. No, that's not what was said. Your question in your original post was answered, not the gigantic generalization offered above. :-) column names for both primary and foreigns key columns do matter so the answer to the generalized questions above are: > It has no bearing to RoR what so ever. No! and: > Right? Wrong! It's the naming of the foreign key constraint that does not matter. -- -- Tom M.
on 2006-01-06 01:40
Sorry, I think I misunderstood your question. Take a look at Active Web D. with Rails, pg226. "It's worth noting that it isn't the foreign key contraints that set up the relationships..." and goes on from there, a good 3-4 paragraphs on on the topic. In short, what's significant is column naming. Rails expects that the name of a column that's a foreign key reference to 'ADDRESSES' will be named 'ADDRESS_ID' _by default_. >From the doc: http://api.rubyonrails.com/classes/ActiveRecord/As... ":foreign_key - specify the foreign key used for the association. By default this is guessed to be the name of the associated class in lower-case and "_id" suffixed. So a Person class that makes a belongs_to<http://api.rubyonrails.com/classes/ActiveRecord/As... to a Boss class will use "boss_id" as the default foreign_key." Table naming and column naming, important. Index or constraint naming, ignored. Hope this settles it for you. SK
on 2006-01-06 19:21
Yes, as long as no one is going into the database through some other tool (Access) to modify data. Setting up referential integrity in the database provides some measure of data integrity at the lowest level. Even if you're the DBA working on the data from vendor tools to modify data by hand that an app messed up, declared referential integrity can quite possibly keep you from accidentally sawing off your leg with a bad INSERT INTO, UPDATE or DELETE query... Having to go through a database (in the most generic sense of the term, like in a flat-file database system, Excel, etc) to look for orphaned child items is pretty dull and boring work that should be prevented at the lowest levels if possible. Relying on it solely in the application layer is...full of a little too much developer hubris, imho.
on 2006-01-06 19:27
But this has to do with the naming of intended foreign key fields by convention (overridable with the :foreign_key attribute). As far as any relationships set up in the database, Rails doesn't know about them. In that sense, they're optional, but for most DBAs, they're necessarily required for a variety of reasons, even if they're not explicitly required in or used by an application framework like Rails.
on 2006-01-06 19:33
:foreign_key lets you override the _expected_ relationship field name. If you're working with a legacy database (i.e., one not set up wtih Rails conventions), this is an important feature to be able to do this. Table naming and column naming according to Rails conventions is very nice, but not necesarily important in all cases. Being able to ultimately specify things *IS* important (i.e., :foreign_key). Index names are used by the database. While not obviously important to the Rails developer, some databases return the name of the index or constraint, and having meaningful names here makes it far easier to get to the source of the problems rather than decoding what "constraint system_005AF32 violated" actually refers to, because they can get returned back into the Rails app by the database...
on 2006-01-07 01:33
> I conclude: anything in the database concerning foreign keys are only > used by the database to ensure integrety. It has no bearing to RoR what > so ever. > > Right? Right. Rails ignores fk contraints, primarily because DHH considers them to be "vile and reckless destroyers of coherence". fk constraints exist only to assist the paranoid (I myself am amongst their number). The naming doesn't matter to Rails, since it ignores the whole constraint. It also doesn't really matter to the db, it's just documentation. For more on why rails uses the associations stuff in your models instead of db constraints (and why I had to write a plugin to get fk constraints into ActiveRecord migrations) see the DHH blog post here: http://www.loudthinking.com/arc/000516.html A.