Download the PHP package icanboogie/activerecord without Composer

Active Record

Connections, models and active records are the foundations of everything that concerns database access and management. They are used to establish database connections, manage tables and their possible relationship, as well as manage the records of these tables. Leveraging OOP, the models and active records are instances which properties, getters/setters and behavior can be inherited in a business logic.

Using the query interface, you won't have to write raw SQL, manage table relationship, or worry about injection.

Finally, using providers you can define all your connections and models in a single place. Connections are established and models are instantiated on demand, so feel free the define hundreds of them.

Installation

Acknowledgments

The implementation of the query interface is vastly inspired by Ruby On Rails' Active Record Query Interface.

Getting started

Unless you bound ActiveRecord to ICanBoogie using the icanboogie/bind-activerecord package, you need to bind the prototype methods Model::lazy_get_activerecord_cache and ActiveRecord::validate.

The following code should do the trick:

Establishing a connection to a database

A connection to a database is created with a Connection instance.

The following code demonstrates how a connection can be established to a MySQL database and a SQLite temporary database:

The Connection class extends PDO. It takes the same parameters, and custom options can be provided with the driver options to specify a prefix to table names, specify the charset and collate of the connection or its timezone.

Defining the prefix of the database tables

ConnectionAttributes::$table_name_prefix specifies the prefix for all the tables name of the connection. Thus, if the icybee prefix is defined the nodes table is renamed as icybee_nodes.

The {table_name_prefix} placeholder is replaced in queries by the prefix:

Defining the charset and collate to use

ConnectionAttributes::$charset_and_collate specifies the charset and collate of the connection in a single string e.g. "utf8/general_ci" for the "utf8" charset and the "utf8_general_ci" collate.

The {charset} and {collate} placeholders are replaced in queries:

Specifying a time zone

ConnectionAttributes::$time_zone specifies the time zone of the connection.

Model overview

A model is an object-oriented representation of a database table, or a group of tables. A model is used to create, update, delete and query records. Models are instances of the Model class, and usually implement a specific business logic.

Defining the name of the table

The $name argument specifies the name of the table. If a table prefix is defined by the connection, it is used to prefix the table name. The name and unprefixed_name properties returns the prefixed name and original name of the table:

The {self} placeholder is replaced in queries by the name property:

Defining the schema of the model

To specify the schema, tt is recommended to use attributes on your ActiveRecord class:

• Boolean
• Integer
• Serial
• BelongsTo
• Decimal
• Character
• Text
• Binary
• Blob
• DateTime
• Timestamp
• Date
• Time
• Id
• HasMany

Alternatively, you can use $schema_builder to build the schema by hand:

Creating the table associated with a model

Once the model has been defined, its associated table can easily be created with the install() method.

The is_installed() method checks if a model has already been installed.

Note: The method only checks if the corresponding table exists, not if its schema is correct.

Placeholders

The following placeholders are replaced in model queries:

• {alias}: The alias of the table.
• {prefix}: The prefix of the table names of the connection.
• {primary}: The primary key of the table.
• {self}: The name of the table.
• {self_and_related}: The escaped name of the table and the possible JOIN clauses.

Defining the relations between models

Extending another model

A model can extend another, just like a class can extend another in PHP. Fields are inherited and the primary key of the parent is used to link records together. When the model is queried, the tables are joined. When values are inserted or updated, they are split to update the various tables. Also, the connection of the parent model is inherited.

Contrary to tables, models are not required to define a schema if they extend another model, but they may end with different parents.

In the following example the parent table of news is nodes but its parent model is contents. That's because news doesn't define a schema and thus inherits the schema and some properties of its parent model.

One-to-one relation (belongs_to)

Records of a model can belong to records of other models. For instance, a news article belonging to a user. The relation is specified with the BELONGS_TO attribute. When the belongs to relation is specified, a getter is automatically added to the prototype of the records. For instance, if records of a news model belong to records of a users model, than the get_user getter is added to the prototype of the records of the news model. The user of a news record can then by obtained using the magic property user.

One-to-many relation (has_many)

A one-to-many relation can be established between two models. For instance, an article having many comments. The relation is specified with the HasMany attribute. A getter is added to the active record class of the model and returns a Query instance when it is accessed.

The following example demonstrates how a one-to-many relation can be established between the "articles" and "comments" models, while creating the models:

Active Records

An active record is an object-oriented representation of a record in a database. Usually, the table columns are its public properties, and it is not unusual that getters/setters and business logic methods are implemented by its class.

If the model managing the record is not specified when the instance is created, StaticModelResolver will be used to resolve the model when needed.

Instantiating an active record

Active record are instantiated just like any other object, but the from() method is usually preferred for its shorter notation:

Validating an active record

The validate() method validates an active record and returns a ValidationErrors instance on failure or an empty array on success. Your active record class should implement the create_validation_rules() method to provide validation rules.

For following example demonstrates how a User active record class could implement the create_validation_rules() method to validate its properties.

Saving an active record

Most properties of an active record are persistent. The save() method is used to save the active record to the database.

Before a record is saved it is validated with the validate() method and if the validation fails a RecordNotValid exception is thrown with the validation errors.

The validation may be skipped using the SAVE_SKIP_VALIDATION option, of course the outcome is then unpredictable so use this option carefully:

The alter_persistent_properties() is invoked to alter the properties that will be sent to the model. One may extend the method to add, remove or alter properties without altering the instance itself.

Deleting an active record

The delete() method deletes the active record from the database:

Date time properties

The package comes with three trait properties especially designed to handle DateTime instances: DateTimeProperty, CreatedAtProperty, UpdatedAtProperty. Using this properties you are guaranteed to always get a DateTime instance, no matter what value type is used to set the date and time.

Retrieving records

Use a find() method to retrieve one or multiple records.

Retrieving a set or records using their primary key is really simple too:

The RecordNotFound exception is thrown when a record could not be found. Its records property can be used to know which records could be found and which could not.

Note: The records of the set are returned in the same order they are requested, this also applies to the records property of the RecordNotFound exception.

The Query Interface

Queries often start from a model, with $model->query() or $model->where().

See The Query Interface

Providing your own query

By default, the query object is Query instance, but the class of the query can be specified with the QUERY_CLASS attribute. This is often used to add features to the query.

Providers

Providers are included to manage connections and models.

The connection provider

The connections provider manages database connections.

Defining connections

Connection definitions can be specified while creating the ConnectionCollection instance. ConnectionCollection implements ConnectionProvider, it is recommended to type against the interface and use the method connection_for_id().

Database connections are created on demand, you can define a hundred of them, but they are only established when needed.

A ConnectionNotDefined exception is thrown in attempt to obtain a connection that is not defined.

Checking defined connections

Established connections

An array with the established connections can be retrieved using the established magic property. The property is read-only.

The ConnectionCollection instance itself can be used to traverse established connections.

Model collection

Models are managed using a model collection that resolves model attributes (such as database connections) and instantiate them.

Defining models

Model definitions can be specified while creating the ModelCollection instance. ModelCollection implements ModelProvider, it is recommended to type against the interface and use the method model_for_id() to retrieve models from the collection.

Note: You don't have to create the Connection instances used by the models, you can use their identifier which will get resolved when the model is needed.

Note: If CONNECTION is not specified the primary connection is used.

Model definitions can be modified or added after the ModelCollection instance has been created.

You can modify the definition of a model until it is instantiated. A ModelAlreadyInstantiated exception is thrown in attempt to modify the definition of an already instantiated model.

Obtaining a model

Use the ModelCollection instance as an array to obtain a Model instance.

Models are instantiated on demand, so that you can define a hundred models an they will only by instantiated, along with their database connection, when needed.

A ModelNotDefined exception is thrown in attempts to obtain a model which is not defined.

Instantiated models

An array with the instantiated models can be retrieved using the instances magic property. The property is read-only.

Installing / Uninstalling models

All the models managed by the provider can be installed and uninstalled with a single command using the install() and uninstall() methods. The is_installed() method returns an array of key/value pair where key is a model identifier and value true if the model is installed, false otherwise.

Model provider

StaticModelProvider::model_for_record() is used by active records to retrieve their model when required, and by queries during joins. Models are retrieved using the model collection returned by ModelProvider.

The following example demonstrates how to define a factory for a model provider:

Note: The factory is invoked once.

Records caching

By default, each model uses an instance of RuntimeActiveRecordCache to cache its records. This cache stores the records for the duration of the request, it is brand new with each HTTP request. The cache is obtained using the prototype features of the model, through the activerecord_cache magic property.

Third parties can provide a different cache instance simply by overriding the lazy_get_activerecord_cache method:

Or using a prototype configuration fragment:

Exceptions

The exception classes defined by the package implement the ICanBoogie\ActiveRecord\Exception interface so that they can easily be identified:

The following exceptions are defined:

• ConnectionAlreadyEstablished: Exception thrown in attempt to set/unset the definition of an already established connection.
• ConnectionNotDefined: Exception thrown in attempt to obtain a connection that is not defined.
• ConnectionNotEstablished: Exception thrown when a connection cannot be established.
• ModelAlreadyInstantiated: Exception thrown in attempt to set/unset the definition of an already instantiated model.
• ModelNotDefined: Exception thrown in attempt to obtain a model that is not defined.
• RecordNotFound: Exception thrown when one or several records cannot be found.
• RelationNotDefined: Exception thrown in attempt to obtain a relation that is not defined.
• ScopeNotDefined: Exception thrown in attempt to obtain a scope that is not defined.
• StatementInvocationFailed: Exception thrown when invoking a statement fails (execute() returned false).
• StatementNotValid: Exception thrown in attempt to execute a statement that is not valid.
• UnableToSetFetchMode: Exception thrown when the fetch mode of a statement fails to be set.

Continuous Integration

The project is continuously tested by GitHub actions.

Code of Conduct

This project adheres to a Contributor Code of Conduct. By participating in this project and its community, you're expected to uphold this code.

Contributing

See CONTRIBUTING for details.