[TYPO3-mvc] [!!!] FYI: Implemented first version of single table inheritance.

[Jochen Rau]

Hi.

Single table inheritance is a beast ;-) That said, I can describe the 
current state I have committed with r2226.

[!!!] But before we start, note that there is a breaking change. Until 
this rev. Extbase made a "best guess" for the table name if it was not 
the lowercased class name (simply by crawling the class hierarchy 
upwards trying to find a mapping rule or table). I have removed this 
"magic" because It was very hard to understand what was happening; esp. 
if there was an error.

Now, let's have a class hierarchy like

                 Party
                 |   |
       Organization   Person
	|    |
    Company ScientificInstitution

The class Party is a class of another extension. All the other classes 
are part of my extension. The classes Party and Organization will never 
get instanciated but their concrete classes Person, Company and 
ScientificInstitution.

There are different ways to map this class hierarchy onto the Relational 
Model of a database:

1) Map the entire class hierarchy to a single table.
     aka "Single Table Inheritance"
2) Map each concrete class to its own table.
     aka "Class Table Inheritance"
3) Map each class to its own table.
     aka "Concrete Table Inheritance"
4) Map the classes into a generic structure.

Examples:
1) Single Table Inheritance: All the data of the concrete classes 
(Company, ScientificInstitution and Person) are stored in the single 
table "party". This table has an extra field (could be any name) 
indicating the record type (the class name by default). The name of the 
extra field must be defined in the "ctrl" section of the TCA of the 
table (key: "type").

If you query for Company objects through a CompanyRepository, you only 
find objects of this particular type. But you can also have an 
OrganizationRepository that is responsible for Objects of type Company 
*and* ScientificInstitution. The configuration is

config.tx_extbase.persistence.classes {
   Organization {
     mapping {
       tableName = party
     }
     subclasses {
       Company = Company
       ScientificInstitution = ScientificInstitution
     }
   }
   Person {
     mapping {
       tableName = party
     }
   }
   Company {
     mapping {
       tableName = party
     }
   }
   ScientificInstitution {
     mapping {
       tableName = party
     }
   }
}

As you can see, you have to define the table name for every class that 
is not stored in a table named as the lowercased class name.

There is a new option "subclasses" where you can specify, which classes 
are subclasses and should be taken into account, too. This might be a 
subset of the "real" subclasses in the class hierarchy. It might be 
puzzling, that the statement is "Company = Company". The right part is 
the class name. The left part can be any unique name (suggestion: the 
class name).

Sometimes it is not possible to store the class name as record type. 
think about mapping tt_content onto your class hierarchy. There is a 
field called "CType". You can define, that the CType "text" should be 
mapped onto your class "Tx_TemplaVoila_Domain_Model_Text". The 
configuration is:

config.tx_extbase.persistence.classes {
   Tx_TemplaVoila_Domain_Model_Text {
     mapping {
       tableName = tt_content
       recordType = text
     }
   }
}

I am sure somebody is "furbo" enough to find this configuration:

config.tx_extbase.persistence.classes {
   Client {
     mapping {
       tableName = party
       recordType = Person
     }
   }
}

in comparison to

config.tx_extbase.persistence.classes {
   Person {
     mapping {
       tableName = party
     }
   }
}

But this is very bad style. Why? I am going to spend a beer on T3DD (or 
any other event) for the best explanation. ;-)

2) Class Table Inheritance: currently not supported by Extbase.

3) Concrete Table Inheritance: There are tables for each of the concrete 
classes Company, ScientificInstitution, and Person. No further 
configuration needed. You can have a repository for each of the concrete 
classes (but not for the class Organization, yet).

4) See FLOW3 ;-)

Please test the new feature and give feedback. Are there any logical 
issues? Issues in the code? Any thoughts about the configuration options?

Regards
Jochen