Other Options for Persistent Classes
This topic describes other options that are available for persistent classes.
Defining a Sharded Class
If you are using sharding for horizontal scaling of data storage, you can define a sharded class by using the Sharded class keyword in the class definition. A sharded class is a persistent class where the data is spread among the data nodes of a sharded cluster, while the application accesses the data as if it were local.
Set the keyword Sharded = 1 to create a sharded class, as in the following example:
Class MyApp.Person Extends %Persistent [ Sharded = 1 ]
Until sharded classes are fully implemented, InterSystems recommends creating sharded tables from SQL, not from the object side.
For more information on sharding, see Horizontally Scaling InterSystems IRIS for Data Volume with Sharding.
Defining a Read-Only Class
It is possible to define a persistent class whose objects can be opened but not saved or deleted. To do this, specify the READONLY parameter for the class as 1:
Parameter READONLY = 1;This is only useful for cases where you have objects that are mapped to preexisting storage (such as existing globals or an external database). If you call the %Save() method on a read-only object, it will always return an error code.
Adding Indexes
Indexes provide a mechanism for optimizing searches across the instances of a persistent class; they define a specific sorted subset of commonly requested data associated with a class. They are very helpful in reducing overhead for performance-critical searches.
Indexes automatically span the entire extent of the class in which they are defined. If a Person class has a subclass Student, all indexes defined in Person contain both Person objects and Student objects. Indexes defined in the Student class contain only Student objects.
Indexes can be sorted on one or more properties belonging to their class. This allows you a great deal of specific control of the order in which results are returned.
In addition, indexes can store additional data that is frequently requested by queries based on the sorted properties. By including additional data as part of an index, you can greatly enhance the performance of the query that uses the index; when the query uses the index to generate its result set, it can do so without accessing the main data storage facility. (See the Data keyword below.)
The only way to simultaneously add an index definition to the class and build the data in the index is by using an ALTER TABLE, CREATE INDEX, or DROP INDEX statement. When adding an index to a class definition, the index must be manually built. To read about building indexes manually, refer to Building Indexes.
For additional information on indexes, refer to Defining and Building Indexes, especially the section Properties That Can Be Indexed. Also see Index Definitions.
Adding Foreign Keys
To enforce referential integrity between tables you can define foreign keys in the corresponding persistent classes. When a table containing a foreign key constraint is modified, the foreign key constraints are checked. One way to add foreign keys is to add relationships between classes; see Defining and Using Relationships. You can also add explicit foreign keys to classes. For information, see Using Foreign Keys and Foreign Key Definitions.
Adding Triggers
Because InterSystems SQL supports the use of triggers, any trigger associated with a persistent class is included as part of the SQL projection of the class.
Triggers are code segments executed when specific events occur in InterSystems SQL. InterSystems IRIS® data platform supports triggers based on the execution of INSERT, UPDATE, and DELETE commands. The specified code will be executed either immediately before or immediately after the relevant command is executed, depending on the trigger definition. Each event can have multiple triggers as long as they are assigned an execution order.
If a trigger is defined with Foreach = row/object, then the trigger is also called at specific points during object access. See Triggers and Transactions.
Triggers are also fired by the persistence methods used by the legacy storage class, %Storage.SQL because it uses SQL statements internally to implement its persistent behavior.
For more information on triggers, see Triggers and Trigger Definitions.
Referring to Fields from ObjectScript
Within a class definition, there are several places that may include ObjectScript code used in SQL. For example, SQL computed field code and trigger code is executed from within SQL. In these cases, there is no concept of a current object, so it is not possible to use dot syntax to access or set data within a specific instance. Instead, you can access the same data as fields within the current row using field syntax.
To reference a specific field of the current row, use the {fieldname} syntax where fieldname is the name of the field.
For example, the following code checks if the salary of an employee is less than 50000:
If {Salary} < 50000 {
// actions here...
}
In UPDATE trigger code, {fieldname} denotes the updated field value. In DELETE trigger code, {fieldname} denotes the value of the field on disk.
To refer to the current field in a SQL computed field, use the {*} syntax.
For example, the following code might appear in the computed code for a Compensation field to compute its value based on the values of Salary and Commission fields:
Set {*} = {Salary} + {Commission}
For trigger-specific syntax, see Special Trigger Syntax.
