As #111011: Add foreign keys to core ended with just adding “foreign keys” as a documentation feature (and not actual foreign keys in the database), I would like to suggest actually implementing these in core.

A simple query like "ALTER TABLE dns_zones ADD FOREIGN KEY (user_id) REFERENCES users (uid) ON DELETE CASCADE;" works on both PostgreSQL and MySQL, and since we now in Drupal 7 have InnoDB as the default database engine (and ditto for MySQL 5.5), this should be almost universally supported.

Comments

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented
Version: 7.x-dev » 8.x-dev

Maybe so, but not in 7. :)

JacobSingh’s picture

JacobSingh commented

Heh, I had the same gripe. It really makes it worse not better. If they are there for documentation, it should look like doc, not like code.

yched’s picture

yched commented

Last I heard, Ctools will rely on 'foreign keys' exposed by Field type schemas to automatically infer Panels-like 'relationships' from 'reference' style field types (file field, taxo field, nodereference field...). Maybe it's done already.

Meaning, FKs would be doc with an actual semantic impact.

colan’s picture

colan
he/him
Primary language English
Location Toronto 🇨🇦
commented
Status: Active » Closed (duplicate)

Marking as a duplicate of the older http://drupal.org/node/911352.

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented
Issue summary: View changes

I think this is more of a duplicate of https://www.drupal.org/project/drupal/issues/2254131 but I guess 911352 shifted it's nature since comment #4.

colan’s picture

colan
he/him
Primary language English
Location Toronto 🇨🇦
commented
Related issues: +#911352: Document that foreign keys may not be used by all drivers, +#2254131: DBTNG should be able to create foreign keys

Since we're updating very old issues...