Persistent classes are one of the features that make InterSystems IRIS different from a traditional application database. Instead of designing database tables separately from application objects, developers can define a class and allow IRIS to manage its persistent representation. This creates a close relationship between the application's object model and the underlying data model.
A basic persistent class inherits from %Persistent:
Class MyApp.Product Extends %Persistent
{
Property Name As %String;
Property Price As %Numeric;
Property Stock As %Integer;
}
Once compiled, this class can be used as a persistent data model. Each instance represents a product that can potentially be stored in the database. However, creating an object does not immediately insert data into the database. The object initially exists only in memory.
Set product = ##class(MyApp.Product).%New()
Set product.Name = "Keyboard"
Set product.Price = 99.90
Set product.Stock = 25
Set status = product.%Save()
This distinction between an in-memory object and a persistent object is important for beginners. The %New() method creates the object, while %Save() makes its current state persistent. Developers should always check the status returned by %Save() because database operations can fail due to validation, constraints, or other application conditions.
After a successful save, IRIS assigns an identifier to the persistent object. This identifier allows the application to retrieve the same object later without having to manually construct a database query.
Set product = ##class(MyApp.Product).%OpenId(1)
Write product.Name
Write product.Price
This makes identifiers an important part of the persistence lifecycle. Developers should understand the difference between the technical ID generated for a persistent object and business identifiers, such as a product code or customer number. A database ID identifies the stored object, while a business identifier represents information meaningful to the application.
Persistent classes also integrate directly with SQL. The class can be accessed through its corresponding SQL table, allowing developers to query the same data using standard SQL syntax.
SELECT ID, Name, Price, Stock
FROM MyApp_Product
WHERE Stock > 0
ORDER BY Name
This integration is particularly useful because ObjectScript can be used for object-oriented application logic, while SQL can be used for filtering, reporting, aggregation, and more complex data retrieval.
Indexes are another important part of persistent class design. If products are frequently searched by name, an index can help the database locate matching records more efficiently:
Index NameIdx On Name;
However, indexes should be created according to actual query requirements. Excessive indexing consumes storage and can increase the cost of insert and update operations.
Finally, remember that persistent classes are compiled artifacts. When properties, indexes, or other class definitions change, the class must be compiled so IRIS can update the corresponding database structures.
For beginners, the key concept is simple: a persistent class connects ObjectScript objects, database storage, identifiers, indexes, and SQL. Understanding this relationship provides a solid foundation for developing applications with InterSystems IRIS.
