2017 © Pedro PelĂĄez
 

library doctrine-date-time-immutable-types-bundle

Bundle integration of Doctrine DateTimeImmutable types for Symfony

image

vasek-purchart/doctrine-date-time-immutable-types-bundle

Bundle integration of Doctrine DateTimeImmutable types for Symfony

  • Friday, September 22, 2017
  • by VasekPurchart
  • Repository
  • 2 Watchers
  • 12 Stars
  • 33,752 Installations
  • PHP
  • 0 Dependents
  • 0 Suggesters
  • 4 Forks
  • 0 Open issues
  • 10 Versions
  • 10 % Grown

The README.md

Doctrine DateTimeImmutable Types Bundle

In Doctrine DBAL 2.6 immutable DateTime types were added, so this bundle no longer uses custom DateTime types implementation, but rather offers control, how the immutable types are registered, offering the possibility to replace the original DateTime types., (*1)

If you cannot upgrade to Doctrine DBAL 2.6 use 1.0 version of this bundle, which uses the vasek-purchart/doctrine-date-time-immutable-types custom DateTime types implementation., (*2)

Why would I want to use immutable types?

All Doctrine date/time based types are using DateTime instances, which are mutable. This can lead to breaking encapsulation and therefore bugs. For two reasons:, (*3)

1) You accidentally modify a date when you are doing some computation on it:, (*4)

<?php

use Doctrine\ORM\Mapping as ORM;

/**
 * @ORM\Entity()
 */
class LogRow
{

    // ...

    /**
     * @ORM/Column(type="datetime")
     * @var \DateTime
     */
    private $createdDate;

    public function getCreatedDate(): DateTime
    {
        return $this->createdDate;
    }

}
<?php

// created date might be modified
// even if this was not intended by the creator
// (there is no "setter" method for this on the entity)
var_dump($logRow->getCreatedDate()); // 2015-01-01 00:00:00
$logRow->getCreatedDate()->modify('+14 days');
var_dump($logRow->getCreatedDate()); // 2015-01-15 00:00:00

2) Or you do intentionally try to update it, which fails because Doctrine will not see this:, (*5)

<?php

$product->getRenewDate()->modify('+1 year');
$entityManager->persist($product);
// no updates will be fired because Doctrine could not detect change
// (objects are compared by identity)
$entityManager->flush();

You can prevent this behaviour by returning a new instance (cloning) or using DateTimeImmutable (which returns a new instance when modified)., (*6)

Configuration

Configuration structure with listed default values:, (*7)

# app/config/config.yml
doctrine_date_time_immutable_types:
    # Choose under which names the types will be registered.
    register: add # One of "add"; "replace"

register * add - add types as new - suffixed with _immutable (e.g. datetime_immutable) - this is already done by DBAL from version 2.6 * replace - replace the original types date, time, datetime, datetimetz, i.e. making them immutable, (*8)

Usage

If you are using the replace option, you don't need to change any property mappings of your entities., (*9)

If you are using the add option (default), you only have to suffix your field types with _immutable:, (*10)

<?php

use Doctrine\ORM\Mapping as ORM;

/**
 * @ORM\Entity()
 */
class LogRow
{

    // ...

    /**
     * @ORM/Column(type="datetime_immutable")
     * @var \DateTimeImmutable
     */
    private $createdDate;

    public function getCreatedDate(): DateTimeImmutable
    {
        return $this->createdDate;
    }

}
<?php

// created date can no longer be modified from outside
var_dump($logRow->getCreatedDate()); // 2015-01-01 00:00:00
$logRow->getCreatedDate()->modify('+14 days');
var_dump($logRow->getCreatedDate()); // 2015-01-01 00:00:00

Installation

Install package vasek-purchart/doctrine-date-time-immutable-types-bundle with Composer:, (*11)

composer require vasek-purchart/doctrine-date-time-immutable-types-bundle

Register the bundle in your application kernel:, (*12)

// app/AppKernel.php
public function registerBundles()
{
    return array(
        // ...
        new VasekPurchart\DoctrineDateTimeImmutableTypesBundle\DoctrineDateTimeImmutableTypesBundle(),
    );
}

The Versions