Queries can be fetched into objects based on custom classes. For example, if we have a class named ExampleClass, the following query will return objects of type ExampleClass.
$result = $connection->query("SELECT id, title FROM {example_table}", [], [
'fetch' => 'ExampleClass',
]);
If the class has a __construct() method, objects will be created, properties will be added to the object, and then the __construct() method will be called. For example, if you have the following class and query:
Insert queries should always use the query builder object. Some databases require special handling for LOB (Large OBject, e.g., TEXT in MySQL) and BLOB (Binary Large OBject) fields, so an abstraction layer is necessary for individual database drivers to implement any required special handling.
Insert queries are initiated using the insert() method like this:
Delete queries should always use the query builder object. They are initiated using the delete() method as follows:
$query = $connection->delete('mytable', $options);
This creates a delete query object that removes records from the mytable table. Note that curly braces are not required around the table name, as the query builder will handle this automatically.
Drupal also supports transactions, including a transparent fallback for databases that do not support transactions. However, transactions can be quite tricky if you try to run two transactions simultaneously. Behavior in such cases also depends on the database.
A similar issue exists with nested locks in C / C++. If code has already acquired lock A and tries to acquire lock A again, the code will block. If you write code that checks whether it already holds the lock and avoids acquiring it again, you can prevent deadlocks, but you might release the lock prematurely.
The Drupal database layer does not provide cross-database abstraction for SQL functions. To ensure portability across supported database engines, your code should use only those functions that are known to be part of the ANSI standard and supported in all databases supported by Drupal. The following is still an incomplete list. The form used here is recommended, as other syntax variants may not work across all databases.
The Drupal 8 Entity System
Entities are typed classes with methods.
| Generic methods |
$entity->id() |
- Drupal 7 - Entities were generic stdClass objects.
- Drupal 8 - Entities are now strongly typed objects, with each entity type defining the class used for its instances.
Requirements
Entity classes must reside in the Entity namespace of the module that provides the entity type, e.g., \Drupal\[module_name]\Entity. This means the PHP files for Entity classes can be found in the module's src/Entity directory.
This cheat sheet provides an overview of commonly used methods, classes, and interfaces for content entities.
Configuration entities use the Entity API to store configuration in the database.
Differences Compared to Content Entities
- Integrated with the CMI API for exportability
- No fields
- Uses a schema file (Content Entities use hook_schema())
Tutorials
This cheat sheet provides an overview of commonly used methods, classes, and interfaces for content entities.