Uploaded image for project: 'Doctrine 2 - ORM'
  1. Doctrine 2 - ORM
  2. DDC-2240

Inconsistent querying for parameter type (from ClassMetadata) between using Find/FindBy and DoctrineQL


    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Duplicate
    • Affects Version/s: 2.3.1
    • Fix Version/s: None
    • Component/s: DQL
    • Security Level: All
    • Labels:



      I have stumbled on a problem were querying the same data with different methods (findBy and DQL) retrieves different results.

      I have extended the Doctrine\DBAL\Types\DateTimeType with my own type

      which I attach.
      I expect, that whenever we deal with an entity that has a property of this type, both convertToDatabaseValue() (whenever we access the DB, conversion from DateTime to a string) and convertToPHPValue() (whenever the result from DB query is returned back, conversion from string to DateTime) have to be executed.

      It is important, as the single purpose of convertToDatabaseValue() is to perform conversion of the incoming DateTime to the UTC timezone prior to conversion to string,
      and then whenever we convert the DB value to DateTime to set it's timezone not to default value (server local timezone), but to UTC (as the values are stored in UTC).

      $entity = $em->getRepository('BVDPetroleumBundle:FuelCardTransaction')->findOneBy(array('id' => $id, 'processed_datetime' => new \DateTime('2011-03-10 23:58:37')));

      as you see, DateTime object is created without DateTimeZone set, which makes it employ the server's default timezone (say EST).

      Entity has this property registered as:

      • @ORM\Column(type="utcdatetime")
        public $processed_datetime;

      And this datatype is registered with Doctrine through Symfony2 configuration:
      utcdatetime: BVD\PetroleumBundle\DoctrineExtensions\DBAL\Types\UTCDateTimeType

      Whenever I query the DB, prior to SQL generation, DateTime is getting converted to UTC by UTCDateTimeType#convertToDatabaseValue(), and becomes:
      '2011-03-10 23:58:37' (EST) -> '2011-03-11 04:58:37' (UTC).
      Then, whenever the object is retrieved back, I expect that UTCDateTimeType#convertToPHPValue() is used to set the correct timezone information
      on the created DateTime object: '2011-03-11 04:58:37' (UTC).
      This is the correct behaviour that is expected, and is correctly achieved by using findBy methods to retrieve data:

      $entity = $em->getRepository('BVDPetroleumBundle:FuelCardTransaction')->findOneBy(array('id' => $id, 'processed_datetime' => new \DateTime('2011-03-10 23:58:37')));

      But, when the DQL is used to issue the same query:

      $queryBuilder = $em->createQueryBuilder()>select('a')>from('BVDPetroleumBundle:FuelCardTransaction','a')
      ->where('a.id = :transaction_id')
      ->andWhere("a.processed_datetime = :datetime")
      ->setParameter('transaction_id', $id)
      ->setParameter("datetime", new \DateTime('2011-03-10 23:58:37'));
      $entity = $queryBuilder->getQuery()->getOneOrNullResult();

      Doctrine\DBAL\Types\DateTimeType#convertToDatabaseValue() is getting executed for 'processed_datetime', instead of

      and the conversion doesn't happen, so the query doesn't return the result, that really exists in DB.

      I attach two methods traces, so it's easier to identify the problem: whenever the findBy is used, and whenever the DQL is used.
      I have managed to trace it to the way how both methods retrieve their $types arrays.

      The reason it succeeds when used with findBy methods:
      Doctrine\ORM\Persisters\BasicEntityPersister#load() is used to retrieve the data.
      The $types property that holds the type information ('utcdatetime') is formed by calling
      BasicEntityPersister#expandParameters($criteria), and in the process of analyzing incoming parameters it queries the entity metadata (@ORM\Column(type="utcdatetime")),
      stored in BasicEntityPersister#$_class property. (method BasicEntityPersister#getType())
      Then it's able to match type 'utcdatetime' to class BVD\PetroleumBundle\DoctrineExtensions\DBAL\Types\UTCDateTimeType

      The reason it fails with DQL:
      It seems that with DQL, it doesn't query the entity metadata (@ORM\Column(type="utcdatetime")) to derive property type. This mechanism leads the type to be recognized as simply 'datetime', and the standard handler Doctrine\DBAL\Types\DateTimeType is used instead:

      The $types (which has 'datetime' instead of 'utcdatetime') array is getting formed in
      list($sqlParams, $types) = $this->processParameterMappings($paramMappings);

      in Doctrine\ORM\Query#processParameterMappings($paramMappings)
      Doctrine\ORM\Query#processParameterValue($parameter->getValue()) is called to convert parameter from Object to string.

      in Doctrine\ORM\AbstractQuery#processParameterValue($value) for object of class DateTime I would expect this to be executed:
      case is_object($value) && $this->_em->getMetadataFactory()->hasMetadataFor(ClassUtils::getClass($value)):
      return $this->convertObjectParameterToScalarValue($value);

      but it's not, and the DateTime is returned out of it, and in Doctrine\ORM\Query\processParameterMappings $type is getting set to $parameter->getType() ('datetime')

      Please confirm/contradict the issue. Right now for workaround, whenever I use DQL, have to explicitly set the timezone of DateTime prior to issuing a query.

      From Russia with love,

      1. UTCDateTimeType.php
        2 kB
        Slavik Derevyanko
      1. DoctrineQL methods trace.png
        159 kB
      2. findBy methods trace.png
        141 kB

        Issue Links


          slavik2121 Slavik Derevyanko created issue -
          beberlei Benjamin Eberlei made changes -
          Field Original Value New Value
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Duplicate [ 3 ]
          beberlei Benjamin Eberlei made changes -
          Link This issue is duplicated by DDC-2224 [ DDC-2224 ]


            • Assignee:
              beberlei Benjamin Eberlei
              slavik2121 Slavik Derevyanko
            • Votes:
              0 Vote for this issue
              4 Start watching this issue


              • Created: