You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Yes, immutable-after-deletion is the intended behavior, though I get why it was surprising and unexpected.
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);.
Yes, better documentation would help; my apologies for not making it more obvious.
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) ?
This code will crash with
TokenRow::$account_id is immutable after Row is deleted
Is this the intended behavior?
Ps.
I found out will writing this issue that I can use
detachOneBy
instead ofgetOneBy
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
The text was updated successfully, but these errors were encountered: