This also happened with BETA1 and also in other scenarios, e.g.

SELECT w0_.id AS id0, w0_.createdAt AS createdAt1, w0_.updatedAt AS updatedAt2, w0_.start AS start3, w0_.end AS end4, w0_.owner_id AS owner_id5 FROM worklog w0_ INNER JOIN user u1_ ON e2_.owner_id = u1_.id WHERE u1_.id = ? AND w0_.start IS NULL

SQLSTATE[HY000]: General error: 1 no such column: e2_.owner_id

This may have to do with the "owner" field being defined in a mapped superclass.

Confirmed, when I move the declaration down to the implementation class the exception goes away.

When I add it rather then moving it, I get an exception saying the field was already added, so the declaration in the supertype is not simply omitted (not that that would explain the invalid SQL).

Generall,y mapped superclasses may only define unidirectional associations, because an association can not point back to a mapped superclass (a mapped superclass is not a persistent class). The relevant doc section is here: http://www.doctrine-project.org/projects/orm/2.0/docs/reference/inheritance-mapping/en#mapped-superclasses

Though, in your example the association actually points back to an entity, not the mapped superclass, so this may be a case that can be addressed properly, so we need to investigate this further.

ps: It is not entirely clear from the information you provided, but I assume there is no class that has targetEntity="NameOfMappedSuperclass" ? Because that will by definition never work.

No, there are no associations to the mapped superclass.

It is purely for defining common meta data and properties for a certain type, exactly what one would use a mapped superclass for.

It's worth noting that while this is a birectional association between the two types when viewed statically, we're not talking about a single, bidirectional relation:

• Calendar has an owner, which is a User. This is the user that created the object, a mechanism applicable to most entities in the system, hence the mapped superclass.
• A User has a Calendar, but he may or may not be the "owner" of that Calendar.

So User has this specified:

/**

• @ManyToOne(targetEntity=Calendar", fetch="EAGER", cascade= {"persist", "remove"}

  )

• @JoinColumn(name="calendar_id", referencedColumnName="id")
  *
• @var Calendar
  */
  private $calendar;

Obviously this means that a User also has an "owner", which may or may not be the object itself.

I think this might be fixed with DDC-671 already.

relating

I need the whole entitiy definitions of Calender and User. Can you please paste them to somewhere?

I cannot reproduce it, i am pretty sure its a duplicate of DDC-671 and should therefore be fixed already in trunk.

> I need the whole entitiy definitions of Calender and User. Can you please paste them to somewhere?

I have since chaned it, but I emailed you what I think are the relevant revisions of the classes.

I've had a similar issue with multiple levels of MappedSuperclasses. It works in RC1, fails in 2.0 stable on non-existent table aliases. Don't have time to do a full bug report right now.