Reputation: 293
Is it possible to have a OneToManyAssociationField as entity extension on for example ProductManufacturer without the ReferenceVersionField in my related custom entity?
If this is not possible, is it possible for the reference version field to have a custom name (so not product_manufacturer_version_id) On first sight, this also does not seem possible.
About the error
I am currently getting the following error when trying to search for manufacturers using $criteria->addAssociation('myCustomEntity')
:
SQLSTATE[42S22]: Column not found: 1054 Unknown column 'product_manufacturer.myCustomEntity.product_manufacturer_version_id' in 'field list'
About the big picture
The use case is similar to the SeoUrl entity where there is a ‘foreign_key’ field which can have a relation to multiple entity types. My entity has not associations, but the other entities are extended to have an association to my entity. Just like the SeoUrl.
However, the DAL creates a query which uses the ‘product_manufacturer_version_id’ field, which does not exist on my custom entity…
Upvotes: 0
Views: 409
Reputation: 13161
Is it possible to have a OneToManyAssociationField as entity extension on for example ProductManufacturer without the ReferenceVersionField in my related custom entity?
No, you must set a ReferenceVersionField
when adding associations to the definition of a versionized entity. This is too deeply rooted in the basic principles of the data abstraction layer to work around.
If this is not possible, is it possible for the reference version field to have a custom name (so not product_manufacturer_version_id) On first sight, this also does not seem possible.
You can change the storage name of the field. That is the name of the corresponding column within your database table. When you instantiate ReferenceVersionField
you can use the second, optional argument to provide the storage name:
public function __construct(string $definition, ?string $storageName = null)
The storage name should be provided in snake case. The name of the object property for the field will then be derived from the storage name and converted to camel case. So given you provide my_version_custom_id
for the storage name, the object property of the entity will be myVersionCustomId
.
Your entity may have multiple associations to different entities, but if those entities are versionized your foreign key constraint has to be a combination of columns for both the foreign primary key as well as the foreign version id.
Upvotes: 2