Schema tool does not support STI - attempts to create a table per subclass

Guilherme Blanco added a comment - 12/Apr/10 9:08 PM - edited That seems to be a reserved keyword issues. I see comments around the STI issues, but this one doesn't seem to be the case. Try to use a different table name: @Table(name= "groups" ) and... @Table(name= "users" ) This should fix the issue. Cheers,

David Abdemoulaie added a comment - 12/Apr/10 9:52 PM No. This is a STI problem. I don't want two different tables. Users and Groups are meant to share the same table "user". This worked prior to the omega CLI changes.

Roman S. Borschel added a comment - 19/Apr/10 5:25 AM After thinking about this a while, I think it is an interesting problem that points out some conceptual issues as well as some opportunities. The reason SchemaTool behaves that way is simple, I think: A mapped superclass is nothing more than a regular php class that inherits its mapping information to the child classes "as if it were defined directly on the child classes". It is mainly a way to "reuse" mapping information without copy/paste. So the example given in the issue description is pretty much the same as this: abstract class Principal {} /** * @Entity * @InheritanceType( "SINGLE_TABLE" ) * @DiscriminatorColumn(name= "type" , type= "string" ) * @DiscriminatorMap({ "User" = "User" , "Group" = "Group" }) * @Table(name= "user" ) */ class Group extends Principal {} /** * @Entity * @InheritanceType( "SINGLE_TABLE" ) * @DiscriminatorColumn(name= "type" , type= "string" ) * @DiscriminatorMap({ "User" = "User" , "Group" = "Group" }) * @Table(name= "user" ) */ */ class User extends Principal {} Hence why it wants to create two tables. However, something else is also probably wrong because it should rather result in an error due to creating the same table twice ("user"). So deriving @Table from a mapped superclass seems to be uncharted territory also. How/Why this ever worked before as you say is still a mystery to me. Do you know by any chance a revision or tag (alpha4?) where this worked so that we can compare to that? As you already found out, making the parent class an @Entity should work fine. We need to think more about how to deal with inheritance mapping information derived from mapped superclasses. For example, what should happen if we take the original example in the issue description but use JOINED instead like this: /** * @MappedSuperclass * @InheritanceType( "JOINED" ) * @DiscriminatorColumn(name= "type" , type= "string" ) * @DiscriminatorMap({ "User" = "User" , "Group" = "Group" }) */ abstract class Principal {} /** * @Entity */ class Group extends Principal {} /** * @Entity */ class User extends Principal {} Can this ever work or does it even make sense? Rewriting it to reflect what it actually "looks like" for Doctrine: abstract class Principal {} /** * @Entity * @InheritanceType( "JOINED" ) * @DiscriminatorColumn(name= "type" , type= "string" ) * @DiscriminatorMap({ "User" = "User" , "Group" = "Group" }) */ class Group extends Principal {} /** * @Entity * @InheritanceType( "JOINED" ) * @DiscriminatorColumn(name= "type" , type= "string" ) * @DiscriminatorMap({ "User" = "User" , "Group" = "Group" }) */ class User extends Principal {} I think this would make no sense at all. Hence the combination of @MappedSuperclass + @InheritanceType probably only seems to make sense currently in the SINGLE_TABLE scenario mentioned in the issue description. An interesting possibility I noticed due to this ticket is that you can indeed use different inheritance mapping strategies in the same hierarchy, as long as the different subtrees of the hierarchy that are mapped with different strategies do not have a common ancestor entity . (For Doctrine the subtrees are then simply unrelated hierarchies, it does not care about common ancestor classes that are regular php classes). We should write some tests for that and add it to the docs, I will create a new ticket for that. Example: class Base {} class RootOfTreeA extends Base {} // Entity + SINGLE_TABLE class RootOfTreeB extends Base {} // Entity + JOINED

Roman S. Borschel added a comment - 30/Aug/10 6:22 AM A solution and/or documented behavior for this should be evaluated before entering RC1.

Benjamin Eberlei added a comment - 16/Nov/10 3:55 PM MappedSuperclass Inheritance Details are confusing and are ignored now.