Inheritance for lifecycle callbacks about phpcr-odm HOT 11 CLOSED

due to how reflection works, we also see inherited methods when reflecting on Bar. the annotations parser should only load annotations for the actual class, not for its parents. the mapping information from parents comes from parsing their mapping. (otherwise things would never work for xml / yaml mapping)

are you sure that both Foo and Bar are mapped classes? as Foo is abstract, it can't be a @PHPCR\Document but it should be a @PHPCR\MappedSuperclass. mapping is only taken from ancestor classes as long as they are documents or mappedsuperclass - see also https://www.doctrine-project.org/projects/doctrine-phpcr-odm/en/latest/reference/inheritance-mapping.html

from phpcr-odm.

Thank you for your explanation.

I had already tried the @PHPCR\MappedSuperclass annotation. Unfortunately it doesn't work for me.

Because there is a working test case (https://github.com/doctrine/phpcr-odm/blob/f2345d0182c15d9ed0434f0172384c7d6bfe38ae/tests/Doctrine/Tests/ODM/PHPCR/Functional/Mapping/AnnotationMappingTest.php), the cause must be related with my local installation.

from phpcr-odm.

are you sure that there is no class between Bar and Foo in the inheritance? as soon as there is a non-mapped class, doctrine stops going to anchestors.

you could also experiment with making Foo a concrete class and map it as document and check if it does have the callback and Bar still does not have the callbacks.

from phpcr-odm.

Found it! I had placed the abstract class Foo outside a Document folder. Damn.

from phpcr-odm.

ah, alright that won't work then as its not seen as mapped. it could make sense to add a check about the parent class that when its not mapped check if it does have any of our annotations and if so output a warning... that should probably a general doctrine feature - not sure if the orm does it already. but can we close this issue, is the problem fixed for you?

from phpcr-odm.

There is a side effect of placing the abstract class Foo in a Document folder (tested with phpcr-odm version 1.3.2):

/** @PHPCR\MappedSuperclass */
abstract class Foo {
  /** @PHPCR\Id(strategy="parent") */
  public $jcrPath;
}

/** @PHPCR\Document */
class Bar extends Foo {
  /** @PHPCR\Id(strategy="auto") */
  public $jcrPath;
}

$document = new Bar;
$documentManager->persist($document);

This code is throwing an exception: Property 'jcrPath' in 'Bar' is declared twice.

Background: I'm trying to write a generic (schema driven) document CRUD class for nested data. A web application send the document type, the operation (read, create, update, delete ...) and the data to the server.

In the majority of cases, the CRUD class on the server should then perform the desired operation alone with the information from the schema.

If I need a new document type, all I have to do is to write the schema and take care of any special cases. So I don't have to write read, create, update and delete methods every time.

So I try to move as many common properties (with sane standards) as possible into the abstract document class (including the @PHPCR\Id property).

Apart from that, you can close this issue.

from phpcr-odm.

hm, i thought it would be possible to overwrite how a field is mapped in a child class. we (probably not on purpose) test that in https://github.com/doctrine/phpcr-odm/blob/master/tests/Doctrine/Tests/Models/Versioning/ExtendedVersionableArticle.php where author is also defined in FullVersionableArticle.

is the error triggered because this is an id versus a normal field? or because the configuration is conflicting?

from phpcr-odm.

I have it seen on special fields only (Id, Nodename). The field configuration doesn't matter.

from phpcr-odm.

ah okay. then maybe this is indeed a legacy from the orm. with tables, it makes little sense to overwrite ids. it makes a tad more sense in phpcr, but i am not sure its a good idea from the OO perspective. would it make sense to make your generator not generate IDs on abstract classes?

from phpcr-odm.

No problem. It is not a big deal to remove the Id property from the abstract class and instead define it in the derived classes to avoid throwing the exception.

from phpcr-odm.

okay, cool! i close this issue, but feel free to open new issues if something new pops up

from phpcr-odm.