optimize your object model paul dayan – sales engineer
TRANSCRIPT
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?