Wallogit.com
2017 © Pedro Peláez
Persist your Value Objects with Doctrine using JMS Serializer. The DBAL Type supports anything that can be handled by JMS Serializer (scalar, array, Doctrine Collections, DateTime, etc)., (*1)
Add "webit/doctrine-jms-json": "^2.0.0" to the require section of your composer.json, (*2)
{
"require": {
"webit/doctrine-jms-json": "^3.0.0"
}
}
Configure register new Doctrine DBAL type and configure the Serializer:, (*3)
# boostrap.php
use Doctrine\DBAL\Types\Type;
use Webit\DoctrineJmsJson\DBAL\JmsJsonType;
use JMS\Serializer\SerializerBuilder;
use Webit\DoctrineJmsJson\Serializer\Type\DefaultSerializerTypeResolver;
Type::addType('jms_json', 'Webit\DoctrineJmsJson\DBAL\JmsJsonType');
$serializer = SerializerBuilder::create()->build();
// initialize JmsJsonType
JmsJsonType::initialize($serializer, new DefaultSerializerTypeResolver());
Now you can use "jms_json" in the Doctrine field mapping as a type., (*4)
See full configuration of JMS Serializer here See full documentation of Doctrine Mapping here See Doctrine Custom Types documentation here, (*5)
"jms_json" DBAL type can be very useful to store Value Objects or objects that structures may vary., (*6)
Consider example of a slider on a web page. Let class BannerSet contain the Slider configuration., (*7)
interface Slider
{
}
class BannerSet
{
private $id;
/** Slider */
private $slider;
/**
* @return Slider
*/
public function slider()
{
return $this->slider;
}
/**
* @param Slider $slider
*/
public function changeSlider(Slider $slider)
{
$this->slider = $slider;
}
}
There are plenty of different JavaScript slider configurations so we don't know in advance the Slider structure. Let's introduce two implementations:, (*8)
use JMS\Serializer\Annotation as JMS;
class Slider1 implements Slider
{
/**
* @JMS\Type("string")
*/
private $theme;
/**
* @JMS\Type("double")
*/
private $slideTime;
// ...
}
class Slider2 implements Slider
{
/**
* @JMS\Type("array<string>")
*/
private $effects;
/**
* @JMS\Type("boolean")
*/
private $stopOnHover;
/**
* @JMS\Type("integer")
*/
private $pauseTime;
// ...
}
To persist the BannerSet in the database using Doctrine ORM we need to provide the mapping. Using the standard relational approach we need to map BannerSet and every Slider (probably using [single table inheritance]). It means, we'll have two tables in the database "banner_set" and "slider" with one-to-one relationship between them - quite complex for storing slider configuration. The more, this approach requires to store Slider instances like Entities (we have to introduce ID to store in the table), what breaks our model., (*9)
Slider configuration is just object we need to store, but we don't need to query for it. So it's much simpler to store it in a JSON format in one column of "banner_set" table., (*10)
BannerSet Doctrine mapping file would look like:, (*11)
entity:
class: BannerSet
id:
id:
type: int
fields:
slider:
type: jms_json
And that's it!, (*12)
Obviously, we need to provide the Serializer mapping for Slider1 and Slider2 (what can be done in different ways, eg. via Annotations - check the JMSSerializer documentation for more details)., (*13)
See WebitDoctrineJsonBundle Symfony 2/3 integration., (*14)
composer install ./vendor/bin/phpunit
Introduces support for native JSON type database field. Internally data are stored in a valid JSON format ('{"_jms_type": "Deserialisation Type", "data": "DATA TO BE DESERIALISED"}'). This breaks backwards compatibility with version 1.x. Version 1.x cannot be upgraded to 2.x without manual conversion of the saved data., (*15)
Provides backwards compatibility with version 1.x on conversion to PHP Value (reading from the database). Please note, the data read from the format of version 1.x will be converted automatically to the new format during flush process of the entity., (*16)
Provides support for higher JMS Serializer versions (2.x, 3.x). This version required PHP >= 7.2., (*17)