We are working on a symfony/doctrine project and have come to a near halt on development.

We feel that now, it may be a bug/feature in doctrine, regarding foreign keys

Part of our model includes a join table that references three different table. Below is a diagram of what the model looks like, and the relevant portion of our schema.yml is at the bottom.

Image of our schema: http://imgur.com/dfFYI.png

We have a form that contains a set of embedded forms that attempt to create a new Person entry and add rows to the join table, adding items to the PersonName table as needed.

The form attempts to do this by creating and saving PersonName objects with NameType parameters, but are running into the problem of Doctrine not including that column when trying to do an insert into the join table.

Part of the problem seems to be caused by the Doctrine_Connection_UnitOfWork::saveAssociations method:

foreach ($v->getInsertDiff() as $r)

Are we correct in understanding that this means that Doctrine 1.2 does not support tables with multiple foreign keys in this scenario?

Here is the relevant portion of schema.yml:

agPerson:
columns:
id:
primary: true
type: integer(5)
autoincrement: true
relations:
agPersonName:
class: agPersonName
refClass: agPersonMjAgPersonName
local: person_id
foreign: person_name_id
agPersonNameType:
class: agPersonNameType
refClass: agPersonMjAgPersonName
local: person_id
foreign: person_name_type_id
agPersonNameType:
columns:
id:
primary: true
type: integer(2)
autoincrement: true
person_name_type:
unique: true
type: string(30)
notnull: true
app_display:
default: 1
type: boolean
notnull: true
relations:
agPerson:
class: agPerson
refClass: agPersonMjAgPersonName
local: person_name_type_id
foreign: person_id
agPersonName:
class: agPersonName
refClass: agPersonMjAgPersonName
local: person_name_type_id
foreign: person_name_id
agPersonName:
columns:
id:
primary: true
type: integer(5)
autoincrement: true
person_name:
unique: true
type: string(64)
notnull: true
relations:
agPerson:
class: agPerson
refClass: agPersonMjAgPersonName
local: person_name_id
foreign: person_id
agPersonNameType:
class: agPersonNameType
refClass: agPersonMjAgPersonName
local: person_name_id
foreign: person_name_type_id
agPersonMjAgPersonName:
columns:
id:
primary: true
type: integer(5)
autoincrement: true
person_id:
type: integer(5)
notnull: true
person_name_id:
type: integer(5)
notnull: true
person_name_type_id:
type: integer(2)
notnull: true
is_primary:
type: boolean
notnull: true
indexes:
UX_ag_person_mj_ag_person_name:
fields: [person_name_id, person_name_type_id, person_id]
type: unique
relations:
agPerson:
local: person_id
foreign: id
agPersonName:
local: person_name_id
foreign: id
agPersonNameType:
local: person_name_type_id
foreign: id
actAs:
Timestampable:

As a caveat: we've noticed that sfdoctrineguard group table, has such a relationship:

mysql> describe sf_guard_user_group;
---------------------------------------+

---------------------------------------+

---------------------------------------+

i.e. IT has two foreign keys taken into account

When using pessimistic locking as described in:

http://www.doctrine-project.org/projects/orm/1.2/docs/manual/component-overview:locking-manager:examples/zh

the locking manager locks the entire table rather than the specific object.

This should be clear from the attached patch which corrects the issue (assuming I have correctly interpreted the intention of pessimistic locking!).

The current behavior will have worked as expected for users but it will have locked far more than was intended and may thus have affected performance.

NB: I can confirm this works for non-composite keys but please review and test for composite keys as I have no such tables to hand.

The example from the documentation on savepoints:

 
try {
    $conn->beginTransaction();
    // do some operations here 

    // creates a new savepoint called mysavepoint
    $conn->beginTransaction('mysavepoint');
    try {
        // do some operations here

        $conn->commit('mysavepoint');
    } catch(Exception $e) {
        $conn->rollback('mysavepoint'); # (a)
    }
    $conn->commit();
} catch(Exception $e) {
    $conn->rollback();
}

What seems to be a bug to me: (a) doesn't actually do a savepoint-rollback if reached, but rather returns false as soon as the nesting level is seen to be > 1.