Annotations from Traits are ignored

[josefsabl]

Bug Report

Q	A
BC Break	formally yes, but practically no :)
Version	1.2.5

Summary

We use traits to customize features for our Documents. It however looks like Doctrine ignores annotations from traits. Changing annotations for the class in trait doesn't have any effect.

Current behavior

ID's are native Mongo instead of autoincremental even if autoincrement is specified in the fields overloaded version in trait.

How to reproduce

Let's say we have our base document set up to have id.

/** @ODM\Document */
abstract class BaseDocument extends MappedSuperclass {
	/** @ODM\Id */
	public $id;
}

Then we set up concrete document like this:

/** @ODM\Document */
class UserDocument extends BaseDocument {
}

And we want have its id incremental instead of native Mongo id.

/** @ODM\Document */
class UserDocument extends BaseDocument {
	/** @ODM\Id(strategy="Increment") */
	public $id;
}

But we want to do it with trait. Because this behaviour is repeated in other documents.

trait TIncrementalID {
	/** @ODM\Id(strategy="Increment") */
	public $id;
}

/** @ODM\Document */
class UserDocument extends BaseDocument {
	use TIncrementalID;
}

And this does not work and trait is ignored whatsoever. We also cannot implement abstract class because the autoincremental documents need to extend other classes. E.g. we have several classes of users, some of them need to be autoincremental some not.

Expected behavior

ID of class should be autoincremental when this is specified in trait.

[malarzm]

@josefsabl thanks for the report! I think that traits are working just fine (we were using similar approach quite extensively) what I think is broken is that you can't override identifier once it's set. Could you please verify this?

[malarzm]

Actually, it might be that you have a public $id in both BaseDocument and in TIncrementalID - I can't really say which definition will "win", but most probably not having an id in your BaseDocument will fix your issue.

[josefsabl]

Yes, I indeed have public $id in both base and trait. But in this case the trait should win :) PHP works like that at least. And it doesn't win in Doctrine.

I am not sure if you need me to test something now. If you do, just let me know.

Thanks for your time looking into this!

[malarzm]

But in this case the trait should win :) PHP works like that at least. And it doesn't win with Doctrine.

This doesn't seem to be true, check out this: https://3v4l.org/fcptj - the only way I can get comment from a trait is if I remove public $id from Obj class altogether.

I'm inclined to say it's not Doctrine's issue :)

[josefsabl]

Yes, regarding the reflection this is true. This however isn't :)

the only way I can get comment from a trait is if I remove public $id from Obj class altogether.

https://3v4l.org/Zd8M1. Although I think it is not that relevant.

What I actually had in mind is the general behavior of traits. It is hard to display for properties as they are quite straightforward and there is not much you can do with them so this feels irrelevant. Until you start to do magic with them (e.g. annotations).

This is closer to what I had in mind: https://3v4l.org/kSgjg

The point is that if something in the class is declared in the parent class as well as in trait. The trait version wins :-)

The complete example is here: https://3v4l.org/R0GbP

Yet this pattern is not followed by Doctrine:

https://3v4l.org/AS7d2
https://3v4l.org/MJQiY

PS: I understand this problem may be considered ambiguous. There actually are pieces missing in PHP's traits implementation (see this "bug" https://bugs.php.net/bug.php?id=64963).

Thank you again :)

[malarzm]

https://3v4l.org/Zd8M1. Although I think it is not that relevant.

Sorry for thought short cut, it's obviously possible to get comment from a trait but then one must know that there's a trait which should actually take precedence. IIRC doctrine/annotations are using similar code to the one I had in my 3v4l therefore they do not know or care about traits, it just reads data available through reflection.

All in all, this all boils down to annotation and reading them thus there's nothing we can do within ODM to change the behaviour. Could you please submit an issue to https://github.com/doctrine/annotations as that's where the work needs to be done?