Sylius and MongoDB It’s not just changing connection strings

No content

MongoDB and Sylius It’s not a simple story

Let’s talk about schemas

Relational databases Some say they are simple • Normalisation rules help us design “good” schemas • Have a primary key, add everything that depends on this primary key • If it’s not directly related to the primary key, extract it • ??? • Pro fi t!

MongoDB Schemas are just as complicated • MongoDB is not “schemaless” • It has a schema, but it is fl exible • It avoids some constraints from relational databases • After all, they’re from the 1970s

Don’t think about storing data

Think about consuming it

Example Address Book Data { "name": "alcaeus", "email": [ "", "" ], "phone": [ "", "" ] }

Example Fancy Address Book Data { "name": "alcaeus", "email": [ { "type": "work", "address": "" }, { "type": "private", "address": "" } ], "phone": [ { "type": "mobile", "number": "" }, { "type": "home", "number": "" } ] }

Time for Queries Everybody loves queries, right? SELECT entry.* from entry JOIN email ON email.entry_id = entry.id WHERE email.address = 'something';

Effects of Normalisation Does it help? • Need to join across tables to fi nd our main record • Only get main data • Multiple queries required to fetch rest of data • Alternative: complicated result preparation • How does this help?

Time for Queries #2 I love THOSE queries { "email.address": "something" }

Normalisation is a Relic

Sylius and MongoDB

Sylius and MongoDB What’s the big problem? • Sylius uses Doctrine ORM • Doctrine ORM and Doctrine MongoDB ODM are very similar • Interfaces are shared, entities can be shared • How hard can it be?

Read ORM mappings in ODM?

ERD Product

From ERD to Tables From Many to More CREATE TABLE sylius_channel (...); 
 
 CREATE TABLE sylius_product_option (...); 
 CREATE TABLE sylius_product_option_translation (...); 
 CREATE TABLE sylius_product_option_value (...); 
 CREATE TABLE sylius_product_option_value_translation (...); 
 CREATE TABLE sylius_product_attribute (...); 
 CREATE TABLE sylius_product_attribute_translation (…); 
 CREATE TABLE sylius_taxon (...); 
 CREATE TABLE sylius_taxon_translation (...); 
 CREATE TABLE sylius_product (...); 
 CREATE TABLE sylius_product_translation (...); 
 CREATE TABLE sylius_product_image (...); 
 CREATE TABLE sylius_product_attribute_value (...); 
 CREATE TABLE sylius_product_channels (...); 
 CREATE TABLE sylius_product_taxon (...); 
 CREATE TABLE sylius_product_options (...); 
 CREATE TABLE sylius_product_variant (...); 
 CREATE TABLE sylius_product_variant_option_value (...); 
 CREATE TABLE sylius_channel_pricing (...);

From Tables to Collections Making use of advanced schema types • References point to related data • Embedded documents include all related data • Could be used in relational databases (jsonb / complex types) • Advantages to both • It’s important to understand when to choose which

Taxons Embedded Translations { "_id": "...", "code": "...", "translations": { "en": { "slug": "hardware", "name": "Hardware", "description": "..." }, "de": { "slug": "hardware", "name": "Hardware", "description": "..." } } }

Taxons Simpli fi ed Translations { "_id": "...", "code": "...", "slug": { "en": "hardware", "de": "hardware" }, "name": { "en": "Hardware", "de": "Hardware" }, "description": { "en": "...", "de": "..." } }

Options Embedded Values { "_id": "...", "code": "length", "name": { "en": "Length", "de": "Länge" }, "values": [ { “code": "length-1-m“, "value": { "en": "3 ft", "de": "1 m" } } ] }

Product Referencing Options { "_id": "...", "code": "lightning-cable", "options": [ "...", "...", "..." ] }

Product ODM References { "_id": "...", "code": "lightning-cable", "options": [ { "ref": "sylius_product_option", "id": "..." }, { "ref": "sylius_product_option", "id": "..." }, { "ref": "sylius_product_option", "id": "..." } ] }

These mappings require effort

But we’re just getting started

Referencing or embedding? Is there another way? • Example: linking product variants and their option values • We don’t own the data, so we should use references • We don’t want to join, so embedded data would be best • We can’t reference an embedded document • Why not do both?

Product Hybrid References { "_id": "...", "code": "lightning-cable", "options": [ { "ref": "sylius_product_option", "id": "...", "code": "length", "name": { "en": "Length", "de": "Länge" } } ] }

Product Variant Hybrid References { "_id": "...", "code": "lightning-cable-1-m", "position": 0, "options": { "length": { "code": "length-1-m", "value": { "en": "3 ft", "de": "1 m" } } } }

Product Variant Embed All The Variants? { "_id": "...", "code": "lightning-cable", "options": [ ... ], "variants": [ { "code": "lightning-cable-1-m", "options": { "length": { "code": "length-1-m", "value": { "en": "3 ft", "de": "1 m" } } } } ] }

Transactions

Transactions Quick facts • MongoDB is ACID compliant • You can run multi-document transactions • No nested transactions • Good schema design can help you avoid them • Doctrine MongoDB ODM doesn’t support them

Transactions In a nutshell • Start transaction • Do your business logic • Commit transaction • (Or abort if you’ve decided otherwise) • Rollback on error

Transactions In MongoDB $session = $client->startSession(); $session->startTransaction(); // Complex database logic here $session->commitTransaction();

Transactions Retry Failed Commits $session->startTransaction(); // Complex database logic here while (1) { try { $session->commitTransaction(); } catch (RuntimeException $e) { if ( $e->getCode() !== 50 /* MaxTimeMSExpired */ && $e->hasErrorLabel('UnknownTransactionCommitResult') ) { // Retry committing the transaction continue; } throw $e; } }

Transactions Retry Failed Transactions while (1) { $session->startTransaction(); // Complex database logic here while (1) { try { $session->commitTransaction(); } catch (RuntimeException $e) { if ( $e->getCode() !== 50 /* MaxTimeMSExpired */ && $e->hasErrorLabel('UnknownTransactionCommitResult') ) { // Retry committing the transaction continue; } if ( $e->hasErrorLabel('TransientTransactionError') ) { // Restart transaction continue 2; } throw $e; } } }

Transactions Keep It Simple $doComplexDatabaseLogic = function (Session $session): void { // Complex database logic here }; $session = $client->startSession(); \MongoDB\with_transaction( $session, $doComplexDatabaseLogic, );

Transactions With Doctrine MongoDB ODM $session = $client->startSession(); \MongoDB\with_transaction( $session, function (Session $session) use ($documentManager): void { $documentManager->flush(['session' => $session]); } );

Transactions With Doctrine MongoDB ODM $session = $client->startSession();

What’s Next?

The ecosystem needs updating

Ecosystem Updates Doctrine MongoDB ODM • Support transactions in UnitOfWork • Support new update mechanisms • Support hybrid references • Support updating hybrid references

Ecosystem Updates Doctrine Extensions • Update Translation extension to leverage embedded documents • Update Tree extension to support nested set in ODM • Update Sortable extension to support ODM

Ecosystem Updates Sylius • Create mapping fi les for Doctrine MongoDB ODM • Create repositories and rewrite queries

Open Source needs YOU

Thanks! @alcaeus github.com/alcaeus symfony-devs: @alcaeus