Download the PHP package stratadox/table-loader without Composer

Table Loader

Installation

Install using composer require stratadox/table-loader

What is this?

The TableLoader package is designed to transform the result of a select query into objects. It solves the challenge of deserialising joined table rows into objects without duplicating the entities.

To load a table means to produce objects from the associative arrays that result from a SQL query.

An object that LoadsTables can make interrelated objects from a list of associative arrays.

Table loading works closely together with the Hydration modules to easily integrate with mapped hydration and lazy- and extra lazy loading.

What does it do?

The purpose of the TableLoader package is to transform SQL-like table results into a set of objects.

Connecting eagerly loaded relationships

When eagerly loading a relationship from a SQL database, one generally performs some kind of JOIN query.

The TableLoader package provides several options for converting the joined result into interconnected objects.

Each entity can be given any number of has-one and/or has-many relationships. Bidirectional associations can be produced by assigning such relationships to both sides.

Any number of tables can be joined at a time. Self-referencing joins are equally supported.

Mapping concrete subclasses

When dealing with polymorphism in a SQL schema, objects are generally mapped in either of three ways:

• Single Table Inheritance
• Class Table Inheritance
• Concrete Table Inheritance

The TableLoader supports any of these methods, so long as a decision key is provided. (Also known as discriminator column)

Managing identities

It can happen that some of the objects have already been loaded by a previous query.

For example, let's assume we're first loading only employee X. Later on we're fetching company Y with all employees - including employee X.

While we do want company Y to include employee X on the books, we do not want two copies of employee X in memory.

To solve this challenge, loaded entities are added to an Identity Map. The table loader consults the identity map when extracting an entity from the table row data. A new entity is only produced if it was not already present in the map.

If employee X had a lazy has-one mapping to their company, the company relation was a Proxy when the employee was first loaded. By loading the company Y, and its eager has-many employees mapping, the real company Y is automatically loaded into the relationship that previously held a proxy.

Usage Samples

Simple result without (eager) relations:

Assuming for table:

Unidirectional has-many mapping:

Bidirectional has-many mapping:

Many-to-many relationship:

Multiple joined tables:

To do

• Make simple table builder.
• Segregate builder interfaces.
• Allow direct hydrator injection in joined table builder?
• More unhappy path testing and better exception handling.
• Use deserializer instead of an old hydrator version.