OptimizeYour Object Model

Paul Dayan – Sales Engineer

2

What’s this about?

• You are familiar with object-oriented design and programming

• It’s easy using an in-memory object graph in a managed environment such as the Caché runtime, javascript, Java or .NET

• But what about persistence?

3

PetOwnerHasInsurancePets

An object-oriented example

PersonNameAddressesChildren

AddressLocationStreetCityCountry

CountryName

∞ 1

PetNameBreedOwner∞

ChildName

Serial

Parent-child

List

Array

Reference

4

What about persistence?

• The object graph is easy to understand and manage in memory

• All objects have the same in-memory behaviour:• The runtime destroys objects that are no longer referenced

• We may want classes to have differing behaviour when persisted

• What’s the SQL syntax?

5

The options

• Simple property:

• Datatype

• Serial object reference

• Persisted object reference

• Collection:

• Array

• List

• Relationship:

• Between persisted objects

• One-to-many

• Parent-child

6

Simple property

• Simple datatype: stored in the containing object

• Serial object reference (%SerialObject)

• Effectively a user-defined datatype• Stored in the containing object• Saved, reloaded and deleted with the containing object

• Persisted object reference

• Object ID automatically stored in containing object• Object reloaded when referenced• No constraint management if object is deleted• When containing object is reloaded, reference is null

7

Collection property

• Collection can be list or array

• Members are datatypes, serial objects or persistent objects

• Examples:

• Property Addresses As array Of Address;• Property Children As list Of Child(POPSPEC = ":3");

• Persistent objects:

• Parent stores collection of IDs• Are not automatically saved• Are not deleted if the parent is deleted

8

List collection property

• List collection limited to 32 KB.

• If Long Strings enabled, limit raised to 3.4 MB.

• Long strings are the default in v2012.2.

• Items available as single column using SQL

• Optional property parameter STORAGEDEFAULT = "array“• Collection projected as child table in SQL

9

Considerations

• Datatype: simple or serial, single or collection• Pros• Loaded with containing object – faster to access• Easy to manage – saved and deleted with containing object

• Cons• Increases size of containing object• Slower access to containing objects• Memory consumed when containing object loaded

• Good for• Small, frequently-accessed properties

10

Relationship

• One-to-many or Parent-child

• Similar to collection of persistent objects

• Two-way reference – property in both classes

• Collection in parent or one• Simple reference in child or many

• Object ID of the parent is stored in the child

• Reference using relationship property:

• set pet = petOwner.Pets.GetAt(1)• set petOwner = pet.PetOwner

11

Managing a relationship

• Relationship on “one” side is %RelationshipObject

• Nothing is persisted – containing object size not increased

• Relationship on “many” side is simple object reference

• ID of related object is persisted

• A House class with one-to-many to Door class• set door.House = house

• do house.Doors.Insert(door)

• set door.House = “”

• do house.Doors.Remove(door)

• set door = house.Doors.GetNext(.key)

• Saving either object persists the changes

12

Parent-child relationship

• Children are deleted when parent is deleted

• Child can’t be same class as parent

• Child can’t be assigned to a different parent

• Children clustered with parent on disk• Depending on first compilation order, may be stored in

parent

• Child ID is of the form <parent ID>||<child sub-ID>• set pet = ##class(Personnel.Pet).%OpenId("17||3")

13

One-to-one relationship

• Can be simulated by:• Creating a one-to-many relationship• Applying a unique index to the relationship on the “many”

side

• The “one” side relationship is still a collection

14

Many-to-many relationship

OrderCustomerDateOrderNumberOrderLines

ProductNameProductCodeOrderLines

OrderLinesOrderProductQuantity

15

Many-to-many relationship

• Requires an intermediate associative class

• Both classes have one-to-many relationship with associative class

• The associative object has a reference to one of each of the primary classes

• The associative object contains properties for the association

• The relationships can be one-to-many or parent-child

• The application must manage the associative objects

16

Using SQL

• Persistent classes projected as tables

• Properties of embedded (serial) object projected as parent properties:• Name <parent property>_<child property>

• Addresses_Street

• Special syntax for embedded collections• List stored as nested %List (Caché list)• Array projected as table

17

Embedded arrays – projected table

• Embedded array projected to table• Name <parent class>_<parent collection property>• Example: Person_Addresses

• Columns in projected table:• Name <parent collection property>_<child property>• Example: Person_Addresses.Addresses_Street

18

Embedded array – pseudo-columns

• element_key pseudo-column for array key:• SELECT element_key FROM Personnel.Person_Addresses

• ID pseudo-column is <parent ID>||<key>:• SELECT Addresses_Street FROM Personnel.Person_Addresses

WHERE ID = '16||Home‘

• Parent class name is parent ID pseudo-column in SQL:• SELECT Person FROM Personnel.Person_Addresses

19

Embedded list

• Not exposed as a projected table (by default)

• Exposed as a column that is a %List• Each contained item is a %List

• User datatype (serial object)• Properties held in a %List within the %List

• Example:• SELECT $list($list($list(Cars,1),1),1) FROM

Personnel.Person WHERE ID = 1

• Audi

20

Embedded list as projected table

• Use STORAGEDEFAULT parameter on collection property:• Property Cars As list Of Car(POPSPEC = ":2",

STORAGEDEFAULT = "array");

• List projected same as array:• SELECT * from Personnel.Person_Cars

• Same pseudo-columns as array• element_key is integer index into collection base 1• <parent class> parent ID• ID is composite key: <parent ID>||<element key>

21

STORAGEDEFAULT caveat!

• If you add STORAGEDEFAULT = “array” after first compilation:• Storage definition is not updated by compilation• Projected table is not created

• Force storage definition to be updated:• View >> View Storage• Delete the storage definition text• Recompile the class

22

Derived classes

• By default, objects of a sub-class are stored in the global of the super-class

• The super-class properties are stored in the usual way• The additional properties of the sub-class are stored in a sub-item

indexed by sub-class name• Deleting the super-class extent deletes all sub-class objects

• Both the super-class and the sub-class are exposed as SQL tables

• The super-class table includes the sub-class objects• The sub-class table contains only the objects of the sub-class type

23

Super-class with NoExtent

• Option to have no global and SQL table for the super-class

• NoExtent class attribute on super-class:• Class Personnel.Person [ NoExtent ]

• Can’t persist (%Save) super-class objects

• No global or SQL table for super-class

• Separate global (and SQL table) for each sub-class

24

Conclusion

• Object graph in memory – easy to manage

• Persistence brings other considerations• Performance• Constraints

• Caché has several options to fit different requirements

• Make this part of the design exercise

25

Thank You!

Any questions?