Download the PHP package webit/doctrine-jms-json without Composer
On this page you can find all versions of the php package webit/doctrine-jms-json. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download webit/doctrine-jms-json
More information about webit/doctrine-jms-json
Files in webit/doctrine-jms-json
Package doctrine-jms-json
Short Description Converts complex objects using JMS Serializer
License MIT
Informations about the package doctrine-jms-json
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
Usage
Configure register new Doctrine DBAL type and configure the Serializer:
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.
There are plenty of different JavaScript slider configurations so we don't know in advance the Slider structure. Let's introduce two implementations:
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:
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.
All versions of doctrine-jms-json with dependencies
ext-json Version *
jms/serializer Version ^2.0.0|^3.0.0
doctrine/dbal Version ^2.10.0|^3.0.0
doctrine/collections Version ^1.5.0|^2.0.0