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

[Jochen Rau]

Hi.

Just an additional note. If you want to use a table to store data from 
different classes in it, you have to provide a "type" field. This type 
field can be used to display BE forms with different fields as usual in 
TYPO3. You have to add the type to the items of the select field and you 
have to add the type to the "types" section in the TCA. Here is how the 
setup is done in the latest rev. of the BlogExample (shortened a bit):

setup.txt
---------
plugin.tx_blogexample {
   persistence {
     classes { 
Tx_BlogExample_Domain_Model_Administrator.mapping.tableName = fe_users
     }
   }
}

ext_tables.txt
--------------
$TCA['fe_users']['types']['Tx_BlogExample_Domain_Model_Administrator'] = 
$TCA['fe_users']['types']['0'];

array_push($TCA['fe_users']['columns']['tx_extbase_type']['config']['items'], 
array('LLL:EXT:blog_example/Resources/Private/Language/locallang_db.xml:fe_users.tx_extbase_type.Tx_BlogExample_Domain_Model_Administrator', 
'Tx_BlogExample_Domain_Model_Administrator'));

The fields from type "0" are just copied. No additions in the domain 
model. Be sure not to overwrite config from other extensions! -> 
array_push.

tca.php
-------

$TCA['tx_blogexample_domain_model_blog'] = array(
	'columns' => array(
		'administrator' => Array (
[...]
			'config' => Array (
				'type' => 'select',
				'foreign_table' => 'fe_users',
				'foreign_table_where' => "AND 
fe_users.tx_extbase_type='Tx_BlogExample_Domain_Model_Administrator'",
				'items' => array(
					array('--none--', 0),
					),
		         )
			)
		),
	),
   [...]
);

Note the foreign_table_where here to restrict the selection to the 
appropriate type.

I am curious about your feedback.

Regards
Jochen

On 15.04.10 22:37, Jochen Rau wrote:
> 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
>
>