Change Details

This is a technical subticket of {T390611} ## Integration details This ticket creates a backwards-breaking change in the use case dependencies (`DonorIdRepository` added to `AddDonationUseCase` and `UpdateDonorUseCase`) and needs a major release and a manual update PR for the Fundraising Application after merging (you might wait until the donation bounded context is fully changed) ## Implementation Notes - Convert the donor, address and name interfaces to classes with properties (including an integer ID property). Keep the existing accessors. Create an abstract Donor base class. You may already add house number and street name to the postal address and change the `getStreetAddress` to return a concatenated value. The classes should be in the `Domain\Model\Donor\` namespace or one of its sub-namespaces. - Change `AddDonationUseCase::getPersonalInfoFromRequest`: use a `DonorIdRepository` interface (and a `DoctrineDonorIdRepository`) to generate new donor IDs. This is a backwards-breaking change in `AddDonationUseCase` Reuse the ID for address and name entities. - Create Doctrine mapping XML files for the new classes. You may keep them in the `config/DoctrineClassMapping` directory. - Don't use autogenerated IDs, we'll generate the IDs in code (reusing tghe donor ID for address and name) - Pay attention to the naming, it //must// match the namespace, the files should start with `WMDE.Fundraising.DonationContext.Domain.Model.` - Define the name and address entities as one-to-one unidirectional associations. They may have IDs - Add `persist` and `remove` to the name and address associations (see [Transitive persistence cascade](https://www.doctrine-project.org/projects/doctrine-orm/en/3.3/reference/working-with-associations.html#transitive-persistence-cascade-operations)) - Add a `donor` property to the existing Donation entity (in the `DoctrineEntities` namespace and the mapping). For maximum backwards compatibility (until we have migrated all the data, which is another ticket), make it nullable for now - Change the `DoctrineDonationRepository` When updating donations check the ID of the donors of the entity vs the domain object. if they don't match, it means that code has changed the donor type (e.g. through scrubbing or in the `UpdateDonor` use case). When you encounter this, you must delete the old entity. Ideally, calling `$oldDonation = $donationEntity->getDonor(); $donationEntity->setDonor($donation); $entityManager->persist($donationEntity); $entityManager->remove($oldDonation); $entityManager->flush();` should take care of all the steps and remove all the lingering dependent entities. - Change `UpdateDonorUseCase::updateDonor`: You need to create a new donor with a new id (use a `DonorIdRepository` interface (and a `DoctrineDonorIdRepository`)) - Change `DomainToLegacyConverter` to add the donor from the Donation (domain) to the (entity) donation. - Change `LegacyToDomainConverter` to read the Donor from the Donation entity and assign it to the Domain Donation. You can drop the `DonorFactory`. Make sure the `DoctrineDonationTest` still works. If tests fail, make sure that you change the test code only in places where they check low-level data. If the donor is null, return an anoymous `ScrubbedDonor` (mark this default as deprecated and to be removed when the data has been migrated) - Use a throwaway script or the debugger to observe database behavior (executed SQL) of `DoctrineDonationRepository::getDoctrineDonationById`. and the query behavior when you access the donor property of the entity. If the behavior shows that Doctrine lazy-loads the donor (multiple SQL statements), change the code of `getDoctrineDonationById` to use a DQL query that eagerly loads the donor data (see [Entity Object Graph Traversal documentation](https://www.doctrine-project.org/projects/doctrine-orm/en/3.3/reference/working-with-objects.html#entity-object-graph-traversal).

This is a technical subticket of {T390611} ## Integration details This ticket creates a backwards-breaking change in the use case dependencies (`DonorIdRepository` added to `AddDonationUseCase` and `UpdateDonorUseCase`) and needs a major release and a manual update PR for the Fundraising Application after merging (you might wait until the donation bounded context is fully changed) ## Implementation Notes - Change `Donation::scrubPersonalData` to receive a `ScrubbedDonor` instead of creating it inside the donation. You may move the donor creation to a static constructor in `ScrubbedDonor`. Change `DatabaseDonationAnonymizer` accordingly. This change is needed because in the next steps we'll need an ID when creating donors. - Create a `DonorIdRepository` interface (and a `DoctrineDonorIdRepository`) to generate new donor IDs. - Convert the donor, address and name interfaces to classes with properties (including an integer ID property). Keep the existing accessors. Create an abstract Donor base class. You may already add house number and street name to the postal address and change the `getStreetAddress` to return a concatenated value. The classes should be in the `Domain\Model\Donor\` namespace or one of its sub-namespaces. - Change `AddDonationUseCase::getPersonalInfoFromRequest`: use the `DonorIdRepository` (injected in the use case constructor) when generating new donors. This is a backwards-breaking change in `AddDonationUseCase`. Reuse the ID for address and name entities. - Create Doctrine mapping XML files for the new classes. You may keep them in the `config/DoctrineClassMapping` directory. - Don't use autogenerated IDs, we'll generate the IDs in code (reusing tghe donor ID for address and name) - Pay attention to the naming, it //must// match the namespace, the files should start with `WMDE.Fundraising.DonationContext.Domain.Model.` - Define the name and address entities as one-to-one unidirectional associations. They may have IDs - Add `persist` and `remove` to the name and address associations (see [Transitive persistence cascade](https://www.doctrine-project.org/projects/doctrine-orm/en/3.3/reference/working-with-associations.html#transitive-persistence-cascade-operations)) - Add a `donor` property to the existing Donation entity (in the `DoctrineEntities` namespace and the mapping). For maximum backwards compatibility (until we have migrated all the data, which is another ticket), make it nullable for now - Change the `DoctrineDonationRepository` When updating donations check the ID of the donors of the entity vs the domain object. if they don't match, it means that code has changed the donor type (e.g. through scrubbing or in the `UpdateDonor` use case). When you encounter this, you must delete the old entity. Ideally, calling `$oldDonation = $donationEntity->getDonor(); $donationEntity->setDonor($donation); $entityManager->persist($donationEntity); $entityManager->remove($oldDonation); $entityManager->flush();` should take care of all the steps and remove all the lingering dependent entities. - Change `UpdateDonorUseCase::updateDonor`: You need to create a new donor with a new id (use a `DonorIdRepository` interface (and a `DoctrineDonorIdRepository`)). Reuse the ID for address and name entities. - Change `DomainToLegacyConverter` to add the donor from the Donation (domain) to the (entity) donation. - Change `LegacyToDomainConverter` to read the Donor from the Donation entity and assign it to the Domain Donation. You can drop the `DonorFactory`. Make sure the `DoctrineDonationTest` still works. If tests fail, make sure that you change the test code only in places where they check low-level data. If the donor is null, return an anoymous `ScrubbedDonor` (mark this default as deprecated and to be removed when the data has been migrated) - Use a throwaway script or the debugger to observe database behavior (executed SQL) of `DoctrineDonationRepository::getDoctrineDonationById`. and the query behavior when you access the donor property of the entity. If the behavior shows that Doctrine lazy-loads the donor (multiple SQL statements), change the code of `getDoctrineDonationById` to use a DQL query that eagerly loads the donor data (see [Entity Object Graph Traversal documentation](https://www.doctrine-project.org/projects/doctrine-orm/en/3.3/reference/working-with-objects.html#entity-object-graph-traversal).

This is a technical subticket of {T390611} ## Integration details This ticket creates a backwards-breaking change in the use case dependencies (`DonorIdRepository` added to `AddDonationUseCase` and `UpdateDonorUseCase`) and needs a major release and a manual update PR for the Fundraising Application after merging (you might wait until the donation bounded context is fully changed) ## Implementation Notes - Convert the donor, address and name interfaces to classes with properties (including an integer ID property). Keep the existing accessorshange `Donation::scrubPersonalData` to receive a `ScrubbedDonor` instead of creating it inside the donation. Create an abstract Donor base classYou may move the donor creation to a static constructor in `ScrubbedDonor`. You may already add house number and street name to the postal address and change the `getStreetAddress` to return a concatenated valueChange `DatabaseDonationAnonymizer` accordingly. The classes should bThis change is needed because in the `Domain\Model\Donor\` namespace or one of its sub-namespacesnext steps we'll need an ID when creating donors. - Change `AddDonationUseCase::getPersonalInfoFromRequest`: use- Create a `DonorIdRepository` interface (and a `DoctrineDonorIdRepository`) to generate new donor IDs. - Convert the donor, address and name interfaces to classes with properties (including an integer ID property). Keep the existing accessors. Create an abstract Donor base class. You may already add house number and street name to the postal address and change the `getStreetAddress` to return a concatenated value. The classes should be in the `Domain\Model\Donor\` namespace or one of its sub-namespaces. - Change `AddDonationUseCase::getPersonalInfoFromRequest`: use the `DonorIdRepository` (injected in the use case constructor) when generating new donors. This is a backwards-breaking change in `AddDonationUseCase`. This is a backwards-breaking change in `AddDonationUseCase` Reuse the ID for address and name entities. - Create Doctrine mapping XML files for the new classes. You may keep them in the `config/DoctrineClassMapping` directory. - Don't use autogenerated IDs, we'll generate the IDs in code (reusing tghe donor ID for address and name) - Pay attention to the naming, it //must// match the namespace, the files should start with `WMDE.Fundraising.DonationContext.Domain.Model.` - Define the name and address entities as one-to-one unidirectional associations. They may have IDs - Add `persist` and `remove` to the name and address associations (see [Transitive persistence cascade](https://www.doctrine-project.org/projects/doctrine-orm/en/3.3/reference/working-with-associations.html#transitive-persistence-cascade-operations)) - Add a `donor` property to the existing Donation entity (in the `DoctrineEntities` namespace and the mapping). For maximum backwards compatibility (until we have migrated all the data, which is another ticket), make it nullable for now - Change the `DoctrineDonationRepository` When updating donations check the ID of the donors of the entity vs the domain object. if they don't match, it means that code has changed the donor type (e.g. through scrubbing or in the `UpdateDonor` use case). When you encounter this, you must delete the old entity. Ideally, calling `$oldDonation = $donationEntity->getDonor(); $donationEntity->setDonor($donation); $entityManager->persist($donationEntity); $entityManager->remove($oldDonation); $entityManager->flush();` should take care of all the steps and remove all the lingering dependent entities. - Change `UpdateDonorUseCase::updateDonor`: You need to create a new donor with a new id (use a `DonorIdRepository` interface (and a `DoctrineDonorIdRepository`)) . Reuse the ID for address and name entities. - Change `DomainToLegacyConverter` to add the donor from the Donation (domain) to the (entity) donation. - Change `LegacyToDomainConverter` to read the Donor from the Donation entity and assign it to the Domain Donation. You can drop the `DonorFactory`. Make sure the `DoctrineDonationTest` still works. If tests fail, make sure that you change the test code only in places where they check low-level data. If the donor is null, return an anoymous `ScrubbedDonor` (mark this default as deprecated and to be removed when the data has been migrated) - Use a throwaway script or the debugger to observe database behavior (executed SQL) of `DoctrineDonationRepository::getDoctrineDonationById`. and the query behavior when you access the donor property of the entity. If the behavior shows that Doctrine lazy-loads the donor (multiple SQL statements), change the code of `getDoctrineDonationById` to use a DQL query that eagerly loads the donor data (see [Entity Object Graph Traversal documentation](https://www.doctrine-project.org/projects/doctrine-orm/en/3.3/reference/working-with-objects.html#entity-object-graph-traversal).