mirror of
https://github.com/doctrine/orm.git
synced 2026-03-23 22:42:18 +01:00
DDC-3391: RFC Allow adding extra metadata attributes #4186
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @doctrinebot on GitHub (Nov 13, 2014).
Originally assigned to: @Ocramius on GitHub.
Jira issue originally created by user gvf:
What I'd like to propose is a way of having custom metadata in ClassMetadata.
So the current problem is this: I want to add custom tags to doctrine metadata files, and then get this tags on a loadClassMetadata listener in order to modify the mapping.
Currently the only workaround is parsing this custom tags in the loadClassMetadata listener, going through all the files again.
I was thinking of having a new 'extra' array field in ClassMetadata, every time a driver parses a configuration, throw a new event with the read configuration (being xml, yaml...etc.). A custom listener will parse it looking for the custom tags and return an array that will be added to the 'extra' array field in ClassMetadata.
Then, on the loadClassMetadata listener we retrieve this 'extra' configuration information, and modify the mapping as we want.
Does this make sense?
@doctrinebot commented on GitHub (Nov 14, 2014):
Comment created by gvf:
Ideally instead of the 'extra' array field, it would be nice to easily extend Metadata class so that the new values are filled in the new extended Metadata class.
@doctrinebot commented on GitHub (Nov 14, 2014):
Comment created by stof:
This would be even worse. If the recommended way for extensions is to extend the Doctrine Metadata object to add their field, it means you can only use 1 extension at a time (because you cannot use the extended class of both extensions at the same time for the same object).
This is why it is much better for other libraries to store their own metadata in their own object instead of trying to put it inside the Doctrine ones.
I'm not even sure putting custom tags inside the Doctrine mapping file is the best solution. It may be better to use a separate metadata file for the mapping of the other library (just like you use a different mapping file for the Symfony validation mapping even if it applies to the same class than the Doctrine mapping for instance)
@doctrinebot commented on GitHub (Nov 14, 2014):
Comment created by gvf:
You're right regarding the metadata.
As for the separate files, validation in Symfony is not doctrine specific, that's why it's in a separate file. If you have a look at some doctrine extensions like
Prezent translableorDoctrine2 behavioral extensions, the natural location for the custom tags are the Doctrine mapping files as they are specific to doctrine, by looking at just one file you see the whole picture.Yes, you could have your own mapping files, but then you would need to do some Symfony magic to be able to load them, and this is what would be nice to avoid.
I think of it as a way to easily extend doctrine mapping capabilities, in a 'plugin' way.
I'm currently working on a i18n bundle for Symfony, the tags I add in doctrine mapping files create associations between entities and their translations: I've had to create quite a few compiler passes for my current project to work as desired, and I see no way of abstracting this in a general way, it will need to be application specific. If I could hook into the Doctrine workflow and get those tags to populate my metadata class, that would be great, simple and reusable.
@doctrinebot commented on GitHub (Nov 19, 2014):
Comment created by gvf:
I've come out with another use case:
I need some custom metadata when the repository is instantiated, AFAIK there is no way of doing this right now, or is there?
@doctrinebot commented on GitHub (Nov 19, 2014):
Comment created by @ocramius:
You'd use a different metadata factory for that, specific to your use-case.
Mixing ORM mappings with the rest will just cause more coupling between the ORM and the userland use-case.
@doctrinebot commented on GitHub (Feb 15, 2015):
Comment created by mdobak:
As Gonzalo Vilaseca metioned without ability to set custom metadata attributes in ClassMetadata there is no proper way to obtain custom metadata in repository class. For example popular DoctrineDxtensions written by Gediminas Morkevicius obtain custom metadata by looping throught event subscribers (https://github.com/Atlantic18/DoctrineExtensions/blob/master/lib/Gedmo/Sortable/Entity/Repository/SortableRepository.php). By the way, shame that Doctrine has no API for extensions.
@maryo commented on GitHub (Mar 18, 2016):
I'd also welcome this and it is very easy to implement. Would PR for this feature be accepted? It is still open.
@Ocramius @stof
OFC there is a possibility to create own:
Not realy sure this is the best approach. Too much pain :) when sometimes all one needs is just to store a simple scalar value.
I think that just a
public $extraarray propery in ClassMetadata is still just a "one-way coupling". Coupling of the extension to Doctrine not vice-versa. When writing an ORM extension then it is coupled by nature.So.. Can I provide a PR? :)
@Ocramius commented on GitHub (Mar 18, 2016):
As I've mentioned before, the approach that you detailed as following is the correct one, even if painful:
Do not mix your own concerns with the ORM's concerns: it leads to nothing but painful BC issues. The ORM is not supposed to deal with problems outside its own scope (persistence).
@maryo commented on GitHub (Mar 18, 2016):
Well...OK. Thanks for reply then :)