Handling Large and Nested Object Graphs

Explore practical solutions to optimize last database operations.
Post Reply
surovy113
Posts: 29
Joined: Sat Dec 21, 2024 9:35 am

Handling Large and Nested Object Graphs

Post by surovy113 »

Sterling will easily parse large and complex object graphs. It is important to understand the appropriate strategy, however, when you have a hierarchical relationship between classes that are defined as tables.

Consider Class A that contains a collection of Class B. Currently, Sterling doesn't maintain an independent "link table" for foreign keys. In other words, the relationships are serialized as part of the class. Therefore, if you add 500 items to Class A and save it, each time Class A will save each of the 500 items (even though on disk Class A will just contain the foreign keys to Class B).

The correct strategy is to manipulate changes by saving the Class B files. Keep a dirty flag on Class A to note when new classes are added. As long as you only change the child instances, the parent will always load the latest when loaded from the database. To create new relationships, however, you must eventually save the parent to establish the relationship.

Tombstoning on the Windows Phone 7


Sterling is an ideal solution for tombstoning Windows Phone 7 applications. See 3. The Sterling Engine overseas data for a tip and example of hooking into the Windows Phone 7 events. When creating applications for the phone, consider using settings to store relevant keys that pertain to data in view models, then use Sterling to load the data with the persisted keys.

Image

Derived Types


Sterling handles interfaces and base classes without issue because Sterling will always serialize the concrete type. However, it is tempting to try to define a base type as a Person class, for example, and then implement Student and Teacher that dervie from person.

Sterling will handle this better if it is managed like a traditional database, where the domain may identify common attributes for a base class but the database defines distinct tables. Because Sterling serializes the concrete type, it will "miss" a base definition and fail to serialize the object as a referenced table. Instead, define separate tables for Student and Teacher to keep them partitioned in storage. You will introduce no additional overhead, and Sterling will still recognize the tables and handle them appropriately even if you store them on your host type as type Person.

Rollback / Pseudo-Transaction Support


Sterling queries may reference cached data, while the Load function always loads the latest from disk irrespective of cache. If you wish to perform a rollback, then you can simply store the older value in a separate variable before performing your transaction. If some condition triggers the need to rollback, you can simply save the original value back.
Post Reply