Telerik OpenAccess Classic

Telerik OpenAccess ORM Send comments on this topic.
Primary Key
Programmer's Guide > OpenAccess ORM Classic (Old API) > Programming With OpenAccess > Mapping > Classes > Primary Key

Glossary Item Box

This documentation article is a legacy resource describing the functionality of the deprecated OpenAccess Classic only. The contemporary documentation of Telerik OpenAccess ORM is available here.

OpenAccess ORM supports internal identity, single field identity and multiple field identity, internal identity being the default. Both types of identity can be used with built-in or user-defined key generators (refer to db-key-generator for more information).

User defined key generators are currently not supported. They will be supported in a future release.

Internal Identity

Internal Identity is the default identity type used by OpenAccess. In this case, the OpenAccess ORM Runtime system manages the identity. The user does not need to do anything to implement object identity; all that needs to be done is make an object persistent and to add it to an IObjectScope instance and therefore, this is the easiest to implement.

The generated identity is of the integer type and it is a hidden field. It should be used in cases where the application does not use the identity value directly (refer to Specifying Internal Identity for more information).

Single Field Identity

In this case the identity for objects is provided by the values of a single field of an object, i.e., one exclusive field holds the identity information.

Single Field Identity can be used if your class has only one primary key field. The user needs to specify the [Persistent(IdentityField="xx")] attribute, which names the field containing the identity, and OpenAccess ORM manages the rest (refer to Single Field Identity for more information).

Only one identity mechanism can be specified within a single class hierarchy, i.e., it is not possible to specify both Single field identity (IdentityField) and Multiple Field Identity (Identity), within an inheritance hierarchy.

Multiple Field Identity

In this case the identity for objects is provided by the values of certain fields of an object. Multiple Field Identity should be used in cases where you need more control or flexibility over the identity generation, or if you need more than one field, i.e., a composite key to generate your primary key, or need a key type that is not supported by single field identity as the primary key. In this case, you take control over the specification of the identity of your objects, i.e., you need to specify the object-id class (refer to Multiple Field Identity for more information).

Currently, the values for these primary key fields must be supplied by the application or by one of the built-in key generators provided by OpenAccess ORM (refer to db-key-generator for more information). In a future release you will have the ability to define and configure your own key generators.

Only one identity mechanism can be specified within a single class hierarchy, i.e., it is not possible to specify both Single field identity (IdentityField) and Multiple Field Identity (Identity), within an inheritance hierarchy.

Autoinc / Identity / Serial Columns

OpenAccess ORM supports IDENTITY columns on Microsoft SQL Server, MySQL, Advantage Database Server, SQL Anywhere Server, SQL Azure, Microsoft SQL CE, VistaDB 4.0 and Oracle. OpenAccess ORM supports, internal, single field and multiple field identity classes. Following is an example of a class using the AUTOINC key generator:

Copy Code
<class name="Order">
  <extension key="db-key-generator" value="AUTOINC" />
</class>

The AUTOINC key generator is slower than the default HIGHLOW key generator and it is not portable across databases. In case of Firebird, AUTOINC is currently not supported.

Usually, a separate database query must be run after each insert to retrieve the generated primary key value. This is slow and also prevents the use of statement batching. This feature should therefore, only be used if you need to map to a legacy database schema using AUTO_INCREMENT, IDENTITY or SERIAL columns.