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
{{ message }}
This repository has been archived by the owner on Feb 5, 2024. It is now read-only.
The method UnitOfWork ->assertValidDocumentType will fail, as currently all references are handled by the PersistentViewCollection, not only those matching the targetDocument.
I would suggest the view is extended to provide the type of the referenced document in the key and the related objects are fetched using the the target document in the key filter.
Alternatively the createDocument could be wrapped by a try/catch to filter invalid document type failures.
Best regards,
Sven
The text was updated successfully, but these errors were encountered:
Now we add another entity class referencing the customer, with or without extending the customer doesn't matter:
namespaceEntity;
useDoctrine\ODM\CouchDB\Mapping\AnnotationsasCouchDB;
useDoctrine\Common\Collections\ArrayCollection;
class Order {
/** * @CouchDB\Id */protected$id;
/** * @CouchDB\Index * @CouchDB\ReferenceOne(targetDocument="Customer") */protected$customer;
}
Now, when trying to load the campaigns of the customer, it will fail with this InvalidDocumentTypeException: "The class 'Entity\Order' is not of the expected type 'Entity\Campaign".
My first solution thoughts do not resolve this issue. The only chance I currently see is extending the ReferenceOne annotation with a mappedFor attribute as a counterpart to the mappedBy to allow a mapping per field, not document type. With this, the setup would look as follows:
The associations in the campaign and order would have to be an object (instead of array) to map the entity attribute to a different inverse_associations key (resulting in the key ["customer-1", "campaignCustomer", "campaign-1"]).
Last comment for today: My workaround is to use unique (prefixed) fieldnames in the dependent documents (campaignCustomer and orderCustomer in the above example) with an according mappedBy attribute.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The method UnitOfWork ->assertValidDocumentType will fail, as currently all references are handled by the PersistentViewCollection, not only those matching the targetDocument.
I would suggest the view is extended to provide the type of the referenced document in the key and the related objects are fetched using the the target document in the key filter.
Alternatively the createDocument could be wrapped by a try/catch to filter invalid document type failures.
Best regards,
Sven
The text was updated successfully, but these errors were encountered: