As previously reported by @flaushi in https://github.com/doctrine/doctrine2/pull/7471#discussion_r241949045, we discovered
that binding a parameter causes a `ClassMetadataFactory#getClassMetadata()` call, which in turn leads to large performance
regression when using any `object` type as parameter.
Following two snippets lead to an internal `ClassMetadataFactory#getClassMetadata()` call, which in turn leads to an
exception being thrown and garbage collected, plus multiple associated performance implications:
```php
$query->setParameter('foo', new DateTime());
$query->getResult();
```
```php
$query->setParameter('foo', new DateTime(), DateTimeType::NAME);
$query->getResult();
```
This is due to following portion of code:
434820973c/lib/Doctrine/ORM/Query.php (L406-L409)
Notice how `$value = $this->processParameterValue($value);` happens before attempting to infer the type for the parameter value.
That call leads to this segment being reached, which leads to the regression:
434820973c/lib/Doctrine/ORM/AbstractQuery.php (L423-L433)
Assuming the bound parameter type is provided, we can completely skip attempting to introspect the given object:
```php
$query->setParameter('foo', new DateTime(), DateTimeType::NAME);
$query->getResult();
```
Processing the parameter value is not needed in this case, so we can safely skip that logic for all known parameters.
In order to not introduce a BC break or change the `AbstractQuery#processParameterValue()` implementation, we could filter
out all parameters for which the type is given upfront, and later on merge them back in instead.
The test expectation to be set is for `UnitOfWork#getSingleIdentifierValue()` to never be called.
There was a bug in the "INSTANCE OF" operator as described in
https://groups.google.com/forum/#!topic/doctrine-user/B8raq8CNMgg
"INSTANCE OF" was not taking into account subclasses.
It was merely translating the class to its discriminator.
This is not correct since the class can have subtypes and those
are, indeed, still instance of the superclass.
Also, classes may not have a discriminator (e.g. abstract classes).
This commit also provides useful tests to avoid regression.
expr()->countDistinct allows to create COUNT(DISTINCT) expression with mulltiple fields but parser requires only one field.
\Doctrine\ORM\Query\Parser::AggregateExpression
some body, please, fix this problem