Currently, if we are writing an explicit foreign key, it is assumed that we're writing to a composite table:

User
    name String
    email String
    
    Primary name email

Post
    userName String
    userEmail String
   
    Foreign User fkpostuser userName userEmail

This also works (somewhat by accident) using a custom singleton primary key:

User
    name String

    Primary name

Post
    user UserId
    Foreign User fkpostuser user

However, we can't do this with an automatically generated primary key.

User
    name String

Post
    user UserId
    Foreign User fkpostuser user

This restriction is artificial. It shouldn't really matter since writing UserId should cause the relevant migrations to generate foreign keys anyway, but as #1113 surfaced (and #1118 can solve) the only way to write a FieldCascade is on an explicit foreign key.

From #1113:

We should be able to define explicit Foreign declarations to tables that lack an explicit primary key. Database.Persist.Quasi.takeForeign is where this gets parsed out. "no explicit primary key" is found in fixForeignKey. If we get Nothing back from entityPrimaryKey, then we have an automatically generated ID. This means we want to check for the field name being id and generate a reference to the entityId field.