I don't mean to be a jerk, but I'm going to be. You haven't done your homework, and are blaming sequel for your misunderstandings about databases.
In mysql (as with most databases) a foreign key is actually a constraint on a column. It is not necessarily integer in nature, but most people do it with integers, because they are referencing unique- id based columns in other tables. Sequel's handling of foreign keys is accurate. http://dev.mysql.com/doc/refman/5.1/en/innodb-foreign-key-constraints.html If you read down to the examples, you'll see how there is a column (in at least several examples) of type integer, which has the foreign key constraint on it. The reason ruby-sequel makes it an integer column by default (as opposed to say, a char, since there is *no* foreign key column-type in mysql or any other DB I've used), is because the most common use of foreign keys is on integer columns. What you missed seeing with Sequel creating the integer column is the constraints it added on it. Sequel even has parameters for doing the cascade on delete for the foreign keys, if you wish to use sequel to construct your DB: DB.create_table :sections do # ... other necessary stuff. foreign_key :course_id, :courses, :on_delete => :cascade end -Joe On Jan 26, 2009, at 4:27 PM, Victor 'Zverok' Shepelev wrote: > > From: [email protected] [mailto:[email protected] > ] On > Behalf Of [email protected] >> Sent: Tuesday, January 27, 2009 12:04 AM >> To: [email protected] >> Subject: Re: Cascade delete >> >> >> Victor: have you considered doing this at the db level? I've found >> that >> when done through ON DELETE CASCADE references in postgres these >> types of >> referential deletes are much faster that doing them in ruby (or any >> middleware). >> > > I've thought about it, but AFAIK Sequel (which is my primary DB > interface) > provides no good means for working with foreighn_keys either (at > least, on > MySQL, "foreighn_key" column definition just defines INTEGER NOT NULL > field). Therefore, I'd be happy to remain on "just Sequel" with all > those > tasks. In any case "delete all associated also" seems to useful > behavior for > models. > > V. > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sequel-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/sequel-talk?hl=en -~----------~----~----~----~------~----~------~--~---
