Thanks for your answer Benjamin! your change indeed solved the problem But the file wasn't JoinedEntityPersister (it doesn't exist at least in the latest doctrine copy from "git://github.com/doctrine/doctrine2.git doctrine"). It was on the file BasicEntityPersister.php, located in the same dir you mention.
About my model, I didn't show the entire model because it didn't make sense for this issue. But one reason I have for this hierarchy is that I have lots of models that need to be related with all the instances of my model "Entity". For instance, all Users, Contacts, Leads, Customers and Suppliers need to have Activities, and I need to provide a way to select one between all these models when you, for example, create an Activity. Then I have a model "Opportunity" that needs to be associated only with BusinessPartner's. And, lastly, I have a couple of models that need to be associated with all my "Element"s. BaseElement is a mapped superclass that has only the basic fields for ALL my models (related to Element or not), that have in common all the entities in my model (don't confuse with the model "Entity". Yes, it's a little bit confuse but I couldn't think in another name to relate People and Business Partners ).
The other point: People can't be a customer or a lead. My requirements say that only business partners can be customers, leads or suppliers. Business partners are companies. They can't be individuals. Business partners can have contacts. And if a user needs to "transform" a lead to a customer, it can create a customer from a lead, and have a reference back to it. I thought I need them to have them separated because this won't be only a CRM. It's going to be a sales system too (I don't know if this is the correct english term for this type of system), so I need to have them in two different entities for a couple of reasons. If I only have a status that describes a customer or a lead, I can't, for example, enforce some business rules at database level I'll have (in a DB portable way at least that I know of). I need to enforce, if it's possible and portable, this type of business rules because there will be other apps that will interact with my DB. For instance, if I need to associate an invoice to a lead_or_customer, how can I enforce this on the DB if I only have a status field that determines if it's a lead or a contact? Separating the entities is the only way I could think of to solve this type of problems. Maybe is not the best way. I'll need to rethink the trade-offs of this decision. Thanks for pointing this out
For now it's a CRM. But it's only the beginning. It will have lots of additional models when I'll add modules for a sales system, voIP vinculation, etc. That's why I tried to make a reusable tree on my model. I know the performance risks having too many entities related to each other, having lots of joins and one table in common that will be always touched could be a bottleneck if there are lots of users doing lots of operations. But I'm in the hurry and I need to save development time. I'm the only person that will work on this app, and I have only 6 months from scratch to finish the CRM, which is a really big app in very little time for me (having to work on a pretty big ACL module and a Workflow module too). Inheritance gave me a DRY way in lots of aspects of my app. I can sacrifice some performance to save development time. Then I can optimize if I need it
THANKS A LOT for your fix and for quickly look this issue! and for your comments too. I'm not an expert yet and constructive comments like these help me to rethink some points on my decisions.