Skip to content

dbojdo/Doctrine-JMS-JSON

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

17 Commits
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Doctrine JMS Json Type

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).

Installation

Add "webit/doctrine-jms-json": "^2.0.0" to the require section of your composer.json

{
    "require": {
        "webit/doctrine-jms-json": "^3.0.0"
    }
}

Usage

Configure register new Doctrine DBAL type and configure the Serializer:

# 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.

See full configuration of JMS Serializer here See full documentation of Doctrine Mapping here See Doctrine Custom Types documentation here

Example

"jms_json" DBAL type can be very useful to store Value Objects or objects that structures may vary.

Consider example of a slider on a web page. Let class BannerSet contain the Slider configuration.

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:

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.

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.

BannerSet Doctrine mapping file would look like:

entity:
    class: BannerSet
    id:
        id:
            type: int
    fields:
        slider:
            type: jms_json

And that's it!

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).

Symfony 2/3 integration

See WebitDoctrineJsonBundle Symfony 2/3 integration.

Tests

composer install
./vendor/bin/phpunit

Change log

Version 2.0.0

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.

Version 2.1.0

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.

Version 3.0.0

Provides support for higher JMS Serializer versions (2.x, 3.x). This version required PHP >= 7.2.

About

Persist your Value Objects with Doctrine using JMS Serializer

Resources

Stars

Watchers

Forks

Packages

No packages published

Languages