Article information
Article relates to
OpenAccess Classic
Created by
Alexander Filipov
Last modified
December 18, 2008
Last modified by
Disadvantages of flat mapping are:
Because flat mapping is the default model used by Telerik OpenAccess ORM, there are no additional actions needed to achieve it except persisting your classes (a step by step ‘how to’ can be found here). While the project is being built, the following table is created: The discriminator column has the name ‘voa_class’ by default and its type is a 32-bit positive hash of the fully qualified class name. This value can be changed with another or even can be removed if flat mapping without a discriminator column is required. On the forward mapping wizard can be noticed that mapping strategy for all subclasses was set to ‘flat’. These are the default settings. We will have to change them later when using other mapping models. Flat mapping with no discriminator Normally a discriminator column is required for flat inheritance. However if each class in the hierarchy has at the most one subclass, then the discriminator can be disabled and all the rows are considered instances of the leaf class of the hierarchy. A UserException is thrown on any attempt to persist a non-leaf-class instance. In the example flat mapping without a discriminator column could be used if we had only the ‘Pet’, ‘Dog’ and ‘Rottweiler’ classes or any other hierarchy that has no more than one child class per parent. Configuration is made in the ‘Forward mapping’ wizard by selecting the ‘{no}’ option in the ‘Class-ID’ combo box for the top class (in the example this is ‘Pet’). As a result the following table is created: Vertical mapping With vertical mapping each class has its own table containing only its fields. Advantages of vertical mapping are:
Disadvantages of vertical mapping are:
To enable vertical mapping for a subclass change its mapping strategy in the ‘Forward mapping’ wizard to ‘vertical’. This change should be made for each child class we want to map vertically. Setting for the ‘Dog’ class looks like this: The corresponding tables for the sample class hierarchy, with vertical mapping are shown below: Note that there is a discriminator column in the ‘pet’ table. It can be disabled the same way as it is for ‘flat mapping’ - by selecting the ‘{no}’ option in the ‘Class-ID’ combo box for the base class. Nevertheless it is a good practice to keep this column because OpenAccess ORM optimizes the SQL statements and higher performance is achieved when all the instances returned are known to be of a given subclass. For example if the following OQL query is executed:
The generated SQL statement would be:
Note that INNER joins are used instead of OUTER joins, which is faster.
Mixed Flat and Vertical mapping Telerik OpenAccess ORM supports mixing of flat and vertical mappings in the same hierarchy. For example, in order to save database space, you could choose to use vertical mapping only for seldom-used subclasses with many large fields. Change the inheritance strategy to ‘vertical’ only for these classes and leave the default settings for the rest. In the example if both ‘Dog’ and ‘Cat’ strategies are changed to vertical with ‘WeinerDog’ and ‘Rottweiler’ left flat, the hierarchy will be mapped to three database tables as shown below. A discriminator column (‘voa_class’) is added to the base table to distinguish between ‘Dog’, ‘WeinerDog’ and ‘Rottweiler’. Horizontal mapping Horizontal inheritance can only be enabled for the topmost class in a hierarchy. Each immediate subclass is stored in its own table with a "copy" of the fields from the superclass. A horizontally mapped class, i.e. the superclass, does not itself have a table. Therefore, a horizontally mapped class cannot be directly persisted. Only subclasses of the class can be stored in the database. For this reason, it is recommended (but not required) that horizontally mapped classes be declared abstract. Note: While using single or multiple field identity, it is required that the horizontally mapped class is declared abstract. In case of horizontal mapping, the identity and version information is specified at the next derived class, and if the IdentityField and the VersionField specified are fields that belong to the base class, those fields have to be accessible from the derived classes. Therefore, declaring these fields as "Protected" might be the best way, since if these fields are declared as "Private" the enhanced code will not be able to access these fields. The enhancer will check this and report an error. Each subclass may map the fields inherited from the superclass differently. Each subclass may have its own settings for identity type, objectid-class, key generator and optimistic locking just like a top level class. Classes further down the hierarchy may be mapped with any combination of flat and vertical inheritance. To enable horizontal mapping, just change the inheritance strategy to ‘horizontal’ (in the ‘Forward mapping’ wizard) for the base class and change the default values for the rest if needed.
For example our ‘WeinerDog’ and ‘Rottweiler’ classes have been mapped ‘vertically’. The corresponding tables for the sample class hierarchy, with horizontal mapping are shown below: Advantages of horizontal mapping are:
Disadvantages of horizontal mapping are:
Resources Buy Try