fixForeignRecord crash on deleted Records

[sunkan]

This code will crash with TokenRow::$account_id is immutable after Row is deleted

$account = $mapper->fetchRecord(1, ['tokens']);

$token = $account->tokens->getOneBy(['type' => 'test']);

if (isValid($token)) {
    $atlas->delete($token);
}

$account->modified = date('c');
$atlas->update($account);

Is this the intended behavior?

Ps.
I found out will writing this issue that I can use detachOneBy instead of getOneBy but that's not always what you want.

Ps 2.
Also found the detachDeleted method.

We should probably update the documentation with a not about this behavior

[far-blue]

I think I'm getting the same issue with a different case.

I have a record A with a oneToOne relationship with record B.

If I fetch an instance of A and include the 'with' for record B and then later try to delete the instance of A, it appears to mark the instance of record B as deleted and then attempt to update the foreign key value from A onto the deleted instance of B.

I'm using non-primary key linking in the relationship between A and B using a uuid field.

I get the error B::$uuid is immutable after Row is deleted.

[far-blue]

Just to clarify, I'm using setDelete() and persist() rather then delete() on the instance of A.

[pmjones]

@sunkan

1. Yes, immutable-after-deletion is the intended behavior, though I get why it was surprising and unexpected.
2. Looking this over, it seems like detachOneBy() is the right thing to do in this particular case, followed by delete(). E.g., $token = $account->tokens->detachOneBy(...); $atlas->delete($token);.
3. Yes, better documentation would help; my apologies for not making it more obvious.

@far-blue

Deletion of one should not cause Atlas to infer the deletion of the other. I have tried replicating that behavior but have been unsuccessful. Are you still seeing the problem (yes, two years later, I know, sorry) ?