[DDC-3360] Problem custom name sequeceGenerator YAML for annotatition entities Created: 22/Oct/14  Updated: 29/Oct/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers
Affects Version/s: 2.3.3
Fix Version/s: None
Security Level: All

Type: Bug Priority: Critical
Reporter: Sandro Cândido de Oliveira Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Hi Benjamin

Problem custom name sequeceGenerator YAML why not create the custom name you want. Being created the default postgres, where is the problem?

Note: https://groups.google.com/forum/#!topic/doctrine-user/7ctTFGWu4mo

Message:

  type: entity
  id:
    id:
      type: integer
      generator:
        strategy: SEQUENCE
      sequenceGenerator:
        sequenceName: message_sq
        allocationSize: 100
        initialValue: 1

The entity is created like this:

namespace message\models\entities;

use Doctrine\ORM\Mapping as ORM;

/**
 * Message
 *
 * @ORM\Table(name="message")
 * @ORM\Entity
 * @ORM\HasLifecycleCallbacks
 */
class Message
{
    /**
     * @var integer
     *
     * @ORM\Column(name="id", type="integer")
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="SEQUENCE")
     * @ORM\SequenceGenerator(sequenceName="message_id_seq", allocationSize=1, initialValue=1)
     */

Should be created as specify:

/**
 * Message
 *
 * @ORM\Table(name="message")
 * @ORM\Entity
 * @ORM\HasLifecycleCallbacks
 */
class Message
{
    /**
     * @var integer
     *
     * @ORM\Column(name="id", type="integer")
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="SEQUENCE")
     * @ORM\SequenceGenerator(sequenceName="message_sq", allocationSize=1, initialValue=1)
     */


 Comments   
Comment by Marco Pivetta [ 22/Oct/14 ]

Is the bug reproducible also in 2.4.6?

Comment by Steve Müller [ 22/Oct/14 ]

Moved to ORM issue tracker. This is not DBAL related.

Comment by Sandro Cândido de Oliveira [ 29/Oct/14 ]

Hi

Is the bug reproducible also in 2.4.6 and 2.5.0-DEV





[DDC-3346] findOneBy returns an object with partial collection for the properties with mapping oneToMany/Fetch Eager Created: 10/Oct/14  Updated: 10/Oct/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4.6
Fix Version/s: None
Security Level: All

Type: Bug Priority: Critical
Reporter: Adrien Russo Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None


 Description   

findOneBy returns an object with partial collection for the properties with mapping oneToMany/Fetch Eager. This bug appear only for entities without inheritance.

Mapping
       
Test\Bar:
    type: entity
    table: bar
    fields:
        code:
            type: string
    oneToMany:
        posts:
            targetEntity: Test\Post
            fetch: EAGER
            mappedBy: bar
            cascade: ['all']
    
Test\Post:
    type: entity
    table: post
    fields:
        content:
            type: text
    manyToOne:
        bar:
            targetEntity: Test\Bar
            cascade: []
            joinColumn:
                name: bar_id
                referencedColumnName: id
Data
    
$bar = new \Test\Bar('foo');
$bar->addPost(
  new Test\Post('toto')
);
$bar->addPost(
  new Test\Post('tata')
);
 
$bar->getPosts()->count(); #value is 2
$manager->persist($bar);
$manager->flush();
FindOneBy with fetch eager
$bar = $repository->findOneBy(['code' => 'foo']);
$bar->getPosts()->count(); #value is 1
FindOneBy with fetch Lazy
$bar = $repository->findOneBy(['code' => 'foo']);
$bar->getPosts()->count(); #value is 2

I think this bug is due to the LIMIT 1 clause happening on findOneBy which also applies on joins generated here.

For instance, the generated SQL statement generated might look like

Sql Statement
SELECT
	t0. ID AS id_1,
	t0.code AS code_2,
	t1. ID AS id_3,
	t1.content AS content_4,
	t1.bar_id AS bar_id_5
FROM
	bar t0
LEFT JOIN post t1 ON t1.bar_id = t0. ID
WHERE
	t0. code = 'foo'
LIMIT 1





[DDC-3343] `PersistentCollection::removeElement` schedules an entity for deletion when relationship is EXTRA_LAZY, with `orphanRemoval` false. Created: 09/Oct/14  Updated: 13/Oct/14

Status: Awaiting Feedback
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.2, 2.3, 2.4
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Andrea Sprega Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mapping, orm


 Description   

Given the following entity for which I only report the relevant association:

class Group
{
    /**
     * @ORM\OneToMany(targetEntity="User", mappedBy="group", fetch="EXTRA_LAZY")
     */
    protected $users;
    //...
}

and its inverse

class User
{
    /**
     * @ORM\ManyToOne(targetEntity="Group", inversedBy="users")
     * @ORM\JoinColumn(name="group_id", onDelete="SET NULL")
     */
    protected $group;
    //...
}

I experience a weird issue when, inside Group, I call $this->users->removeElement($user): Doctrine schedules the $user entity for deletion, no matter what (it doesn't check for the orphanRemoval attribute). Also, even re-adding the entity to a new Group before the flush() occurs doesn't prevent it from being deleted.

I believe this is a bug, since I do not see any special mention of this behavior in the documentation for extra lazy associations:
http://doctrine-orm.readthedocs.org/en/latest/tutorials/extra-lazy-associations.html.

The workaround for me has been to remove fetch="EXTRA_LAZY" from the relationship.

After digging a little bit into the source code, this seems to be the commit (and the line) that introduced this behavior:

https://github.com/doctrine/doctrine2/commit/356f5874bf81ca4e37681c233e24cc84d16e7a39#diff-108586f774fc8acb02163ed709e05e86R403

I also found this on Google:

https://groups.google.com/forum/#!topic/doctrine-user/cx_yBuoqiAE

which basically didn't help much, except for suggesting that it should be a feature when there is an orphanRemoval and/or a cascade operation in place (and that makes perfectly sense).

I set this to "critical" since (as it occurred to me) it can lead to irrecoverable data loss.

Is this effectively a bug?






[DDC-3336] Undefined property: Doctrine\ORM\Query\AST\SimpleArithmeticExpression::$field Created: 04/Oct/14  Updated: 26/Oct/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: 2.4.4
Fix Version/s: None
Security Level: All

Type: Bug Priority: Critical
Reporter: Glen Ainscow Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Reference
relates to DDC-1958 pager produces wrong results on postg... Resolved

 Description   

I upgraded from 2.4.1 to 2.4.4, and now I'm seeing this notice here & there: Undefined property: Doctrine\ORM\Query\AST\SimpleArithmeticExpression::$field in /*/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/Pagination/LimitSubqueryOutputWalker.php on line 200

This seems to be in a method with the description "Generates new SQL for Postgresql or Oracle if necessary." ... but we're on MySQL (Percona).



 Comments   
Comment by Glen Ainscow [ 05/Oct/14 ]

Changed this to critical. It's also screwing up ordering, for example:

SELECT tp, p, CASE WHEN tp.memberTo IS NULL THEN 1 ELSE 0 END AS HIDDEN ord FROM Tournaments_Model_TeamPlayer tp INNER JOIN tp.player p LEFT JOIN p.user u WHERE tp.team = ?1 ORDER BY ord DESC, tp.memberFrom ASC

The paginator doesn't order the data correctly unless I remove the 2nd order by (tp.memberFrom ASC). The generated SQL from the QB/DQL is correct, so the paginator must be messing something up.

See: http://www.doctrine-project.org/jira/browse/DDC-1958?focusedCommentId=24010&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-24010

Comment by Marco Pivetta [ 13/Oct/14 ]

Need a test case in order to verify the issue

Comment by Glen Ainscow [ 26/Oct/14 ]

Okay, try this:

        $qb->from('Team', 't')
              ->select('t')
              ->orderBy('(1-1000)*1', 'DESC')
              ->getQuery()
              ->getResult();

This is simplified, the actual query works with field values, like this:

        ->orderBy('(((t.eloRating-1000)*t.reliability) + 1000)', 'DESC')

This causes the first issue.

Comment by Glen Ainscow [ 26/Oct/14 ]

The second issue is explained by Guilherme Santos.





[DDC-3212] Remove ArrayHydrator logic Created: 14/Jul/14  Updated: 13/Oct/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.5
Fix Version/s: 3.0
Security Level: All

Type: Improvement Priority: Critical
Reporter: Marco Pivetta Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: hydration, hydrator


 Description   

The Doctrine\ORM\Internal\Hydration\ArrayHydrator ( https://github.com/doctrine/doctrine2/blob/85fbf684363b932a4ebaf543ef059f9ee1e512b0/lib/Doctrine/ORM/Internal/Hydration/ArrayHydrator.php ) is currently very messy and complicated due to the lack of actual Doctrine\ORM\UnitOfWork references when working with it, since we are not dealing with objects.

In order to reduce the amount of bugs and code duplication when working with array hydration, I would simply suggest making use of the Doctrine\ORM\Internal\Hydration\ObjectHydrator ( https://github.com/doctrine/doctrine2/blob/85fbf684363b932a4ebaf543ef059f9ee1e512b0/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php ) and its siblings, and then extracting data coming from the results in it as an array.

This could be a simple reflection-based extraction (pseudo):

class ArrayHydrator
{
    public function hydrateAllData()
    {
        foreach ($this->objectHydrator->hydrateAllData() as $object) {
            yield $this->extractData($object);
        }
    }
}

The point here is that array-based hydration is not the primary focus of the ORM, and users should probably rely on SQL only when they want array hydration.



 Comments   
Comment by Marco Pivetta [ 14/Jul/14 ]

Note: performance is one of our biggest requirements, and array hydration is meant to achieve that. As I stated above, plain SQL is probably better for this sort of operation, so the issue is more about deprecating the ArrayHydrator completely, providing utilities to manipulate SQL resultsets instead.





[DDC-3062] [GH-997] [FIX] Allow to use ManyToMany with all operators Created: 31/Mar/14  Updated: 08/Jul/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Critical
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of bakura10:

Url: https://github.com/doctrine/doctrine2/pull/997

Message:

Hi,

ping @guillhermoblanco : I think this may be blocking for 2.5

I introduced not so long ago support for ManyToMany for Criteria. However, I realized my implementation was really incomplete, because I hard-coded the "=" operator (https://github.com/doctrine/doctrine2/pull/885/files#diff-982b7374bbe9d5f4b6b71f4869a446eaR575). This means that it fails in a lot of cases when you use something different than "eq" for Criteria.

This PR fixes that, however it's a bit hacky. The SqlExpressionVisitor was made by type hinting for a BasicEntityPersister, preventing us from using us for a collection persister. Therefore I added a new interface to keep BC.

There is also a lot of code duplication (the whole "getSelectConditionSQL" was copied from the BasicEntityPersister), but without trait or BC, I have no idea about how to solve it.

All tests pass, test were added for other operators.






[DDC-2953] ArrayHydrator: Not all items hydrated while orderBy Created: 05/Feb/14  Updated: 18/Aug/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.3.4, 2.4.1
Fix Version/s: None
Security Level: All

Type: Bug Priority: Critical
Reporter: Mariusz Jaskółka Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: array, hydration
Environment:

Linux and Windows, PHP5


Attachments: File ArrayHydrator.php     File Array_Hydrator_4.2.php     File Array_hydrator_4.2_bugfix.php    
Issue Links:
Dependency
depends on DDC-2955 [GH-933] [WIP] DDC-2953 Resolved

 Description   

I will explain the problem using example and pseudo-code:

I have query like that:
SELECT (...) FROM order LEFT JOIN person LEFT JOIN identifier (...) order by (...)

The rows returned by query are following (the order is very important):
order_id|person_id|identifier_id|
12 |21 |33 |
12 |21 |34 |
11 |21 |35 |
11 |21 |33 |
11 |21 |34 |
12 |21 |35 |

After hydration the result is like:
result[0][person][identifier][0][id]=33
result[0][person][identifier][0][id]=34
result[1][person][identifier][0][id]=35
result[1][person][identifier][0][id]=34

But it should be:
result[0][person][identifier][0][id]=33
result[0][person][identifier][0][id]=34
result[0][person][identifier][0][id]=35
result[1][person][identifier][0][id]=35
result[1][person][identifier][0][id]=34
result[1][person][identifier][0][id]=33

The reason is that ArrayHydrator::_identifierMap contains only object id and parents object id. In may example there is difference in parents parent (grandparent) id.



 Comments   
Comment by Marco Pivetta [ 05/Feb/14 ]

I've started work on this at https://github.com/doctrine/doctrine2/pull/933

Comment by Mariusz Jaskółka [ 06/Feb/14 ]

This is how I temporary solved the issue, maybe it can help (attachment).

Comment by Marco Pivetta [ 06/Feb/14 ]

Mariusz Jaskółka can you provide a diff with current master? This seems to be based off 2.3 or previous versions...

Comment by Mariusz Jaskółka [ 06/Feb/14 ]

Version 2.4.2 oryginal file and bugfix

Comment by Mariusz Jaskółka [ 06/Feb/14 ]

Oh sorry it is version 2.4.1 (composer downloaded that version for me).
I hope it will be ok.

Comment by Marco Pivetta [ 06/Feb/14 ]

Mariusz Jaskółka thanks! I'm trying it right now

Comment by Mariusz Jaskółka [ 06/Feb/14 ]

I added one dimention to $this->_identifierMap to be sure that all object's children's keys will be mapped separately.

Comment by Marco Pivetta [ 06/Feb/14 ]

Mariusz Jaskółka, I've applied your hotfix at https://github.com/doctrine/doctrine2/commit/c05921032ff6947daca2d7275031e5cde4700634 and the tests seem to pass on my system and on travis. You may want to check it out and see if it works for your use case.

Comment by Mariusz Jaskółka [ 06/Feb/14 ]

It works for my use case correctly. You apparently forgot to remove/comment line 82 which is not necessary now.

Comment by Marco Pivetta [ 06/Feb/14 ]

Mariusz Jaskółka fixed, thanks!

Comment by Marco Pivetta [ 14/Jul/14 ]

I don't think we'll have a fix for this issue for 2.5, as it will probably require a complete rewrite of the array hydrator

Comment by Guilherme Blanco [ 14/Jul/14 ]

... and introducing BC breaks.

Comment by Doctrine Bot [ 18/Aug/14 ]

A related Github Pull-Request [GH-933] was closed:
https://github.com/doctrine/doctrine2/pull/933





[DDC-3367] [GH-1171] Improvements for complex select statements when using new object expression Created: 28/Oct/14  Updated: 28/Oct/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of jaimz22:

Url: https://github.com/doctrine/doctrine2/pull/1171

Message:

My update allows you to alias objects created with the ["new" object expression](http://doctrine-orm.readthedocs.org/en/latest/reference/dql-doctrine-query-language.html#new-operator-syntax), as well as the ability to create queries that allow you to have multiple "new" object expressions and mixed scalar results.

Suppose you create a query as such:

```dql
SELECT new UserDTO(u.id,u.name) as user,new AddressDTO(a.street,a.postalCode) as address, a.id as addressId FROM User u INNER JOIN u.addresses a WITH a.isPrimary = true
```

upon executing this query, you'll end up with a result set that looks like the following:

```php
array(
0=>array(
0=>

{UserDTO object},
1=>{AddressDTO object},
2=>{u.id scalar},
3=>{u.name scalar},
4=>{a.street scalar},
5=>{a.postalCode scalar},
'addressId'=>{a.id scalar},
),
...
)
```

My changes fix that so you'd end up with a more usable result set:

```php
array(
0=>array(
'user'=>{UserDTO object}

,
'address'=>

{AddressDTO object}

,
'addressId'=>

{a.id scalar}

)
...
)
```






[DDC-3366] [GH-1170] Added prev to collections Created: 26/Oct/14  Updated: 26/Oct/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of wshafer:

Url: https://github.com/doctrine/doctrine2/pull/1170

Message:

Added prev() to array collections. This is needed when you want to cycle through the array in reverse order.






[DDC-3364] QueryBuilder fails when using alias in having with like expr Created: 21/May/14  Updated: 26/Oct/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Webdevilopers Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: GROUP_CONCAT, dql, expression, having, like, mysql
Environment:

Debian, MySQL, PHP, Zend Framework 2, Doctrine Module, Doctrine Extensions



 Description   

In my select I create an alias. I use a like expr on this alias in the having clause.

Trying several variations I still get the following error:
Expected '.' or '(', got 'long_name'

My example including variations inside comments:

$having = $qb->expr()->like('long_name', $qb->expr()->literal('%' . $term . '%'));

$qb->select(array(
    'b.id', 'b.name AS branch_name',
    'c.name AS company_name',
    'GroupConcat(b.name, \', \', c.name) AS long_name' // same for 'c.name AS long_name'
))
->from('Application\Entity\Branch', 'b')
->join('b.company', 'c')
->where('b.compartment = 1')
->having('(' . $having . ')') // same for having($having)
->groupBy('c.id')
->orderBy('c.name')
->addOrderBy('b.name');

I use a Doctrine Extension for the MySQL GROUP_CONCAT functionality:
https://github.com/beberlei/DoctrineExtensions/blob/master/lib/DoctrineExtensions/Query/Mysql/GroupConcat.php

This should have no effect on the result since I tried a simple alias - see comment - instead of it.

The problem seems to be using an alias inside the having clause when adding the like expr.
The following clause would work:

$having = $qb->expr()->like('c.name', $qb->expr()->literal('%' . $term . '%'));

I also tried this workaround using the GROUP_CONCAT method inside the where part:

->andWhere($qb->expr()->like('GroupConcat(b.name, \', \', c.name)', $qb->expr()->literal('%' . $term . '%')))

Allthough I used the groupBy part I got this error:
General error: 1111 Invalid use of group function



 Comments   
Comment by Marco Pivetta [ 26/Jun/14 ]

What is the actual failure/exception type? What about the generated SQL?

Comment by Steve Müller [ 26/Oct/14 ]

Moved to ORM, the error and use case is ORM related.





[DDC-3363] "The EntityManager is closed." after insert error. Created: 25/Oct/14  Updated: 25/Oct/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4.6
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Ksaveras Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   
               try {
                    $em = $this->getContainer()->get('doctrine')->getManager();
                    $em->persist($article);
                    $em->flush();
                } catch (\Exception $e) {
                    $output->writeln($e->getMessage());
                }

If flush will generate error - all other flush operations will end with error: "The EntityManager is closed.".

Internet says that recreating EM is almost imposible without using own EM management code.

WHY i have to code EM management code to use EM? It's Doctrine's task to manage EM.

I just want to use try catch and process errors - Closing and opening connections it's Doctrine's task.

This task (reopen connection) should be done by Doctrine.






[DDC-3362] [GH-1168] [DDC-1952] Support for array parameters on the SQLFilter Created: 24/Oct/14  Updated: 24/Oct/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of xpavp03:

Url: https://github.com/doctrine/doctrine2/pull/1168

Message:

Allows passing an array to SQLFilter parameter and have each item pass through quote() before turning the whole array into a comma-separated list.

For purpose see here:
http://www.doctrine-project.org/jira/browse/DDC-1952

Exception is made for types that Doctrine already recognizes as an array and stores as their derivate (array, simple_array, json_array).



 Comments   
Comment by Doctrine Bot [ 24/Oct/14 ]

A related Github Pull-Request [GH-1168] was assigned:
https://github.com/doctrine/doctrine2/pull/1168





[DDC-3361] Doctrine error while trying to execute a DQL query on PostgreSQL 9.2.x Created: 23/Oct/14  Updated: 23/Oct/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: DQL
Affects Version/s: 2.4.6
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Reynier Perez Mira Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: postgresql, typecast
Environment:

CentOS 6.5, PostgreSQL 9.2, Symfony 2.5.5, Doctrine 2.4.6



 Description   

I have this DQL on a repository class:

    public function filterNorm($codigo = null, $anno = null, $term = null, $comite_tecnico = null)
    {
        $qb = $this->getEntityManager()->createQueryBuilder();
        $qb
                ->select('n')
                ->from("AppBundle:Norma", "n");

        if ($codigo != NULL) {
            $qb->where(
                    $qb->expr()->like('n.numero', $qb->expr()->literal('%'.$codigo.'%'))
            );
        }

        if ($anno != NULL) {
            $qb->orWhere(
                    $qb->expr()->like('n.anno', $qb->expr()->literal('%'.(int) $anno.'%'))
            );
        }

        if ($term != NULL) {
            $qb->orWhere(
                    $qb->expr()->like('n.nombre', $qb->expr()->literal('%'.$term.'%'))
            );
        }

        if ($comite_tecnico != NULL) {
            $qb->orWhere(
                    $qb->expr()->like('n.comite_tecnico', $qb->expr()->literal('%'.(int) $comite_tecnico.'%'))
            );
        }

        return $qb->getQuery()->getResult();
    }

And when I try to execute it, leaving the first paramter null, I got this error:

An exception occurred while executing 'SELECT n0_.numero AS numero0, n0_.anno AS anno1, n0_.id AS id2, n0_.nombre AS nombre3, n0_.activo AS activo4, n0_.comite_tecnico_id AS comite_tecnico_id5 FROM nomencladores.norma n0_ WHERE n0_.anno LIKE '%34%' OR n0_.nombre LIKE '%sad%'':

SQLSTATE[42883]: Undefined function: 7 ERROR: operator does not exist: integer ~~ unknown
LINE 1: ...o_id5 FROM nomencladores.norma n0_ WHERE n0_.anno LIKE '%34%...
^
HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. 

I think in somewhere Doctrine is failing or not, not so sure, if not what will be the solution around this issue I'm having?



 Comments   
Comment by Marco Pivetta [ 23/Oct/14 ]

First of all: do not hardcode parameters in your DQL, as that represents a possible DQL injection vector.

Is your schema in sync with the ORM mappings? Postresql seems to complain about a missing operator between incompatible types.

Comment by Reynier Perez Mira [ 23/Oct/14 ]

What you mean with "do not hardcode parameters in your DQL"? How should I do this? And yes schema and ORM mappings are good:

Symfony > doctrine:schema:validate
[Mapping] OK - The mapping files are correct.
[Database] OK - The database schema is in sync with the mapping files.

Comment by Marco Pivetta [ 23/Oct/14 ]

What you mean with "do not hardcode parameters in your DQL"? How should I do this?

You wrote:

$qb->where($qb->expr()->like('n.numero', $qb->expr()->literal('%'.$codigo.'%')));

Should be:

$qb->where($qb->expr()->like('n.numero', ':codigo'));
$qb->setParameter('codigo', '%' . $codigo . '%');




[DDC-3358] [GH-1166] Fixing HHVM+XSD validation tests as of documented HHVM inconsistencies Created: 20/Oct/14  Updated: 20/Oct/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of Ocramius:

Url: https://github.com/doctrine/doctrine2/pull/1166

Message:

See https://github.com/facebook/hhvm/blob/3445a26e54faba5828eb6b8f6e74e52b472cf282/hphp/doc/inconsistencies#L131-L134 as a reference



 Comments   
Comment by Doctrine Bot [ 20/Oct/14 ]

A related Github Pull-Request [GH-1166] was assigned:
https://github.com/doctrine/doctrine2/pull/1166





[DDC-3354] Replacing indexed item on association with indexBy cannot comply with unicity constraint Created: 17/Oct/14  Updated: 19/Oct/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4.6
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Charles Bouchard-Légaré Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: collection, mapping, orm


 Description   

Using a bidirectional one-to-many relation having an 'indexBy' clause on the owning side and a unique constraint over the indexed field and the 'mappedBy' field of the inverse side, replaced indexed fields being inserted before removed violated the unique constraint.

As stated in the code examples below, if done without the unique constraint, when replacing an indexed field, the row is replaced in the database (new one created, old one deleted).

Here is an example:

Yaml Mapping for Person and Email
Person:
    type: entity
    id:
        id:
            type: integer
            generator:
                strategy: AUTO
    oneToMany:
        emailAddresses:
            targetEntity: Email
            indexBy: name
            mappedBy: owner
            cascade: [ all ]
            orphanRemoval: true

Email:
    type: entity
    id:
        id:
            type: integer
            generator:
                strategy: AUTO
    fields:
        name:
            type: string
            nullable: false
        address:
            type: string
            nullable: false
    uniqueConstraints:
        unique_named_person_email:
            columns: [ owner_id, name ]
    manyToOne:
        owner:
            targetEntity: Person
            inversedBy:   emailAddresses
            joinColumn:
                name: owner_id
                referencedColumnName: id
PHP definitions for Person and Email
class Person {
    protected $id;
    /**
     * @var Collection|Email[] $emailAddresses
     */
    protected $emailAddresses;

    /**
     * I would expect this to work.
     */
    public function setEmailAddress_expected($name, $emailAddress)
    {
        /**
         * Expected to work but throws UniqueConstraintViolationException
         * If done without the 'unique_named_person_email' constraint', it 
         * works properly creating a new Email and deleting the old one.
         */
        $this->emailAddresses->set(
            (string) $name,
            new Email($this, (string) $name, (string) $emailAddress)
        );
    }
    
    /**
     * I would expect this to work.
     */
    public function setEmailAddress_expected_too($name, $emailAddress)
    {
        /**
         * Expected to work but throws UniqueConstraintViolationException
         * If done without the 'unique_named_person_email' constraint, it 
         * works properly creating a new Email and deleting the old one.
         */
        $this->emailAddresses->remove((string) $name);
        $this->emailAddresses->set(
            (string) $name,
            new Email($this, (string) $name, (string) $emailAddress)
        );
    }

    /**
     * Works
     */
    public function setEmailAddress_works($name, $emailAddress)
    {
        $existing = $this->emailAddresses->get((string) $name);
        if ($existing) {
            $existing->setAddress((string) $emailAddress);
        } else {
            $this->emailAddresses->set(
                (string) $name,
                new Email($this, (string) $name, (string) $emailAddress)
            );
        }
    }
}

class Email {
    protected $id;
    protected $owner;
    protected $name;
    protected $address;
    public function __construct($owner, $name, $address)
    {
        $this->owner = $owner;
        $this->name = $name;
        $this->address = $address;
    }

    /**
     * I am forced to create this method.
     */
    public function setAddress($address)
    {
        $this->address = $address;
    }
}

IMO, Using 'indexBy' on a one-to-many relation should automatically generate a unique constraint for the combination of the indexed field and the 'mappedBy' field.

Documentation states that

Fields that are used for the index by feature HAVE to be unique in the database. The behavior for multiple entities with the same index-by field value is undefined.

which is unclear (especially the use of the word 'database'). I wonder why indexes used for association should be unique for a whole table.



 Comments   
Comment by Marco Pivetta [ 19/Oct/14 ]

I wonder why indexes used for association should be unique for a whole table.

That's because we can't ensure that indexes aren't overwritten when hydrating a collection: that is what the behavior "undefined" stands for.

As for replacing values in the collection, that's how the ORM works in any case, as it inserts data before removing any data to avoid removes from causing FK constraint failures (see https://github.com/doctrine/doctrine2/blob/d361ed904e5d56711304b755b5b2a8484d9a35b6/lib/Doctrine/ORM/UnitOfWork.php#L347-L379)





[DDC-3352] [GH-1162] DDC-3349: Possibility to override order of fields of composite ID produc... Created: 14/Oct/14  Updated: 19/Oct/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Reference
is referenced by DDC-3349 Possibility to override order of fiel... Open

 Description   

This issue is created automatically through a Github pull request on behalf of tiger-seo:

Url: https://github.com/doctrine/doctrine2/pull/1162

Message:

DDC-3349: Possibility to override order of fields of composite ID produced by Mapping



 Comments   
Comment by Doctrine Bot [ 17/Oct/14 ]

A related Github Pull-Request [GH-1162] was assigned:
https://github.com/doctrine/doctrine2/pull/1162





[DDC-3349] Possibility to override order of fields of composite ID produced by Mapping Created: 13/Oct/14  Updated: 19/Oct/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: New Feature Priority: Major
Reporter: tiger-seo Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mapping

Issue Links:
Reference
relates to DDC-3352 [GH-1162] DDC-3349: Possibility to ov... Open

 Description   

So, the problem is when the one needs to use association key in composite identifier; they are added in the end of the identifier array, which is clearly not always suitable in regards to performance.
For example, following mapping:

Acme\DemoBundle\Entity\PageLocalFans:
    type: entity
    id:
        date:
            type: date
        page:
            associationKey: true
        countryCode:
            type: string
            length: 2
    fields:
        fans:
            type: integer
    manyToOne:
        page:
            targetEntity: Page
            joinColumn:
                name: page_id
                referencedColumnName: id
                onDelete: CASCADE

will turn into sql as:

CREATE TABLE page_local_fans (
  date         DATE       NOT NULL,
  country_code VARCHAR(2) NOT NULL,
  page_id      INT        NOT NULL,
  fans         INT        NOT NULL,
  INDEX IDX_7391EB36C4663E4 (page_id),
  PRIMARY KEY (date, country_code, page_id)
) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB;

and there is no way to change the order of the primary from

PRIMARY KEY (date, country_code, page_id)

to

PRIMARY KEY (date, page_id, country_code)


 Comments   
Comment by tiger-seo [ 14/Oct/14 ]

i've done the PR for this, pls see https://github.com/doctrine/doctrine2/pull/1162

Comment by Doctrine Bot [ 17/Oct/14 ]

A related Github Pull-Request [GH-1162] was assigned:
https://github.com/doctrine/doctrine2/pull/1162





[DDC-3344] Flush on a specific entity is not correctly cascaded to associated entities Created: 10/Oct/14  Updated: 19/Oct/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4.6
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Pavel Horal Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

In a setup with a simple entity associated entity, the cascade is not performed when flushing the parent entity. This violates contract specified by EntityManager#flush($entity) PHPDoc:

If an entity is explicitly passed to this method only this entity and the cascade-persist semantics + scheduled inserts/removals are synchronized.

It seems that the reason behind this is UnitOfWork#computeAssociationChanges, which expects that a #computeChangeSets is called elswehere (which it is not when flushing a specific entity):

MANAGED associated entities are already taken into account during changeset calculation anyway, since they are in the identity map.

This makes flushing and cascading very confusing. Also I believe this might be a cause of other issues, like DDC-3113.



 Comments   
Comment by Marco Pivetta [ 10/Oct/14 ]

Doctrine\ORM\EntityManager#flush() is not supposed to be called with a specific entity when there are cascade operations involved.

The optional argument has to be only used for performance reasons, but can indeed break things.

Comment by Pavel Horal [ 10/Oct/14 ]

Thank you for the reply. I am probably (and possibly other people) misinterpretting the PHPDoc. Can you explain what is meant by "and the cascade-persist semantics"?

Comment by Marco Pivetta [ 19/Oct/14 ]

Pavel Horal I don't really understand that bit myself, but git blame states that the comment was introduced in https://github.com/doctrine/doctrine2/commit/5d3298e706b1457ca8be02469b00ef219afe84e6 by Benjamin Eberlei.

Maybe it just needs a docblock rewrite

Comment by Pavel Horal [ 19/Oct/14 ]

Commit is linked with DDC-720 . Again, that gives me an impression that events should be cascaded:

In a nutshell, this change would mean that flush() can optionally accept an entity as an argument. When that happens, the resulting changeset will be limited to that entity and any entity reachable from it.

Comment by Marco Pivetta [ 19/Oct/14 ]

Again, that gives me an impression that events should be cascaded

No, the entire flush($entity) functionality is just to limit the entire Doctrine\ORM\UnitOfWork operations over the single object: it's expected behavior.

In general, you should use flush($entity) only if you have very high priority performance optimizations, as it was never meant to be reliable API when using listeners.

I'd even suggest deprecating it for removal in the next major release, as it has only caused issues so far.





[DDC-3340] __wakeup not called in UoW::createEntity when loading uninitialized proxy Created: 07/Oct/14  Updated: 13/Oct/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Uwe Jäger Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I'm using __wakeup to initialize a property with an empty ArrayCollection for a transient property. But when I try to "find" the entity and the uninitialized Proxy is already in the entity map, the proxy is simply set to "initialized" but my code to init the collection is never call (see https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/UnitOfWork.php#L2552). So neither the constructor of my entity nor the proxies' _load method are called.
Where should I initialize that collection?



 Comments   
Comment by Uwe Jäger [ 07/Oct/14 ]

I just added a postLoad event listener that seems to do the trick in this case, so I have three things to do
1. implement __wakeup to make proxies' load work
2. implement a constructor
and
3. add a postLoad Listener.

Lot's of code for a simple $this->collection = new ArrayCollection();

Comment by Marco Pivetta [ 07/Oct/14 ]

Can you code this as a failing test case? Fixing it should be trivial afterwards.

Also, which version is affected?

Comment by Christophe Coevoet [ 13/Oct/14 ]

__wakeup is not a way to hook in the loading of the entity for Doctrine. The way to hook into the loading of the entity is to use the postLoad lifecycle callback.

Calling __wakeUp when initializing the proxy would be abusing this method, as it has a different purpose in PHP.

Comment by Marco Pivetta [ 13/Oct/14 ]

Christophe Coevoet we currently use __wakeup for transient properties wakeup on proxy initialization...

Comment by Marco Pivetta [ 13/Oct/14 ]

As an example:

class Foo
{
    /** @Id @Column */
    private $bar;
    private $transientField;

    public function __construct()
    {
        $this->transientField = new SomeUtil();
    }

    public function __wakeup()
    {
        $this->transientField = new SomeUtil();
    }
}

This is expected __wakeup usage. Is this broken for you, Uwe Jäger?

Comment by Uwe Jäger [ 13/Oct/14 ]

This is broken when the entity was loaded before via a relation and the proxy is not initialized. Doing a find in the same request finds the proxy in UoWs identityMap but __wakeup is not called then, so the property is not initialized.

Comment by Marco Pivetta [ 13/Oct/14 ]

Uwe Jäger is it actually a proxy? Or just an entity? Proxy initialization happens if __wakeup is defined as of https://github.com/doctrine/doctrine2/blob/3ca0dae6062f13b448f9b5f154cf9690d24a1913/lib/Doctrine/ORM/Proxy/ProxyFactory.php#L138

Comment by Uwe Jäger [ 13/Oct/14 ]

It is a proxy, please check https://github.com/doctrine/doctrine2/blob/3ca0dae6062f13b448f9b5f154cf9690d24a1913/lib/Doctrine/ORM/UnitOfWork.php#L2552, there __wakeup is not called.

Comment by Marco Pivetta [ 13/Oct/14 ]

Uwe Jäger that is indeed a bug. Checking reflection there seems to be a bit too performance-heavy.

A test for that would be (pseudo):

class Foo
{
    /** @Id @Column */
    public $id;
    public $transientField;

    public function __construct()
    {
        $this->transientField = 123;
    }

    public function __wakeup()
    {
        $this->transientField = 123;
    }
}
$foo = new Foo();

$em->persist($entity);
$em->flush();
$em->clear();

$entity = $em->getReference('Foo', $foo->id);
$em->createQuery('SELECT f FROM Foo f')->setHint(AbstractQuery::HINT_REFRESH, true)->getResult();

$this->assertInstanceOf('...Proxy', $entity);
$this->assertTrue($entity->__isInitialized());
$this->assertSame(123, $entity->transientField);




[DDC-3335] Merge with value object causes notice Created: 03/Oct/14  Updated: 03/Oct/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.5
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: David de Boer Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This:

// Assume Location is some value object
$valueObject = new Location(); // or e.g. new \stdClass()
$em->merge($valueObject);

causes this:

Notice: Undefined offset: 0 in /vagrant/api/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php line 729

While I agree merge shouldn't work for value objects, wouldn't it be better to throw an exception when ClassMetadataInfo tries to find an identifier that isn't there?






[DDC-3332] [GH-1152] Adds error message when the key is composite Created: 02/Oct/14  Updated: 02/Oct/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of fran6co:

Url: https://github.com/doctrine/doctrine2/pull/1152

Message:

An example is:

```
SELECT u FROM User u INNER JOIN Address a ON a.user = u
```

When User has a composite key.



 Comments   
Comment by Doctrine Bot [ 02/Oct/14 ]

A related Github Pull-Request [GH-1152] was assigned:
https://github.com/doctrine/doctrine2/pull/1152





[DDC-3328] [GH-1150] Improve Comparison::CONTAINS: allow to use custom position for % and _ wildcard characters Created: 28/Sep/14  Updated: 19/Oct/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of Fedik:

Url: https://github.com/doctrine/doctrine2/pull/1150

Message:

This pull prevent forced wrapping of the value in to `%`
and allow to use the custom position for `%` and `_` wildcard characters in case `Comparison::CONTAINS`

Allow to build the `contains` expressions like:
```php
Criteria::expr()->contains('myField', 'some string%');
Criteria::expr()->contains('myField', '%some string');
Criteria::expr()->contains('myField', '10%');
Criteria::expr()->contains('myField', 's_m_ string');
```



 Comments   
Comment by Doctrine Bot [ 19/Oct/14 ]

A related Github Pull-Request [GH-1150] was assigned:
https://github.com/doctrine/doctrine2/pull/1150





[DDC-3327] [GH-1149] Update Composite.php for HHVM compatibility Created: 26/Sep/14  Updated: 26/Sep/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of zhil:

Url: https://github.com/doctrine/doctrine2/pull/1149

Message:

Not sure, why this issue is not founded in unittests, but I got HHVM crushed with message
```
Fatal error: Stack overflow in ...../vendor/doctrine/orm/lib/Doctrine/ORM/Query/Expr/Composite.php on line 58
```
The same issue is being reported here
https://github.com/facebook/hhvm/issues/1747

@LinuxDoku proposed quick patch, which works great for me and its in this PR.

Just in case, if you wonder what trigger this error - here is my repository function, which trigger it
```
public function findOpenTeamTimeEntry($user)
{
$r = $this->createQueryBuilder("t")
->join("t.owner","u")
->where("t.dateEnd IS NULL")
->andWhere("u.id = :user_id")
>setParameter(":user_id",$user>getId())
->getQuery()
->getResult();
if(is_array($r) && count($r))

{ return $r[0]; }

else

{ return false; }

}
```






[DDC-3320] [GH-1144] [DDC-3287] Change parent classes of some Events Created: 23/Sep/14  Updated: 19/Oct/14

Status: Awaiting Feedback
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of zebba:

Url: https://github.com/doctrine/doctrine2/pull/1144

Message:

Following my <a href="http://doctrine-project.org/jira/browse/DDC-3287">issue report</a> in Jira find attached the necessary changes.



 Comments   
Comment by Doctrine Bot [ 19/Oct/14 ]

A related Github Pull-Request [GH-1144] was assigned:
https://github.com/doctrine/doctrine2/pull/1144





[DDC-3316] [GH-1141] Always allow proxies on ToOne associations Created: 22/Sep/14  Updated: 22/Sep/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of goetas:

Url: https://github.com/doctrine/doctrine2/pull/1141

Message:

Hi!
This patch combined with https://github.com/doctrine/common/pull/338 will allow to have proxies for long chains of ToOne associations:

```
User

{ private $id; // @id private $city; private $name; }

City

{ private $id; // @id private $region; // @id private $name; }

Region

{ private $id; // @id private $country; // @id private $name; }

Country

{ private $id; // @id private $name; }

```

```php
$user = $repo->find(1);

// the current implementation must load the city, region
$user->getCity()>getRegion()>getCountry();
// the current implementation must load the city, region and the country
$user->getCity()>getRegion()>getCountry()->getName();

//with this patch
// here no queries will be executed
$user->getCity()>getRegion()>getCountry();
// here only will be loaded
$user->getCity()>getRegion()>getCountry()->getName();
```
Of course this patch will require some unit test, but can be acceptable as idea?






[DDC-3315] [GH-1140] [DDC-2704] merge throughout entity hierarchy Created: 19/Sep/14  Updated: 19/Sep/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of tiger-seo:

Url: https://github.com/doctrine/doctrine2/pull/1140

Message:






[DDC-3314] Error with AttributeOverride when upgrading schema Created: 19/Sep/14  Updated: 23/Sep/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: JB Blanchon Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: orm


 Description   

I want to override an attribute from FOSuserBundle:User class with annotations.

My class extends BaseUser

SiteCustomer.php
class SiteCustomer extends BaseUser

My use statement is like this

SiteCustomer.php
use FOS\UserBundle\Model\User as BaseUser;

When I put the annotations on my entity

SiteCustomer.php
 /*
 * @ORM\AttributeOverrides({
 *     @ORM\AttributeOverride(name="emailCanonical",
 *         column=@ORM\Column(
 *             name="email_canonical",
 *             type="string",
 *             length=255,
 *             unique=false
 *         )
 *     )
 * })
 */

I get this error message :


MappingException: Invalid field override named 'emailCanonical' for class SiteCustomer.

I got the same error message, for usernameCanonical.
I need to override this field in order to remove the uniqness of the field
I use Doctrine v2.4.4 what is wrong with my annotation ? Why do I get this error when trying to upgrade my schema

Thank you



 Comments   
Comment by Marco Pivetta [ 22/Sep/14 ]

Did you try reaching where the exception is thrown? It typically says more about the specific failure.

Comment by JB Blanchon [ 23/Sep/14 ]
Stack Trace 1
  */
    public static function invalidOverrideFieldName($className, $fieldName)
    {
        return new self("Invalid field override named '$fieldName' for class '$className'.");
    }
    /**
[1] Doctrine\ORM\Mapping\MappingException: Invalid field override named 'emailCanonical' for class 'Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer'.
    at n/a
        in /home/jaybe/www/yProx/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/MappingException.php line 129

    at Doctrine\ORM\Mapping\MappingException::invalidOverrideFieldName('Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer', 'emailCanonical')
        in /home/jaybe/www/yProx/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php line 2032

    at Doctrine\ORM\Mapping\ClassMetadataInfo->setAttributeOverride('emailCanonical', array('fieldName' => 'emailCanonical', 'type' => 'string', 'scale' => '0', 'length' => '255', 'unique' => false, 'nullable' => false, 'precision' => '0', 'columnName' => 'email_canonical'))
        in /home/jaybe/www/yProx/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/Driver/AnnotationDriver.php line 415

    at Doctrine\ORM\Mapping\Driver\AnnotationDriver->loadMetadataForClass('Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer', object(ClassMetadata))
        in /home/jaybe/www/yProx/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/Driver/MappingDriverChain.php line 103

    at Doctrine\Common\Persistence\Mapping\Driver\MappingDriverChain->loadMetadataForClass('Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer', object(ClassMetadata))
        in /home/jaybe/www/yProx/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php line 117

    at Doctrine\ORM\Mapping\ClassMetadataFactory->doLoadMetadata(object(ClassMetadata), object(ClassMetadata), true, array('Ylly\CrmBundle\Entity\User'))
        in /home/jaybe/www/yProx/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php line 318

    at Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->loadMetadata('Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer')
        in /home/jaybe/www/yProx/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php line 211

    at Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->getMetadataFor('Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer')
        in /home/jaybe/www/yProx/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php line 295

    at Doctrine\ORM\EntityManager->getClassMetadata('Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer')
        in /home/jaybe/www/yProx/vendor/doctrine/orm/lib/Doctrine/ORM/Repository/DefaultRepositoryFactory.php line 67

    at Doctrine\ORM\Repository\DefaultRepositoryFactory->createRepository(object(EntityManager), 'Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer')
        in /home/jaybe/www/yProx/vendor/doctrine/orm/lib/Doctrine/ORM/Repository/DefaultRepositoryFactory.php line 50

    at Doctrine\ORM\Repository\DefaultRepositoryFactory->getRepository(object(EntityManager), 'Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer')
        in /home/jaybe/www/yProx/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php line 759

    at Doctrine\ORM\EntityManager->getRepository('Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer')
        in /home/jaybe/www/yProx/src/Ylly/CmsBundle/Controller/CmsBaseController.php line 93

    at Ylly\CmsBundle\Controller\CmsBaseController->getRepo('Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer')
        in /home/jaybe/www/yProx/src/Ylly/Extension/SiteCustomerBundle/Controller/AdminController.php line 79

    at Ylly\Extension\SiteCustomerBundle\Controller\AdminController->getSiteCustomerRepo()
        in /home/jaybe/www/yProx/src/Ylly/Extension/SiteCustomerBundle/Controller/AdminController.php line 15

    at Ylly\Extension\SiteCustomerBundle\Controller\AdminController->indexAction()
        in  line 

    at call_user_func_array(array(object(AdminController), 'indexAction'), array())
        in /home/jaybe/www/yProx/apps/bootstrap.php.cache line 2952

    at Symfony\Component\HttpKernel\HttpKernel->handleRaw(object(Request), '1')
        in /home/jaybe/www/yProx/apps/bootstrap.php.cache line 2924

    at Symfony\Component\HttpKernel\HttpKernel->handle(object(Request), '1', true)
        in /home/jaybe/www/yProx/apps/bootstrap.php.cache line 3063

    at Symfony\Component\HttpKernel\DependencyInjection\ContainerAwareHttpKernel->handle(object(Request), '1', true)
        in /home/jaybe/www/yProx/apps/bootstrap.php.cache line 2331

    at Symfony\Component\HttpKernel\Kernel->handle(object(Request))
        in /home/jaybe/www/yProx/web/admin_dev.php line 14

Here is the stack trace of my error.
If this is not what you need, tell me what do you want and how to get it.
Thank you.





[DDC-3313] [GH-1139] Single entity flush Created: 18/Sep/14  Updated: 18/Sep/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of goetas:

Url: https://github.com/doctrine/doctrine2/pull/1139

Message:

The current `flush` behavior seems to be inconsistent or not well documented.






[DDC-3310] [GH-1138] Join column index names Created: 15/Sep/14  Updated: 15/Sep/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of stanlemon:

Url: https://github.com/doctrine/doctrine2/pull/1138

Message:

@Ocramius recommended I open this up to discuss the issue I am seeing.

I am trying to explicitly name the index on a column which is used in a join. I've attempted to add two functional tests in this PR to demonstrate what I am seeing. Please forgive me if these tests are not correctly, this is the first time I've attempted to submit a PR like this.

There are two situations I am encountering...

First, I explicitly name the index in the ```@Table``` annotation on the column used in the join - but the SQL generated from ```SchemaTool``` appears to be a random hash.

Second, when I have an existing database table with an existing index and it's named properly (in this example, idx_maker_id) and then I run ```SchemaTool->updateSchema()``` it drops the index with the proper name and creates a new randomly hashed name.

Is there a different way of accomplishing what I am trying to do here, or is this a bug?

Thanks for your help and assistance!






[DDC-3305] [GH-1133] [Embeddables] Improved exception message Created: 12/Sep/14  Updated: 12/Sep/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of phansys:

Url: https://github.com/doctrine/doctrine2/pull/1133

Message:

Improved exception message when embeddable definition is missing 'class' attribute.
Instead of:
```
The class '' was not found in the chain configured namespaces ...
```
It shows:
```
The embed mapping 'embeddedname' misses the 'class' attribute.
```






[DDC-3303] @ORM\Embedded does not work with extending classes Created: 10/Sep/14  Updated: 10/Sep/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers
Affects Version/s: 2.5
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: TheBelgarion Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Linux, Symfony 2.5 ORM 2.5.*@dev
doctrine/annotations = "v1.2.0",



 Description   

I update my symfony 2.5 with ORM 2.5. to try out the Embedded function.
I currently does not work correctly with extending class

/**
 * @ORM\Entity
 * @ORM\Table(name="A", uniqueConstraints={@UniqueConstraint(name="id", columns={"id"})})
 */
class A extends B {}
abstract class Item {

    /**
     * @var $bonus
     * @ORM\Embedded(class="Bonus")
     *
     */
    private $bonus;
}

it only works if i put the definition of the Embedded properties directly in class A ( but it works with all normal properties defined in the Abstract )






[DDC-3300] [GH-1130] [WIP] Added resolve entities support in discrim. map Created: 09/Sep/14  Updated: 09/Sep/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of mmoreram:

Url: https://github.com/doctrine/doctrine2/pull/1130

Message:

This PR is WIP. I just wanted to know if what I am doing is wrong or I can go on with tests and documentation.

This is what happens.

I have nicely the ability to define a relation using just the interfaces, and then, resolve these relations overriding the interfaces with the implementations. This resolves a big problem: Multiple implementations of one interface.

But, when you define a discriminatorMap, you *Must* define it using specific implementations, so all this flexibility gained in the relations is lost at this point.

Using a new listener, its easy to override this interfaces.

What do you think?






[DDC-3298] Persisting one to one not nullable relational entity Created: 08/Sep/14  Updated: 08/Sep/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4.4
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Bil Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: onetoone, persist
Environment:

Use with Symfony 2.5



 Description   

When having a not nullable onetoone unidirectional relation and trying to persist the parent entityn sql throws this exception : SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'deliveryMode_id' cannot be null.

Scheme is Shop has a deliveryMode :

class Shop{

...

/**

  • @ORM\OneToOne(targetEntity="acme\Bundle\DeliveryBundle\Entity\DeliveryMode", cascade= {"all"}

    , orphanRemoval=true)

  • @ORM\JoinColumn(nullable=false)
  • @Assert\Valid
    */
    private $deliveryMode;
    ...
    }

When I do a :

$shop=new Shop();
$deliveryMode=new DeliveryMode();
$shop->setDeliveryMode($deliveryMode);
...
$entityManager->persist($shop);
$entityManager->flush();

Then, above exception is thrown

BUT: When I put in on a doctrine transaction, it works perfectly, and it also works when I remove the "not nullable" constraint, deliveryMode is perfectly persisted.

It seems to me there a bug with the order of executing the inserts, the deliveryMode should be inserted, then the shop, I think that is not the case






[DDC-3297] Refreshing and locking entities ignores deleted records Created: 07/Sep/14  Updated: 07/Sep/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: 2.4.1
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Glen Ainscow Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

If you refresh or lock an entity that has been deleted elsewhere, no exception is thrown, so it appears as if the record still exists.

Example:

    $blogId = 1;

    $em = (get em from somewhere);

    $blog = $em->find('App_Model_Blog', $blogId);

    var_dump($blog->getTitle());

    // This could be part of a separate request or transaction.
    $em->getConnection()->exec(sprintf('DELETE FROM blogs WHERE id = %d', $blogId));

    $stmt = $em->getConnection()->query(sprintf('SELECT * FROM blogs b WHERE b.id = %d', $blogId));

    var_dump($stmt->rowCount() === 0 ? 'DELETED' : 'NOT DELETED');

    //$em->beginTransaction();

    //$em->lock($blog, LockMode::PESSIMISTIC_WRITE);

    //$em->commit();

    $em->refresh($blog);

    var_dump($blog->getTitle());





[DDC-3296] JoinColumns seems to only populate one JoinColumn Created: 04/Sep/14  Updated: 04/Sep/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4.2
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Daniel Platt Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm
Environment:

Symfony 2.3.19



 Description   

I have two entities that are linked via two properties (trackingClickId and trackingSiteId).

However it seems to miss the second JoinColumn.

[Mapping] FAIL - The entity-class '...\Entity\SaleData' mapping is invalid:

  • The join columns of the association 'click' have to match to ALL identifier columns of the target entity '..\Entity\SaleData', however 'tracking_site_id' are missing.
TrackingData.php
class TrackingData
{

    /**
     * @ORM\Column(name="tracking_click_id", type="integer")
     * @ORM\Id
     */
    private $trackingClickId;

    /**
     * @ORM\Column(name="tracking_site_id", type="integer")
     * @ORM\Id
     * @Assert\NotBlank
     */
    private $trackingSiteId;

    /**
     * @ORM\OneToMany(targetEntity="SaleData", mappedBy="click")
     * @ORM\JoinColumns=({
     *      @ORM\JoinColumn(name="tracking_click_id", referencedColumnName="tracking_click_id"),
     *      @ORM\JoinColumn(name="tracking_site_id", referencedColumnName="tracking_site_id"), 
     * })
     */
    private $sales;
    
}
SaleData.php
class SaleData
{

    /**
     * @ORM\Column(name="tracking_site_id", type="integer")
     * @ORM\Id
     * @Assert\NotBlank
     */
    private $trackingSiteId;

    /**
     * @ORM\Column(name="tracking_click_id", type="integer")
     * @ORM\Id
     * @Assert\NotBlank
     */
    private $trackingClickId;

    /**
     * @ORM\ManyToOne(targetEntity="TrackingData", inversedBy="sales")
     * @ORM\JoinColumns=({
     *      @ORM\JoinColumn(name="tracking_click_id", referencedColumnName="tracking_click_id"),
     *      @ORM\JoinColumn(name="tracking_site_id", referencedColumnName="tracking_site_id")
     * })
     */
    private $click;
}

I have been poking around in Doctrine\ORM\Tools\SchemaValidator (L:215).

var_dump($identifierColumns, $assoc['joinColumns']);

array(2) {
  [0] =>
  string(17) "tracking_click_id"
  [1] =>
  string(16) "tracking_site_id"
}
array(1) {
  [0] =>
  array(6) {
    'name' =>
    string(17) "tracking_click_id"
    'unique' =>
    bool(false)
    'nullable' =>
    bool(true)
    'onDelete' =>
    NULL
    'columnDefinition' =>
    NULL
    'referencedColumnName' =>
    string(17) "tracking_click_id"
  }
}





[DDC-3294] [GH-1129] Allow inheritance of FilterCollection Created: 02/Sep/14  Updated: 02/Sep/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of TomasVotruba:

Url: https://github.com/doctrine/doctrine2/pull/1129

Message:

I need to inherit this class and now I have to pretty much copy the whole mechanism, because methods in inherited class cannot reach private properties. This would solve the issue.






[DDC-3291] Cannot use eq expression for comparison of DateTime Created: 01/Sep/14  Updated: 02/Sep/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Przemyslaw Wrobel Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

When I use return ArrayCollection::matching() with criteria defined with eq expression like that:

Criteria::create()->where(Criteria::expr()->eq('day', $day))

I get no results since equality operator uses === comparison which will almost always return false for objects. The only way I found to get around this is to use in operator instead

Criteria::create()->where(Criteria::expr()->in('day', array($day)))





[DDC-3284] Yaml mapping. Comment on table and realtion Created: 29/Aug/14  Updated: 01/Sep/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: Documentation, Mapping Drivers, ORM
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Documentation Priority: Major
Reporter: Vladimir Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Windows, XAMPP, PHP5.3, ZF2, Doctrine-ORM



 Description   

Is there any way to comment my tables and table relations with yml schema?
I can comment plain field like this
prediction:
type: text
nullable: true
length: null
fixed: false
options:
comment: 'program prediction'

But for relation:

project:
targetEntity: File\Entity\File
cascade: { }
mappedBy: null
inversedBy: null
joinColumns:
project:
referencedColumnName: id
orphanRemoval: false
options:
comment: 'File with project data'

Or for whole table:
Program\Entity\Program:
type: entity
table: program
options:
comment: 'State program table'

It doesn't work at all. When I perform migrations those comments are totally ignored. And I can't find any documentation for yml mapping table commenting



 Comments   
Comment by Steve Müller [ 29/Aug/14 ]

Commenting tables is a vendor specific feature and therefore not all database vendors support it. I think currently it is only possible to comment tables via mapping for MySQL. The mapping you provided for commenting tables should work however. See here: https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Mapping/Driver/YamlDriver.php#L247-L249
I'm not quite sure what you mean by commenting relations. Where would you expect Doctrine to add a comment to?

Comment by Vladimir [ 29/Aug/14 ]

I mean commenting a column that is a foreign key. Like 'project' column above that is a link to Files table and entity.

Comment by Steve Müller [ 01/Sep/14 ]

Unfortunately commenting columns part of an association mapping is not possible in ORM at the moment.





[DDC-3282] Pagination class CountOutputWalker has poor performance with MySQL Created: 28/Aug/14  Updated: 28/Aug/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: Tools
Affects Version/s: 2.4.4
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Major
Reporter: Frédéric Rocheron Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

GNU/Linux CentOS 6.5, Php 5.4.32, MySQL 5.5.39, Symfony 2.5.3



 Description   

When the CountOutputWalker is used for pagination, it creates a count query of this type :

    SELECT %s AS dctrn_count
    FROM (
        SELECT DISTINCT "here are the identifiers from the original query"
        FROM (
            "here is the original query"
        ) dctrn_result
    ) dctrn_table

The problem is that the original query inside the count query is executed without limiting the results number each time the pagination has to count the total number of rows. And when the total number of rows returned by the original query is large and/or with big selected rows, it can hurt badly the performance, even kill the server.
Maybe I don't understand something but in my opinion this count query does exactly what we try to avoid with pagination : load all data at one time !
So I don't understand why things are done this way. Again, I'm not a db specialist so I'm almost sure I'm missing something.

But the thing is I've met these performance issues with big select queries on a medium amount of rows (~35000) on MySQL (using knp-components Pager).
The ugly solution I found was to use the CountWalker instead of the CountOutputWalker except when the query has a "HAVING" clause. That was because the CountWalker produce a better count query for performance but cannot handle well "HAVING" clauses (as far as I know).
Finally I think the solution is to modify the CountWalker so it can take care of more complex queries and/or improve the CountOutputWalker to preserve performance.

Here are some discussions related to this problem :
Removed use of CountOutputWalker
Count Performance of DoctrineORMAdapter COUNT query and large record sets
Doctrine ORM pagination improvements

Thanks a lot for your time



 Comments   
Comment by Christophe Coevoet [ 28/Aug/14 ]

Well, the issue is that the CountWalker cannot count stuff using a GROUP BY or HAVING clause by design. It is simply impossible to write the given SQL without ending up on what the CountOutputWalker is doing,(maybe a bit simpler in some cases thanks to a complete knowledge of what the query is doing, but not much and not in a general case).

The solution is indeed to tell the Paginator not to use the output walker when you know it is not necessary. This is precisely why there are 2 implementations of the pagination with a boolean flag to switch between them

Comment by Christophe Coevoet [ 28/Aug/14 ]

And the output walker actually perform better than the tree walker in many platforms according to Benjamin Eberlei (not MySQL though), which is why it is hard to choose the best walker for queries being supported by both of them (a project can do it better than the core, as it knows which platform it uses)

Comment by Frédéric Rocheron [ 28/Aug/14 ]

Thank you for your very clear explanations !
I assumed I was missing something but I did not think it was just impossible to solve this problem "automatically" . That's a bit annoying but ok.
The solution for MySQL seems to use the CountWalker for queries without GROUP BY or HAVING clause and CountOutputWalker for other queries. A better solution would be to create a custom hand-made count query for queries with GROUP BY or HAVING clause. This is possible in "knp-components Pager" and, I suppose, in the other pagination libraries using doctrine-orm Tools.

But as "knp-components Pager" does not use the "doctrine-orm Tools Paginator" but only the walkers from doctrine-orm, it doesn't have the boolean flag to switch between CountWalker and CountOutputWalker. The CountOutputWalker is used if doctrine-orm version is 2.3.0 or more and that's it.
I've made a pull request to activate the use of CountWalker for queries without HAVING clause but I think now it's a bad idea. The solution should be to add the same boolean flag to the "knp-components Pager" library. I will talk to them about that.

Thanks again for your time

Comment by Christophe Coevoet [ 28/Aug/14 ]

See https://github.com/KnpLabs/knp-components/issues/114

Comment by Frédéric Rocheron [ 28/Aug/14 ]

great





[DDC-3280] ObjectHydrator does not support iteration over non-distinct result sets Created: 27/Aug/14  Updated: 27/Aug/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.x
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Timothy Michael Bradley Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm


 Description   

ObjectHydrator attempts to retrieve previously created objects during iteration (i.e. Query::iterate()). It needs to create an entirely new object because the previous one is not available.

This may also be a performance/scalability issue, and it may be a matter of setting default behavior.

Note that calling Query::useResultCache(false) does not fix this issue.

This part of the code causes a warning because of this issue.

// Update result pointer
$index = $this->identifierMap[$dqlAlias][$id[$dqlAlias]];
$this->resultPointers[$dqlAlias] = $result[$index];
$resultKey = $index

Here is the warning:

Notice: Undefined offset: 0 in [basedir]/vendor/doctrine/orm/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php on line 519





[DDC-3277] Yaml convert-mapping bug Created: 27/Aug/14  Updated: 01/Sep/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers, ORM, Tools
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Vladimir Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mapping, orm, yaml, yml
Environment:

Windows+XAMPP, PHP5.3, Zend Framework 2



 Description   

I use yaml mapping in my project for better migration management. For example, I use

    orm:convert-mapping yml ./yml --from-database --namespace="User\Entity\\" --filter="User\Entity\User"

To make yml entites for my User module. In my yml I have smth like this:

      password:
            type: string
            nullable: false
            length: 256
            fixed: false
            comment: ''
        email:
            type: string
            nullable: false
            length: 64
            fixed: false
            comment: ''
        status:
            type: smallint
            nullable: false
            unsigned: false
            comment: ''

I can write a comment to column

         status:
                type: smallint
                nullable: true
                unsigned: false
                comment: '%some comment%'
                column: status

And when I perform migration comment disappears. Here https://github.com/doctrine/migrations/issues/184 I was adviced to use such construction:

    status:
        type: smallint
        nullable: true
        column: status
        options:
            unsigned: false
            comment: '%some comment%'

And It works! But convert-mapping generates wrong code. Does anyone know any way to generate a correct one with convert-mapping?



 Comments   
Comment by Marco Pivetta [ 28/Aug/14 ]

Seems like Christophe Coevoet started working on this: https://github.com/doctrine/doctrine2/pull/1123

Comment by Vladimir [ 29/Aug/14 ]

Thank you very much! Will with feature be available with update through composer?

Comment by Doctrine Bot [ 30/Aug/14 ]

A related Github Pull-Request [GH-1123] was assigned:
https://github.com/doctrine/doctrine2/pull/1123

Comment by Doctrine Bot [ 30/Aug/14 ]

A related Github Pull-Request [GH-1123] was closed:
https://github.com/doctrine/doctrine2/pull/1123

Comment by Steve Müller [ 01/Sep/14 ]

Vladimir there is no release date scheduled for 2.5 yet. If you want to use the patch you will have to use "dev-master" version in your composer.json





[DDC-3267] [GH-1117] QueryBuilder - replace deprecated getAlias() by getAliases()[0] Created: 22/Aug/14  Updated: 22/Aug/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of TomasVotruba:

Url: https://github.com/doctrine/doctrine2/pull/1117

Message:






[DDC-3259] Second level & UnitOfWork inconsistencies Created: 19/Aug/14  Updated: 22/Oct/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Major
Reporter: Asmir Mustafic Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: second-level-cache


 Description   

Hi!

I have a lot of entities with entity associations as keys and I'm trying to use second level cache.

Looking at the method: UnitOfWork::createEntity($className, array $data, &$hints = array())

  • $className: contains the class name
  • $data: contains the raw data (the row coming from the database)

Enabling the second level cache, DefaultQueryCache::get calls the createEntity method passing a $data that contains object entities and some raw data (https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Cache/DefaultQueryCache.php#L155).

I think that DefaultQueryCache should not introduce a variant of $data and should create a compatible version of $data.



 Comments   
Comment by Marco Pivetta [ 19/Aug/14 ]

Asmir Mustafic do you have any example of where this may be happening?

Comment by Asmir Mustafic [ 19/Aug/14 ]

https://github.com/doctrine/doctrine2/pull/1114

This is the same branch of https://github.com/doctrine/doctrine2/pull/1113, plus this commit (https://github.com/goetas/doctrine2/commit/bfbbb9123fd28f7fa053b76895eaa77e00095aa6) that simply involves the second level cache too.
Travis should fail soon.

Comment by Doctrine Bot [ 19/Aug/14 ]

A related Github Pull-Request [GH-1114] was closed:
https://github.com/doctrine/doctrine2/pull/1114

Comment by Asmir Mustafic [ 19/Aug/14 ]

Here the failure https://travis-ci.org/doctrine/doctrine2/jobs/32972996#L402

Comment by Doctrine Bot [ 22/Oct/14 ]

A related Github Pull-Request [GH-1113] was assigned:
https://github.com/doctrine/doctrine2/pull/1113





[DDC-3258] [GH-1113] Added support for composite primary key on findBy methods and Criteria Created: 18/Aug/14  Updated: 22/Oct/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Duplicate
is duplicated by DDC-3260 [GH-1114] Composite pk break test Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of goetas:

Url: https://github.com/doctrine/doctrine2/pull/1113

Message:

Hi!
I tried to implement the matching of entities that uses composite primary keys...

Any suggestion?



 Comments   
Comment by Doctrine Bot [ 22/Oct/14 ]

A related Github Pull-Request [GH-1113] was assigned:
https://github.com/doctrine/doctrine2/pull/1113





[DDC-3251] Segmentation fault in ClassMetadataInfo.php Created: 12/Aug/14  Updated: 20/Oct/14

Status: Awaiting Feedback
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: 2.3
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Kshitij Parajuli Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Linux dev1 3.9.9-302.fc19.x86_64 #1 SMP Sat Jul 6 13:41:07 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Fedora release 19 (Schrödinger’s Cat)

PHP 5.5.14 (cli) (built: Jul 16 2014 11:41:07)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies
with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2014, by Zend Technologies
with Xdebug v2.2.5, Copyright (c) 2002-2014, by Derick Rethans

Doctrine Command Line Interface version 2.3.6-DEV



 Description   

I'm seeing a segfault when doing a EntityManager->merge(). Specifically, when on this line in ClassmetadataInfo.php. Details below.

$value = $this->reflFields[$this->identifier[0]]->getValue($entity);

/var/log/messages

Aug 12 08:39:01 dev1 kernel: [62152.629221] php[3539]: segfault at f434172bd1 ip 00007ff432c3aae9 sp 00007fffa060b1b0 error 4 in php[7ff4329e7000+38c000]

strace

--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xc4f1053d11} ---
+++ killed by SIGSEGV ++

gdb backtrace:

(gdb) bt
#0  0x00007f8c8f5ceae9 in zend_std_read_property ()
#1  0x00007f8c8f5b61d7 in zend_read_property ()
#2  0x00007f8c8f4ab66e in zim_reflection_property_getValue ()
#3  0x00007f8c8f59a4ab in dtrace_execute_internal ()
#4  0x00007f8c8abb9a46 in xdebug_execute_internal () from /usr/lib64/php/modules/xdebug.so
#5  0x00007f8c8f65a895 in zend_do_fcall_common_helper_SPEC ()
#6  0x00007f8c8f5d45c8 in execute_ex ()
#7  0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#8  0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#9  0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#10 0x00007f8c8f5d45c8 in execute_ex ()
#11 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#12 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#13 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#14 0x00007f8c8f5d45c8 in execute_ex ()
#15 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#16 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#17 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#18 0x00007f8c8f5d45c8 in execute_ex ()
#19 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#20 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#21 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#22 0x00007f8c8f5d45c8 in execute_ex ()
#23 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#24 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#25 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#26 0x00007f8c8f5d45c8 in execute_ex ()
#27 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#28 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#29 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#30 0x00007f8c8f5d45c8 in execute_ex ()
#31 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#32 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#33 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#34 0x00007f8c8f5d45c8 in execute_ex ()
#35 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#36 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#37 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#38 0x00007f8c8f5d45c8 in execute_ex ()
#39 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#40 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#41 0x00007f8c8f659852 in ZEND_INCLUDE_OR_EVAL_SPEC_VAR_HANDLER ()
#42 0x00007f8c8f5d45c8 in execute_ex ()
#43 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#44 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#45 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#46 0x00007f8c8f5d45c8 in execute_ex ()
#47 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#48 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#49 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#50 0x00007f8c8f5d45c8 in execute_ex ()
#51 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#52 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
---Type <return> to continue, or q <return> to quit---
#53 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#54 0x00007f8c8f5d45c8 in execute_ex ()
#55 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#56 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#57 0x00007f8c8f659852 in ZEND_INCLUDE_OR_EVAL_SPEC_VAR_HANDLER ()
#58 0x00007f8c8f5d45c8 in execute_ex ()
#59 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#60 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#61 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#62 0x00007f8c8f5d45c8 in execute_ex ()
#63 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#64 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#65 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#66 0x00007f8c8f5d45c8 in execute_ex ()
#67 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#68 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#69 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#70 0x00007f8c8f5d45c8 in execute_ex ()
#71 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#72 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#73 0x00007f8c8f659852 in ZEND_INCLUDE_OR_EVAL_SPEC_VAR_HANDLER ()
#74 0x00007f8c8f5d45c8 in execute_ex ()
#75 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#76 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#77 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#78 0x00007f8c8f5d45c8 in execute_ex ()
#79 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#80 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#81 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#82 0x00007f8c8f5d45c8 in execute_ex ()
#83 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#84 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#85 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#86 0x00007f8c8f5d45c8 in execute_ex ()
#87 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#88 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#89 0x00007f8c8f659852 in ZEND_INCLUDE_OR_EVAL_SPEC_VAR_HANDLER ()
#90 0x00007f8c8f5d45c8 in execute_ex ()
#91 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#92 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#93 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#94 0x00007f8c8f5d45c8 in execute_ex ()
#95 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#96 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#97 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#98 0x00007f8c8f5d45c8 in execute_ex ()
#99 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#100 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#101 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#102 0x00007f8c8f5d45c8 in execute_ex ()
#103 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#104 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#105 0x00007f8c8f5abed0 in zend_execute_scripts ()
---Type <return> to continue, or q <return> to quit---
#106 0x00007f8c8f54bc65 in php_execute_script ()
#107 0x00007f8c8f65c8a8 in do_cli ()
#108 0x00007f8c8f436420 in main ()

xdebug trace:

   54.4457   16731856                                           -> Tekelec\DVAT\Service\TagService->createTag() /home/vagrant/dvat/library/Tekelec/DVAT/Service/TagService.php:51
   54.4457   16731856                                             -> Doctrine\ORM\EntityManager->merge() /home/vagrant/dvat/library/Tekelec/DVAT/Service/TagService.php:28
   54.4457   16731904                                               -> is_object() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php:632
   54.4457   16731856                                               -> Doctrine\ORM\EntityManager->errorIfClosed() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php:636
   54.4457   16731856                                               -> Doctrine\ORM\UnitOfWork->merge() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php:638
   54.4458   16731992                                                 -> Doctrine\ORM\UnitOfWork->doMerge() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1701
   54.4458   16732136                                                   -> spl_object_hash() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1744
   54.4458   16732448                                                   -> get_class() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1752
   54.4458   16732496                                                   -> Doctrine\ORM\EntityManager->getClassMetadata() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1752
   54.4458   16732496                                                     -> Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->getMetadataFor() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php:268
   54.4458   16732448                                                   -> Doctrine\ORM\UnitOfWork->getEntityState() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1760
   54.4458   16732496                                                     -> spl_object_hash() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1367
   54.4458   16732400                                                   -> Doctrine\ORM\Mapping\ClassMetadataInfo->getIdentifierValues() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1766
   54.4458   16732448                                                     -> ReflectionProperty->getValue() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php:672

The reproducing steps are complicated and require propriety code, but this happens most of the time (80+ percent).

Here is the php bug for this: https://bugs.php.net/bug.php?id=67828



 Comments   
Comment by Marco Pivetta [ 12/Aug/14 ]

Did you try clearing your opcode caches? Is this reproducible in insulated environment?

Comment by Kshitij Parajuli [ 12/Aug/14 ]

Yes, I tried clearing the opcode caches (and clearing proxies and restarting the server). This was also reproducible in multiple servers (one production and one development).

It is not yet reproducible in isolated environment, but I am looking at it. Will update the ticket if I find easy reproducing steps.

Comment by Benjamin Eberlei [ 12/Aug/14 ]

Please try without xdebug, this is enabled according to stacktrace.

Comment by Harold Herrera [ 20/Oct/14 ]

I would like get the Doctrine2-orm, but I get an error in the doctrineORM-2.3.6....tar.gz, could you help me please?.

Comment by Marco Pivetta [ 20/Oct/14 ]

Harold Herrera that is a question unrelated with the issue here.





[DDC-3248] PreUpdateEventArgs::setNewValue() does not update Entity state Created: 11/Aug/14  Updated: 11/Aug/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Lukas Kahwe Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

see https://github.com/doctrine/doctrine2/commit/bc6714c2c8d015cb2e3ae198fcb1b98b3bbe35e0#commitcomment-7329820

as well as https://github.com/doctrine/phpcr-odm/pull/539#discussion_r16027731






[DDC-3241] object type fails to save serialized class to postgresql Created: 05/Aug/14  Updated: 05/Aug/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Reno Reckling Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Reference
relates to DBAL-964 [GH-653] Update docs to include warni... Resolved

 Description   

Doctrine 2 fails to properly store data from serialize() into postgresql.
This happens because the postgresql pdo driver truncates text on NULL bytes when escaping values. This leads to truncated serialized objects being inserted into the database.

A ugly but working workaround for us is to call json_encode(serialize()) when saving to the database and unserialize(json_decode()) when reading the value back because json_encode properly serializes the NULL bytes of the serialize() output to readable text.

This is pretty ugly though and it would help if doctrine would provide a minimal encoding/decoding function for postgresql that converts all NULL bytes to something else to not break the object type on postgresql.



 Comments   
Comment by Marco Pivetta [ 05/Aug/14 ]

I'm fairly sure that we don't want to invent our own serialization format. Instead, base64_encode could work.

Due to BC compat, we can't introduce it for 2.x, so it would have to be a completely new type.

Comment by Reno Reckling [ 05/Aug/14 ]

Agreed, we'll just go with base64_encode for now.
Maybe someone should update the documentation that using the object type on postgresql is not working as well as that using binary strings containing a NULL byte in any varchar/text column on postgresql is not working either.

Comment by Marco Pivetta [ 05/Aug/14 ]

Reno Reckling just open a pull request against the doctrine/doctrine2 repository

Comment by Reno Reckling [ 05/Aug/14 ]

Marco Pivetta Here you go: https://github.com/doctrine/dbal/pull/653
http://www.doctrine-project.org/jira/browse/DBAL-964

Thanks for the reply.

Comment by Doctrine Bot [ 05/Aug/14 ]

A related Github Pull-Request [GH-653] was closed:
https://github.com/doctrine/dbal/pull/653

Comment by Marco Pivetta [ 05/Aug/14 ]

Merged DBAL-964, but the issue persists here.





[DDC-3239] [GH-1097] `expandParameters`/`getType` in BasicEntityPersister seems to really cover just few cases Created: 01/Aug/14  Updated: 01/Aug/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of kamazee:

Url: https://github.com/doctrine/doctrine2/pull/1097

Message:

The test case below seems fairly simple, but I believe that it might uncover a bigger issue.

It seems odd that [`getType` (and, hence, `expandParameters`)](https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php#L1731-1795) in BasicEntityPersister clearly expects field name but often gets different things.

Just set a breakpoint there and watch values through the test suite. There might be not just field name, but a column with alias as well. This works:
![screenshot from 2014-08-01 14 03 44](https://cloud.githubusercontent.com/assets/231518/3778796/c5cc3e66-1979-11e4-9279-5c322b7e8402.png)

But this, apparently, doesn't:
![screenshot from 2014-08-01 14 07 29](https://cloud.githubusercontent.com/assets/231518/3778816/20da192c-197a-11e4-90b4-4c37ee454fb6.png)

There are multiple places (more than one) that call `expandParameters` with criteria that can't be resolved with `getType`. Is this situation expected or worth further investigation/fixing?






[DDC-3238] GROUP BY does not work as expected in MS SQL Server Created: 31/Jul/14  Updated: 18/Aug/14

Status: Awaiting Feedback
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: 2.4.1, 2.4.2
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Spencer Weiss Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

MS SQL Server 2012



 Description   

Running the query taken from this page: <http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/dql-doctrine-query-language.html>

$query = $em->createQuery('SELECT u, count(g.id) FROM FundAsset u JOIN u.locations g GROUP BY u.id');

I receive the following error from MS SQL Server:

SQLSTATE[42000]: [Microsoft][SQL Server Native Client 11.0][SQL Server]Column 'fund_assets.active' is invalid in the select list because it is not contained in either an aggregate function or the GROUP BY clause.

It appears that Doctrine's GROUP BY clause does not work correctly in Microsoft SQL Server.



 Comments   
Comment by Marco Pivetta [ 18/Aug/14 ]

Needs a failing test case.





[DDC-3236] Quote table names Created: 31/Jul/14  Updated: 31/Jul/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Major
Reporter: Benjamin Horn Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Different dbs have different reserved words. I started my project with mysql where i couldnt name my table as "order". After changing to postgre it turned out that "user" is reserved. Although

ALTER TABLE "member" RENAME TO "user";

works.

I know i could use prefixes in yml eg

Com\ApiBundle\Entity\User:
    type: entity
    table: prefix_user

but
-i build my db
-automatically generate my yaml files from it
-then i generate the entities

If i have prefixed table names my entities will have them too.
Besides doctrine is a layer on top of different dbs, it would be nice not to worry about reserved words when i naming my tables.

What is your opinion on this feature.



 Comments   
Comment by Steve Müller [ 31/Jul/14 ]

Benjamin Horn this looks more like a DBAL related issue. Can you please give more details how the broken SQL is created by you? Also please provide information about which DBAL and/or ORM version you are referring to as we have fixed a lot of quotation problems with DDL statements in current DBAL master over the last few months. So please also try using the latest master and see if you can reproduce the issue.
If the issue still persists it would be helpfult to know which database vendor and which version you are using (as different vendors and versions have different reserved keywords).





[DDC-3231] [GH-1089] Entity repository generator default repository Created: 27/Jul/14  Updated: 18/Aug/14

Status: Awaiting Feedback
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of encoder32:

Url: https://github.com/doctrine/doctrine2/pull/1089

Message:

1) I set default repository class in configuration to MyApp\Doctrine\DefaultRepository
2) I created entity class MyApp\Entity\TestEntity and generated repository class for it
3) Actually the repository class "MyApp\Entity\TestEntityRepository" turned out to be a descendant of "Doctrine\ORM\EntityRepository" when I expected "MyApp\Doctrine\DefaultRepository" as default.

Related pull request https://github.com/doctrine/DoctrineBundle/pull/315






[DDC-3229] Error when running the tests Created: 24/Jul/14  Updated: 24/Jul/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: Git Master
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Jeroen De Dauw Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Fresh clone at 089cca636e0e44a70dd9167b7d813762ea80daca.

php -v
PHP 5.5.9-1ubuntu4.3 (cli) (built: Jul 7 2014 16:36:58)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies
with Zend OPcache v7.0.3, Copyright (c) 1999-2014, by Zend Technologies
with Xdebug v2.2.3, Copyright (c) 2002-2013, by Derick Rethans

j@wd42:~/workspace/doctrine2$ phpunit
PHPUnit 4.3-ge243de0 by Sebastian Bergmann.

Configuration read from /home/j/workspace/doctrine2/phpunit.xml.dist

............................................................. 61 / 2500 ( 2%)
........S.................................................... 122 / 2500 ( 4%)
............................................................. 183 / 2500 ( 7%)
............................................................. 244 / 2500 ( 9%)
............................................................. 305 / 2500 ( 12%)
............................................................. 366 / 2500 ( 14%)
.........................S...SSSS.S.......................... 427 / 2500 ( 17%)
............................................................. 488 / 2500 ( 19%)
....................................................SS....... 549 / 2500 ( 21%)
............................................................. 610 / 2500 ( 24%)
............................................................. 671 / 2500 ( 26%)
............................................................. 732 / 2500 ( 29%)
............................................................. 793 / 2500 ( 31%)
........................................................S.SSS 854 / 2500 ( 34%)
SSSSSSSSS.................................................... 915 / 2500 ( 36%)
..........................................SS................. 976 / 2500 ( 39%)
.............S...S...........S..............................S 1037 / 2500 ( 41%)
........PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 65552 bytes) in /home/j/workspace/doctrine2/vendor/doctrine/common/lib/Doctrine/Common/Proxy/ProxyGenerator.php on line 280
PHP Stack trace:
PHP 1.

{main}

() /usr/bin/phpunit.phar:0
PHP 2. PHPUnit_TextUI_Command::main() /usr/bin/phpunit.phar:586
PHP 3. PHPUnit_TextUI_Command->run() phar:///usr/bin/phpunit.phar/phpunit/TextUI/Command.php:132
PHP 4. PHPUnit_TextUI_TestRunner->doRun() phar:///usr/bin/phpunit.phar/phpunit/TextUI/Command.php:179
PHP 5. PHPUnit_Framework_TestSuite->run() /home/j/workspace/doctrine2/vendor/phpunit/phpunit/src/TextUI/TestRunner.php:423
PHP 6. PHPUnit_Framework_TestSuite->run() /home/j/workspace/doctrine2/vendor/phpunit/phpunit/src/Framework/TestSuite.php:715
PHP 7. PHPUnit_Framework_TestCase->run() /home/j/workspace/doctrine2/vendor/phpunit/phpunit/src/Framework/TestSuite.php:715
PHP 8. PHPUnit_Framework_TestResult->run() /home/j/workspace/doctrine2/vendor/phpunit/phpunit/src/Framework/TestCase.php:672
PHP 9. PHPUnit_Framework_TestCase->runBare() /home/j/workspace/doctrine2/vendor/phpunit/phpunit/src/Framework/TestResult.php:654
PHP 10. PHPUnit_Framework_TestCase->runTest() /home/j/workspace/doctrine2/vendor/phpunit/phpunit/src/Framework/TestCase.php:734
PHP 11. ReflectionMethod->invokeArgs() /home/j/workspace/doctrine2/vendor/phpunit/phpunit/src/Framework/TestCase.php:859
PHP 12. Doctrine\Tests\ORM\Functional\Ticket\DDC1436Test->testIdentityMap() /home/j/workspace/doctrine2/vendor/phpunit/phpunit/src/Framework/TestCase.php:859
PHP 13. Doctrine\ORM\AbstractQuery->getOneOrNullResult() /home/j/workspace/doctrine2/tests/Doctrine/Tests/ORM/Functional/Ticket/DDC1436Test.php:42
PHP 14. Doctrine\ORM\AbstractQuery->execute() /home/j/workspace/doctrine2/lib/Doctrine/ORM/AbstractQuery.php:766
PHP 15. Doctrine\ORM\AbstractQuery->executeIgnoreQueryCache() /home/j/workspace/doctrine2/lib/Doctrine/ORM/AbstractQuery.php:923
PHP 16. Doctrine\ORM\Internal\Hydration\AbstractHydrator->hydrateAll() /home/j/workspace/doctrine2/lib/Doctrine/ORM/AbstractQuery.php:977
PHP 17. Doctrine\ORM\Internal\Hydration\ObjectHydrator->hydrateAllData() /home/j/workspace/doctrine2/lib/Doctrine/ORM/Internal/Hydration/AbstractHydrator.php:147
PHP 18. Doctrine\ORM\Internal\Hydration\ObjectHydrator->hydrateRowData() /home/j/workspace/doctrine2/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php:160
PHP 19. Doctrine\ORM\Internal\Hydration\ObjectHydrator->getEntity() /home/j/workspace/doctrine2/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php:432
PHP 20. Doctrine\ORM\UnitOfWork->createEntity() /home/j/workspace/doctrine2/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php:268
PHP 21. Doctrine\Common\Proxy\AbstractProxyFactory->getProxy() /home/j/workspace/doctrine2/lib/Doctrine/ORM/UnitOfWork.php:2714
PHP 22. Doctrine\Common\Proxy\AbstractProxyFactory->getProxyDefinition() /home/j/workspace/doctrine2/vendor/doctrine/common/lib/Doctrine/Common/Proxy/AbstractProxyFactory.php:119
PHP 23. Doctrine\Common\Proxy\ProxyGenerator->generateProxyClass() /home/j/workspace/doctrine2/vendor/doctrine/common/lib/Doctrine/Common/Proxy/AbstractProxyFactory.php:218
PHP 24. strtr() /home/j/workspace/doctrine2/vendor/doctrine/common/lib/Doctrine/Common/Proxy/ProxyGenerator.php:280






[DDC-3228] ORM\Tools\Export\Driver\PhpExporter.php does not properly export manyToOne associations Created: 24/Jul/14  Updated: 24/Jul/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers, ORM, Tools
Affects Version/s: Git Master
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Dan V Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mapping, orm, schematool
Environment:

PHP 5.5.9-1ubuntu4 (cli)



 Description   

PhpExporter.php fails to check the association for manyToOne/oneToOne and exports all associations as oneToOne.

See https://github.com/doctrine/doctrine2/tree/master/lib/Doctrine/ORM/Tools/Export/Driver/PhpExporter.php#L116 where oneToOne is hardcoded if the bitmask matches either manyToOne or oneToOne.

As opposed to YamlExporter.php:

https://github.com/doctrine/doctrine2/tree/master/lib/Doctrine/ORM/Tools/Export/Driver/YamlExporter.php#L165

Which does roughly the same thing, but then properly sets the association type by checking the actual association on lines 186 through one 190:

https://github.com/doctrine/doctrine2/tree/master/lib/Doctrine/ORM/Tools/Export/Driver/YamlExporter.php#L186-L190






[DDC-3224] getResult(HYDRATE_OBJECT) with joined query is returning reduced number of rows Created: 23/Jul/14  Updated: 17/Sep/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4.2
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: gondo Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm
Environment:

osx, PHP-FPM 5.5.13, nginx/1.6.0, mysql 5.6.19 Homebrew



 Description   

given that i have these 2 entities (pseodocode):

/**
 * @ORM\Table(name="entity1", options={"collate"="utf8_unicode_ci", "charset"="utf8"})
 * @ORM\Entity(repositoryClass="Entity1Repository")
 */
class Entity1 {
    /**
     * @var integer
     * @ORM\Column(name="id", type="integer")
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;

    /**
     * @var string
     * @ORM\Column(name="name", type="string")
     */
    protected $name;

    /**
     * @var Entity2[]
     * @ORM\OneToMany(targetEntity="Entity2", mappedBy="entity1")
     */
    protected $entity2;
}

/**
 * @ORM\Table(name="entity2", options={"collate"="utf8_unicode_ci", "charset"="utf8"})
 * @ORM\Entity()
 */
class Entity2 {
    /**
     * @var integer
     * @ORM\Column(name="id", type="integer")
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;

    /**
     * @var \DateTime
     * @ORM\Column(name="date", type="datetime")
     */
    protected $date;

    /**
     * @var Entity1
     * @ORM\ManyToOne(targetEntity="Entity1", inversedBy="entity2", fetch="EAGER")
     */
    protected $entity1;
}

tables and data

entity1:

id name
1 Jhon
2 Clare

entity2:

id date entity1_id
1 2011-01-01 00:00:01 1
2 2012-02-02 00:00:02 1
3 2013-03-03 00:00:03 2
4 2014-04-04 00:00:04 2

my query builder

use Doctrine\ORM\EntityRepository;

class Entity1Repository extends EntityRepository
{
    public function getData()
    {
        $qb = $this
            ->createQueryBuilder('Entity1')
            ->select('Entity1, Entity2.date')
            ->join('Entity1.entity2', 'Entity2', Join::WITH, 'Entity2.date > :date')
            ->setParameter('date', '2000-01-01 00:00:01')
        ;
        $result1 = $qb->getQuery()->getArrayResult(); // HYDRATE_ARRAY
        $result = $qb->getQuery()->getResult(); // HYDRATE_OBJECT
        
//        return $result1;
//        return $result2;
    }
}

proper result is this:

id name date
1 Jhon 2011-01-01 00:00:01
1 Jhon 2012-02-02 00:00:02
2 Clare 2013-03-03 00:00:03
2 Clare 2014-04-04 00:00:04

what is happening

$result1 = $qb->getQuery()->getArrayResult(); // HYDRATE_ARRAY

is really returning proper number of rows

BUT and here comes the BUG finally:

$result2 = $qb->getQuery()->getResult(); // HYDRATE_OBJECT

is returning just 2 rows:

id name date
1 Jhon 2011-01-01 00:00:01
2 Clare 2013-03-03 00:00:03

this is because somehow entities are made unique.

my workaround

as a workaround, what i have to do is, to exectute 2 queries. 1st to get just Entity1.ids joined with Entity2.dates by using `getArrayResult()`
and second query to get Entity1 objeces by unique ids from 1st query.
and than manualy join those results in php.



 Comments   
Comment by Marco Pivetta [ 23/Jul/14 ]

I see that you are using Join::WITH, but not providing a conditional in the example. Are you filtering a fetch-joined association?

Comment by gondo [ 23/Jul/14 ]

sorry i've tried to simplify my structure as much as it was possible, there are actually real conditions, one of them is date condition (among many others). i've updated my code

Comment by Marco Pivetta [ 23/Jul/14 ]

There are still some inconsistencies in the issue - where is that query parameter used, for example?

Comment by gondo [ 23/Jul/14 ]

im using it in EntityRepository (sorry, didnt know thats important) i ll update my code
and the whole code is in Symfony2 project (web and command line applications)

Comment by Marco Pivetta [ 23/Jul/14 ]

What I mean is that in

->setParameter('date', new \DateTime('last month'))

, parameter :date does not exist in the DQL.

Comment by gondo [ 23/Jul/14 ]

i see, sorry its part of JOIN condition, i've updated the code





[DDC-3221] Invalid binding for primary key of entity relation Created: 21/Jul/14  Updated: 21/Jul/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: 2.4.3
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Alexandr Smaga Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm


 Description   

Hello.

We use doctrine2 ORM with doctrine/doctrine-bundle in our symfony2 based project. We developed functionality which is similar to some kind of import process.

And we have an issue that appears from time to time in different points during the import.

Issue is following:
Lets imagine we have 3 entities Account, Contact, Contact Address.
Account has many to one relation on contact and contact has one to many relation on contact address.

Our import creates all 3 entities and persist only Account, contact and address are persisted via cascade persist.
We have writer that contains following code

    public function write(array $items)
    {
        try {
            $this->entityManager->beginTransaction();
            foreach ($items as $item) {
                $this->entityManager->persist($item);
            }
            $this->entityManager->commit();
        } catch (\Exception $exception) {
            $this->entityManager->rollback();

            throw $exception;
        }
        $this->entityManager->flush();
        $this->entityManager->clear();
    }

So we clear EntityManager for each batch in order to avoid high memory consumption.
Import fails during different entities insert, but errors are very similar.
Example of error is

> [error] An exception occurred while executing 'INSERT INTO ... VALUES (?, ?, ?, ?, ?)' with params ["__start__", "2014-07-21 00:55:35", 0, null, 21]:
>
> SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (`DB`.`account`, CONSTRAINT `FK_B3D57B301023C4EE` FOREIGN KEY (`contact_id`) REFERENCES `contact` (`id`) ON DELETE CASCADE)

After debugging I found that problem is in BasicEntityPersister#prepareUpdateData

$uow->getEntityIdentifier($newVal);


returns oid that is real one, but UOW contains not the same ID as in $newVal entity. It seems like spl_object_hash duplicates oid.

Any help is appreciated.
Thanks in advance.






[DDC-3220] Association mappings of embedded class not loaded into entity classMetadata Created: 21/Jul/14  Updated: 21/Jul/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Anatolie Marinescu Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None


 Description   

method inlineEmbeddable from Doctrine\ORM\Mapping\ClassMetadataInfo mapped only columns, but relations is omitted






[DDC-3218] Argument 3 passed to Doctrine\ORM\Event\PreUpdateEventArgs::__construct() must be of the type array, null given Created: 18/Jul/14  Updated: 26/Aug/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4.2, 2.4.4
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Grégoire Pineau Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None
Environment:

Linux / Mint 15
php 5.5.*



 Description   

Argument 3 passed to Doctrine\ORM\Event\PreUpdateEventArgs::__construct() must be of the type array, null given, called in /home/greg/dev/product/insight/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php on line 1009 and defined

Stack trace:

[1] PHPUnit_Framework_Error: Argument 3 passed to Doctrine\ORM\Event\PreUpdateEventArgs::__construct() must be of the type array, null given, called in /project/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php on line 1009 and defined
at n/a
in /project/vendor/doctrine/orm/lib/Doctrine/ORM/Event/PreUpdateEventArgs.php line 47

at PHPUnit_Util_ErrorHandler::handleError('4096', 'Argument 3 passed to Doctrine\ORM\Event\PreUpdateEventArgs::__construct() must be of the type array, null given, called in /project/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php on line 1009 and defined', '/project/vendor/doctrine/orm/lib/Doctrine/ORM/Event/PreUpdateEventArgs.php', '47', array('entity' => object(Violation), 'em' => object(EntityManager)))
in /project/vendor/doctrine/orm/lib/Doctrine/ORM/Event/PreUpdateEventArgs.php line 47

at Doctrine\ORM\Event\PreUpdateEventArgs->__construct(object(Violation), object(EntityManager), null)
in /project/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php line 1009

at Doctrine\ORM\UnitOfWork->executeUpdates(object(ClassMetadata))
in /project/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php line 341

at Doctrine\ORM\UnitOfWork->commit(null)
in /project/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php line 389

at Doctrine\ORM\EntityManager->flush()
in /project/src/SensioLabs/Bundle/MyBundle/Controller/MyController.php line 127

at SensioLabs\Bundle\MyBundle\Controller\MyController->ignoreAction(object(Request), object(Project), object(Analysis), '4')
in line

at call_user_func_array(array(object(MyController), 'ignoreAction'), array(object(Request), object(Project), object(Analysis), '4'))
in /project/app/bootstrap.php.cache line 1043

at Symfony\Component\HttpKernel\HttpKernel->handleRaw(object(Request), '1')
in /project/app/bootstrap.php.cache line 1015

at Symfony\Component\HttpKernel\HttpKernel->handle(object(Request), '1', true)
in /project/app/bootstrap.php.cache line 1154

at Symfony\Component\HttpKernel\DependencyInjection\ContainerAwareHttpKernel->handle(object(Request), '1', true)
in /project/app/bootstrap.php.cache line 435

at Symfony\Component\HttpKernel\Kernel->handle(object(Request))
in /project/vendor/symfony/symfony/src/Symfony/Component/HttpKernel/Client.php line 81

at Symfony\Component\HttpKernel\Client->doRequest(object(Request))
in /project/vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Client.php line 111

at Symfony\Bundle\FrameworkBundle\Client->doRequest(object(Request))
in /project/vendor/symfony/symfony/src/Symfony/Component/BrowserKit/Client.php line 319

at Symfony\Component\BrowserKit\Client->request('POST', '/projects/id-foo/analyses/2/rule/4/ignore', array('ignore_rule' => array('comment' => 'Message about why this rule has been ignored', '_token' => 'CxEFTSv4GZQSWYXtRt-eHybaML4z8I0WK1DHiwr8Ih0')))
in /project/src/SensioLabs/Bundle/MyBundle/Test/Client.php line 489

at SensioLabs\Bundle\MyBundle\Test\Client->ignoreRuleViolations('id-foo', '2', '4', false)
in /project/src/SensioLabs/Bundle/MyBundle/Tests/Acceptance/ViolationCommentsTest.php line 217

at SensioLabs\Bundle\MyBundle\Tests\Acceptance\ViolationCommentsTest->testDashboardWithCriticalIgnoredRules()
in line

at ReflectionMethod->invokeArgs(object(ViolationCommentsTest), array())
in /project/vendor/phpunit/phpunit/src/Framework/TestCase.php line 951

at PHPUnit_Framework_TestCase->runTest()
in /project/vendor/phpunit/phpunit/src/Framework/TestCase.php line 817

at PHPUnit_Framework_TestCase->runBare()
in /project/vendor/phpunit/phpunit/src/Framework/TestResult.php line 686

at PHPUnit_Framework_TestResult->run(object(ViolationCommentsTest))
in /project/vendor/phpunit/phpunit/src/Framework/TestCase.php line 753

at PHPUnit_Framework_TestCase->run(object(PHPUnit_Framework_TestResult))
in /project/vendor/phpunit/phpunit/src/Framework/TestSuite.php line 675

at PHPUnit_Framework_TestSuite->run(object(PHPUnit_Framework_TestResult))
in /project/vendor/phpunit/phpunit/src/TextUI/TestRunner.php line 426

at PHPUnit_TextUI_TestRunner->doRun(object(PHPUnit_Framework_TestSuite), array('listGroups' => false, 'loader' => null, 'useDefaultConfiguration' => true, 'configuration' => '/project/app/phpunit.xml.dist', 'filter' => 'testDashboardWithCriticalIgnoredRules', 'testSuffixes' => array('Test.php', '.phpt')))
in /opt/dotfiles/vendor/phpunit/phpunit/PHPUnit/TextUI/Command.php line 176

at PHPUnit_TextUI_Command->run(array('/usr/local/bin/phpunit', 'c', 'app/', '-filter', 'testDashboardWithCriticalIgnoredRules', 'src/SensioLabs/Bundle/MyBundle/Tests/Acceptance/ViolationCommentsTest.php'), true)
in /opt/dotfiles/vendor/phpunit/phpunit/PHPUnit/TextUI/Command.php line 129

at PHPUnit_TextUI_Command::main()
in /opt/dotfiles/vendor/phpunit/phpunit/composer/bin/phpunit line 63

I fails in this code

    private function executeUpdates($class)
    {
        $className          = $class->name;
        $persister          = $this->getEntityPersister($className);
        $preUpdateInvoke    = $this->listenersInvoker->getSubscribedSystems($class, Events::preUpdate);
        $postUpdateInvoke   = $this->listenersInvoker->getSubscribedSystems($class, Events::postUpdate);

        foreach ($this->entityUpdates as $oid => $entity) {
            if ($this->em->getClassMetadata(get_class($entity))->name !== $className) {
                continue;
            }

            if ($preUpdateInvoke != ListenersInvoker::INVOKE_NONE) {
// => this line
                $this->listenersInvoker->invoke($class, Events::preUpdate, $entity, new PreUpdateEventArgs($entity, $this->em, $this->entityChangeSets[$oid]), $preUpdateInvoke);
                $this->recomputeSingleEntityChangeSet($class, $entity);
            }

            if ( ! empty($this->entityChangeSets[$oid])) {
                $persister->update($entity);
            }

            unset($this->entityUpdates[$oid]);

            if ($postUpdateInvoke != ListenersInvoker::INVOKE_NONE) {
                $this->listenersInvoker->invoke($class, Events::postUpdate, $entity, new LifecycleEventArgs($entity, $this->em), $postUpdateInvoke);
            }
        }
    }


 Comments   
Comment by Marco Pivetta [ 18/Jul/14 ]

Requires a test case

Comment by Victor [ 26/Aug/14 ]

I have same bug when call flush() method from entity manager in my few event listeners in Symfony.

P.S. If I call flush() only from one listener - it works well, but when call flush() in first, and then in second - it fails. And it does not matter in which order listeners are called.

Comment by Grégoire Pineau [ 26/Aug/14 ]

yeah, the bug occurs in the same circumstance as described by victor.
(sorry for the delay, and sorry to not provider a test case)

Comment by Christophe Coevoet [ 26/Aug/14 ]

Calling flush() inside a Doctrine listener is not a supported Doctrine usage. it means you are trying to nest several flushes inside each other, which can indeed break the unit of work

Comment by Grégoire Pineau [ 26/Aug/14 ]

I refactored this part of our code base, to remove all flush from the listener. Everything works right now.
But I did not know this was not possible. (And it's not me the guy who created this **** in our codebase )

Comment by Victor [ 26/Aug/14 ]

So, for example, if I use postUpdate Doctrine event to modify the entity after save them to DB, I can't save additional changes to DB again with flush() in my listener?
Is it will be fixed or it's a normal behavior of Doctrine?





[DDC-3215] wrong quotation Created: 16/Jul/14  Updated: 17/Jul/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: DQL, ORM
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: revrev Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dql, orm


 Description   

when doctrine build query´s, for example when you doing

$entitity->getTest()->clear();

following queries are generated (test_id is integer in mysql):

DELETE FROM test WHERE test_id = '6'

Is this right?
For me the right query would be:

DELETE FROM test WHERE test_id = 6

as in http://dev.mysql.com/doc/refman/5.5/en/type-conversion.html
6 will be converted to float, this can be an issue, or?

Comparisons that use floating-point numbers (or values that are converted to floating-point numbers) are approximate because such numbers are inexact. This might lead to results that appear inconsistent:

mysql> SELECT '18015376320243458' = 18015376320243458;
        -> 1
mysql> SELECT '18015376320243459' = 18015376320243459;
        -> 0

this also happens in dql sometimes, why doctrine does this not automatic right due to description in the entities?

     /**
     * @ORM\Id @ORM\Column(type="integer")
     * @ORM\GeneratedValue
     */


 Comments   
Comment by Marco Pivetta [ 16/Jul/14 ]

Could you please convert this to a failing test case? Doctrine doesn't quote integers as strings by default.

Comment by revrev [ 16/Jul/14 ]

i try to describe what i have done

i have an Entity with:

    /**
     * @ORM\ManyToMany(targetEntity="Messen", inversedBy="vertrag_messen")
     * @ORM\JoinTable(name="vertrag_messen")
     **/
    private $vertrag_messen;

    public function __construct()
    {
        $this->vertrag_messen = new \Doctrine\Common\Collections\ArrayCollection();
    }

    public function getMessen()
    {
        return $this->vertrag_messen;
    }

when i now clear the Data

$entitity->getMessen()->clear();

following query is created
DELETE FROM vertrag_messen where messe_id = '6'

Should here not set the value 6 as integer (param_int) (DELETE FROM test vertrag_messen where messe_id = 6) that mysql doesn´t have to cast the value? (http://dev.mysql.com/doc/refman/5.5/en/type-conversion.html) or is this not an problem?

Comment by Marco Pivetta [ 16/Jul/14 ]

is messe_id in your entity an integer or a string at the moment in time when that query is being executed?

Comment by revrev [ 16/Jul/14 ]

the value comes automatic
$entitity = $em->getRepository('Base\Entities\Vertrag')>find(intval($data["id"]));

i don´t set messe_id here

Comment by Marco Pivetta [ 16/Jul/14 ]

Can you var_dump the Base\Entities\Messe instance?

Comment by revrev [ 16/Jul/14 ]

object(stdClass)#1014 (64) {
["__CLASS__"]=>
string(24) "Base\Entities\Vertrag"
["id"]=>
int(6)
[„vertrag_messen"]=>
array(1)

Unknown macro: { [0]=> string(20) "BaseEntitiesMessen" }


["erstellungsdatum"]=>
object(stdClass)#1210 (3)

Unknown macro: { ["__CLASS__"]=> string(8) "DateTime" ["date"]=> string(25) "2013-09-28T00}

["zeitraumvon"]=>
NULL
["zeitraumbis"]=>
NULL
["jahr"]=>
int(2014)
["created"]=>
object(stdClass)#1178 (3)

Unknown macro: { ["__CLASS__"]=> string(8) "DateTime" ["date"]=> string(25) "2013-09-28T19}

["updated"]=>
object(stdClass)#1177 (3)

Unknown macro: { ["__CLASS__"]=> string(8) "DateTime" ["date"]=> string(25) "2014-07-16T17}

["uuid"]=>
string(36) "52470c58-4288-45eb-b75f-0c41c0a81437"
}

Comment by Marco Pivetta [ 17/Jul/14 ]

yeah, integer identifier there.
Could you verify if the problem also comes up with current master? I think this issue is related with another one that was fixed some months ago in 2.5.x-dev





[DDC-3211] Annotation @ORM\Table(name="schema.table") don't generate sql using OCI8 Created: 09/Jul/14  Updated: 12/Jul/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers, ORM
Affects Version/s: 2.4.1, 2.4.2
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Jorge Potosme Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: cli, mapping, oci8, oracle, orm, symfony
Environment:

OS: Fedora 20
Web Server: Apache
DBMS: Oracle 12c
Framework: Symfony2
PHP version: 5.5.14
DBMS Driver: OCI8



 Description   

Using Symfony and "doctrine/orm": "2.4.@dev", "doctrine/doctrine-bundle": "1.3.@dev", with OCI8(Oracle Call Interface)
I have an entity
/**
* @ORM\Entity
* @ORM\Table(name="rrhh.usuario")
*/
class Usuario implements UserInterface

{ ... }

When i use de CLI (php app/console doctrine:schema:create --dump-sql) this don't show nothing, the output is empty.

If i change (name="rrhh.usuario") to (name="usuario", schema="rrhh") the CLI show the sql query but without the schema.



 Comments   
Comment by Marco Pivetta [ 09/Jul/14 ]

Duplicates this issue





[DDC-3203] "Orphan Removal" for ManyToMany and "Cascade remove" doesn't trigger "preRemove" callback on related entity Created: 01/Jul/14  Updated: 02/Jul/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Tadej Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Latest ZendFramework2, latest ZF2 DoctrineModule and latest ZF2 DoctrineORMModule



 Description   

I'm not sure if it's me, but I couldn't get "preRemove" callback/event working when "remove" action is triggered from related entity, but it works where the entity itself (the one with "preRemove" event) is removed directly.

According to documentation:
"If an association is marked as CASCADE=REMOVE Doctrine 2 will fetch this association. If its a Single association it will pass this entity to ´EntityManager#remove()`"....and similar for multiple entities.
DOC: http://doctrine-orm.readthedocs.org/en/latest/reference/working-with-objects.html?highlight=working-with-objects%20removing-entities#removing-entities

"preRemove event is called on every entity when its passed to the EntityManager#remove()"
DOC: http://docs.doctrine-project.org/en/latest/reference/events.html#preremove

So according to documentation "preRemove" should get triggered on "cascade remove", but it doesn't get in my case. Is this normal behavior or a bug?

I'm not sure if it the problem might be in any of ZF2 modules, but I've decided to post the issue here, since I'm referring to documentation of this project.

Beside that I've also noticed that "orphan removal" doesn't work on ManyToMany, although documentation says that it's supported (on IRC they've said that it may be a bug in documentation, that it is not really yet supported...they found no code changes when documentation was changed).
DOC:
http://docs.doctrine-project.org/en/latest/reference/working-with-associations.html#orphan-removal






[DDC-3200] [GH-1077] Support filter parameters in Configuration Created: 01/Jul/14  Updated: 01/Jul/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of jmikola:

Url: https://github.com/doctrine/doctrine2/pull/1077

Message:

Based on work done in doctrine/mongodb-odm#908

My understanding is that this makes it easier to setup filters at boot time, instead of having to fetch them from the collection later on.

For added context, the related PR from MongoDB ODM's Symfony bundle is doctrine/DoctrineMongoDBBundle#255






[DDC-3197] [GH-1074] [DDC-3160] Alternate fix for DDC-2996 bug Created: 26/Jun/14  Updated: 06/Jul/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of zimmermanj42:

Url: https://github.com/doctrine/doctrine2/pull/1074

Message:

The fix implemented for DDC-2996 seems to have broken quite a bit of code outside of Doctrine (for instance, the popular DoctrineExtensions project).

I'm not too well versed in Doctrine internals, but looking at the fix, I found it odd that an entity would live in both the insertion and update tracking in the unit of work.

This implementation should fix the case described in DDC-2996, while not creating any side effects with objects that are scheduled to be inserted.

I've ran this test with the Doctrine test suite and have also tested this change with the DoctrineExtensions project; unless I'm doing something wrong, it seems to have good results.

Again, I'm not too well versed in the inner workings of Doctrine, but I did a little research, poked around some code, and came up with this.



 Comments   
Comment by Doctrine Bot [ 06/Jul/14 ]

A related Github Pull-Request [GH-1057] was closed:
https://github.com/doctrine/doctrine2/pull/1057

Comment by Doctrine Bot [ 06/Jul/14 ]

A related Github Pull-Request [GH-1074] was closed:
https://github.com/doctrine/doctrine2/pull/1074





[DDC-3195] indexBy implementation on containsKey of PersistentCollection in EXTRA LAZY mode uses property name as column name instead of column name Created: 26/May/14  Updated: 26/Jun/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers, ORM
Affects Version/s: 2.4.2
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: jos de witte Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None
Environment:

Any



 Description   

indexBy implementation on containsKey (and possibly other EXTRA LAZY implemented methods) of PersistentCollection in EXTRA LAZY mode uses property name as column name instead of column name for OneToMany collections

For example property = fieldName, column name field_name.
Set indexBy on OneToMany annotation to fieldName (as it should be ) and it tries to use fieldName in backend instead of field_name






[DDC-3191] [GH-1072] Fix attempt of traversing bool in FileLockRegion Created: 26/Jun/14  Updated: 26/Jun/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of kamazee:

Url: https://github.com/doctrine/doctrine2/pull/1072

Message:

Minor fix: on some platforms (i.e. ArchLinux) `glob()` returns `false` when nothing matched even though no errors occurred. As docs for `glob` say, such behavior is expected (see ‘Note’ at http://php.net/glob)

This made 1 existing test fail:

./vendor/bin/phpunit 
PHPUnit 4.3-g58f3a0e by Sebastian Bergmann.

Configuration read from /home/alex/git/doctrine2/phpunit.xml.dist

.............................................................   61 / 2495 (  2%)
........S.............E......................................  122 / 2495 (  4%)
.............................................................  183 / 2495 (  7%)
.............................................................  244 / 2495 (  9%)
.............................................................  305 / 2495 ( 12%)
.............................................................  366 / 2495 ( 14%)
.........................S...SSSS.S..........................  427 / 2495 ( 17%)
.............................................................  488 / 2495 ( 19%)
....................................................SS.......  549 / 2495 ( 22%)
.............................................................  610 / 2495 ( 24%)
.............................................................  671 / 2495 ( 26%)
.............................................................  732 / 2495 ( 29%)
.............................................................  793 / 2495 ( 31%)
.......................................................S.SSSS  854 / 2495 ( 34%)
SSSSSSSS.....................................................  915 / 2495 ( 36%)
.........................................SS..................  976 / 2495 ( 39%)
............S...S...........S..............................S. 1037 / 2495 ( 41%)
............................................................. 1098 / 2495 ( 44%)
..................S.......................................... 1159 / 2495 ( 46%)
.................................................SS.......... 1220 / 2495 ( 48%)
.......................S..................................... 1281 / 2495 ( 51%)
............................................................. 1342 / 2495 ( 53%)
............................................................. 1403 / 2495 ( 56%)
............................................................. 1464 / 2495 ( 58%)
............................................................. 1525 / 2495 ( 61%)
............................................................. 1586 / 2495 ( 63%)
.........S.................................................S. 1647 / 2495 ( 66%)
............................................................. 1708 / 2495 ( 68%)
............................................................. 1769 / 2495 ( 70%)
............................................................. 1830 / 2495 ( 73%)
............................................................. 1891 / 2495 ( 75%)
............................................................. 1952 / 2495 ( 78%)
............................................................. 2013 / 2495 ( 80%)
............................................................. 2074 / 2495 ( 83%)
............................................................. 2135 / 2495 ( 85%)
............................................................. 2196 / 2495 ( 88%)
............................................................. 2257 / 2495 ( 90%)
............................................................. 2318 / 2495 ( 92%)
............................................................S 2379 / 2495 ( 95%)
.......S......S.......S.....................S...........S.... 2440 / 2495 ( 97%)
.......................................................

Time: 14.37 seconds, Memory: 164.50Mb

There was 1 error:

1) Doctrine\Tests\ORM\Cache\FileLockRegionTest::testEvictAll
Invalid argument supplied for foreach()

/home/alex/git/doctrine2/lib/Doctrine/ORM/Cache/Region/FileLockRegion.php:204
/home/alex/git/doctrine2/tests/Doctrine/Tests/ORM/Cache/AbstractRegionTest.php:80

Traversing bool is no good and casting to array wouldn't hurt there as far as I can tell.






[DDC-3189] blob doctrine2 not inserting file in mysql Created: 24/Jun/14  Updated: 26/Jun/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4.3
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Gustavo Monti Rocha Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Linux Ubuntu 12.04, Mysql 5


Attachments: PNG File a.png     Zip Archive testedoctrineupload.zip    

 Description   

I have an entity mapped as:

/**
 * @Entity @Table(name="Upload")
**/
class Upload
{
/** @Id @Column(type="integer") @GeneratedValue **/
protected $id;

/** @Column(type="string") **/
protected $nome;

/** @Column(type="blob") **/
protected $arquivo;

When I use this (WORKS)

 $query = "INSERT INTO Upload1 (name, size, type, content ) "."VALUES ('$fileName', '$fileSize', '$fileType', '$content')";

 mysql_query($query)

When I use this doctrine way (NOT WORKING, if you try to get this file from mysql, return a corrupted or empty file)

$upload = new Upload();

$upload-> setContent($content);
$upload-> setName($fileName);
$upload-> setSize($fileSize);
$upload-> setType($fileType);

$entityManager->persist($upload);
$entityManager->flush();

My html file:

<form method="post" enctype="multipart/form-data">
<table width="350" border="0" cellpadding="1" cellspacing="1" class="box">
<tr> 
<td width="246"> 
<input type="hidden" name="MAX_FILE_SIZE" value="2000000">
<input name="userfile" type="file" id="userfile"> 
</td>
<td width="80"><input name="upload" type="submit" class="box" id="upload" value=" Upload    "></td>
</tr>
</table>
</form>


 Comments   
Comment by Gustavo Monti Rocha [ 24/Jun/14 ]

trying to insert this image

Comment by Gustavo Monti Rocha [ 24/Jun/14 ]

Using:
$entityManager->getConnection()>getConfiguration()>setSQLLogger( new Doctrine\DBAL\Logging\EchoSQLLogger());

Getting:
"START TRANSACTION" INSERT INTO Upload (name, type, size, content) VALUES (?, ?, ?, ?) array(4) { [1] => string(5) "a.png" [2] => string(9) "image/png" [3] => int(264547) [4] => string(270342) "‰PNG  \0\0\0 IHDR\0\0@\0\0„\0\0\0v/jõ\0\0\0sBITÛáOà\0\0\0tEXtSoftware\0gnome-screenshotï¿>\0\0 \0IDATxœìw|TÅöÀÏܲ{·$›^I¥“Лҫ€ QPô©`

{êÏγ÷^ŸýYÀ‚ˆ\"¢ô %½m’í햙ߛ,›mÙe¾>š½÷Ι™3gæÎœ;]3ÿR P( …B¡P( …\0\0³X¾Ÿ†X]ŸÞ]ÿÂôP(\0àÜnñ¯N…B¡P( …B¡P(„B\0\0\\.÷ñ’ÊüünݺÇøîÚl¶m;æçfh4\0@BUR)”3®©šR( …B¡P( …ræa2Y+«ëV\0@4……}

Y–<¸§×KEÙ±ãHaaßâ¢#n·\0Ãf¦§ÄÇÇþÅé¦PÎ0¨‹B¡P( …B¡P(g(„ÙttTJ5\"\0< g§æefe¥ú?3rd¿Š £V.W7ì&\0˜âF+‰ø%9uÆF\0HINø«pôx…ZÅuÉL¥“Ô(‘Ù³¯\0ú÷í}ã¶9°A‡Óãr¥Åé¯n"... } array(4)

{ [1] => string(6) "string" [2] => string(6) "string" [3] => string(7) "integer" [4] => string(4) "blob" }

"COMMIT"

Comment by Steve Müller [ 26/Jun/14 ]

This looks more like a DBAL issue. Can you please provide the error/exception message that you receive from the driver/database server? Also do you use PDOMySQL or mysqli driver?

Comment by Gustavo Monti Rocha [ 26/Jun/14 ]

Steve,

I'm not getting any error/expection. Table looks like insert the blob file but when I try to download it is corrupted. You could see at getting .zip file and executing it.

I'm using PDOMysql.

Comment by Marco Pivetta [ 26/Jun/14 ]

This would probably need a data sample to reproduce the issue.

Comment by Gustavo Monti Rocha [ 26/Jun/14 ]

Marco,

you could use project attached and image in order to reproduce.

Comment by Marco Pivetta [ 26/Jun/14 ]

Gustavo Monti Rocha you should actually provide a functional test for this in case, see https://github.com/doctrine/dbal/tree/master/tests/Doctrine/Tests/DBAL

For example, the zip file you uploaded fails on various includes, and doesn't show the failures to me.





[DDC-3188] Call to a member function getValue() on a non-object in vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php Created: 24/Jun/14  Updated: 27/Jun/14

Status: Reopened
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Daniel Imhoff Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

PHP 5.4.11
opensuse
apache2



 Description   

This is the line that causes the fatal error: https://github.com/doctrine/doctrine2/blob/v2.4.2/lib/Doctrine/ORM/UnitOfWork.php#L678

This is the association that is breaking it (i.e. reflFields[ 'user' ] is a non-object):

Tweet.php
/**
 * @ManyToOne(targetEntity="User")
 * @JoinColumn(name="user_id", referencedColumnName="id")
 *
 * @var User
 */
protected $user;

This is the pk of the referenced entity.

User.php
/**
 * @Id
 * @Column(name="id", type="bigint", nullable=false)
 *
 * @var int
 */
protected $id;

If an exception was thrown due to missing metadata information, I could catch it, but fatal errors due to this bug have been crashing our scripts and they've had to be manually restarted.

Let me know what other information is needed.

Full stack trace:

PHP 5. Doctrine\ORM\EntityManager->flush() our_code.php
PHP 6. Doctrine\ORM\UnitOfWork->commit() vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php:389
PHP 7. Doctrine\ORM\UnitOfWork->computeChangeSets() vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:297
PHP 8. Doctrine\ORM\UnitOfWork->computeScheduleInsertsChangeSets() vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:703
PHP 9. Doctrine\ORM\UnitOfWork->computeChangeSet() vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:404
PHP Fatal error: Call to a member function getValue() on a non-object in vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php on line 678



 Comments   
Comment by Marco Pivetta [ 24/Jun/14 ]

Did you actually validate your mappings?

Comment by Daniel Imhoff [ 24/Jun/14 ]

I did not validate the mapping. I did not know about the orm:validate-schema until just now. I will fix these errors and resubmit if there is still an issue.

Sorry about that, thanks.

Comment by Daniel Imhoff [ 24/Jun/14 ]

The tweet and user relationship is not in the list of invalid mappings.

Comment by Marco Pivetta [ 26/Jun/14 ]

Are User and Tweet in the same namespace?

Comment by Daniel Imhoff [ 27/Jun/14 ]

Yes, and I've since then used the FQNS. I would get a class not found error when validating schema.
This is something that I know can't really be debugged by you guys, I was just hoping for a little direction. We are using memcache to store our metadata, and we are clearing and regenerating the metadata during every deploy (it is not autogenerated). I'm now using a commit hash as the namespace of the metadata, so we'll see if this fixes the issue.

Comment by Marco Pivetta [ 27/Jun/14 ]

It looks like a typo (CasESensiTIViTy issue) to me.





[DDC-3184] Invalid hydration of entities using ManyToOne relation via queryBuilder Created: 23/Jun/14  Updated: 23/Jun/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4, 2.4.1, 2.4.2, 2.4.3
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Dmitry Korotovsky Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: None

Attachments: File DDC3184Test.php    

 Comments   
Comment by Dmitry Korotovsky [ 23/Jun/14 ]

In master branch all works perfect

Comment by Dmitry Korotovsky [ 23/Jun/14 ]

Marco Pivetta, fix in 2.5 branch will be ported to 2.4 stable version?

Comment by Marco Pivetta [ 23/Jun/14 ]

Dmitry Korotovsky first we'll need to check what commit fixed the issue. Could you git bisect with your test?

Comment by Dmitry Korotovsky [ 23/Jun/14 ]

Yes, i found it: https://github.com/doctrine/doctrine2/commit/38b683838648b549aad0e38ce88c70b6393755b3

Comment by Marco Pivetta [ 23/Jun/14 ]

Assigning to Guilherme Blanco, since he is the author of the fix.





[DDC-3183] Add JsonSerializable to Collections Created: 22/Jun/14  Updated: 22/Jun/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 3.0
Fix Version/s: 3.0
Security Level: All

Type: New Feature Priority: Major
Reporter: Gabriel Bull Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: collection, orm


 Description   

Implement this:

http://www.php.net/manual/fr/class.jsonserializable.php

Can't really make this claim if Doctrine is not implementing basic interfaces for collections:

> The missing (SPL) Collection/Array/OrderedMap interface.






[DDC-3182] [GH-1066] Added jsonSerialize method to PersistentCollection Created: 22/Jun/14  Updated: 22/Jun/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of gabrielbull:

Url: https://github.com/doctrine/doctrine2/pull/1066

Message:

Added jsonSerialize.

Here is to commit on collections:
https://github.com/doctrine/collections/pull/33



 Comments   
Comment by Doctrine Bot [ 22/Jun/14 ]

A related Github Pull-Request [GH-1066] was closed:
https://github.com/doctrine/doctrine2/pull/1066





[DDC-3181] Class Table Inheritance - wrong table order on insert with more than one level of inheritance Created: 20/Jun/14  Updated: 20/Jun/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4.2
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: M. de Lange Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm
Environment:

oracle



 Description   

note: this issue seems the same as DDC-732

When using class table inheritance with multiple levels i.e.:
Object -> SolidObject -> Building -> House
(House inherits from Building, Building from SolidObject, SolidObject from Object)

Object has the discriminator column and mapping. When persisting a new House entity I get a foreign key error because there is no row in the Building table.

I searched in the Code and found the problem. In the class "Doctrine\ORM\Persisters\JoinedSubclassPersister" in function "executeInserts()" around line 146 the array $subTableStmts is first declared and then filled with insert statements. The statement of the House-table is first added, and then the parent-tables (except the root-table "Object", since that one is executed first).

So the order in which the insert statements are executed is:
1 Insert into Object ...
2 Insert into House ... (which causes the error)
3 insert into Building ...
4 Insert into SolidObject

I edited the source to insert into the parent-tables (first SolidObject, then Building) before inserting into the table that belongs to the class that is persisted (House). And this works fine in my case.






[DDC-3176] Table-inheritance and OneToOne association as entity ID Created: 18/Jun/14  Updated: 18/Jun/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Elioty Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: association, identity, inheritance, orm
Environment:

Ubuntu 14.04, PHP 5.5.9-1ubuntu4, Symfony 2.5



 Description   

The issue is fully described here:
http://stackoverflow.com/questions/24265731/symfony-doctrine-class-table-inheritance-and-foreign-key-as-primary-key






[DDC-3174] Query Cache not correct working when using SQLFilter Created: 17/Jun/14  Updated: 17/Jun/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4.1
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Benno Eggnauer Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: cache, sqlfilter


 Description   

We have an SQLFilter to filter on entities with a specific Trait implemented. The filter is very easy:

$res = $targetTableAlias . '.agency_id = ' . $this->getCurrentAgencyId();

On our system we have the query cache enabled, this works as long the "AgencyId" doesn't change. When the ID changes, the query cache seems to return the wrong (old cache) query.



 Comments   
Comment by Marco Pivetta [ 17/Jun/14 ]

I'm not sure if this case should be contemplated by the ORM. Filters are low-level and supposed to be stateless (services).

Comment by Benno Eggnauer [ 17/Jun/14 ]

OK, we can disable the query cache for this case. But then should at least the documentation be updated, which explicitly mentions to use filter for locales, which are also not stateless: http://doctrine-orm.readthedocs.org/en/latest/reference/filters.html#example-filter-class

Also in the query cache chapter: http://doctrine-orm.readthedocs.org/en/latest/reference/caching.html#query-cache

It is highly recommended that in a production environment you cache the transformation of a DQL query to its SQL counterpart. It doesn’t make sense to do this parsing multiple times as it doesn’t change unless you alter the DQL query.

Comment by Marco Pivetta [ 17/Jun/14 ]

Benno Eggnauer can you eventually provide a pull request?





[DDC-3171] [GH-1060] [DDC-3170] SimpleObjectHydrator fails to get discriminator column from mapped SQL result Created: 17/Jun/14  Updated: 17/Jun/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of ureimers:

Url: https://github.com/doctrine/doctrine2/pull/1060

Message:

This PR fixes DDC-3170(http://www.doctrine-project.org/jira/browse/DDC-3170).

When querying a simple entity which uses single table- or class table inheritance using simple object hydration (``AbstractQuery::HYDRATE_SIMPLEOBJECT``), the mapped discriminator column was not retrieved correctly.

If the column got an alias during result set mapping other than it's actual name (e.g. ``type34`` instead of ``type``) than this alias wasn't correctly resolved when retrieving the discriminator column from the SQL result set.



 Comments   
Comment by Ulf Reimers [ 17/Jun/14 ]

I created DDC-3170 for this and put it into the PR like stated in https://github.com/doctrine/doctrine2/blob/master/CONTRIBUTING.md#doctrinebot-tickets-and-jira.

Unfortunately the BOT still created this issue here which can be removed in my opinion.

Comment by Doctrine Bot [ 17/Jun/14 ]

A related Github Pull-Request [GH-1060] was closed:
https://github.com/doctrine/doctrine2/pull/1060





[DDC-3170] SimpleObjectHydrator fails to get discriminator column from mapped SQL result Created: 17/Jun/14  Updated: 17/Jun/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Ulf Reimers Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: hydrator, inheritance, orm


 Description   

When querying a simple entity which uses single table- or class table inheritance using simple object hydration (AbstractQuery::HYDRATE_SIMPLEOBJECT), the mapped discriminator column is not retrieved correctly.

Example:

/**
 * @Entity
 * @InheritanceType("JOINED")
 * @DiscriminatorColumn(name="type", type="string")
 * @DiscriminatorMap({"product" = "Product"})
 */
abstract class AbstractEntity
{
    /** @Id @Column(type="integer") @GeneratedValue */
    public $id;
}

/**
 * @Entity
 */
class Product extends AbstractEntity
{
}

$manager->createQueryBuilder()
                ->select('p')
                ->from('Product, 'p')
                ->getQuery()
                ->getResult(AbstractQuery::HYDRATE_SIMPLEOBJECT);

// -> Exception: [Doctrine\ORM\Internal\Hydration\HydrationException] The discriminator column "type" is missing for "Product" using the DQL alias "p".

The SQL statement used is equal to:

SELECT r0_.id AS id0, r0_.type AS type1 FROM Product r1_ INNER JOIN AbstractEntity r0_ ON r1_.id = r0_.id

As you can see, the type column is given an alias of type1. This is saved in the ResultSetMapping of the request but not taken into account when actually retrieving the discriminator column back from the SQL result.

The problem is inside SimpleObjectHydrator#hydrateRowData().

When the discriminator column name is fetched via

$discrColumnName = $this->_platform->getSQLResultCasing($this->class->discriminatorColumn['name']);

the result is simply type which is wrong because the alias is type2. This can be fixed by adding

if ($metaMappingDiscrColumnName = array_search($discrColumnName, $this->_rsm->metaMappings)) {
    $discrColumnName = $metaMappingDiscrColumnName;
}

right after the column retrieval, because then the alias of the meta field type is correctly taken into account.

I'll create a PR with a unit test for this fix right after this ticket's creation.

I hope I'm doing everything right, this is my first contribution.



 Comments   
Comment by Ulf Reimers [ 17/Jun/14 ]

PR is https://github.com/doctrine/doctrine2/pull/1060

I though that I first create a ticket, then propose a fix for that with a PR and by adding the Ticket ID in the PR-Title they are linked automatically. But unfortunately it seems I've done something wrong there.

Comment by Doctrine Bot [ 17/Jun/14 ]

A related Github Pull-Request [GH-1060] was closed:
https://github.com/doctrine/doctrine2/pull/1060





[DDC-3169] ManyToMany association fails when joining on a single column of a composity key Created: 17/Jun/14  Updated: 17/Jun/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4.2
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Bram Gerritsen Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: association, composite, orm


 Description   

I have two entities with a ManyToMany association between them. The first entity Campsite has a composite key (campsiteID, year). The second entity Region has a single key (regionID).
I want to create an association between Campsite::campsiteID and Region::regionID. See the entities below.

Campsite
/**
 * @ORM\Table(name="Campsite")
 */
class Campsite
{
    /**
     * @ORM\Id
     * @ORM\Column(name="campsiteID", type="integer", precision=0, nullable=false)
     */
    protected $campsiteID;

    /**
     * @ORM\Id
     * @ORM\Column(name="year", type="smallint", precision=0, nullable=false)
     */
    protected $year;

    /**
     * @ORM\ManyToMany(targetEntity="AcsiGeo\Entity\Region", fetch="EAGER", cascade={"detach"})
     * @ORM\JoinTable(name="CampsiteRegion",
     *   joinColumns={
     *     @ORM\JoinColumn(name="campsiteID", referencedColumnName="campsiteID", nullable=false)
     *   },
     *   inverseJoinColumns={
     *     @ORM\JoinColumn(name="regionID", referencedColumnName="regionID", nullable=false)
     *   }
     * )
     * @var \Doctrine\Common\Collections\ArrayCollection $regions
     */
    protected $regions;
}
Region
/**
 * @ORM\Table(name="Region")
 */
class Region
{
    /**
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="IDENTITY")
     * @ORM\Column(name="regionID", type="integer", precision=0, nullable=false)
     */
    protected $regionID;
}

I run the following code to persist a new one.

$campsite = new Campsite();
$campsite->setCampsiteID(111111);
$campsite->setYear(2014);

$region = new Region();
$region->setRegionID(1);
$campsite->addRegion($region);

$em->persist($region);
$em->persist($campsite);
$em->flush();

This results in a record added to the CampsiteRegion table:

campsiteID : 2014
regionID: 1

This is clearly wrong as the value of the year field is added to the campsiteID column.

While debugging the problem I've found an issue with the method to determine the params in ManyToManyPersister on line 147.
The following code pops the last identifier from the array of identifiers.

$params[] = $isRelationToSource ? array_pop($identifier1) : array_pop($identifier2);

In my case:

array(
    'campsiteID' => 111111,
    'year' => 2014
)

Which picks 2014 as the value to use.
When I change the code to get the actual column from the array everything works as expected.

$params[] = $isRelationToSource ? $identifier1[$joinTableColumn] : $identifier2[$joinTableColumn];

I am not 100% sure if this change will have some side effects / edge case I'm not aware of.

For the time being I have fixed the problem bij just reversing the properties in my class, but this is not a real fix of course.






[DDC-3165] one to zero or one with identity through foreign entity Created: 13/Jun/14  Updated: 13/Jun/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: Git Master
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Andries Seutens Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   
<?php

/**
 * @Entity
 */
class User
{
    /** 
     * @Id @Column(type="integer") 
     * @GeneratedValue 
     */
    private $id;
    
    /**
     * @ORM\OneToOne(targetEntity="Address")
     *
     * @var Address
     */
    private $address;
    
    public function getAddress()
    {
        return $this->address;
    }
}

/**
 * @Entity
 */
class Address
{
    /**
     * @Id @OneToOne(targetEntity="User") 
     */
    private $user;
    
    public function foo()
    {}
}


?>

The relation between user and address is one to zero or one. When a record exists on both sides, everything goes fine. When the right side (address) does not have a relevant record, calling $user->getAddress(); always returns an instance. Calling a method on that instance results in an exception:

Fatal error: Uncaught exception 'Doctrine\ORM\EntityNotFoundException' with message 'Entity of type 'Address' was not found.' in doctrine/orm/lib/Doctrine/ORM/Proxy/ProxyFactory.php on line 176

Expected behaviour:
$user->getAddress() should return NULL when the right side is empty.

NOTES:
Mind that the address is identified through a foreign entity (User)






[DDC-3164] [GH-1057] Add failing test for DDC-3160 Created: 12/Jun/14  Updated: 06/Jul/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of flack:

Url: https://github.com/doctrine/doctrine2/pull/1057

Message:

See http://www.doctrine-project.org/jira/browse/DDC-3160



 Comments   
Comment by Doctrine Bot [ 06/Jul/14 ]

A related Github Pull-Request [GH-1057] was closed:
https://github.com/doctrine/doctrine2/pull/1057

Comment by Doctrine Bot [ 06/Jul/14 ]

A related Github Pull-Request [GH-1074] was closed:
https://github.com/doctrine/doctrine2/pull/1074





[DDC-3161] [GH-1054] SQLFilters enahancements Created: 10/Jun/14  Updated: 10/Jun/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of v3labs:

Url: https://github.com/doctrine/doctrine2/pull/1054

Message:

SQL filters in Doctrine are a bit too limited for my taste.
This pull request makes the current connection available inside sql filter classes.
The connection is needed to quote identifiers or values and generate sql statements for the current database. (sample use-case https://github.com/Atlantic18/DoctrineExtensions/blob/master/lib/Gedmo/SoftDeleteable/Filter/SoftDeleteableFilter.php)
Currently you can access the connection only through reflection which let's face it - is a hack.

I've also made the class depend on EntityManagerInterface instead of EntityManager.

There's a test for the new method.






[DDC-3155] orm:convert-mapping drops underscores from Doctrine type names specified in DB comments Created: 05/Jun/14  Updated: 05/Jun/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: Tools
Affects Version/s: 2.4.2
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: John Flatness Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

If you run orm:convert-mapping on a schema with comments like (DC2Type:json_array), the type name does get picked up, but the underscore is removed, so the type that ends up in the generated mapping's @Column annotation is jsonarray, not json_array.

The underscore being removed also seems to be affecting the EntityGenerator's attempt to map to correct PHP types for the @var annotation: that's showing up as just @var jsonarray even though the EntityGenerator should be mapping that to array. So it looks like the underscore is probably getting dropped at an earlier stage.






[DDC-3149] [GH-1046] Fix the "Erroneous data format for unserializing" error message Created: 03/Jun/14  Updated: 03/Jun/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of peterjmit:

Url: https://github.com/doctrine/doctrine2/pull/1046

Message:

Backport patch from PR #1045 to 2.3 branch.

@ocramius - I'm not sure if this is viable, but based on the comments from people it could be helpful to have this fixed in 5.3? I'm not 100% sure whether PHP or Doctrine is at fault here?



 Comments   
Comment by Doctrine Bot [ 03/Jun/14 ]

A related Github Pull-Request [GH-1046] was closed:
https://github.com/doctrine/doctrine2/pull/1046





[DDC-3148] ResultSetMappingBuilder::generateSelectClause ignores quoted column names Created: 02/Jun/14  Updated: 02/Jun/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: Git Master
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Christian Ruhstaller Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

If an entity has a quoted column (Magic Words etc.) and you want to use "generateSelectClause" for the specific entity it won't return the quoted name, just the plain name. If the name is a SQL Magic Word the corresponding SQL will fail.

Exp.: "profile.real" (wrong) instead of "profile.`real`".

File: Doctrine/ORM/Query/ResultSetMappingBuilder.php
Function: generateSelectClause

Line 445:
$sql .= " AS " . $columnName;

Example Entity:
...
class Profile

{ /** * @ORM\Column(name="`real`", type="boolean") */ protected $real=false; }




[DDC-3147] [GH-1045] Fix the "Erroneous data format for unserializing" error message Created: 30/May/14  Updated: 30/Aug/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of marmotz:

Url: https://github.com/doctrine/doctrine2/pull/1045

Message:

cf http://www.doctrine-project.org/jira/browse/DDC-3120



 Comments   
Comment by Doctrine Bot [ 30/May/14 ]

A related Github Pull-Request [GH-1045] was closed:
https://github.com/doctrine/doctrine2/pull/1045

Comment by Doctrine Bot [ 27/Aug/14 ]

A related Github Pull-Request [GH-1109] was closed:
https://github.com/doctrine/doctrine2/pull/1109

Comment by Doctrine Bot [ 28/Aug/14 ]

A related Github Pull-Request [GH-1109] was assigned:
https://github.com/doctrine/doctrine2/pull/1109

Comment by Doctrine Bot [ 30/Aug/14 ]

A related Github Pull-Request [GH-1050] was closed:
https://github.com/doctrine/doctrine2/pull/1050

Comment by Doctrine Bot [ 30/Aug/14 ]

A related Github Pull-Request [GH-1050] was assigned:
https://github.com/doctrine/doctrine2/pull/1050





[DDC-3146] Hydrator memory leak when using iterator Created: 30/May/14  Updated: 14/Aug/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.3.2, 2.3.5, 2.4.2
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Emiel Nijpels Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: hydrator, leak, memory
Environment:

PHP 5.4.21, OS X 10.9.3; PHP 5.3.28, OS X 10.9.4



 Description   

When the hydrator iterate() function is invoked, a new event is added to the event manager with a reference to the current hydrator object. This reference is never cleared which causes the hydrator object to never be cleared from memory by the PHP garbage collection.

/doctrine/orm/lib/Doctrine/ORM/Internal/Hydration/AbstractHydrator.php
$evm = $this->_em->getEventManager();
$evm->addEventListener(array(Events::onClear), $this);

The effects of this bug are best visible when creating multiple iterator objects after each other in a repository:

// Loop through test code 10 times
for ($f = 0; $f < 10; $f++) {
    // Create test query
    $query = $this->createQueryBuilder('p')->getQuery();

    // Create IterableResult object
    $iterableResult = $query->iterate();

    // Loop through the iterator
    foreach ($iterableResult as $row) {}

    // Print out memory usage
    print(memory_get_usage() . PHP_EOL);
}

This results in the following output:

10536552
10549920
10563288
10576664
10590040
10603416
10616792
10630168
10643608
10656984

Notice how the used memory increases by about 13KB after each iteration.
To stop this memory leak the following code can be added to the end of the cleanup() function in the AbstractHydrator class:

$evm = $this->_em->getEventManager();
$evm->removeEventListener(array(Events::onClear), $this);

The output is now:

10537920
10537048
10537048
10537048
10537048
10537048
10537048
10537048
10537048
10537048

The reference to the event manager is now automatically removed in the cleanup function which allows the hydrator object to be cleaned up by the garbage collection function in PHP.



 Comments   
Comment by Jeremiah Johnson [ 12/Aug/14 ]

I'm experiencing the same problem on 2.3.2

Comment by Jeremiah Johnson [ 14/Aug/14 ]

Tested latest of 2.3.x (2.3.5) and problem still exists.

Comment by Marco Pivetta [ 14/Aug/14 ]

Jeremiah Johnson can you provide a PR with the fix and a test?





[DDC-3136] DQL JOIN association return null Created: 24/May/14  Updated: 24/May/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: DQL, Mapping Drivers, ORM
Affects Version/s: 2.4.2
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Raphael Parazols Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Symfony2



 Description   

Hello,
I observe a strange behavior of a query result done by DQL (only tested DQL in fact). In the last entry of my result, the joined entity are returned to null

My tables are:

Entity1
/**
 * @ORM\Table(name="entity1")
 * @ORM\Entity()
**/
class Entity1
{	
	 /**
     * @ORM\Column(name="entity1_id", type="integer")
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="AUTO")
     */
	protected $entity1_Id; 
	
	/**
	* @ORM\Column(name="entity1_text", type="string")
	*/
    protected $entity1_Text;
}
Entity2
/**
 * @ORM\Table(name="entity2")
 * @ORM\Entity()
**/
class Entity2
{	
        /**
	* @ORM\OneToOne(targetEntity="Entity1")
	* @ORM\JoinColumn(name="entity1_id", referencedColumnName="entity1_id")
	* @ORM\Id
	*/
	protected $entity1_id; 
    
	/**
	* @ORM\ManyToOne(targetEntity="Entity3")
	* @ORM\JoinColumn(name="entity3_id", referencedColumnName="entity3_id")
	*/
	protected $entity3; 
}
Entity3
/**
 * @ORM\Table(name="entity3")
 * @ORM\Entity()
**/
class Entity3
{	
	 /**
     * @ORM\Column(name="entity3_id", type="integer")
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="AUTO")
     */
	protected $entity3_Id; 
	
	/**
	* @ORM\Column(name="entity3_text", type="string")
	*/
    protected $entity3_Text;
}

So when I do a simple request like this:

DQL Request
SELECT ent2, ent3 FROM f4cIndexBundle:Entity2 ent2 JOIN ent2.entity3 ent3

The result is looks like this

Result NOK
array (size=2)
  0 => 
    object(f4c\IndexBundle\Entity\Entity2)[550]
      protected 'entity1_id' => 
        object(Proxies\__CG__\f4c\IndexBundle\Entity\Entity1)[502]
          ...
      protected 'entity3' => 
        object(f4c\IndexBundle\Entity\Entity3)[497]
          protected 'entity3_Id' => int 2
          protected 'entity3_Text' => string 'TEXT OF ENTITY 3 - SPECIFIC 2' (length=29)
  1 => 
    object(f4c\IndexBundle\Entity\Entity2)[498]
      protected 'entity1_id' => 
        object(Proxies\__CG__\f4c\IndexBundle\Entity\Entity1)[499]
          ...
     protected 'entity3' => null

The entity3 of the last result is never joined and set to null (it's not possible because of the JOIN no ?)
I spent to days on this and I observed that when I add a property in my entity 2 like this

Entity2
/**
 * @ORM\Table(name="entity2")
 * @ORM\Entity()
**/
class Entity2
{	
    ...
    /**
	* @ORM\Column(name="entity2_text", type="string")
	*/
    protected $entity2_Text;
}

The result is ok

Result OK
array (size=2)
  0 => 
    object(f4c\IndexBundle\Entity\Entity2)[550]
      protected 'entity1_id' => 
        object(Proxies\__CG__\f4c\IndexBundle\Entity\Entity1)[498]
         ...
      protected 'entity2_Text' => string 'TEXT2' (length=5)
      protected 'entity3' => 
        object(f4c\IndexBundle\Entity\Entity3)[499]
          protected 'entity3_Id' => int 1
          protected 'entity3_Text' => string 'TEXT OF ENTITY 3 - SPECIFIC 1' (length=29)
  1 => 
    object(f4c\IndexBundle\Entity\Entity2)[494]
      protected 'entity1_id' => 
        object(Proxies\__CG__\f4c\IndexBundle\Entity\Entity1)[495]
          ...
      protected 'entity2_Text' => string 'TEXT1' (length=5)
      protected 'entity3' => 
        object(f4c\IndexBundle\Entity\Entity3)[496]
          protected 'entity3_Id' => int 2
          protected 'entity3_Text' => string 'TEXT OF ENTITY 3 - SPECIFIC 2' (length=29)

Is it normal ? Is this a kwon issue ?

Thanks for your help

Raphael P.






[DDC-3135] Unnecessary SELECT after updating of versioned table Created: 23/May/14  Updated: 23/May/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4.2
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: ikti Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

PHP 5.5.9-1ubuntu4 (cli) (built: Apr 9 2014 17:11:57)



 Description   

When I update entity with version doctrine generates 2 SQLs:

INSERT INTO TableA (key, value) VALUES (1, 1);
SELECT version FROM TableA WHERE key = 1;

OR

UPDATE TableA SET value= 2, version = version + 1 WHERE key = 1 AND version = 1;
SELECT version FROM TableA WHERE key = 1;

Not only second query is unnecessary (version value is always 1 after persisting and is always prev version + 1 after successful update) but can also read incorrect value if row is updated between update and select statement. In this case entity manager will have outdated data, but most recent version.






[DDC-3134] Inconsistent defaults for onDelete when defining many-to-many relations Created: 23/May/14  Updated: 23/May/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4.2
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Adria Lopez Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Symfony 2.5.0-BETA2



 Description   

When defining a relation with the following annotation:

/**
 * @ORM\ManyToMany(targetEntity="A\B\C")
 */

The following SQL is generated for the foreign key constraints:

ALTER TABLE the_table ADD CONSTRAINT FK_A63A409AA76ED395 FOREIGN KEY (something1) REFERENCES thing2 (id) ON DELETE CASCADE;
ALTER TABLE the_table ADD CONSTRAINT FK_A63A409AF8BD700D FOREIGN KEY (something2) REFERENCES thing1 (id) ON DELETE CASCADE;

As it can be seen, the default seems to be to include ON DELETE CASCADE. This feels like a dangerous behaviour (and I couldn't find it documented), but fair enough. The inconsistency comes when adding:

/**
 * @ORM\ManyToMany(targetEntity="A\B\C")
 * @ORM\JoinTable(name="the_table",
 *      joinColumns={@ORM\JoinColumn()},
 *      inverseJoinColumns={@ORM\JoinColumn()}
 * )
 */

In this case, even if we are not providing any values for the join and inverse join columns, we get:

ALTER TABLE the_table ADD CONSTRAINT FK_A63A409AA76ED395 FOREIGN KEY (something1) REFERENCES something2 (id);
ALTER TABLE user_unit ADD CONSTRAINT FK_A63A409AF8BD700D FOREIGN KEY (something2) REFERENCES something1 (id);

As it can be seen, the ON DELETE CASCADE is gone.

I understand this is the case because, when giving empty JoinColumn annotations it's not the engine defaults that are processed, but the inferred values for the annotation. Still, this seems to be either a bug or an undocumented behaviour.

Am I doing anything wrong here? Should this be looked into?






[DDC-3130] [GH-1033] [WIP] Lazy criteria for ManyToMany collection Created: 18/May/14  Updated: 18/May/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of bakura10:

Url: https://github.com/doctrine/doctrine2/pull/1033

Message:

This continues my previous work on making Criteria most efficient.

Currently we are wrapping matching calls on repositories and matching calls on EXTRA_LAZY associations around a LazyCriteria. However, ManyToMany are still completely loaded: https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/PersistentCollection.php#L874

This is still problematic from a performance point of view because count, contains... cannot be optimized. I think the solution is similar to previous one, hence creating a Lazy collection for that kind of associations.

However, this is really tricky to do because of the whole mess inside the persisters (can't wait for them to be completely refactored, it's getting really hard to maintain this mess ).






[DDC-3122] Querying entities with ResolveTargetEntity Created: 14/May/14  Updated: 15/May/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: 2.4.2
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Heo Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Hello

The problem refers to a following situation:
You have 2 classes that use a quite simple inheritance and an interface:

interface CInterface { /* ... */ }
class AClass implements CInterface { /* ... */ }
class BClass extends class AClass { /* ... */ }

When we configure the ResolveTargetEntityListener the following way:

array(
  'CInterface' => 'BClass'
)

when using the entity manager to find an entity:

$entityManager->find('BClass', $id);

we'll get a following Doctrine\DBAL\DBALException:

An exception occurred while executing 'SELECT t1.id AS id2 FROM bclass_table_name t1 WHERE t0.id = ?' with params [1]:

SQLSTATE[42S22]: Column not found: 1054 Unknown column 't0.id' in 'where clause'

As you can see the column names are generated properly but the WHERE clause has an invalid refference to t0 table (should be t1).

Similar problem:

http://stackoverflow.com/questions/17588682/doctrine-inheritance-replacement



 Comments   
Comment by Marco Pivetta [ 14/May/14 ]

Is AClass a mapped superclass or the root of the inheritance?

Comment by Heo [ 15/May/14 ]

AClass is the root of the inheritance. I would like to add that the only problem is the "find" method. Database relations are created properly (with the SchemaTool), all keys refer to proper columns.

Comment by Marco Pivetta [ 15/May/14 ]

Heo can you abstract a test case for this?





[DDC-3117] [GH-1027] Support for Partial Indexes for PostgreSql and Sqlite Created: 07/May/14  Updated: 19/Aug/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mapping, postgresql, sqlite

Issue Links:
Dependency
depends on DBAL-900 [GH-600] Support for Partial Indexes ... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of PowerKiKi:

Url: https://github.com/doctrine/doctrine2/pull/1027

Message:

Support for Partial Indexes was available in Doctrine 1 following
http://www.doctrine-project.org/jira/browse/DC-82. This commit
reintroduce support for Doctrine 2. We use the same syntax with an
optionnal "where" attribute for Index and UniqueConstraint.

It is unit-tests covered and documented in manual. This Pull Request depends on https://github.com/doctrine/dbal/pull/600. So they should both be merged or rejected together.

Thanks for your time !



 Comments   
Comment by Adrien Crivelli [ 07/May/14 ]

This patch depends on DBAL-900. So they should both be merged or rejected together.

Comment by Doctrine Bot [ 16/May/14 ]

A related Github Pull-Request [GH-600] was closed:
https://github.com/doctrine/dbal/pull/600

Comment by Doctrine Bot [ 02/Aug/14 ]

A related Github Pull-Request [GH-600] was assigned:
https://github.com/doctrine/dbal/pull/600

Comment by Doctrine Bot [ 19/Aug/14 ]

A related Github Pull-Request [GH-600] was closed:
https://github.com/doctrine/dbal/pull/600





[DDC-3115] UnitOfWok can't access proxies protected property Created: 04/May/14  Updated: 04/May/14

Status: Reopened
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: Git Master
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Machete Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: orm
Environment:

php5.5.11-1~dotdeb.1
debian 7.5 64bit
apache2
doctrine-orm-module 0.8.0


Attachments: PNG File doctrine-error.PNG    

 Description   

Running the code on different environments for a while now, I have never had any problems. Recently I installed the code onto a different server and I've been experiencing the following issue:

> Fatal error: Cannot access protected property DoctrineORMModule\Proxy_CG_\Page\Entity\PageRevision::$date in src/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php on line 2596

I am absolutely clueless, why this happens. It seems to be affecting only specific data rows, as you might reproduce here: http://de.serlo.org/pages

The field is defined as followed:

    /**
     * @ORM\Column(type="datetime", options={"default"="CURRENT_TIMESTAMP"})
     */
    protected $date;

However, the exact same database snapshot works fine here: http://ptr.serlo.org/pages

Attached you will find a screenshot of the datarows. The yellow ones mark each one working and one not working row.

I have no idea what the problem is here.



 Comments   
Comment by Marco Pivetta [ 04/May/14 ]

Discussed this on IRC - very tricky, seems like one of the servers has the reflection property not set to "accessible"

Comment by Machete [ 04/May/14 ]

Adding `$class->reflFields[$field]->setAccessible(true)` before line 2596 resolved this issue. Even after removing it, everything worked fine.

note to self:
> [18:23] <@ocramius> machete_: can you find out where that particular property is instantiated?
> [18:23] <@ocramius> should be in `ClassMetadataInfo::wakeUpReflection()` or such
> [18:25] <@ocramius> if you find that again, consider looking at locations in the code where `new ReflectionClass()` is instantiated





[DDC-3113] Associated entity with "cascade" persist that is eagerly loaded doesn't get saved when its parent is flushed Created: 01/May/14  Updated: 01/May/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.3.4
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Juraj Seffer Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Address entity definition within User class
/**

  • Address
    *
  • @ORM\OneToOne(targetEntity="Address", fetch="EAGER", cascade="persist")
  • @var \Application\Entity\Address
    */
    protected $address;

When User gets loaded via Doctrine, the resulting Address object within the User is not a proxy object but the concrete class specified in targetEntity. When trying to persist the User:

$entityManager->persist($user);
$entityManager->flush($user);

User object gets saved and another associated entity that is lazy loaded does get saved. What doesn't get saved into the database is the Address object. No exceptions are thrown, the Address object is simply ignored.






[DDC-3110] paginator doesn't respect order by clause when using the fetchJoinCollection flag Created: 30/Apr/14  Updated: 30/Apr/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: 2.4.2
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Greg Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

MariaDB 5.5



 Description   

I have a DQL query with a ORDER BY clause.
When I paginate the result with new Paginator($query, $fetchJoinCollection = true); the orderind isn't correct.
The order is lost in the second request (Perform a Limit Subquery with DISTINCT to find all ids of the entity in from on the current page)

It creates a SQL query like that :
SELECT
DISTINCT id0
FROM
(
SELECT
d0_.id AS id0,
d0_.name AS name1,
d0_.note AS note2,
FROM
data d0_
ORDER BY
d0_.note DESC
) dctrn_result
LIMIT
20 OFFSET 0

The external SELECT don't keep the order so it just fetch the 20 first elements from the whole table.






[DDC-3109] [Doctrine\ORM\Mapping\MappingException] Invalid field override named 'xxx' for class 'Entity\xxx' Created: 30/Apr/14  Updated: 26/Jun/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers, ORM, Tools
Affects Version/s: 2.3
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: david pichsenmeister Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None
Environment:

kubuntu 14.04, php 5.5.9, MySQL 5.5


Attachments: File Organization.php     File User.php    
Issue Links:
Duplicate
duplicates DDC-2693 Attribute/association overrides shoul... Open

 Description   

Subclass should override association, but on generating entities, error:

[Doctrine\ORM\Mapping\MappingException]
Invalid field override named 'settings' for class 'Entity\Organization'.

is thrown. also, when updating schema, the assocations in the subclass are ignored (means are not present in the database).



 Comments   
Comment by Alexandre PAIXAO [ 23/May/14 ]

I think it is a duplicate of this bug : http://www.doctrine-project.org/jira/browse/DDC-2693





[DDC-3108] Criteria cannot reference a joined tables' fields when used with an ORM QueryBuilder Created: 30/Apr/14  Updated: 30/Apr/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: DQL, ORM
Affects Version/s: 2.4.2
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Chris Rog Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: criteria, dql, orm, querybuilder


 Description   

This regression was introduced in 2.4.2 with the addition of the "rootAlias" stuff. Basically, the hard-coded addition of the rootAlias + "." prevents any Criteria object from referencing any field that isn't on the first table selected.

Example:
// Assume $repo is a valid EntityRepository and $value is some scalar value.
$qb = $repo->createQueryBuilder('T1')->join('T1.field', 'T2');

$criteria = new Comparison('T2.field2', Comparison::EQ, $value);

$qb->addCriteria($criteria);
$dql = $qb->getDQL();

$dql is now (roughly) equal to:
SELECT T1 FROM <entityclass> T1 JOIN T1.field T2 WHERE T1.T2.field2 = <value>

Evaluating this causes QueryExceptions to be thrown; usually something along the lines of "Expected Doctrine\ORM\Query\Lexer::<token>, got '.'"

There's a similar issue involving ordering by a related field for the same reason.






[DDC-3105] Doctrine Console Error (ORMPurger) Created: 29/Apr/14  Updated: 29/Apr/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Carlos Mendoza Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: Cli, schematool


 Description   

In symfony2 the command doctrine:fixtures:load Fails One-To-Many, Self-referencing using Doctrine\Common\DataFixtures\Purger\ORMPurger in example:

class DescriptionArea

{ //.. /** * @ORM\OneToMany(targetEntity="DescriptionArea", mappedBy="parent") */ protected $descriptionAreas; /** * @ORM\ManyToOne(targetEntity="DescriptionArea", inversedBy="descriptionAreas") */ protected $parent; //.. }

Throw error:
[Doctrine\DBAL\DBALException]

An exception occurred while executing 'DELETE FROM prefix_DescriptionArea':

SQLSTATE[23000]: Integrity constraint violation: 1451 Cannot delete or update a parent row: a foreign key constraint fails (sigtec_dev.prefix_DescriptionArea,

CONSTRAINT FK_7265873E727ACA70 FOREIGN KEY (parent_id) REFERENCES prefix_DescriptionArea (id))

Before running the query should delete the index when the table has self-reference.






[DDC-3104] Invalid count on EXTRA LAZY collection of SINGLE TABLE entities Created: 28/Apr/14  Updated: 20/May/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.3.2
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Oleg Namaka Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None

Issue Links:
Reference
relates to DDC-1595 Wrong count in relation with inheritance Resolved

 Description   
  • This issue relates to http://www.doctrine-project.org/jira/browse/DDC-1595
  • With the following entities
    • EntityPromotionAbstract entity:
      * @ORM\Entity
       * @ORM\InheritanceType("SINGLE_TABLE")
       * @ORM\Table(name="entity_promotion")
       * @ORM\DiscriminatorColumn(name="type", type="string")
       * @ORM\DiscriminatorMap({
       *     "brand"           = "BrandPromotion",
       *     "category"        = "CategoryPromotion",
       * })
       */
      abstract class EntityPromotionAbstract
      
    • CategoryPromotion entity:
       * @ORM\Entity
       */
      class CategoryPromotion extends EntityPromotionAbstract
      {
          /**
           * Category
           *
           * @var Category
           * @ORM\ManyToOne(targetEntity="Category", inversedBy="CategoryPromotions")
           * @ORM\JoinColumn(name="instance_id", referencedColumnName="category_id")
           */
          protected $Category;
      ...
      }
      
    • BrandPromotion entity:
       * @ORM\Entity
       */
      class BrandPromotion extends EntityPromotionAbstract
      {
          /**
           * Brand
           *
           * @var Brand
           * @ORM\ManyToOne(targetEntity="Brand", inversedBy="BrandPromotions")
           * @ORM\JoinColumn(name="instance_id", referencedColumnName="brand_id")
           */
          protected $Brand;
      }
      
    • Brand entity:
          /**
           * Associated BrandPromotions
           *
           * @var \Doctrine\Common\Collections\Collection
           *
           * @ORM\OneToMany(targetEntity="BrandPromotion", mappedBy="Brand", fetch="EXTRA_LAZY")
           */
          protected $BrandPromotions;
      
    • Category entity:
          /**
           * Associated CategoryPromotions
           *
           * @var \Doctrine\Common\Collections\ArrayCollection|\Doctrine\ORM\PersistentCollection
           *
           * @ORM\OneToMany(targetEntity="CategoryPromotion", mappedBy="Category", fetch="EXTRA_LAZY")
           */
          protected $CategoryPromotions;
      
  • When Brand::BrandPromotions collection is not initialized, calling count on it will return a count of BrandPromotion and CategoryPromotion elements, but calling isEmpty will return a count of BrandPromotion entities only.
  • \Doctrine\ORM\Persisters\OneToManyPersister::count does not take into account a discriminator value of 'brand':
            foreach ($targetClass->associationMappings[$mapping['mappedBy']]['joinColumns'] as $joinColumn) {
                $whereClauses[] = $joinColumn['name'] . ' = ?';
    
                $params[] = ($targetClass->containsForeignIdentifier)
                    ? $id[$sourceClass->getFieldForColumn($joinColumn['referencedColumnName'])]
                    : $id[$sourceClass->fieldNames[$joinColumn['referencedColumnName']]];
            }
    
    
  • This results in a query:
    SELECT count(*) FROM entity_promotion t WHERE instance_id = ?
    
  • The query should include a type condition:
    SELECT count(*) FROM entity_promotion t WHERE instance_id = ? AND (t.type in 'brand')
    


 Comments   
Comment by Marco Pivetta [ 29/Apr/14 ]

Why would the query include a type conditional? To me, it seems like the association was built between invalid data types instead.

Comment by Oleg Namaka [ 06/May/14 ]
  • Could you elaborate on what exactly you mean when you are saying, that the association was built between invalid data types?
  • Even if your statement is valid, then why calling on a initialized collection $collection->isEmpty() produces a correct result? Calling $collection->count() produces also a correct result on an initialized collection, wheres calling $collection->count() on an unitialized collection results in an invalid element count.
Comment by Marco Pivetta [ 06/May/14 ]

Ah, I see what you mean now. Sorry, I was confusing this with a joined table inheritance.

Comment by Vigintas Labakojis [ 20/May/14 ]

Exactly same behaviour just wasted me a few hours. Shame I'll have to switch fetch mode back to LAZY until this gets fixed.





[DDC-3098] [GH-1016] improved error handling for invalid association values Created: 23/Apr/14  Updated: 23/Apr/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of flip111:

Url: https://github.com/doctrine/doctrine2/pull/1016

Message:

Possibly to do:
1. Make custom Exception for line 713
2. Make custom Exception for line 817
3. Does the object check on line 816 slow down the code too much? Alternatively a try-catch could be put around line 1415 or higher up.






[DDC-3096] JoinColumn definition does not regard column type with value translation Created: 22/Apr/14  Updated: 22/Apr/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Volker Nauruhn Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: entityPersister, mapping, mysql, orm
Environment:

Symfony 2.4.3



 Description   

I made a custom column type for doctrine which converts values between MySQL and PHP.

When I use a field with this column type as JoinColumn in a ManyToOne relation plus the column has a different name than the field, the BasicEntityPersister gets always "null" when he is asking for type of the given column name because he is ascing for given column name and not field name.

Example
=====================

Make.php:

/**
 @ORM\Column(name="language_code", type="locale")
 */
private $locale;

Foobar.php

/**
 @ORM\ManyToOne(targetEntity="Make")
 @ORM\JoinColumn(name="make_locale", referencedColumnName="language_code")
 */
private $makes;

The localeType translates between long and short language codes. For exmaple "de" (PHP) to "de_DE" (MySQL).



 Comments   
Comment by Marco Pivetta [ 22/Apr/14 ]

This is not a blocker, as you're really going into custom implementations.

You should probably provide a failing test case to clarify what you are doing





[DDC-3091] Not set entity to results if use query with JOIN Created: 17/Apr/14  Updated: 17/Apr/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Vitaliy Zhuk Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Hi.
I have a problem, if i can use query with JOIN without grouping (DISTINCT) by identifier entity. Problem: not set entities to result, if entity has cached in ObjectHydration.

For example:

SQL query:

SELECT 
  b0_.id AS id0,
  b0_.hash AS hash1, 
  b0_.mii AS mii2, 
  b0_.iin AS iin3, 
  b0_.last_digits AS last_digits4, 
  b0_.number AS number5, 
  b0_.holder AS holder6, 
  p1_.keyword AS keyword7, 
  t2_.client AS client8, 
  CONCAT(b0_.hash, CONCAT(p1_.keyword, t2_.client)) AS sclr9 

FROM bank_card b0_ 
  INNER JOIN transaction_bank_card t2_ ON (t2_.bank_card_id = b0_.id) 
  INNER JOIN projects p1_ ON (t2_.project_key = p1_.keyword) 

WHERE (p1_.keyword = 'project1' AND t2_.client = '123') OR (p1_.keyword = 'project2' AND t2_.client = '321') /* ... Other where */

GROUP BY sclr9

Mysql result:

id0 hash1 mii2 iin3 last_digits4 number5 holder6 keyword7 client8 sclr9
28 1d741fd06f3315dad28039926effc5d7 5 533330 2763 533330******2763 John Doe p6 78165 1d741fd06f3315dad28039926effc5d7p678165
34 58b021876f625e3000137cd835f5fe40 5 555456 5047 555456******5047 OLOLO OLOLO p6 78165 58b021876f625e3000137cd835f5fe40p678165
2 887d30e9b4d18676c6e0dc8e21e36d28 5 556458 4251 556458******4251 Monkey Testing p6 78165 887d30e9b4d18676c6e0dc8e21e36d28p678165
1 bb14a77f2e363cd144b669f0b594d304 4 432114 1118 432114******1118 Monkey Testing p6 100673 bb14a77f2e363cd144b669f0b594d304p6100673
1 bb14a77f2e363cd144b669f0b594d304 4 432114 1118 432114******1118 Monkey Testing p6 100922 bb14a77f2e363cd144b669f0b594d304p6100922
1 bb14a77f2e363cd144b669f0b594d304 4 432114 1118 432114******1118 Monkey Testing p6 101441 bb14a77f2e363cd144b669f0b594d304p6101441
1 bb14a77f2e363cd144b669f0b594d304 4 432114 1118 432114******1118 Monkey Testing p6 78165 bb14a77f2e363cd144b669f0b594d304p678165
1 bb14a77f2e363cd144b669f0b594d304 4 432114 1118 432114******1118 Monkey Testing p6 85550 bb14a77f2e363cd144b669f0b594d304p685550
1 bb14a77f2e363cd144b669f0b594d304 4 432114 1118 432114******1118 Monkey Testing p6 85566 bb14a77f2e363cd144b669f0b594d304p685566
1 bb14a77f2e363cd144b669f0b594d304 4 432114 1118 432114******1118 Monkey Testing p6 85768 bb14a77f2e363cd144b669f0b594d304p685768

And the PHP code (from custom entity repository):

$qb
            ->select('bc')
            ->addSelect('p.key AS project_key')
            ->addSelect('tbc.client AS client')
            ->addSelect('CONCAT(bc.hash, CONCAT(p.key, tbc.client)) AS unique_key')
            ->innerJoin('FooBundle:TransactionBankCard', 'tbc', 'WITH', 'tbc.bankCard = bc.id')
            ->innerJoin('BarBundle:Project', 'p', 'WITH', 'tbc.project = p.key')
            ->where($orX)
            ->groupBy('unique_key');

        $result = $qb->getQuery()->getResult();

And this code returned only unique entities by identifier (Identifier: id field), but must returned the all entities from query.

The Object Hyndration has cached created entities, and if the next row is entity (indicate as identifier and dql alias), then hydration not set this entity to result.
Problem code: https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php#L569-L572

Thank.






[DDC-3088] EntityManager::clear doesn't working with inserting Created: 16/Apr/14  Updated: 18/Aug/14

Status: Awaiting Feedback
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Adrian Ch Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

PHP 5.4.25-1+sury.org~precise+2 (cli) (built: Feb 12 2014 10:45:30)
Symfony version 2.4.2 - app/dev/debug



 Description   

It looks like EntityManager's clear() method doesn't remove objects that was persisted during script execution.

Bellows are two functions. First one insert 10.000 records and use clear after each flush that should remove objects from memory, but instead of that memory usage growths in each iteration. There isn't any other reference for this objects.

I've checked how it works for reading and with clearing it works perfectly - script uses only constant memory.

 
    private function testInserting($em, $entityClass, $batchSize, $startMemoryUsage)
    {
        for ($i = 1; $i <= 10000; ++$i) {

            $item = new $entityClass();
            $item->setName($i);
            $item->setPresentation($i);
            $em->persist($item);

            if ($i % $batchSize == 0) {
                $em->flush();
                $em->clear();

                $currentMemoryUsage = memory_get_usage();
                printf("%d:\n\t%.2f MB (%.2f MB)\n", $i, $currentMemoryUsage /1024 / 1024, ($currentMemoryUsage - $startMemoryUsage) / 1024 / 1024);
            }
        }
    }
    
    
private function testReading($em, $entityClass, $batchSize, $startMemoryUsage)
    {
        $q = $em->createQuery("select i from $entityClass i");
        $iterableResult = $q->iterate();

        $i = 0;
        while (($row = $iterableResult->next()) !== false) {
            $em->clear();
            if ($i % $batchSize == 0) {
                $currentMemoryUsage = memory_get_usage();
                printf("%d:\n\t%.2f MB (%.2f MB)\n", $i, $currentMemoryUsage /1024 / 1024, ($currentMemoryUsage - $startMemoryUsage) / 1024 / 1024);
            }

            $i++;
        }
    }
    

My results:

1) Reading without clearing ($em->clear(); removed)

0:
22.89 MB (2.63 MB)
1000:
33.41 MB (13.15 MB)
2000:
44.04 MB (23.78 MB)
3000:
53.50 MB (33.24 MB)
4000:
65.13 MB (44.86 MB)
5000:
74.81 MB (54.55 MB)
6000:
84.27 MB (64.01 MB)
7000:
97.96 MB (77.69 MB)
8000:
107.40 MB (87.14 MB)
9000:
117.17 MB (96.91 MB)
10000:
126.61 MB (106.35 MB)

2) Reading with using clear

0:
22.89 MB (2.63 MB)
1000:
26.25 MB (5.99 MB)
2000:
24.74 MB (4.48 MB)
3000:
26.72 MB (6.46 MB)
4000:
24.79 MB (4.52 MB)
5000:
26.76 MB (6.50 MB)
6000:
24.81 MB (4.55 MB)
7000:
26.77 MB (6.51 MB)
8000:
24.83 MB (4.57 MB)
9000:
26.81 MB (6.54 MB)
10000:
24.86 MB (4.60 MB)

3) Inserting without clearing

1000:
29.50 MB (9.24 MB)
2000:
37.76 MB (17.50 MB)
3000:
45.12 MB (24.86 MB)
4000:
54.34 MB (34.07 MB)
5000:
61.79 MB (41.53 MB)
6000:
69.09 MB (48.82 MB)
7000:
76.40 MB (56.13 MB)
8000:
83.75 MB (63.48 MB)
9000:
95.64 MB (75.37 MB)
10000:
102.98 MB (82.71 MB)

4) Inserting with using clear

1000:
27.90 MB (7.63 MB)
2000:
34.64 MB (14.37 MB)
3000:
40.43 MB (20.17 MB)
4000:
48.20 MB (27.93 MB)
5000:
54.12 MB (33.85 MB)
6000:
59.89 MB (39.63 MB)
7000:
65.67 MB (45.40 MB)
8000:
71.43 MB (51.16 MB)
9000:
81.51 MB (61.25 MB)
10000:
87.29 MB (67.02 MB)



 Comments   
Comment by Marco Pivetta [ 16/Apr/14 ]

Would be useful to see what the entity class looks like.

Additionally, the ORM version being affected is also needed.





[DDC-3083] Persist/Flush silently fails when CTI is applied on an existing table Created: 12/Apr/14  Updated: 13/Apr/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4.2
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Frank Liepert Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Given an existing table (= parent table) the integration of a new parent-child relationship with Class Table Inheritance (CTI) leads to a update problem.

First of all a child table is created with a foreign key to the parent table. Next, the discriminator column is added to the parent table. The discriminator map will be auto-generated.

The problem arises when trying to perform persist() and flush() on a child entity. Initially the child table is logically empty. However, the UnitOfWork triggers updateTable() which will fail since there is nothing to update. Instead, an upsert should be performed.

Another sneaky thing is that the repository will return the child class with the updated data after calling flush() on the same request. On the next request the child class is returned with the data loaded from the persister. Of course, the updated data is missing.



 Comments   
Comment by Marco Pivetta [ 13/Apr/14 ]

Frank Liepert do I understand this correctly if I say that you are trying to (pseudo) upcast an entity to a more specific subtype? That is unsupported by the ORM. Could you make just an example snippet of what you described in the issue?

Comment by Frank Liepert [ 13/Apr/14 ]

Marco Pivetta: You have understood really well. If you say that's not supported by the ORM then this is the answer. Still I think that upsert could solve solve the "problem" and I know that there are/have been discussions about upsert.

Right now I will continue to manually insert the missing rows in the child table. After this necessary step the ORM works as expected.

Nevertheless the real bug is that after persist() and flush() the entity manager returns the child object with the "persisted" data of the child table although there are in fact no rows in the child table.

$parentRepository = $em->getRepository('Parent');

$child = $parentRepository ->find(1);
$child->setChildPropertyA('foo');

$em->persist($child);
$em->flush();

$child = $parentRepository ->find(1);
var_dump($child->getChildPropertyA());
// string(3) "foo"

// But: There is no 'foo' in the child table!


/** 
 * NEW REQUEST
 */

$parentRepository = $em->getRepository('Parent');

$child = $parentRepository ->find(1);
var_dump($child->getChildPropertyA());
// NULL

Comment by Marco Pivetta [ 13/Apr/14 ]

Frank Liepert why are $child in the first request and $child in the second request different here? Are you manually changing the data at SQL level?

Comment by Frank Liepert [ 13/Apr/14 ]

Marco Pivetta as I have explained the persist() and flush() in the first request trigger an UPDATE command (Because there is already a row in the parent table?). Given that the child table was manually created before there are no rows on that table at that time and therefore nothing can be updated. Nevertheless the ORM triggers no error and $child looks like having been persisted. In the second request you'll notice that there haven't been persisted any of the data belonging to the child table.





[DDC-3070] [GH-1001] [DDC-3005] Defer invoking of postLoad event to the end of hydration cycle. Created: 04/Apr/14  Updated: 19/Oct/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Dependency
is required for DDC-3005 Events::postLoad fires without filled... Reopened

 Description   

This issue is created automatically through a Github pull request on behalf of Strate:

Url: https://github.com/doctrine/doctrine2/pull/1001

Message:

This feature makes guarantee, that postLoad event fires after all associations are populated.
Test case also provided.



 Comments   
Comment by Doctrine Bot [ 19/Oct/14 ]

A related Github Pull-Request [GH-1001] was assigned:
https://github.com/doctrine/doctrine2/pull/1001

Comment by Doctrine Bot [ 19/Oct/14 ]

A related Github Pull-Request [GH-1001] was unassigned:
https://github.com/doctrine/doctrine2/pull/1001





[DDC-3063] Unexpected behavior with 'WHERE NOT IN' and empty array Created: 01/Apr/14  Updated: 06/May/14

Status: Reopened
Project: Doctrine 2 - ORM
Component/s: DQL
Affects Version/s: 2.4
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Tim Stamp Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: None
Environment:

CentOS, PHP 5.4, mysql



 Description   

I tried to set version to 2.4.0 but was prevented.

Assume the set 'n' contains 10 records, all with id > 0.

->andWhere('n.id NOT IN (:ids)')->setParameter('ids', [])
returns 0 records.

->andWhere('n.id NOT IN (:ids)')->setParameter('ids', [0])
returns 10 records.


 Comments   
Comment by Marco Pivetta [ 01/Apr/14 ]

This is a simple misunderstanding of how SQL IN() works

Comment by Tim Stamp [ 01/Apr/14 ]

You're right that its invalid SQL, but this is DQL. In SQL this would raise an error, in DQL it says nothing and returns nothing.

Isnt there a way to check if a statement has caused this error?

Comment by Marco Pivetta [ 01/Apr/14 ]

Tim Stamp yeah, when using IN() and NOT IN() you should actually check if the parameters are empty or not before adding the clause.

Comment by Steve Müller [ 01/Apr/14 ]

It's still weird that no error is raised by that. Tim Stamp can you check what SQL is generated by your query?

Comment by Steve Müller [ 01/Apr/14 ]

Hehe I think I got the problem. It might be DBAL related. See:

https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/SQLParserUtils.php#L140
https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/SQLParserUtils.php#L169

Looks like the implementing person did that by intention but don't ask me why.

Comment by Marco Pivetta [ 01/Apr/14 ]

Thats to avoid having an SQL statement like

SELECT * FROM foo WHERE bar IN()

, which is invalid.

Indeed, the NOT IN() case is not contemplated by that.

Comment by Steve Müller [ 01/Apr/14 ]

Just wondering if that kind of implementation isn't changing expectations because it looks like IN(NULL) will select all NULL rows then, even though this is not explicitly requested by the user. I don't care really TBH but this behaviour is not very transparent to the user. Personally I would like to see an error instead... Then at least I know what's going on and can fix that by additional checks instead.

Comment by Marco Pivetta [ 01/Apr/14 ]

Makes sense. Re-opening.

Comment by Steve Müller [ 01/Apr/14 ]

The question is if we can change this behaviour without breaking applications that rely on the current one. Because changing the code to throw an error breaks applications that insist on returning 0 rows for an empty array. I don't know what rules apply here concerning BC. What do you think Marco Pivetta?

Comment by Marco Pivetta [ 01/Apr/14 ]

Steve Müller existing apps should do following anyway:

if ($productIds) {
    $qb->andWhere('p.id IN (:productIds)')->setParameter('productIds', $productIds);
}

If they are not, that's most likely a bug in their codebase.

Comment by Steve Müller [ 01/Apr/14 ]

Agree. Was just wondering about what we can expect and what we can't expect.

Comment by Guilherme Blanco [ 21/Apr/14 ]

Steve Müller feel free to patch DBAL.
It's a bug, not a supported feature. If we have 2 tickets:
1- If I pass an empty array, I get nullable rows and I can't fix this
2- If I pass an empty array, it used to return nullable rows, now it returns nothing
Which one would you fix?

Comment by Tim Stamp [ 06/May/14 ]

Guilherme Blanco shouldn't both these use cases throw an exception, as both cases in MySQL would return an error?





[DDC-3055] table not escaped in orm:schema-tool:update if table already exists and needs to be altered Created: 27/Mar/14  Updated: 19/Jun/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: Tools
Affects Version/s: 2.4.2, 2.4.3
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Hilz Simon Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

the schema tool had to alter a table which name needs to be escaped (and was properly configured to do so). this didnt work because the table name wasnt escaped. completely deleting the table in the db let the schema tool generate the correct querys with escaped table names.



 Comments   
Comment by Marco Pivetta [ 27/Mar/14 ]

Hilz Simon did you try this with master as well?

Comment by Jérôme Poskin [ 19/Jun/14 ]

Hi it seems to fail on version 2.4.3 too





[DDC-3044] [GH-986] Add last modified time for metadata Created: 22/Mar/14  Updated: 18/Aug/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of c960657:

Url: https://github.com/doctrine/doctrine2/pull/986

Message:

This patch improves performance during development and does not affect production performance.

Currently, enabling the metadata cache during development gives a remarkable performance boost, but it requires that you manually flush the metadata cache when the metadata has been changed. When running console commands such as ``console orm:schema-tool:update`` (see #979).

With this change, metadata entries fetched from cache are checked for freshness using a quick last modified check. This is much faster than loading the actual metadata using the metadata driver. This allows you to enable the metadata cache during development without the need for manually flushing the metadata cache.

This PR is part 1 of 2. Part 2 is for the doctrine/common repository.

If this PR is accepted, it allows us to optimize the auto-generate proxy classes feature by comparing the last modified time for the metadata with the modified timestamp of the generated file.






[DDC-3029] DISTINCT , ORDER BY AND Limit in SQL Server Created: 14/Mar/14  Updated: 20/Aug/14

Status: Awaiting Feedback
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Michał Banaś Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Attachments: File SQLServerPlatform.php    

 Description   

I don't know if I should report it here , becouse error is in SQLServerPlatform.php file.
basicaly Distinct includes ROWNUM()
So if you add distinct in DQL it will be translated to "select distinct ...... , Rownum()" - which is always distinct offcource.

Here is original version

    protected function doModifyLimitQuery($query, $limit, $offset = null)
    {
        if ($limit > 0) {
            if ($offset == 0) {
                $query = preg_replace('/^(SELECT\s(DISTINCT\s)?)/i', '\1TOP ' . $limit . ' ', $query);
            } else {
                $orderby = stristr($query, 'ORDER BY');

                if ( ! $orderby) {
                    $over = 'ORDER BY (SELECT 0)';
                } else {
                    $over = preg_replace('/\"[^,]*\".\"([^,]*)\"/i', '"inner_tbl"."$1"', $orderby);
                }

                // Remove ORDER BY clause from $query
                $query = preg_replace('/\s+ORDER BY(.*)/', '', $query);
                $query = preg_replace('/^SELECT\s/', '', $query);

                $start = $offset + 1;
                $end = $offset + $limit;

                $query = "SELECT * FROM (SELECT ROW_NUMBER() OVER ($over) AS doctrine_rownum, $query) AS doctrine_tbl WHERE doctrine_rownum BETWEEN $start AND $end";
            }
        }

        return $query;
    }

In Attachenment there is a fixed version of this file.



 Comments   
Comment by Marco Pivetta [ 18/Aug/14 ]

Can you provide a failing test case and an expected result as well?

Comment by Michał Banaś [ 20/Aug/14 ]

Well I'm not working with PHP anymore for now, but i will try:
it's easy and when you look at the code closer you will see the problem:

Test Case: use Query Builder and genearate query with DIstinct and Order BY And Liimit ( top , skip or something )
Expected result would be to get distinct set of data ordered by key and with limit.
Unfortunately - as the result query will be something:
select distinct .... top ....
from .........
SELECT ROW_NUMBER() OVER ($over) AS doctrine_rownum ... rest of the qurery

so from inner query you will get

doctrine_rownum;column1;column2;column3
1;example;example;example
2;example;example;example
3;example;example;example

I think you can clearly see that each row will be diiffrent. That's why DISTINCT will not work.
What happens next:
At some point doctrine will treat identical entities as one object, so for example if you limit Your query to 10 and all objects will be identical You will get only one Row.

I hope thats clear now

And we have a solution for that. It's probably in attached file. I will try to attach final version

My team is woried that after updating Doctrine ( symfony ) we will have to face the problem again.

Comment by Michał Banaś [ 20/Aug/14 ]

well. For some reason i can't attach final version of the file :/
I can paste it as a comment or You can contact me directly and i will send it to You.

Comment by Marco Pivetta [ 20/Aug/14 ]

Ah, I see now what the problem is. ROWNUM() will basically always make the row unique, making DISTINCT useless.

The problem is clear, but it needs an SQL generation test first.

Michał Banaś can you eventually send the patch as a pull request to https://github.com/doctrine/dbal ? Consider that the code for the SQLServerPlatform changed a lot since 2.4.x

Comment by Michał Banaś [ 20/Aug/14 ]

Well I could do that in private time, but it can take a while since i have no spare time right now and i would have to prepare some basic PPH dev environment with MSSQL.otherwise i would send untested code which is not a good idea.

Comment by Marco Pivetta [ 20/Aug/14 ]

We all do develop these tools in private time, so nobody is forcing anyone to do anything





[DDC-3025] Mapping drivers do not honor scale or precision for identifier fields Created: 12/Mar/14  Updated: 18/Aug/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers, Tools
Affects Version/s: 2.4.2
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: huda salam Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

FYI. I don't use doctrine but with symfony2, and only use .yml or .xml mapping. Not yet try with annotation.

These commands :

php app\console doctrine:schema:update
php app\console doctrine:schema:create

Will not generate id's precision and scale for this kind of mapping :

<doctrine-mapping .....>
  <entity name="Namespace\MyBundle\Entity\MyData" table="my_data">
    <id name="id" type="decimal" column="id" precision="x" scale="y">
      <generator strategy="IDENTITY"/>
    </id>
    <field ... />
  </entity>
</ ....>

Suggested changes :

  • Doctrine\ORM\Mapping\Driver\YamlDriver.php
  • Doctrine\ORM\Mapping\Driver\XmlDriver.php





[DDC-3016] Criterias do not work with embeddables when matching in memory Created: 07/Mar/14  Updated: 22/May/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: New Feature Priority: Major
Reporter: Matthieu Napoli Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

When using criterias and doing the matching on a collection already loaded in memory, it will not work if filtering on embeddable objects.

Example:

    $criteria = new Criteria();
    $criteria->andWhere($criteria->expr()->eq('actions.view', true));

    $authorizations = $this->authorizations->matching($criteria);

Here the ClosureExpressionVisitor will try to get the property named >actions.view instead of >actions->view.

PHPUnit_Framework_Error_Notice : Undefined property: Tests\...\Model\ArticleAuthorization::$actions.view


 Comments   
Comment by Matthieu Napoli [ 22/May/14 ]

I have opened a PR with a potential fix: https://github.com/doctrine/collections/pull/27





[DDC-3007] ManyToMany does not respect all column attributes for the jointable Created: 03/Mar/14  Updated: 10/Sep/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Michael Kühn Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Given following 2 entities:

<?php
class Role {
    /**
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="UUID")
     * @ORM\Column(name="id", type="guid", nullable=false, unique=true, length=36, options={"fixed"=true})
     */
    protected $id;

    /**
     * @ORM\ManyToMany(targetEntity="User", mappedBy="roleList")
     */
    private $userList;
}
<?php
class User {
    /**
     * @ORM\Column(name="id", type="guid", nullable=false, unique=true, length=36, options={"fixed"=true})
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="UUID")
     */
    protected $id;

    /**     *
     * @ORM\ManyToMany(targetEntity="Role", inversedBy="userList")
     * @ORM\JoinTable(name="user_role")
    protected $roleList;
}

It should create a table "user_role" with 2 columns which are CHAR(36).

But it ignores the Column-Attributes and creates a table "user_role" with 2 CHAR(255) columns.

This has various downsides:

  • It's unusable when using MyISAM, because of limited index size. (CREATE TABLE fails, see DBAL-423)
  • If using GUID-Type (see DBAL-423 with the changes from the linked ull request) and specify "length=36" and "fixed=true" on the Column-Annotation, no changes for the entity-tables itself are generated when running orm:schema-tool:update. However, there are still changes for the many-to-many-table generated (because internal "fixed" is false and length is unset) which represent the current state of the columns. These changes are always generated.


 Comments   
Comment by Doctrine Bot [ 10/Sep/14 ]

A related Github Pull-Request [GH-465] was assigned:
https://github.com/doctrine/dbal/pull/465





[DDC-3005] Events::postLoad fires without filled associations Created: 02/Mar/14  Updated: 19/Oct/14

Status: Reopened
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Artur Eshenbrener Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Dependency
depends on DDC-3070 [GH-1001] [DDC-3005] Defer invoking o... Open

 Description   

When we load entities throw one dql query like this:

SELECT e, joined_link FROM Entity LEFT JOIN e.link joined_link

In event subscriber, subscribed to postLoad event for instances of Entity property "link" of entity does not contains fetched in same query joined entity, and does not contains proxy object.

Tell me if failing test case needed.



 Comments   
Comment by Marco Pivetta [ 02/Mar/14 ]

The postLoad event is fired without warranty that association entities/proxies will be set:

http://docs.doctrine-project.org/en/latest/reference/events.html#lifecycle-events

Comment by Artur Eshenbrener [ 03/Mar/14 ]

But why? This shounds like involuntary restriction, and I think it can be fixed. Will my PR with fix accepted, or collaborators don't want to change this behaviour?

Comment by Marco Pivetta [ 03/Mar/14 ]

Artur Eshenbrener triggering `postLoad` in the correct moment in time (when all dependencies are loaded) requires a lot of additional complexity to be inserted in various locations of the ORM.

Since `postLoad` is supposed to be used like `__wakeup` and in general for simple tasks, this kind of refactoring/rewrite would be an overkill.

Comment by Artur Eshenbrener [ 04/Mar/14 ]

> requires a lot of additional complexity to be inserted in various locations of the ORM.
Sounds like "It is very hard to implement, and no one want to do this"

> and in general for simple tasks, this kind of refactoring/rewrite would be an overkill.
Disagree with this. Why only simple? I need to deal with associations in this event. Without this I should inject whole EntityManager to my entity, but I dont want to do this.

And I forced to repeat the question: will PR with fix accepted or not?

Comment by Marco Pivetta [ 04/Mar/14 ]

Sounds like "It is very hard to implement, and no one want to do this"

Not really, the main problem here is performance, since hydration would have to be completely redesigned.
Yes, "too hard" is a good reason for something that is an edge case.

And I forced to repeat the question: will PR with fix accepted or not?

Sure thing! Just needs to avoid a massive rewrite though.

Comment by Marco Pivetta [ 04/Mar/14 ]

To give you some hints, Doctrine\ORM\Events::postLoad is triggered in https://github.com/doctrine/doctrine2/blob/15432fc55f83c2d6ce8d9b86fd3139dd2a4fc328/lib/Doctrine/ORM/UnitOfWork.php#L2788, and Doctrine\ORM\UnitOfWork#createEntity() is used by all the various hydrators internally.

To ensure that Doctrine\ORM\Events::postLoad is triggered after an entity is fully loaded, the various hydrators must trigger the events after being sure that all data has been set, and that the entity is "ready" for use. That's some copy-paste work :\

Comment by Artur Eshenbrener [ 04/Mar/14 ]

I think the entry point is here: https://github.com/doctrine/doctrine2/blob/15432fc55f83c2d6ce8d9b86fd3139dd2a4fc328/lib/Doctrine/ORM/Internal/Hydration/AbstractHydrator.php#L140,
so, copy-paste work is not needed )

Comment by Artur Eshenbrener [ 05/Apr/14 ]

PR is ready: https://github.com/doctrine/doctrine2/pull/1001

Comment by Doctrine Bot [ 19/Oct/14 ]

A related Github Pull-Request [GH-1001] was assigned:
https://github.com/doctrine/doctrine2/pull/1001

Comment by Doctrine Bot [ 19/Oct/14 ]

A related Github Pull-Request [GH-1001] was unassigned:
https://github.com/doctrine/doctrine2/pull/1001





[DDC-2995] Joined Inheritance Mapping and Filters Created: 22/Feb/14  Updated: 14/Oct/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Bojidar Hristov Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: orm


 Description   

Is there any reason why Inheritance Mapping IS LEFT JOINED not INNER JOINED?

When there is a filter and it's left joined it happens a record might not have parent table record. For example

Class B extends Class A.
Class A have column is_active | and filter activated with is_active = 1 condition.

Final query: LEFT JOIN parent_table s1_ ON p2_.id = s1_.id AND (s1_.is_active = '1')

Record 1 have is_active = false, so result set looks like this:

table_b | table_a
id | id is_active discriminatorColumn
1 | null null null

and occurs exception: The discriminator column ... is missing for ....



 Comments   
Comment by Marco Pivetta [ 22/Feb/14 ]

JTI MUST be left-joined, since not every subclass of the root of the inheritance causes inserts on all of the inheritance tables.

What is the DQL query that is causing the problem?

Comment by Bojidar Hristov [ 22/Feb/14 ]

Hello Marco, I don't query from parent table, but from child. No sense to be LEFT JOINED.

DQL is something like that:

SELECT class1, class2 FROM Class1 class1 JOIN class1.class2 class2;

(Class2 extends Class3)
Class3 have is_active column.

And following filter:

public function addFilterConstraint(ClassMetadata $targetEntity, $targetTableAlias) {
if (!$targetEntity->reflClass->implementsInterface('ActivateableInterface'))

{ return ""; }

return $targetTableAlias . '.is_active = ' . $this->getParameter('isActive');
}

Filter condition is added in LEFT JOINED parent_table. Full example SQL:
SELECT ....
FROM class1 c1
INNER JOIN class2 c2 ON c1.c2_id = c2.id
LEFT JOIN table3 c3 ON c2.id = c3.id AND (c3.is_active = '1')

Comment by Marco Pivetta [ 26/Feb/14 ]

There are two possible solutions here:

  • verify if the selected entity is a leaf of a JTI, and use INNER JOIN on that if possible (probably not optimal, since the selection may be part of a LEFT JOIN itself)
  • add filtering on the discriminator column

Bojidar Hristov can you provide a failing test case to make it easier to work on this?

Comment by Bojidar Hristov [ 26/Feb/14 ]

Yes. Here is it sample failing test.

http://pastebin.com/xi8uUNX5 - Parent Class
http://pastebin.com/XRZLbyGX - Child Class
http://pastebin.com/HuPFb98u - Assoc Class
http://pastebin.com/hGqRk74e - TestCase

Here it should found 0 records because ot JOIN and is_active = true filter.

Comment by Benjamin Eberlei [ 23/Mar/14 ]

Since filters are only available on the root, i guess inner join is really necessary here.

Comment by Bojidar Hristov [ 14/Oct/14 ]

Do you need something more? The bug is status Feedback?





[DDC-2990] [GH-956] Foreign association index names Created: 19/Feb/14  Updated: 23/Feb/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Reference
relates to DDC-2989 ORM should allow custom index names f... Open

 Description   

This issue is created automatically through a Github pull request on behalf of jsuggs:

Url: https://github.com/doctrine/doctrine2/pull/956

Message:

See http://www.doctrine-project.org/jira/browse/DDC-2989






[DDC-2988] Notice: Undefined index: joinColumns in BasicEntityPersister.php Created: 19/Feb/14  Updated: 13/Jun/14

Status: Awaiting Feedback
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: 2.3.5, 2.4.2
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Dennis Væversted Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File undefined-joinColumn.patch    
Issue Links:
Duplicate
duplicates DDC-2808 Notice: Undefined index: joinColumns ... Resolved

 Description   

When trying to use findBy on a ManyToMany field i receive the error:

Notice: Undefined index: joinColumns in lib/Doctrine/ORM/Persisters/BasicEntityPersister.php

It seems to be caused internally by the code expecting 'joinColumns' to be directly on the association, however it is found under 'joinTable'.
I have attached a patch that atleast fixes my case, hopefully it can be used to pin-point what the error is.



 Comments   
Comment by Dennis Væversted [ 19/Feb/14 ]

Might be related to this one: http://www.doctrine-project.org/jira/browse/DDC-2808

Comment by Litz Ouille [ 28/May/14 ]

Doctrine ORM 2.4.2 Here.

Here are my annotations
https://gist.github.com/LitzOuille/3cf2e73e169c032147ea

The thing I'm trying to do is
$questionRepository->findBy(array('contacts' => $ids)); // $ids = array(1,2,3, ...)

Comment by Marco Pivetta [ 30/May/14 ]

Calin Pristavu did you validate your mappings?

Comment by Calin Pristavu [ 30/May/14 ]

I failed, sorry.
The error came from the many-to-many condition in the entity.
Sorry for generating confusion, comment deleted !

The many-to-one works just fine !

Comment by Litz Ouille [ 03/Jun/14 ]

A little feedback? Is this a bug? Can it be fixed?
Thanks

Comment by Marco Pivetta [ 03/Jun/14 ]

Litz Ouille that particular repository call cannot work. How are we supposed to find an entity from a list of associated IDs? It would have to be the exact match...

Assuming that API would work as I envision it, it looks like a missing feature.

Dennis Væversted in order to accept a patch, we first need a failing test case demonstrating the failing scenario.

Comment by Litz Ouille [ 03/Jun/14 ]

EDIT: Ok my bad.

I am using findBy(array('id', $arrayIds)) and it is working. I thought I was using on a ManyToOne relationship, but no.

EDIT2: @ocramius In fact I would like to find all questions for which the contacts' list contains at least one id. Something like
SELECT q.*
FROM Question q, QuestionContact qc //qc = jointable
WHERE q.id = qc.question_id
AND qc.contact_id IN ($ids)

EDIT3: Actually when I try to findBy('ManyToMany', $id), it does not work either. I think I will have to use a repository for every query using a ManyToMany relationship.

EDIT4: Ok, so, as said in the original post, findBy does not work with many-to-many.
Notice: Undefined index: joinColumns (BasicEntityPersister.php line 1666)
Dump($this->class->associationMappings[$field]): https://gist.github.com/LitzOuille/51929fdc3eda5576ed31

Comment by Xander ten Boden [ 13/Jun/14 ]

I've got the same issue, also running doctrine 2.4.2:

multiple users can have multiple departments:

/**
 * @ORM\ManyToMany(targetEntity="CartelAuthDepartment", inversedBy="users")
 * @ORM\JoinTable(name="cartel_auth_user_has_cartel_auth_department",
 *		joinColumns={@ORM\JoinColumn(name="cartel_auth_user_id", referencedColumnName="id")},
 *		inverseJoinColumns={@ORM\JoinColumn(name="cartel_auth_department_id", referencedColumnName="id")}
 * )
 */
private $departments;

/**
 * @ORM\ManyToMany(targetEntity="\Cartel\AuthBundle\Entity\CartelAuth\CartelAuthUser", mappedBy="departments")
 */
private $users;

Then I want to find all the users that are within the departments that the current user has:

$aAuthUsers = $oEm->getRepository('CartelAuthBundle:CartelAuth\CartelAuthUser')->findByDepartments($aAuthDepartments);

This results in this error:

Notice: Undefined index: joinColumns in .../vendor/doctrine/orm/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php line 1665





[DDC-2983] TCI association not getting hydrated into sql statement Created: 14/Feb/14  Updated: 23/Mar/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.5
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Machete Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm
Environment:

MySQL, using DoctrineORMModule (zf2 integration)



 Description   

/**
 * @ORM\Entity
 * @ORM\Table(name="base")
 * @ORM\InheritanceType("JOINED")
 * @ORM\DiscriminatorColumn(name="discriminator", type="string")
 * @ORM\DiscriminatorMap({
 * "a" = "A",
 * "b" = "B",
 * })
 */
class Base
{
    /**
     * @ORM\Id
     * @ORM\Column(type="integer")
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;
}

/**
 * @ORM\Entity
**/
class A extends Base {
    /**
     * @ORM\ManyToOne(targetEntity="B", inversedBy="as")
     */
    protected $b;

    /**
     * @ORM\OneToMany(targetEntity="C", cascade={"persist"})
     */
    protected $cs;
}

/**
 * @ORM\Entity
**/
class B Extends Base {
    /**
     * @ORM\OneToMany(targetEntity="A", mappedBy="b")
     */
    protected $as;
}

/**
 * @ORM\Entity
**/
class C {
  // ...
}

Doing this:

$a = new A();
$b = new B();

$a->setB($b);
$b->addA($a);

var_dump($a->getB()); // outputs B (b not null!)
var_dump($b->getAs()) // outputs A (private $_elements => [0] class B)

$em->persist($a);
$em->persist($b);
$em->flush();

Leads to

integrity constraint violation, b_id can not be null

aka

INSERT INTO a (id, b_id), (123, null);

I have no idea why this happens. This works:

$a = new A();
$b = new B();

$a->setB($b);
$b->addA($a);

var_dump($a->getB()); // outputs B (b not null!)
var_dump($b->getAs()) // outputs A (private $_elements => [0] class B)

$em->persist($a);
$em->flush();
$em->persist($b);
$em->flush();


 Comments   
Comment by Benjamin Eberlei [ 23/Mar/14 ]

This most likely happens because the UnitOfWork tries to set the owner and reverse incorrectly due to an ordering issue.





[DDC-2982] [GH-954] Multi Get support for Second Level Cache Created: 14/Feb/14  Updated: 23/Mar/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of goetas:

Url: https://github.com/doctrine/doctrine2/pull/954

Message:

Hi!
As discussed [here](http://www.doctrine-project.org/jira/browse/DDC-2981) i have implemented some kind of multi-get for second level cache implementation.

I have also created a PR to doctrine/cache component (see https://github.com/doctrine/cache/pull/29) that enables this feature at driver cache level.






[DDC-2981] Multi get for second level cache (Doctrine Cache related) Created: 13/Feb/14  Updated: 13/Feb/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Major
Reporter: Asmir Mustafic Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Hi every body!

I'm developing an application that is highly based on doctrine second-level cache feature.
Using memcache or redis as cache back-end, doctrine have to query thousand times for the cached values (especially on one-to-many and many-to-many associations).
This introduces a lot of latency (and network traffic)...

I'm thinking to add to Doctrine\Common\Cache\Cache interface a method fetchMulti(array $keys) that fetches multiple items in one call. In this way doctrine orm can ask for many items with just one call (for example, here https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Cache/DefaultCollectionHydrator.php#L84 this feature can be very useful).

I have made some real-world tests and it can reduce highly the number of total queries (my app runs 190 cache requests instead of 900 cache requests)

Many vendors (memcache, redis, apc ecc) already offer this functionality, but with doctrine-cache we can't use it...

I'm going to implement this feature. Can it be accepted as a pull request?

It may be BC breaking:

  • it can be implemented adding a method inside Doctrine\Common\Cache\Cache interface (more BC breaking but more clean and elegant)
  • it can be implemented adding an interface Doctrine\Common\Cache\MultiCache and later CacheProvider can implement it (less BC breaking)


 Comments   
Comment by Marco Pivetta [ 13/Feb/14 ]

Adding a method to Doctrine\Common\Cache\Cache is not viable because of BC - a new interface would be ok

Comment by Asmir Mustafic [ 13/Feb/14 ]

ok, i agree with you.
But this forces me to check always here https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Cache/Region/DefaultRegion.php#L95 if $this->cache is instance of MultiCache

Comment by Marco Pivetta [ 13/Feb/14 ]

Asmir Mustafic or you build a MultiCacheRegion

Comment by Asmir Mustafic [ 13/Feb/14 ]

It can be a good approach. I will try it.
I'm thinking to provide a default implementation of fetchMulti directly inside CacheProvider that internally loops over each key and call CacheProvider::fetch($id) to fetch its value.
Later i will overwrite this behavior inside vendor specific driver (ApcCache, RedisCache...)





[DDC-2973] [GH-949] Add a default lock mode to the EntityManager Created: 10/Feb/14  Updated: 10/Feb/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of BenMorel:

Url: https://github.com/doctrine/doctrine2/pull/949

Message:

Following [this discussion](https://groups.google.com/forum/#!topic/doctrine-dev/xKGzQcDkilE) on the mailing list, this is a first draft of a proposal to introduce a default lock mode for all entities loaded through an EntityManager.

At the moment, there is no way to set a lock mode for the following use cases:

  • Proxies obtained through `getReference()` and then initialized
  • Entities lazy-loaded through traversal of associations

This proposal introduces the idea of a default lock mode, which can be set at runtime when all reads in a transaction should be locking.

It works this way:

$em->beginTransaction();
$em->getConfiguration()->setDefaultLockMode(LockMode::PESSIMISTIC_WRITE);

// load entities from EntityManager, Repositories or DQL, traverse associations, etc.
// all these entities will be loaded with the given lock mode

$em->commit();
$em->getConfiguration()->setDefaultLockMode(null);

I have successfully tested it with the following use cases:

  • `EntityManager::find()`
  • `EntityRepository::findBy()`
  • DQL queries
  • Proxies
  • Lazy-loaded collections through OneToMany and ManyToMany associations

Before moving forward and writing proper unit tests, I'm looking for your feedback on this proposal. Is this a concept you would be happy to integrate in Doctrine?

If yes, I have a doubt as regards to where the default lock mode should be set: @Ocramius suggested to set it on the `Configuration`; this looked reasonable at first glance, and I have implemented it this way for now. It feels a tiny bit wrong though now that I see it, as I feel like the contents of the Configuration should should only be set during bootstrapping, rather than being set and reset in the controllers as in the example above. I might be wrong obviously.

My suggestion would be to move the default lock mode to the EntityManager, so that the code would become:

$em->beginTransaction();
$em->setDefaultLockMode(LockMode::PESSIMISTIC_WRITE);

Happily waiting for your feedback!






[DDC-2954] Paginator loses items Created: 05/Feb/14  Updated: 12/Feb/14

Status: Awaiting Feedback
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.3.4, 2.4.1
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Mariusz Jaskółka Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: Pagination, Paginator
Environment:

Linux and Windows, PHP 5, Oracle(OCI8)


Attachments: File LimitSubqueryOutputWalker.php     File LimitSubqueryOutputWalker_bugfix.php    

 Description   

Sometimes when when I use Paginator (Doctrine\ORM\Tools\Pagination\Paginator)

  • with query contains orderBy
  • with $fetchJoinCollection = true
  • lot of joins with toMany associations

there are too few items in result (no, it is not the end of list). There two situations:
1. I have four items on page 1 and two items on page 2 (pageLimit is 5). It is no so bad
2. I have four items on page 1 and there is no page 2 (while there should be 5 all items). This is very bad because I lose one item.

------------------------------------------------------------------
EDIT:
In function Paginator::getIterator there is variable $ids. In my situation it contains five numbers [34,26,34,15,12]. There is duplicated value 34 but ids of top-level entities should be distinct (as far as we do not use CROSS JOIN, or maybe I am wrong).

The Paginator::count function works correctly, it does not count duplicated values twice.

Statement that gets $ids is like following:
SELECT a.* FROM (SELECT DISTINCT ID2, BEGINTIME70 FROM (...) dctrn_result ORDER BY BEGINTIME70 DESC) a WHERE ROWNUM <= 5

------------------------------------------------------------------
EDIT 2 - Bugfix description:
The result items of the query is not unique because of
"SELECT DISTINCT col_with_id, order_by_column (...) ORDER BY order_by_column".
If we had items like following:
(1,A)
(1,B)
(1,B)
(2,C)

After DISTINCT operation the result would be:
(1,A)
(1,B)
(2,C)

But we want to have unique firs column, not pairs. That's why we should do "ORDER BY" before "DISTINCT" - not in the same time.
Please confirm if the solution is correct.



 Comments   
Comment by Marco Pivetta [ 05/Feb/14 ]

Mariusz Jaskółka this needs more details

Comment by Mariusz Jaskółka [ 06/Feb/14 ]

OK, I will try to find out where the problem is.

Comment by Mariusz Jaskółka [ 06/Feb/14 ]

I have edited description, maybe additional information will help.

Comment by Mariusz Jaskółka [ 07/Feb/14 ]

I send the bugfix in attachment. I will describe it soon.

Comment by Mariusz Jaskółka [ 07/Feb/14 ]

Bugfix version 2 - previously I did not notice that oracle loses order after DISTINCT operation. Thus I used GROUP BY.

Comment by Mariusz Jaskółka [ 11/Feb/14 ]

I do not know if I can change status of this issue from "Awaiting Feedback". I can not see such option





[DDC-2945] [GH-925] [DDC-2310] [DDC-2675] [2.4] Fix SQL generation on table lock hint capable platforms Created: 31/Jan/14  Updated: 18/Aug/14

Status: Awaiting Feedback
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of deeky666:

Url: https://github.com/doctrine/doctrine2/pull/925

Message:

Backport of PR https://github.com/doctrine/doctrine2/pull/910 for 2.4 branch.






[DDC-2940] [GH-922] Two hooks for DoctrineBundle to allow ContainerFilterCollection Created: 29/Jan/14  Updated: 29/Jan/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of nicoschoenmaker:

Url: https://github.com/doctrine/doctrine2/pull/922

Message:

Allows the DoctrineBundle to inject a ```ContainerFilterCollection``` that creates filters through dependency injection. See doctrine/DoctrineBundle#245.

Would prefer to inject the ```FilterCollection``` into the constructor of the em, but since they have a cyclic dependency I chose setter injection.






[DDC-2930] Pessimistic locking using $em->find('Entity', $id, LockMode::PESSIMISTIC_WRITE) and $em->lock($entiy, LockMode::PESSIMISTIC_WRITE) differs in (not)refreshing entity state from DB Created: 23/Jan/14  Updated: 23/Jan/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4.1
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Jiri Kavalik Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None
Environment:

ubuntu 12.04, mysql, zf2



 Description   

When using pessimistic locking on MySQL(InnoDB tables) there is difference which surprised me:

$em->find('Entity', $id, LockMode::PESSIMISTIC_WRITE);

will reload entity state from DB even when entity was already managed in cache (implemented in DDC-2929)
So I supposed that

$em->lock($entiy, LockMode::PESSIMISTIC_WRITE);

will work alike even when in this case entity is sure already loaded and managed
But it is not the case, actual query log showed only

SELECT 1 FROM table WHERE id FOR UPDATE

If this difference is intended it would be nice to mention it in http://docs.doctrine-project.org/en/latest/reference/transactions-and-concurrency.html

As a workaround I use

$em->refresh($entiy);





[DDC-2929] Pessimistic lock on Query does not update the entity with the DB values if it's already cached Created: 22/Jan/14  Updated: 22/Jan/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: Git Master
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Renaud Drousies Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None
Environment:

PHP 5.4.13-1~dotdeb.1


Issue Links:
Reference
is referenced by DDC-1846 Pessimistic lock does not retreive la... Resolved

 Description   

When asking for a pessimistic lock through a Query object, the entities already in the cache are not refreshed with the latest values from the database (unless you set the Query::HINT_REFRESH hint)

Example:

        $em->beginTransaction();
        try {
            $bar = $em->createQuery('SELECT b FROM Foo:Bar b WHERE b.id = :id')
                        ->setParameter('id', 150)
                        ->getSingleResult();
            var_dump($bar->getAmount()); // Yields some positive value
            $bar->setAmount(0);
            $bar = $em->createQuery('SELECT b FROM Foo:Bar b WHERE b.id = :id')
                        ->setParameter('id', 150)
                        ->setLockMode(\Doctrine\DBAL\LockMode::PESSIMISTIC_WRITE)
                        // ->setHint(\Doctrine\ORM\Query::HINT_REFRESH, true)
                        ->getSingleResult();
            var_dump($bar->getAmount()); // Yields 0

            $em->flush();
            $em->commit();
        } catch (\Exception $e) {
            $em->rollback();
        }

This is similar to DDC-1846

(Tested on 2.4.0 and 2.4.1)






[DDC-2922] Flushing new Entities reachable over several paths that do not all "cascade persist" Created: 17/Jan/14  Updated: 18/Aug/14

Status: Awaiting Feedback
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.3.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Matthias Pigulla Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None


 Description   

Please consider the following associations:

  A <>--> B <-- C  

A is an "aggregate" type object w/ a OneToMany collection of Bs. This association is set to cascade persist operations.

C has a unidirectional OneToOne association to B as well.

Adding a new B to A's collection and flushing the EntityManager works - B is persisted (persistence by reachability).

However, when also creating a new C and pointing it to the new B, adding C to the EntityManager and then flushing leads to an exception because B is discovered as a new Entity through a relationship not set to cascade persist operations.

Obviously the problem here is that there are two paths through which we can discover new Entities. The UoW currently starts search from newly (explicitly) added Entities first before it walks through collections of already-managed entities.

I am unsure if it is just a documentation issue or a deeper problem?

If the UoW worked the other way round, the same problem would occur if the cascade persist was on the other association.

A solution would probably require the UoW to first collect all offending (new) Entities and the link they were discovered through, but later on remove Entities from this list if they are found through another association with the cascade persist option. The exception must not be thrown unless the whole reachability graph has been traversed.



 Comments   
Comment by Marco Pivetta [ 18/Aug/14 ]

Can this be factored into a failing test case? I'm not sure if we can support it, but the code would make it much easier to track down the issue into something fixable.





[DDC-2918] get statements from ORM Created: 15/Jan/14  Updated: 15/Jan/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: Git Master
Fix Version/s: None
Security Level: All

Type: New Feature Priority: Major
Reporter: Flip Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

When doing `persist()` and then `flush()` the statements are not accessible anymore after the operation is done.

The EntityManager uses an EntityPersister. When looking at the BasicEntityPersister->executeInserts() a new statement is created but it's not saved as part of another object.
https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php#L260

Benefit:
When having access to the statements afterwards, all the following methods would be available:
http://www.php.net/manual/en/class.pdostatement.php

Most interesting are rowCount and error related methods.



 Comments   
Comment by Steve Müller [ 15/Jan/14 ]

Flip AFAIK you can use an SQL Logger for this which has to be set in the connection. The ORM testsuite makes use of this, too. See this example: https://github.com/doctrine/doctrine2/blob/master/tests/Doctrine/Tests/ORM/Functional/OneToOneEagerLoadingTest.php#L155

Comment by Flip [ 15/Jan/14 ]

Yes sure, but using a logger will be a strange way to pipe it back into business logic.

For example it's possible to do remove() on a proxy so you don't know if the row was present or not.

or another situation ..

when dealing with concurrency .. somebody else might have deleted the row already ..





[DDC-2917] Inheritance using joins generates invalid SQL when used in SELECT queries with GROUP BY on Postgresql Created: 15/Jan/14  Updated: 15/Jan/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Tom Pryor Assignee: