called when not specifying the type of a DQL parameter being bound via
`Doctrine\ORM\Query#setParameter()`:
```php
$query->setParameter('foo', $theValue, $theType);
```
A full parameter bind is required in order to gain back performance:
```php
$query->setParameter('foo', $theValue, $theType);
```
This is up for discussion with patch reviewers.
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.
Now using PHP to calculate the expected date manipulation, keeping a day
as delta since PHP resets the hour when performing operations with
days/weeks/months/years.
February is a wonderful month, isn't it?
SchemaTool has custom logic for creating the primary key of a
joined-table inherited entity. This logic overlooked association maps
as a possible source for identity columns, resulting in a fatal error
when fetching the primary key list for child entities.
Removed any custom logic for generating primary keys for root entities
in joined-table inheritance, deferring to the common logic used for
other entities.
Also adjusted the child entity logic, scanning association maps for
identity columns, and including the column as appropriate. It also
ensures that the primary key columns are in the correct order.
Right now, when generating entities, a column of type 'guid' will generate the following PHPDoc:
```
/**
* Get id
*
* @return guid
*/
public function getId() {...}
```
Since guid is not a valid PHP type, this throws a warning in PHPStorm, and I assume most IDEs.
Adding the type to the type alias list fixes the problem.
