Chapter 9. Xyster_Orm

Table of Contents

9.1. Introduction
9.2. Setting Up
9.3. Xyster_Orm_Mapper
9.4. Xyster_Orm_Entity
9.5. Xyster_Orm
9.5.1. Getting entities
9.5.2. Storing Changes
9.5.3. Secondary Cache
9.6. Xyster_Orm_Relation
9.6.1. One-to-one
9.6.2. One-to-many
9.6.3. Joined (Many-to-many)
9.7. Lookups
9.7.1. Xyster_Orm_Entity_Lookup_Date
9.7.2. Xyster_Orm_Entity_Lookup_Enum
9.8. Validation
9.8.1. Options
9.8.2. Setting up
9.9. Queries and Reporting
9.9.1. Xyster_Orm_Query
9.9.2. Xyster_Orm_Query_Report
9.10. Plugins
9.10.1. Plugins Included in the Release

9.1. Introduction

Object-relational mapping systems have come into popularity in the last few years. These systems allow the developers to do their job and the data store specialists (typically DBAs) to do theirs. Rows of data pulled from the data store are translated into objects with which developers can work easily. They can make modifications to these objects and save them back to the data store without any knowledge of exactly how to save them there.

Xyster makes use of an ORM system that employs the Data Mapper design pattern, as opposed to the Active Record pattern of some renown. Under this pattern, objects that represent rows in the data store have no knowledge of how to store themselves. Mapper objects exist to facilitate any reads or writes to or from the data’s source. Records in a persistent store are represented as objects called data entities. Groups of these entities are gathered in strongly-typed Sets.

Each type of entity must have three classes to work with the ORM system.

  1. The entity class (which extends Xyster_Orm_Entity)

    1. Just a container for each record's data. It has no knowledge of how to store itself.

  2. The entity set class (which extends Xyster_Orm_Set)

    1. A container for multiple entities

  3. The entity mapper class (which implements Xyster_Orm_Mapper_Interface)

    1. Responsible for CRUD operations (create, retrieve, update, delete) against entities.