4.1. Mapping Persistent Classes
This section deals with the main Class form which is shown on the right hand side of the split pane whenever a Class schema object is selected in the tree. This form is used to enter the most basic mapping information that must be supplied about a persistent class. There are also three additional forms that can be used to specify more sophisticated mapping options:
The main Class form is show below:
The Class form is divided in 2 sections: Class Settings and Cache Configuration.
The Class Settings section contains the following fields:
Mapping type. Select the type of mapping for the class. Valid options are: SUBSET, SUPERSET and CONTAINED. See section 2. Object-Relational Mapping Strategies for an explanation of the SUBSET and SUPERSET mapping types. A CONTAINED type is used to specify a persistent class that is fully contained by another class and is mapped to a subset of the columns within its container class. CONTAINED classes have the following restrictions:
See the Phone class in the
vemployeedemo and the Country class in
the vcontactdemo3 sample applications for examples of CONTAINED classes.
Table name. If the mapping type is SUBSET you must enter, or select from the combo box drop down list, the name of the table the class is mapped to. If the mapping type is SUPERSET, then the table name is usually specified in each attribute's mapping. However, you may specify a default table name in this field to be used for all attributes whose table name is not specified. For SUPERSET mappings you must also specify the joins to be performed and the ID columns of all additional tables in the Superset Mapping Options Form. See section 4.5. Superset Mapping Options for details. VBSF is case sensitive when it comes to all table and column names, so when referring to the same table or column name in multiple forms the same case must be used. If the mapping type is CONTAINED, then this field is disabled as the table name is specified in the container class.
Superclass name. If the class inherits persistent attributes from a base class, enter the name of the superclass. A base class can be mapped to the database by creating a Class schema object for it and defining the class as abstract (see next field). When you specify the name of the superclass in this field VBSF automatically persists all attributes inherited from the superclass.
Abstract. Check this option if the class is an abstract class used as base class for other persistent classes. If an abstract class has no persistable attributes do not create a Class schema object for it. Abstract classes are not persisted to the database, however their attributes can be mapped to the database so that VBSF knows how the inherited attributes of their subclasses are mapped to the database. The ID generation, Filter & Concurrency, and Superset settings for abstract classes are disabled.
The Cache Configuration section is used to configure the object cache for the persistent class. This section is disabled if the mapping type is CONTAINED. It contains the following fields:
Static. A static cache is never garbage collected. Use this option when it is undesirable to remove objects of this type from the cache. This is useful for classes that do not have a large extent and represent categorical or look-up information that is often used throughout the application.
Soft. In a Soft cache objects are garbage collected according to the JVM policy for Soft References. Soft References should be cleared with a bias against clearing recently-created or recently-used soft references, depending on the JVM.
Weak. In a Weak cache objects are garbage collected according to the JVM policy for Weak References. Weak References are cleared at the discretion of the garbage collector without regard for recently-created or recently-used objects.
Local. If checked, the cache for the persistent class will be maintained locally in each Database object. If not checked, the cache for the class is global and shared by all Database objects. This setting applies only to the Enterprise Edition and is ignored in the Professional Edition, as the Professional Edition only supports a local cache.
Managed. If checked, the cache is managed by VBSF using an MRU (most recently used) algorithm. If not checked and the cache is dynamic (soft or weak), entries are removed from cache solely at the discretion of the garbage collector depending on cache type.
Size. This option is enabled only if the cache is managed by VBSF. In this case, the size specifies the number of entries to maintain in the cache. If a dynamic cache, this is the minimum cache size. In other words, this is the number of most recently used entries guaranteed to be in the cache. If static, this is the maximum size that the cache can grow to.
Force ID order when loading. If checked, ordering by ID is forced during initial loading from the database. Forcing of ordering by ID can slow down initial database loading time, but it may be necessary if the database table does not return rows in ID order and the application requires it.