[DDC-3391] RFC Allow adding extra metadata attributes Created: 13/Nov/14  Updated: 15/Feb/15

Status: Awaiting Feedback
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Minor
Reporter: Gonzalo Vilaseca Assignee: Marco Pivetta
Resolution: Unresolved Votes: 1
Labels: drivers, metadata


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?

Comment by Gonzalo Vilaseca [ 14/Nov/14 ]

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.

Comment by Christophe Coevoet [ 14/Nov/14 ]

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)

Comment by Gonzalo Vilaseca [ 14/Nov/14 ]

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 translable`` or ``Doctrine2 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.

Comment by Gonzalo Vilaseca [ 19/Nov/14 ]

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?

Comment by Marco Pivetta [ 19/Nov/14 ]

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.

Comment by MichaƂ Dobaczewski [ 15/Feb/15 ]

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.

[DDC-2164] Extend the cache support to eAccelerator Created: 23/Nov/12  Updated: 26/Nov/12

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4, 3.0
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Minor
Reporter: Enea Bette Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: cache, drivers


It would be nice if the Doctrine caching drivers would support the eAccelerator library.

Comment by Marco Pivetta [ 23/Nov/12 ]

Enea Bette eAccelerator is known for being stripping comments from cached source (making it impossible to use annotations)... Do you happen to know if this is fixed? Supporting it as cache driver is fine btw, I just wonder how many users will start thinking of using eAccelerator and then will be facing this huge limitation.

Comment by Enea Bette [ 26/Nov/12 ]

I know that eAccelerator has this issue. It would be nice if we could utilize it with XML, YML and PHP based mapping though.
Do you know if the same problem would appear with these kinds of mapping strategies?

To give response to your question (eAccelerator and annotations incompatibility), there is a pull request on github, https://github.com/eaccelerator/eaccelerator/issues/19 .

It seems that in the future these could be resolved, and at that time it would be very nice to have that supported with doctrine (symfony2 already has support for this library).

"I just wonder how many users will start thinking of using eAccelerator and then will be facing this huge limitation". Sometimes users just does not have a choice. Imagine the case when you have a hosted site that requires caching functionalities and the only available cache library is eAccelerator (as just in my case). You would be fried as a chicken hehe

Generated at Tue Jul 28 22:05:54 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.