Object Type Tab

On the Object Type tab, you can see and define some basic Object Type settings. The Table, Database Schema, Object Type Name, and Database Session refer to the physical table in the database.

Additional settings:

• Icon (without title)

  Displays the icon which will be used. Another Icon can be selected by the 'Choose Icon' button at the bottom of the window.

• Root Type

  Select this check box to specify the object type as 'Root' object type. Root object types are the target object types for data archiving, i.e. object types for which archive configuration can be created.

• Object Type with Protocol Fields

  There are four standard protocol fields: 'user created', 'date created', 'user changed' and 'date changed'.

  If these fields are present in the physical database table, you can specify that Valuemation should update these fields with the current users and timestamps whenever an instance of this Object Type is created or updated. These fields can be used to audit changes in information then.

  If you select this check box, these fields will be automatically filled (and updated) anytime you create or edit an instance of this Object Type.

  Since Valuemation 5.0, 'user created' and 'date changed' protocol fields also contain information about user domain (if relevant). This way users with the same user ID but in different domains are distinguished.

• Link Object Type

  If selected, the Object Type is set as a linking object type, a special object type used for the creation of m:n relations.

  Setting an object type as Link Object Type is reserved only for simple linking objects which implement an M:N relation. Such 'simple' object types should not:

  • contain additional simple attributes which must be initialized during creation
  • contain additional relations to other objects
  • need special manipulation during the creation/deletion of their instances

    Note that some linking object types found in standard Valuemation may not adhere to the above rules. This is for 'historical reasons' and should neither be used as an example nor modified.

  For its limited use as an M:N relation agent, link object types have the following advantages:

  • existing actions to link/unlink objects can be used
  • no need to initialize the validFrom/validTo dates

  Important note: The 'Link Object Type' flag should be set during object type creation. Under all circumstances refrain from modifying the flag for already existing and otherwise used object types.

• Link Object Type with View

  Here you can specify if you want the instances of this Object Type to be viewable in the editor.

• Catalog Usage Enabled

  If selected, it will hide catalogs of this Object Type. If clear, the catalogs of this Object Type will not be returned by CatalogProvider.getAllPosibleCatalogs. As a result, they will not be listed for selections.

  Practically it means that if you select this check box during the Object Type creation, the catalogs can be based on that Object Type in the next customization step. If you leave it empty, the catalogs cannot be built on the Object Type.

  Note that when editing an Object Type with the check box selected, it is not possible to clear the check box if there are already catalogs based on the Object Type. If you try to do so and click 'Apply', the warning message will appear. The check box will stay selected and cannot be cleared in such a case.

• Allow Differential Export

  If selected, the customization logging mechanism will work also for generic object types and the object type will be shown in the Config Object Type tab of the Exporter of Metamodel Changes. However, any change in a generic object whose Object Type has this option disabled (e.g. EscTypeLevel) will not log a change in the related object whose object type has it enabled (e.g. EscType). In order to use customization logging for generic object types, this option has to be enabled (selected) on all of the object types that you want to log.

• Sorting on Database enabled

  When sorting is specified in a catalog or a master catalog, the data is sorted in the database and the result is read into the memory. If the Sorting on database enabled check box is set to false (clear), then the data is first read from the database and then sorted in the memory. This may cause unwanted "partial sorting" if the Initial Load limit is exceeded. The recommended setting is TRUE (sorting on database enabled).

• Cached

  All instances of this object type will be read from the DB into memory once and subsequently only selected from the cache. Cached objects cannot be modified, created or deleted. If you encounter such or similar problems with a cached object type, leave this check box clear.

• Allow Selecting Primary Keys

  This option enables you to optimize the reading of objects when opening catalogs. If selected, only the primary keys will be read in the first select statement (SELECT pk FROM table WHERE condition ORDER BY pk) and the complete rows will be read in the subsequent select statement (SELECT * FROM table WHERE IN (pk1, pk2,...). This is usually much faster, however, in rare cases (especially in complicated and large DB views) it may turn out to be slower so you may leave this check box clear. By default, the option is used for the integer primary keys only.

• Batch Update Disabled (Extended Properties)

  If the database trigger on the underlying database table does not allow batch update (executing the update, insert and delete statements as a batch), set 'Batch Update Disabled' to false.

• Sort INSERT Statements by Primary Key (Extended Properties)

  If enabled, INSERT statements generated by VM for the table corresponding to the object type will be sorted by the primary key. This can be used to make sure that INSERT statements are executed in a defined order, which may be a prerequisite for some DB triggers.

• Catalog Image Attribute (Extended Properties)

  Enables assignment of one of the business object attributes as attribute storing information about catalog image to be used with particular objects of this object type.

• Locking Type

  Describes the type of locking which will take place at the database level for this Object.

  There are three possible settings:

  • No Lock

    Means "no lock" exactly as the label has it.

  • Optimistic Lock

    Means that several users may access the object, but only one can save changes (the first to save). If the others try to save changes, they will get a message and must first refresh and then make their changes again. This is only relevant in situations where several users are likely to try to access the same record at the same time on a regular basis. Unless this is a specific problem, then optimistic logging should be used.

  • Pessimistic Lock

    If selected, the pessimistic locking will be applied to the Object Type at the database level. This means that only one user can edit or view an instance of the Object Type at any time. If a user is editing, no other user can even view the object.

  See topic 'Locking Modes' for more information.

• Modify...

  Each field can be used to specify a workflow automatically triggered at a certain stage of object creation and editing. This could be, for example, a workflow performing input verification or dependencies checking, or a workflow triggering a subsequent action after object saving.

  • Modify New Object

    A workflow which will be executed after a new object is created via GUI, a workflow or Python script.

  • Modify Copied Object

    A workflow which will be executed after an object is copied via GUI, a workflow or Python script.

  • Modify On Save

    A workflow which will be triggered in the 'EditorView Save' workflow activity.

    If ‘transaction.runSaveWorkflowOnCommit = True’ is set in Python script, methods ApiTransaction.doCommit() / doCommitResume() of that transaction will trigger this workflow, too.

  Edit buttons next to the 'Modify...' fields open the corresponding workflow for editing. If no workflow is assigned in a 'Modify...' field, the adjacent 'Edit' button is disabled.

The buttons at the bottom of the dialog box have the following function:

• Choose Icon

  The button opens a dialog box where the icon associated with the currently edited object type can be selected.

• Extended Properties

  The button opens a dialog box where extended properties of the object type can be specified.

• Check Object Type

  If you click the button, the metamodel check for this particular object type will be performed.