API Platform version(s) affected: 4.3.5 (also present on 4.3 and main branches)
Description
When using the ObjectMapper (stateOptions + input DTO) on a Post operation, creating a new nested related entity fails with a foreign key constraint violation when the related entity uses an application-assigned identifier (e.g. a UUID generated in the constructor).
PersistProcessor::handleLazyObjectRelations() runs for every mapped operation ($operation->canMap()) and replaces any relation value that is not managed but has non-null identifiers with $manager->getReference($class, $identifiers):
// Do not get reference for partial objects or objects with null identifiers
if (!$identifiers || \count($identifiers) !== \count(array_filter($identifiers, static fn ($v) => null !== $v))) {
continue;
}
$reflectionProperty->setValue($data, $relManager->getReference($relClass, $identifiers));
This heuristic assumes "has an id" means "row exists in the database". That holds for #[ORM\GeneratedValue] entities (id is null pre-flush, so the swap is skipped and cascade: ['persist'] works — this is the case covered by the Issue7689 fixtures where Issue7689Category has a nullable auto-increment id). But with app-assigned ids (UUIDv4/v7 assigned in the constructor, a common pattern), a freshly mapped nested entity is indistinguishable from a reference to an existing one:
- The mapper creates a new related entity; its constructor assigns a UUID.
handleLazyObjectRelations() sees an unmanaged object with a non-null identifier and swaps it for a getReference() proxy.
- The proxy counts as managed, so
cascade: ['persist'] on the owning side never persists it.
- Flush inserts the owning entity with an FK pointing to a nonexistent row:
SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row:
a foreign key constraint fails (FOREIGN KEY ("condition_id") REFERENCES "..." ("id"))
How to reproduce
Entities (owning side cascades persist to the relation; both use constructor-assigned UUIDs):
#[ORM\Entity]
class TaskRule
{
public function __construct(
#[ORM\ManyToOne(targetEntity: TaskRuleCondition::class, cascade: ['persist'])]
#[ORM\JoinColumn(nullable: true)]
public ?TaskRuleCondition $condition = null,
#[ORM\Id, ORM\Column]
private(set) UuidV7 $id = new UuidV7(),
) {
}
}
#[ORM\Entity]
class TaskRuleCondition
{
public function __construct(
#[ORM\Column]
public string $completeWhen,
#[ORM\Id, ORM\Column]
private(set) UuidV7 $id = new UuidV7(),
) {
}
}
Input DTOs mapped with the ObjectMapper:
#[Map(target: TaskRule::class)]
final readonly class TaskRulePostInput
{
public function __construct(
public ?TaskRuleConditionInput $condition = null,
) {
}
}
POST with a nested condition payload -> FK violation on flush. Persisting the owning entity manually in a custom processor before PersistProcessor runs works around it, because the cascade marks the relation managed and handleLazyObjectRelations() then skips it via the contains() check.
Possible Solution
Only swap values that are genuinely placeholders for existing rows, instead of assuming any unmanaged object with an id is one:
- only replace actual uninitialized lazy objects (
ReflectionClass::isUninitializedLazyObject() on PHP >= 8.4), and/or
- consult
UnitOfWork::getEntityState($value) — STATE_NEW objects should be left alone so cascade persist can handle them.
Additional Context
API Platform version(s) affected: 4.3.5 (also present on
4.3andmainbranches)Description
When using the ObjectMapper (
stateOptions+ input DTO) on aPostoperation, creating a new nested related entity fails with a foreign key constraint violation when the related entity uses an application-assigned identifier (e.g. a UUID generated in the constructor).PersistProcessor::handleLazyObjectRelations()runs for every mapped operation ($operation->canMap()) and replaces any relation value that is not managed but has non-null identifiers with$manager->getReference($class, $identifiers):This heuristic assumes "has an id" means "row exists in the database". That holds for
#[ORM\GeneratedValue]entities (id is null pre-flush, so the swap is skipped andcascade: ['persist']works — this is the case covered by theIssue7689fixtures whereIssue7689Categoryhas a nullable auto-increment id). But with app-assigned ids (UUIDv4/v7 assigned in the constructor, a common pattern), a freshly mapped nested entity is indistinguishable from a reference to an existing one:handleLazyObjectRelations()sees an unmanaged object with a non-null identifier and swaps it for agetReference()proxy.cascade: ['persist']on the owning side never persists it.How to reproduce
Entities (owning side cascades persist to the relation; both use constructor-assigned UUIDs):
Input DTOs mapped with the ObjectMapper:
POSTwith a nestedconditionpayload -> FK violation on flush. Persisting the owning entity manually in a custom processor beforePersistProcessorruns works around it, because the cascade marks the relation managed andhandleLazyObjectRelations()then skips it via thecontains()check.Possible Solution
Only swap values that are genuinely placeholders for existing rows, instead of assuming any unmanaged object with an id is one:
ReflectionClass::isUninitializedLazyObject()on PHP >= 8.4), and/orUnitOfWork::getEntityState($value)—STATE_NEWobjects should be left alone so cascade persist can handle them.Additional Context