No, I couldn't make this work so I took a slightly different approach. What I wanted to do was to have a bundle with all my custom user functionalities (login, auth, password recovery, etc). Something like the FOSUserBundle. That's why I needed to decouple the user from the rest of the code.
What I ended up doing was using doctrine inheritance. So, in my base bundle (that's what I call this custom bundle), I have a BaseUser which is of type "mappedSuperclass". I also have the same for a profile class and a company class. Of course, a user belongs to a company and has a profile, so I needed to setup the relationships. The trick for me was not setting them up in the base bundle, but on my project bundle (whatever project that uses the base bundle). I create mapped classes for the user, profile and company, and set up the relationships on those classes. This way, I have all the functionalities of the base bundle (managed by composer) in every project I work in. One note though. There were some classes inside the base bundle that needed relationships to the user, but didn't have to be exposed. One example was a UserKeys class that has keys to allow the user to do stuff without been logged in (like recover password). The user keys class DOES have a relationship (many-to-one) with the user. Here I did use resolver target entity listener. The relationship in the UserKeys class is set up agains a user interface (because the base bundle doesn't "see" the project bundle). This work's fine. Hope this helps. El domingo, 14 de diciembre de 2014 07:28:24 UTC-3, Alex Li Si Cin escribió: > > Hi. > > Did you manage to solve that situation? > > понедельник, 30 декабря 2013 г., 17:39:41 UTC+2 пользователь Matías Castro > написал: >> >> Hi guys, I'm trying to implement this example >> <http://docs.doctrine-project.org/en/latest/cookbook/resolve-target-entity-listener.html> >> >> taken from doctrine2 docs (using symfony2 explained here >> <http://symfony.com/doc/current/cookbook/doctrine/resolve_target_entity.html>, >> >> both are the same). >> >> I'm doing everything exactly as described but I get a: >> >> [Doctrine\DBAL\Schema\SchemaException] >>> The table with name 'example.customer' already exists. >> >> >> In my implementation, the class Acme\CustomerModule\Entity\Customer is a >> mapped entity, same as Acme\AppModule\Entity\Customer (which is the source >> of the problem I think). There is no example for this class on the docs, so >> I'm assuming that this is correct, since the docs explicitly say: >> >> With the ResolveTargetEntityListener, we are able to decouple our >>> bundles, keeping them usable by themselves, but still being able to define >>> relationships between different objects >> >> >> So, the only way for the CustomerModule to work by it's own, is >> that Acme\CustomerModule\Entity\Customer is a mapped entity. >> >> Has anyone implemented something like this so I can take a look? Thanks a >> lot! >> > -- You received this message because you are subscribed to the Google Groups "doctrine-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/doctrine-user. For more options, visit https://groups.google.com/d/optout.
