Decouple UnitOfWork from Hydrators #2641
Conversation
| * | ||
| * @psalm-return class-string | ||
| */ | ||
| public function getClassNameForAssociation(array $mapping, $data): string |
There was a problem hiding this comment.
I'm not a fan of expanding DM's public surface but I'm not sure where else this could go... definitely not into generated hydrators as maintaining that will be PITA, ClassMetadataFactory is a no-go because of interface.
So just a food for thought, no other concerns from my end 👌
There was a problem hiding this comment.
Yeah, I moved it over because it doesn't need to be in there - ideally we'd have some kind of metadata construct that allows us to get this information. Either way, I'm saving that for a future refactoring of metadata (which I don't want to tackle)
|
Are the failing shared cluster tests somehow relevant to this PR? |
Nope, they have been failing for a while now and I haven't had a chance to dig into it and figure out what's causing them. |
Summary
Hydrators currently get the
UnitOfWorkinjected directly. This leads to a circular dependency, as theDocumentManagerneeds aHydratorFactory, but theHydratorFactoryneeds aUnitOfWorkinstance which can't exist without aDocumentManager. To resolve this,HydratorFactoryno longer takes aUnitOfWorkinstance, and generated hydrators instead take theUnitOfWorkinstance exposed by the document manager.This PR also moves a method from
UnitOfWorkto theDocumentManageras it's not tied toUnitOfWork.Note that this PR is only the first of a few refactorings necessary to properly decouple things from
UnitOfWork, with the goal of havingUnitOfWorkrepresent a single set of persistable document changes. Removing the circular dependency also allows us to make hydrator factories configurable, which is important to leverage the new codec infrastructure in the PHP driver and thus speed up a lot of hydration operations.