[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-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-2507] [GH-698] Fix for [DDC-2506] CTI JOINs and WITH conditionals Created: 14/Jun/13  Updated: 27/Oct/14  Resolved: 24/Jun/13

Status: Resolved
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: Marco Pivetta
Resolution: Incomplete Votes: 0
Labels: None


 Description   

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

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

Message:

http://www.doctrine-project.org/jira/browse/DDC-2506

Moved the `SqlWalker::walkConditionalExpression()` out of `walkJoin()` and into `walkJoinAssociationDeclaration()` after the base class JOIN but *before* the `_generateClassTableInheritanceJoins()`, thus allowing WITH conditions in Class Table Inheritance joins to apply correctly.

On a side note, I'm not able to get phpunit to run (even on a clean Master) so I'm leaving the testing up to Travis.



 Comments   
Comment by Doctrine Bot [ 24/Jun/13 ]

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

Comment by Doctrine Bot [ 13/Aug/13 ]

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

Comment by Doctrine Bot [ 20/Oct/14 ]

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

Comment by Doctrine Bot [ 27/Oct/14 ]

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





[DDC-2131] Fetch join not working on class table inheritance Created: 07/Nov/12  Updated: 27/Oct/14  Resolved: 12/Nov/12

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

Type: Bug Priority: Major
Reporter: alsar Assignee: Benjamin Eberlei
Resolution: Duplicate Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates DDC-1256 Generated SQL error with DQL WITH and... Resolved
Reference
is referenced by DDC-2869 [GH-886] [DDC-1256] Fix applying ON/W... Resolved

 Description   

I have an entity Appointment, that is associated with application forms.
I have an abstract class AbstractApplicationForm that has multiple (6) child classes.

The mapping info for the abstract application form looks like this:

AbstractApplicationForm.php
/**
 * @ORM\Entity()
 * @ORM\Table("applicationform")
 * @ORM\InheritanceType("JOINED")
 * @ORM\DiscriminatorColumn(name="discr", type="string")
 * @ORM\DiscriminatorMap({
 *     "slc" = "SlcApplicationForm",
 *     "vsdb" = "VsdbApplicationForm",
 *     "vss" = "VssApplicationForm",
 *     "opzd" = "OpzdApplicationForm",
 *     "vzu" = "VzuApplicationForm",
 *     "opzdvzu" = "OpzdVzuApplicationForm"
 * })
 */
abstract class AbstractApplicationForm
...

I have an OneToMany connection from Appointment to AbstractApplicationForm.
When i construct an DQL, to get an appointment with only specific application forms it gets wrong translated into SQL.

For instance if the query builder looks like this:

$qb->select('ap, af')
   ->from(Appointment::getClass(), 'ap')
   ->leftJoin('ap.applicationForms', 'af', 'WITH', 'af.id = 123456789')
   ->andWhere('ap.id = :appointment')
   ->setParameter('appointment', $appointment);

So with this dql i should get an appointment with filtered application forms. In this case it whould return an appointment with only one application form (that with the id 123456789).
But it returns all associated application form instead on only that with the id 123456789, because it ignores the with clause.

Here is the SQL that gets generated from the DQL:

SELECT ...
FROM program_execution_activity_appointment p8_, program_execution_activity_appointment p0_
LEFT JOIN applicationform a1_ ON p0_.id = a1_.appointment_id 
LEFT JOIN applicationform_slc a2_ ON a1_.id = a2_.id 
LEFT JOIN applicationform_vsdb a3_ ON a1_.id = a3_.id 
LEFT JOIN applicationform_vss a4_ ON a1_.id = a4_.id 
LEFT JOIN applicationform_opzd a5_ ON a1_.id = a5_.id 
LEFT JOIN applicationform_vzu a6_ ON a1_.id = a6_.id 
LEFT JOIN applicationform_opzdvzu a7_ ON a1_.id = a7_.id AND (a1_.id = 123456789) 
WHERE p0_.id = 1

The problem i see here is that the AND is added to the last join (applicationform_opzdvzu). But it should added to the first join (applicationform). Because the first join represents the parent entity (AbstractApplicationForm).
There is also a problem in the FROM clause. The problem is that program_execution_activity_appointment p8_ is never used anywhere else, except in the from clause.

The generated query should look like this:

SELECT ...
FROM program_execution_activity_appointment p0_
LEFT JOIN applicationform a1_ ON p0_.id = a1_.appointment_id AND (a1_.id = 123456789) 
LEFT JOIN applicationform_slc a2_ ON a1_.id = a2_.id
LEFT JOIN applicationform_vsdb a3_ ON a1_.id = a3_.id
LEFT JOIN applicationform_vss a4_ ON a1_.id = a4_.id
LEFT JOIN applicationform_opzd a5_ ON a1_.id = a5_.id
LEFT JOIN applicationform_vzu a6_ ON a1_.id = a6_.id
LEFT JOIN applicationform_opzdvzu a7_ ON a1_.id = a7_.id
WHERE p0_.id = 1

This sql works as expected.

I hope i was clear enough what the problem is.



 Comments   
Comment by Benjamin Eberlei [ 12/Nov/12 ]

This is a duplicate of DDC-1256

Comment by Benjamin Eberlei [ 12/Nov/12 ]

This is not easy to fix as you can see DDC-1256 is open for a while. However in your case there is an easy solution, why not fetch the appointment form by id, and then go the association to the appointment? This is the inverse operation on that relation, but suits your needs perfectly.

Comment by gseric [ 29/May/13 ]

Benjamin, this issue is duplicate of duplicate (according to your status changes). So original issues is DDC-349, but this error was introduced in 2.3. DDC-349 was created way back in 2010 so it can't be the same problem.

As far as I can tell, the problem was introduced with "Arbitrary join support" feature:
https://github.com/doctrine/doctrine2/pull/368 (SqlWalker.php changes)
Basically, in version 2.3 and later WITH statement is wrongly handled after SqlWalker::_generateClassTableInheritanceJoins()
Before 2.3 it was handled before.

You can see it clearly in this issue's description:
should be (< 2.3):
LEFT JOIN <CTI parent entity> ON <auto condition> AND <my custom WITH part> <CTI child left joins>
but we get (>= 2.3):
LEFT JOIN <CTI parent entity> ON <auto condition> <CTI child left joins> AND <my custom WITH part>

This issue can't be easily avoided in situation where you want to SELECT only one child row per parent row (based on some condition). WITH is natural and fastest option.

Comment by gseric [ 01/Jul/13 ]

This bug seems to be recognized and fixed (pull request ATM) in DDC-2506

Comment by Doctrine Bot [ 13/Aug/13 ]

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

Comment by Artur Eshenbrener [ 22/Dec/13 ]

Why do you think that applying ON/WITH conditions only to base table is good? What if I will reference to fields from child entity in ON/WITH clause?
I think that all user conditions should be applied to last join in class table inheritance joins, because only in that join references to all tables are available. Otherwise I get sql error.

Comment by Artur Eshenbrener [ 23/Dec/13 ]

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

Comment by Doctrine Bot [ 17/Feb/14 ]

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

Comment by Doctrine Bot [ 27/Oct/14 ]

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





[DDC-2235] Single table inheritance discriminator in WHERE when using arbitrary join syntax Created: 11/Jan/13  Updated: 27/Oct/14  Resolved: 16/Aug/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.3
Fix Version/s: 2.4
Security Level: All

Type: Bug Priority: Major
Reporter: Jordi Forns Assignee: Guilherme Blanco
Resolution: Fixed Votes: 6
Labels: None

Issue Links:
Duplicate
duplicates DDC-1940 Doctrine DQL: erroneous sql generatio... Resolved

 Description   

The condition on the discriminator column is placed in the WHERE clause when using arbitrary join syntax, which renders LEFT JOINs useless.

Given these classes:
A - no inheritance
B1 - abstract, root of a hierarchy, discriminator column is named 'type'
I setup a query builder like this:

$qb->select('a.id AS idA, b.id AS idB')
    ->from('\Entity\A', 'a')
    ->leftJoin('\Entity\B1', 'b', \Doctrine\ORM\Query\Expr\Join::WITH, 'a.something=b.something');
And the SQL Doctrine generates is something like this:
SELECT a.id, b.id FROM a LEFT JOIN b ON (a.something=b.something) WHERE b.type IN ('1', '2', '3')

The problems is that the WHERE condition makes the left join useless.

The condition on the discriminator column should be placed in the JOIN clause to avoid the problem.



 Comments   
Comment by Ondrej Hlavaty [ 10/Feb/13 ]

Can this be somehow worked around? If not, it is really serious problem...

Comment by Jordi Forns [ 18/Feb/13 ]

I couldn't find any workaround.
Trying to force the 'type' condition in the join clause resulted useless as Doctrine would add the 'where' condition regardless.

Comment by Michel Salib [ 22/Mar/13 ]

Easier way to workaround right now, is to declare a OneToMany from class A to class B on a protected field (no need of getter or setter). That way you can do classic join via relationship transversing and then the condition will be placed in the ON part of the query.

Comment by Yuta Konishi [ 01/Apr/13 ]

I could access with below codes. You should use RAW SQL it is easy solution I guess. good luck.

$qb = $em->createQueryBuilder();

$qb->select('a, b')
->from('YourEntity1', 'a')
->leftJoin('YourEntity2', 'b', \Doctrine\ORM\Query\Expr\Join::WITH, 'a.id = b.relationId');

$raw_sql = $qb->where( 
	$qb->expr()->in('a.relationId', $ids)
)
->orderBy('a.updatedAt', 'DESC')
->setMaxResults(10)
->getQuery()->getSQL();

$conn = $em->getConnection();
$stmt = $conn->query($raw_sql);

/* $stmt->fetchAll(); // access as Array */
Comment by Benjamin Eberlei [ 04/Apr/13 ]

Assigned to Alexander

Comment by Benjamin Eberlei [ 14/Apr/13 ]

Duplicate of DDC-1940

Comment by Jordi Forns [ 22/Apr/13 ]

Benjamin: this bug doesn't seem to be a dupe of DDC-1940. Actually that issue doesn't seem to be a bug at all.

As a reminder, the problem in this issue is that when performing arbitrary left joins on entities that are part of a class hierarchy, the discriminator condition is placed in the where clause instead of the join clause. This means that rows that could not be joined will have null values in the discriminator column and thus will not be returned because of the where condition (which will contain something like " where x.discriminator in (1,2,3) ").

Comment by Tom Arnfeld [ 27/Apr/13 ]

Has this issue been resolved elsewhere? From reading over DDC-1940 it doesn't seem to be a duplicate at all. I'm experiencing the same problem as Jordi and can't seem to find a solution. Is there any particular reason the `IN ()` predicate is not a part of the join, but instead placed in the main `WHERE` clause?

Comment by Tom Arnfeld [ 28/Apr/13 ]

I've been looking into the root cause of this bug (or feature..) to try and understand why it's happening, and after trying various possible fixes (a little hard without full understanding of the Doctrine/Query internals) I've ended up with a fix that seems to work well for my use case, at least. I've not run any of the unit tests (I plan to, and may adjust my fix based on that) but the top revision is my change... https://gist.github.com/tarnfeld/a6bb50ec707c7af1c5dc/revisions

Would love some feedback.

Pull request here: https://github.com/doctrine/doctrine2/pull/656

Comment by Jordi Forns [ 29/Apr/13 ]

Tom's fix moves the condition of the discriminator column to the LEFT JOIN, which is exactly what was needed.

Alexander: could you please give it a look?

Comment by Jordi Forns [ 23/May/13 ]

Tom's proposal seems to fix the issue.

Comment by Gordon Forsythe [ 11/Jun/13 ]

Agree, Tom's pull request looks like it fixes the issue. Is there a reason this hasn't been merged yet?

Comment by Gordon Forsythe [ 24/Jun/13 ]

I believe this may have been fixed by #DDC-2506 but I haven't tested it yet.
There is a pull request for it https://github.com/doctrine/doctrine2/pull/708 and there has been recent activity.
Disregard, not related.

Comment by Tom Arnfeld [ 24/Jun/13 ]

The two don't seem to be at all related to me, or maybe i'm missing something? Also, this PR has been open for two months, with no sign of being merged :/

Comment by Doctrine Bot [ 13/Aug/13 ]

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

Comment by Benjamin Eberlei [ 13/Aug/13 ]

Gordon Forsythe I don't like your tone. This is an open-source project and we do this in our free time. Please respect that we cannot offer specific response times at all.

Comment by Doctrine Bot [ 16/Aug/13 ]

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

Comment by Marco Pivetta [ 16/Aug/13 ]

Fixed at https://github.com/doctrine/doctrine2/commit/605c32dbb384e25117625a7cb4db4e7319a16bae ( https://github.com/doctrine/doctrine2/pull/758 )

Comment by Benjamin Eberlei [ 20/Aug/13 ]

merged into 2.4

Comment by Doctrine Bot [ 09/Aug/14 ]

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

Comment by Doctrine Bot [ 27/Oct/14 ]

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





[DDC-2506] WITH Conditionals on Class Table Inheritance LEFT JOINs are inserted incorrectly Created: 14/Jun/13  Updated: 27/Oct/14  Resolved: 20/Aug/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: DQL
Affects Version/s: Git Master
Fix Version/s: 2.4, 2.3.5
Security Level: All

Type: Bug Priority: Major
Reporter: Matt Janssen Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 2
Labels: dql, inheritance, joins, sql-walker


 Description   

The following JOIN

JOIN c.ctiRelationship cti WITH cti.id IN (42)

generates unexpected SQL

LEFT JOIN class_base p1_ ON u1_.cti_id = p1_.id 
LEFT JOIN class_child1 p2_ ON p1_.id = p2_.id
LEFT JOIN class_child2 p3_ ON p1_.id = p3_.id AND (p1_.id IN (42)) 

when it SHOULD be generating

LEFT JOIN class_base p1_ ON u1_.cti_id = p1_.id AND (p1_.id IN (42)) 
LEFT JOIN class_child1 p2_ ON p1_.id = p2_.id
LEFT JOIN class_child2 p3_ ON p1_.id = p3_.id


 Comments   
Comment by Matt Janssen [ 14/Jun/13 ]

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

Comment by gseric [ 01/Jul/13 ]

Thanks Matt, this bug prevented me to upgrade to 2.3. BTW it was originally reported in DDC-2131 (I put a comment there to redirect users here).

Comment by Gordon Forsythe [ 03/Jul/13 ]

I've tested this PR and it does work.

Comment by Doctrine Bot [ 13/Aug/13 ]

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

Comment by Doctrine Bot [ 17/Feb/14 ]

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

Comment by Doctrine Bot [ 27/Oct/14 ]

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





[DDC-2527] [GH-708] Unit test and fix for DDC-2506: CTI JOIN WITH conditionals failing. Created: 24/Jun/13  Updated: 27/Oct/14  Resolved: 25/Aug/13

Status: Resolved
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: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: None


 Description   

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

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

Message:

http://www.doctrine-project.org/jira/browse/DDC-2506



 Comments   
Comment by Doctrine Bot [ 13/Aug/13 ]

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

Comment by Marco Pivetta [ 25/Aug/13 ]

DDC-2506

Comment by Doctrine Bot [ 27/Oct/14 ]

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





[DDC-2525] [GH-707] [#DDC-2524] Wrong commit order with cascade remove and double association Created: 24/Jun/13  Updated: 27/Oct/14  Resolved: 08/Sep/13

Status: Resolved
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: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

This PR contains the failing test cas for DDC-2524(http://www.doctrine-project.org/jira/browse/DDC-2524).



 Comments   
Comment by Doctrine Bot [ 31/Jul/13 ]

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

Comment by Fabio B. Silva [ 08/Aug/13 ]

Closed, For more details see https://github.com/doctrine/doctrine2/pull/707

Comment by Benjamin Eberlei [ 08/Sep/13 ]

Was not merged

Comment by Doctrine Bot [ 04/Nov/13 ]

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

Comment by Doctrine Bot [ 27/Oct/14 ]

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





[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-2371] [GH-631] Fix typo in one of the orderBy examples. Created: 26/Mar/13  Updated: 26/Oct/14  Resolved: 08/Sep/13

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

Type: Documentation Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

Fix typo in one of the orderBy examples.



 Comments   
Comment by Benjamin Eberlei [ 26/Mar/13 ]

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

Comment by Doctrine Bot [ 26/Oct/14 ]

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





[DDC-3365] Indexes and uniqueConstraints has been ignored Created: 26/Oct/12  Updated: 26/Oct/14

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

Type: Bug Priority: Minor
Reporter: Diego Oliveira Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Ubuntu 12.04 with MySQL 5.5 and PHP 5.4


Attachments: Text File dbal-fixing-373.patch     Text File orm-fixing-373.patch    

 Description   

I using the Doctrine Migrations and when I declared my entity with the indexes section, the index name has been ignored. It's like this:

indexes:
IDX_ADDRESS_CITY:
columns: city_id

but, the diff tools ignore it and give me this code:
$this->addSql("CREATE INDEX IDX_7299B5238BAC62AF ON tb_address (city_id)");

and it should be:
$this->addSql("CREATE INDEX IDX_ADDRESS_CITY ON tb_address (city_id)");

Notice: I open the same bug on the migrations repository in github and @kimhemsoe told me to open here, since this is generated by DBAL component.



 Comments   
Comment by Padraig O'Sullivan [ 11/Dec/12 ]

Did you specify an index name in the indexes property for your entity in your PHP file? In this case, you should have something like:

indexes={@Index(name="IDX_ADDRESS_CITY", columns={"city_id"})}

That should result in the correct SQL being generated. If I modify the above to:

indexes={@Index(columns={"city_id"})}

I also get a migration that has SQL with an auto-generated index name.

Comment by Diego Oliveira [ 02/Feb/13 ]

Yes I did specify a name, as you can see:

uniqueConstraints:
    UNIQUE_STATE_SLUG:
        columns: slug
indexes:
    IDX_USER_ADDRESS:
        columns: address_id

I don't try do to it using annotations because I choose do use yaml to describe my entities. I will take a look on the source code to see if I can fix it and send a PR.

Comment by Diego Oliveira [ 02/Apr/13 ]

I already sent this patch to Guilherme Blanco, but I guess he doesn't have time to take a look on it.

I guess my solution it's not ideal, but it solve the problem and can be a base to make a better solution.

Comment by Benjamin Eberlei [ 20/Apr/13 ]

Diego Oliveira the fix doesn't seem too nice with the additional boolean flag.

I would rather like to fix the root cause instead of adding this solution.

Comment by Benjamin Eberlei [ 20/Apr/13 ]

The issue is tricky, because we cannot just move the index definitions above, they will need the columns, however that directly generates the index in the schema tool. Maybe if the gather join column methods would check if they can add an index already it would work.

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

Moving this to ORM as it is completely related to ORM's schema tool. The schema tool hast to declare the order and priority of indexes.





[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-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-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-1037] The EntityManager is closed when an exception is thrown in UoW's commit method Created: 16/Feb/11  Updated: 25/Oct/14  Resolved: 16/Feb/11

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

Type: Bug Priority: Major
Reporter: Sergei Lissovski Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None
Environment:

php 5.3.2, mysql, win7



 Description   

If an exception is thrown in commit method of UoW then the EM will be closed automatically and there's no way to restore it from the closed state rather than creating a new instance. To my mind this is a quite questionable feature. We faced this problem while executing functional tests - in our case if one of tests fails then other tests will fail as well, ORMException is thrown stating that EM is already closed.

https://github.com/doctrine/doctrine2/blob/2.0.0/lib/Doctrine/ORM/UnitOfWork.php#L290 - here is it.



 Comments   
Comment by Benjamin Eberlei [ 16/Feb/11 ]

There is absolutly no way to recover from an exception in the UnitOfWork. There is just no way to tell how to reset the UnitOfWork state to accomplish that.

For functional tests you should re-use the Database connecton but create a new EntityManager for each test!

Comment by John Kleijn [ 28/Feb/11 ]

I'm sure there is some valid reason to close the entity manager on exception, but it is a debugging nightmare. It also makes cleanup after an exception impossible. An example:

 
public function create($data)
{
	$event = $this->_factory($data);

	$events = is_array($event) ? $event : array($event);

	$this->flush();

	try {
		foreach($events as $event){
			$this->_createMessages($event);
		}
		return count($events) == 1 ? $events[0] : $events;
	}
	catch(\Exception $e){
		foreach($events as $event){
			$this->_deleteMessages($event);
			$this->getEntityManager()->remove($event);
		}
		throw $e;
	}
}

The event objects need to be persisted before the messages are created, which means they should be removed when something goes wrong.

Comment by Benjamin Eberlei [ 28/Feb/11 ]

I dont understand the code, because flush is called outside the try catch. Why cant you persist messages and events in one flush? Cant you just wrap both flushes into one transaction? See the Transaction docs. If an exception is thrown the transaction is aborted and all written data is discarded.

Comment by Ksaveras [ 25/Oct/14 ]

It's not resolved anyway.

after insert error in try catch i get error "The EntityManager is closed"

Why i have to code app to use and reuse doctrine?





[DDC-1952] Add support for array parameters on the SQLFilter Created: 27/Jul/12  Updated: 24/Oct/14

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

Type: Improvement Priority: Minor
Reporter: Menno Holtkamp Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 2
Labels: None


 Description   

The SQLFilter currently only accepts string parameters which would result in SQL like:

"tableAlias.column = '$filterParameter'"

To filter an Entity that has a lifecycle, this can be usefull to filter Entities that are in a specific state, for example:

"tableAlias.state = 1"

To be able to apply the filter on an Entity that can be in multiple states, it is usefull to be able to assign an array of states using setParameter:

$allowedStates = array(1,2,3,4);
$filter->setParameter('allowedStatesParam', $allowedStates);
sprintf("tableAlias.state IN (%s)", implode(',', $this->getParameter('allowedStatesParam')));

to eventually result in:

"tableAlias.state IN (1,2,3,4)"

However, this is currently not supported, it seems to go wrong on the PDO::quote() of the parameter. The SQL works ok when setting it statically in the filter, not taking the parameter into account.

It would be nice to have support for arrays on the setParameter()



 Comments   
Comment by Petr 'PePa' Pavel [ 24/Oct/14 ]

I've just created a pull request that implements just that. The only difference is that you don't call implode on the parameter when using it.
https://github.com/doctrine/doctrine2/pull/1168

The usage would be:

$allowedStates = array(1,2,3,4);
$filter->setParameter('allowedStatesParam', $allowedStates);

$quotedList = $this->getParameter('allowedStatesParam');
"tableAlias.state IN ($quotedList)"




[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-1792] [GH-340] add public has() method to filter collection. Created: 19/Apr/12  Updated: 24/Oct/14  Resolved: 30/Jul/13

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

Type: Improvement Priority: Major
Reporter: Benjamin Eberlei Assignee: Guilherme Blanco
Resolution: Duplicate Votes: 0
Labels: None


 Description   

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

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

Message:

Sorry if there is any reason why this is not implemented already.
This is useful when some feature, for example `soft-deleteable` filter may be optional.



 Comments   
Comment by Doctrine Bot [ 30/Jul/13 ]

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

Comment by Marco Pivetta [ 30/Jul/13 ]

To be handled in DDC-2581

Comment by Doctrine Bot [ 10/Aug/13 ]

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

Comment by Doctrine Bot [ 24/Oct/14 ]

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





[DDC-2405] Changing strategy generates bad query. Created: 19/Apr/13  Updated: 24/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: Van Rotemberg Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None


 Description   

For (unit, acceptance, functional) testing purpose I need to change the strategy of my GameStuff Entity class.

In previous version is was using php instruction below, but since doctrine orm 2.3, it doesn't work anymore.

$orm->getClassMetaData('Entities\GameStuff')->setIdGeneratorType(\Doctrine\ORM\Mapping\ClassMetadata::GENERATOR_TYPE_NONE);

will trigger:

Doctrine\DBAL\DBALException: An exception occurred while executing 'INSERT INTO vbank_accounts (game_id, updated_at, created_at) VALUES (?, ?, ?)' with params

{"1":1000010, "2":0,"3":"2013-04-19 17:16:05","4":"2013-04-19 17:16:05"}

:

SQLSTATE[HY093]: Invalid parameter number: number of bound variables does not match number of tokens



 Comments   
Comment by Benjamin Eberlei [ 20/Apr/13 ]

The problem is that changing ClassMetadata after generating it from the cache is not really supported and depends on the Internal State of other classes. Have you tried creating a completly new EntityManager and then directly setting this? It could be that the SQL for the entity was already generated inside Doctrine, with the ID Generator information at IDENTITY_AUTO.

Comment by Van Rotemberg [ 21/Apr/13 ]

> The problem is that changing ClassMetadata after generating it from the cache is not really supported

Yeah, it is a problem indeed, why set ticket status to resolved ?
Do you think it's normal to have a public method that trigger a fatal error ?

Please fix it or put setIdGeneratorType as private, or AT LEAST add a context exception ...

Comment by Marco Pivetta [ 21/Apr/13 ]

Almost every interaction with metadata outside the `loadClassMetadata` event will cause unexpected problems. I don't think throwing an exception there helps in any way.

Comment by Van Rotemberg [ 21/Apr/13 ]

@marco pivetta

The generation of the actual exception comes from DBALException on the query excetion and point a bad generated query (Invalid parameter number),
when the problem comes from setting ClassMetada, and concerns a problem of cache generated after loadClassMetadata.

Adding an exception is just the fast way pointing where the problem comes from and that "setting metadata after loadMetadata is not supported anymore". (It will spare developper's time that used to set metadata, but also help future contribution)

> Please fix it or put setIdGeneratorType as private, or AT LEAST add a context exception ...
Note: BTW, my favorite solution would be to fix it (re-generate cache, or edit cache, or disable cache or whatever)

Comment by Marcus Obwandner [ 24/Oct/14 ]

I have the same Problem.

We have rewritten an old Application, a Part of it have rewritten the whole Structures. Old about 6 Tables, new about 12 Tables. i have written a converter between the Structures. but we must keep the old foreign Key, for the Part, because we don't changed the other Parts of the application data structures.

When I tested the script with a small batch of Entries (About 20) no problems, but now i run with the full Dataset, this Error occurs every now and then.





[DDC-2517] [GH-703] Clear visitedCollections Created: 19/Jun/13  Updated: 23/Oct/14  Resolved: 25/Jun/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4, 2.3.5
Security Level: All

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


 Description   

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

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

Message:

Visited collections are cleared only in commit(). Commit clears up only if it actually has something to do. Processing large amounts of records without changing them cause visitedCollections to grow without any way of clearing.



 Comments   
Comment by Doctrine Bot [ 30/Jun/13 ]

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

Comment by Doctrine Bot [ 23/Oct/14 ]

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





[DDC-2476] [GH-680] [wip] better reverse engineers the mapping metadata from a database Created: 29/May/13  Updated: 23/Oct/14  Resolved: 08/Sep/13

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

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


 Description   

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

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

Message:

  1. The problem:
    1.use symfony2 doctrine:mapping:import from msyql database to annotation
    2.use symfony2 doctrine:schema:update will see a lot of sql update about just import database schema.
    3.this PR fix eliminate some of those sql update...
  1. has fixed problem:
  • column default
  • column unsigned (add test)
  • column comment
  • column type decimal with precision and scale
  • table with simple index
  • table with unique index


 Comments   
Comment by Doctrine Bot [ 12/Jun/13 ]

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

Comment by Guilherme Blanco [ 12/Jun/13 ]

Fixed: https://github.com/doctrine/doctrine2/commit/3d86c82a7fb51875d1b6c66b865134c9ccf1a878

Comment by Guilherme Blanco [ 12/Jun/13 ]

https://github.com/doctrine/doctrine2/commit/3d86c82a7fb51875d1b6c66b865134c9ccf1a878

Comment by Benjamin Eberlei [ 08/Sep/13 ]

Fix Version 2.4

Comment by Doctrine Bot [ 23/Oct/14 ]

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

Comment by Doctrine Bot [ 23/Oct/14 ]

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





[DDC-2365] [GH-626] default discriminator map - full namespace Created: 22/Mar/13  Updated: 23/Oct/14  Resolved: 30/Mar/13

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

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


 Description   

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

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

Message:

Using Symfony2, if you have two entities with the same name in different bundles, automatic discriminator map detection will trow MappingException.

If the namespace is included, there should be no more duplicate key issues.

(In this case, setting the map manually is not an option)



 Comments   
Comment by Benjamin Eberlei [ 30/Mar/13 ]

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

Comment by Doctrine Bot [ 23/Oct/14 ]

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





[DDC-2418] [GH-654] Ilike Created: 27/Apr/13  Updated: 23/Oct/14  Resolved: 27/Apr/13

Status: Resolved
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: Won't Fix Votes: 0
Labels: None


 Description   

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

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

Message:

Ilike expression added for postgres support



 Comments   
Comment by Doctrine Bot [ 27/Apr/13 ]

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

Comment by Doctrine Bot [ 23/Oct/14 ]

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





[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-2511] [GH-701] list_bugs.php needs to call to getters for protected vars Created: 17/Jun/13  Updated: 22/Oct/14  Resolved: 17/Jun/13

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

Type: Documentation Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

list_bugs.php needs to call to getters for protected vars. This was changed in the "getting-started" code repository, but not in the "getting-started" tutorial.



 Comments   
Comment by Doctrine Bot [ 17/Jun/13 ]

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

Comment by Marco Pivetta [ 17/Jun/13 ]

Merged at https://github.com/doctrine/doctrine2/commit/a39ceb3159d9716b528c422099c853224a1bc863

Comment by Doctrine Bot [ 22/Oct/14 ]

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





[DDC-2373] [GH-633] [DDC-2042] Added "targetEntity" to AssociationOverride Created: 26/Mar/13  Updated: 22/Oct/14  Resolved: 27/Mar/13

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

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


 Description   

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

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

Message:

Hey,

I needed to override "targetEntity" so I forked Doctrine and applyed it myself. Just after that I found a Ticket DDC-2042 in your Jira so I added a unit test to and would be more than happy to see this commit get merged in to the main master (at some point ).

Cheers, Alex

I will stick around in the #doctrine-dev on Freenode for any questions. My nick there is "fanta".

Keep up the good work.

/**

  • @ORM\Entity
  • @ORM\Table(name="customer")
  • @ORM\AssociationOverrides( { * @ORM\AssociationOverride(name="products", * targetEntity="MyNewProduct" * ) * }

    )
    */



 Comments   
Comment by Benjamin Eberlei [ 27/Mar/13 ]

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

Comment by Doctrine Bot [ 22/Oct/14 ]

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

Comment by Doctrine Bot [ 22/Oct/14 ]

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





[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-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-2493] [GH-689] [WIP][DDC-1995 ] Support metadata class as parameter for instance of expression Created: 07/Jun/13  Updated: 22/Oct/14  Resolved: 07/Jun/13

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

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


 Description   

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

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

Message:

Hi guys,

This is a possible solution for DDC-1995(http://www.doctrine-project.org/jira/browse/DDC-1995),

I've attempted some diferent ways to fix this problem without success.
Anyway, RSM still looks like the wrong place to parameters mapping.



 Comments   
Comment by Doctrine Bot [ 07/Jun/13 ]

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

Comment by Fabio B. Silva [ 07/Jun/13 ]

Merged : https://github.com/doctrine/doctrine2/commit/462173ad71ae63cd9877e1e642f7968ed1f9971b

Comment by Doctrine Bot [ 22/Oct/14 ]

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

Comment by Doctrine Bot [ 22/Oct/14 ]

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





[DDC-3322] [GH-1146] Allow orderBy to reference associations Created: 23/Sep/14  Updated: 22/Oct/14  Resolved: 22/Oct/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed 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/1146

Message:

If I specify an order-by clause on a to-many association, e.g. `@OrderBy(

{"foo" = "ASC"}

)`, where foo is a to-one-association on the target entity, the collection is sorted by foo_id (this behaviour is implemented in BasicEntityPersister::getOrderBySQL()).

This works fine. However, Doctrine\ORM\Tools\SchemaValidator complains that foo is not a field.

This change makes the validator accept order-by clauses on associations where the target entity is the owning side, and the association is single-valued (AFAICT this is the same restrictions that BasicEntityPersister uses).



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

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

Comment by Doctrine Bot [ 22/Oct/14 ]

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





[DDC-2492] [GH-688] Implement QuoteStrategy on SqlWalker walkRangeVariableDeclaration Created: 06/Jun/13  Updated: 22/Oct/14  Resolved: 12/Jun/13

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

Based on:
http://www.doctrine-project.org/jira/browse/DDC-1845
https://github.com/doctrine/doctrine2/commit/cb72219b118c158c9b5344c4b81ff2b1a9149ab0



 Comments   
Comment by Doctrine Bot [ 12/Jun/13 ]

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

Comment by Marco Pivetta [ 12/Jun/13 ]

Merged at https://github.com/doctrine/doctrine2/commit/6ef48561baa6cd6e3da1304d7d815883be9a9af1

Comment by Doctrine Bot [ 22/Oct/14 ]

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





[DDC-2499] [GH-691] IDENTITY function fix for Joined Inheritance Created: 12/Jun/13  Updated: 22/Oct/14  Resolved: 12/Jun/13

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

In a joined inheritance scenario, the identity function implementation assumed the foreign key column was on the table corresponding to the (sub)class named in the select statement. If the relation was on a super-class incorrect sql was generated.



 Comments   
Comment by Doctrine Bot [ 12/Jun/13 ]

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

Comment by Marco Pivetta [ 12/Jun/13 ]

Merged at https://github.com/doctrine/doctrine2/commit/0248f743babbd9b8861ff744a25f006ce2b83f9d

Comment by Doctrine Bot [ 21/Oct/14 ]

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

Comment by Doctrine Bot [ 22/Oct/14 ]

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





[DDC-3359] [GH-1167] use add() instead of [] notation Created: 21/Oct/14  Updated: 21/Oct/14  Resolved: 21/Oct/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: entityGenerator


 Description   

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

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

Message:

Update addMethodTemplate.

removeElement() is being used in the remover method, using add()
in the adder is more consistent with the remover.



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

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

Comment by Doctrine Bot [ 21/Oct/14 ]

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





[DDC-3246] [GH-1103] Update Expr.php Created: 09/Aug/14  Updated: 21/Oct/14  Resolved: 21/Oct/14

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

Type: Improvement Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: dql, querybuilder


 Description   

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

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

Message:

adding NOT EXISTS statement



 Comments   
Comment by Doctrine Bot [ 18/Aug/14 ]

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

Comment by Doctrine Bot [ 21/Oct/14 ]

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





[DDC-2158] [GH-518] regression fix for left joins (double ON) Created: 20/Nov/12  Updated: 21/Oct/14  Resolved: 25/Nov/12

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

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Fixed 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/518

Message:



 Comments   
Comment by Benjamin Eberlei [ 25/Nov/12 ]

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

Comment by Doctrine Bot [ 21/Oct/14 ]

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

Comment by Doctrine Bot [ 21/Oct/14 ]

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





[DDC-2510] [GH-700] Update getting-started.rst Created: 17/Jun/13  Updated: 21/Oct/14  Resolved: 17/Jun/13

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

Type: Documentation Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

The tutorial assumes Doctrine 2.4



 Comments   
Comment by Doctrine Bot [ 17/Jun/13 ]

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

Comment by Marco Pivetta [ 17/Jun/13 ]

Merged at https://github.com/doctrine/doctrine2/commit/1a958f70fdb2aa67d41c76c0f0bde7fb393ed4ab

Comment by Doctrine Bot [ 20/Oct/14 ]

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

Comment by Doctrine Bot [ 21/Oct/14 ]

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





[DDC-2508] [GH-699] commented a change that was ahead of stable; added calls to getters Created: 15/Jun/13  Updated: 21/Oct/14  Resolved: 16/Jun/13

Status: Resolved
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: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

CreateHelperSet appears to be a method in 2.4, which is not stable yet and does not correspond with this 2.3 tutorial.
list_bugs.php was trying to get protected vars.



 Comments   
Comment by Doctrine Bot [ 16/Jun/13 ]

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

Comment by Doctrine Bot [ 21/Oct/14 ]

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

Comment by Doctrine Bot [ 21/Oct/14 ]

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





[DDC-3301] [GH-1131] Use repository class Created: 09/Sep/14  Updated: 21/Oct/14  Resolved: 21/Oct/14

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Won't Fix Votes: 0
Labels: entitymanager, repository


 Description   

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

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

Message:

Now we can use custom repository find() method



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

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

Comment by Doctrine Bot [ 21/Oct/14 ]

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





[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-3269] [GH-1120] [DDC-3205] Metadata info Created: 23/Aug/14  Updated: 20/Oct/14  Resolved: 20/Oct/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Kim Hemsø
Resolution: Fixed Votes: 0
Labels: console, debug

Issue Links:
Duplicate
is duplicated by DDC-3357 [GH-1165] [DDC-3205] #1120 - metadata... Resolved

 Description   

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

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

Message:

This PR adds support for showing the metadata for a single entity to the `orm:info` command.

  • The output is formatted using the `TableHelper` if it is available (Symfony 2.4+). If the TableHelper is not available
    it will format simply with `field: value`.
  • Partial regex matches are accepted, e.g. `mapping:info Attraction`, `mapping:info Attraction.*`

E.g.:

````bash
$ php app/console doctrine:mapping:info "Sulu\Bundle\ContactBundle\Entity\Count"
----------------------------------------------------------------------------------------------------------------------------+

Field Value

----------------------------------------------------------------------------------------------------------------------------+

Name Sulu\Bundle\TagBundle\Entity\Tag
Root entity name Sulu\Bundle\TagBundle\Entity\Tag
Custom generator definition None
Custom repository class Sulu\Bundle\TagBundle\Entity\TagRepository
Mapped super class? Empty
Embedded class? Empty
Parent classes Empty
Sub classes Empty
Embedded classes Empty
Named queries Empty
Named native queries Empty
SQL result set mappings Empty
Identifier ["id"]
Inheritance type 1
Discriminator column None
Discriminator value None
Discriminator map Empty
Generator type 4
Table {"name":"ta_tags"}
Composite identifier? Empty
Foreign identifier? Empty
Sequence generator definition None
Table generator definition None
Change tracking policy 1
Versioned? None
Version field None
Read only? Empty
Entity listeners Empty
Association mappings:  
creator  
fieldName creator
targetEntity Sulu\Bundle\SecurityBundle\Entity\User
joinColumns [{"name":"idUsersCreator","referencedColumnName":"id","nullable":true,"onDelete":"SET NULL"}]
type 2
mappedBy Null
inversedBy Null
isOwningSide 1
sourceEntity Sulu\Bundle\TagBundle\Entity\Tag
fetch 2
cascade Empty
isCascadeRemove Empty
isCascadePersist Empty
isCascadeRefresh Empty
isCascadeMerge Empty
isCascadeDetach Empty
sourceToTargetKeyColumns {"idUsersCreator":"id"}
joinColumnFieldNames {"idUsersCreator":"idUsersCreator"}
targetToSourceKeyColumns {"id":"idUsersCreator"}
orphanRemoval Empty
Field mappings:  
name  
fieldName name
type string
columnName name
unique 1
created  
fieldName created
type datetime
columnName created

----------------------------------------------------------------------------------------------------------------------------+



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

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Doctrine Bot [ 20/Oct/14 ]

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

Comment by Kim Hemsø [ 20/Oct/14 ]

Fixed by https://github.com/doctrine/doctrine2/pull/1165





[DDC-3357] [GH-1165] [DDC-3205] #1120 - metadata info command Created: 19/Oct/14  Updated: 20/Oct/14  Resolved: 19/Oct/14

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

Type: New Feature Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Duplicate Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates DDC-3269 [GH-1120] [DDC-3205] Metadata info Resolved
duplicates DDC-3205 [DX] Interactive Management Command Open

 Description   

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

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

Message:

Supersedes #1120 - see DDC-3205 (http://www.doctrine-project.org/jira/browse/DDC-3205)



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

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Doctrine Bot [ 20/Oct/14 ]

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





[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-179] Time part of Date fields is initialized with current time instead of 00:00:00 Created: 26/Nov/09  Updated: 20/Oct/14  Resolved: 17/Jan/10

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.0-ALPHA4
Fix Version/s: 2.0-ALPHA4
Security Level: All

Type: Bug Priority: Major
Reporter: Eric Durand-Tremblay Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Reference
is referenced by DBAL-993 TimeType should reset date fields to ... Resolved

 Description   

This will be very easy for your to fix and it will help me a lot.

AbstractPlatform:1510

Change:

public function getDateFormatString()
    {
        return 'Y-m-d';
    }

By :

public function getDateFormatString()
    {
        return '!Y-m-d';
    }

Here is the extract from php documentation

    Format accepted by date().

    If format does not contain the character ! then portions of the date/time value specified in format but not specified in time will be set to the current system time.

    If format contains the character !, then portions of the generated time specified to the left-hand side of the ! in format will be set to corresponding values from the Unix epoch.

    If the first character of format is !, then all portions of the date/time value generated which are not specified in time will be initialized to corresponding values from the Unix epoch.

    The Unix epoch is 1970-01-01 00:00:00 UTC.



 Comments   
Comment by Eric Durand-Tremblay [ 26/Nov/09 ]

It look like it's more complicated.

the ! break the date when it is used by convertToDatabaseValue

So, it should only be used with convertToPHPValue

Here is what it could look like in DateType.php:30

 public function convertToPHPValue($value, AbstractPlatform $platform)
    {
        return ($value !== null) 
            ? \DateTime::createFromFormat('!' . $platform->getDateFormatString(), $value) : null;
    }
Comment by Benjamin Eberlei [ 27/Nov/09 ]

Looks like a no-brainer to me, however while thinking about it indenpendently of this issue we should probably add tests for summer-time annoyances that could occour.

Comment by Benjamin Eberlei [ 13/Jan/10 ]

Implemented

Comment by Eric Durand-Tremblay [ 14/Jan/10 ]

Look like you did not take into account my second comment.

The insert/update of date value is now broken

UPDATE client SET modified_at = ?, birthdate = ? WHERE id = ?                                          
Array                                                                                                                  
(                                                                                                                      
    [0] => 2010-01-14 15:14:20                                                                                         
    [1] => !2010-01-15                                                                                                                                                                                                
    [2] => 1                                                                                                           
)     
Comment by Benjamin Eberlei [ 15/Jan/10 ]

woah there is no test for this, bad

Comment by Roman S. Borschel [ 17/Jan/10 ]

So can this be closed now?

Comment by Benjamin Eberlei [ 17/Jan/10 ]

Yes, resolved!





[DDC-2505] [GH-697] Fix phpDoc syntax in ClassMetadataInfo.php Created: 14/Jun/13  Updated: 20/Oct/14  Resolved: 25/Jun/13

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

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


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 14/Jun/13 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Doctrine Bot [ 20/Oct/14 ]

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





[DDC-3268] [GH-1118] Use the new Docker queue on Travis Created: 22/Aug/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

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

Type: Improvement Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Incomplete Votes: 0
Labels: ci, docker, travis


 Description   

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

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

Message:

faster better stronger

let's see how it copes with this test suite



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

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





[DDC-3234] Empty properties when filtering collections Created: 30/Jul/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

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

Type: Bug Priority: Major
Reporter: Diogo Domanski de Souza Assignee: Marco Pivetta
Resolution: Cannot Reproduce Votes: 0
Labels: Collection, Criteria, orm
Environment:

PHP 5.5.9, Nginx 1.4.6, PHP FPM, Zend Framework 2.3.1, Linux Ubuntu 14.04



 Description   

I'm facing some troubles when filtering an entity association (ArrayCollection) by using Criteria.

The scenario is the following: I have 3 entities:

User.php
<?php

namespace Entity;

use Doctrine\ORM\Mapping as ORM;
use \Doctrine\Common\Collections\Criteria;
use Zend\Stdlib\Hydrator;

/**
 * User
 *
 * @ORM\Table(name="user")
 * @ORM\Entity(repositoryClass="Entity\UserRepository")
 * @ORM\HasLifecycleCallbacks
 * @author domanski
 */
class User implements \Serializable {
	/**
	 *
	 * @ORM\Id
	 * @ORM\Column(name="id", type="integer", nullable=false)
	 * @ORM\GeneratedValue(strategy="AUTO")
	 * @var integer
	 */
	private $id;

	/**
	 * @ORM\Column(name="delete_date", type="datetime")
	 * @var \DateTime
	 */
	private $deleteDate;
	
	public function __construct(array $options = array()) {
		if (!empty($options))
			$this->hydrate($options);
	}

	public function hydrate(array $options = array(), \Doctrine\ORM\EntityManager $em = null) {
		$hydrator = new Hydrator\ClassMethods();
		$hydrator->hydrate($options, $this);
	}

	/**
	 * 
	 * @return int
	 */
	public function getId() {
		return $this->id;
	}

	/**
	 * 
	 * @param int $id
	 * @return \Entity\User
	 */
	public function setId($id) {
		$this->id = $id;
		return $this;
	}

	/**
	 * 
	 * @return \DateTime
	 */
	public function getDeleteDate() {
		return $this->deleteDate;
	}

	/**
	 * @param \DateTime|null $deleteDate
	 * @return \Entity\User
	 */
	public function setDeleteDate($deleteDate = null) {
		$this->deleteDate = $deleteDate;
		return $this;
	}

	/**
	 * 
	 * @return array
	 */
	public function toArray() {
		$result = array(
			'id' => $this->getId(),
			'delete_date' => $this->getDeleteDate()
		);

		return $result;
	}

}
FieldWorker.php
<?php

namespace Entity;

use Doctrine\ORM\Mapping as ORM;
use \Doctrine\Common\Collections\Criteria;

use Zend\Stdlib\Hydrator;

/**
 * Description of FieldWorker
 *
 * @ORM\Entity(repositoryClass="Entity\FieldWorkerRepository")
 * @ORM\Table(name="field_worker")
 * @ORM\HasLifecycleCallbacks
 * @author domanski
 */
class FieldWorker {
	
	/**
	 * This attribute must exist so the inverse join with any other entity can work
	 * 
	 * @ORM\Id
	 * @ORM\Column(type="integer", name="user_id")
	 * @var string
	 */
	protected $id;
	
	/**
	 * 
	 * @ORM\OneToOne(targetEntity="Entity\User")
	 * @ORM\JoinColumn(name="user_id", referencedColumnName="id")
	 * @var \Entity\User
	 */
	protected $user;
	
	public function __construct($options = array()) {		
		if(!empty($options))
			$this->hydrate($options);
	}
	
	public function hydrate(array $options = array(), \Doctrine\ORM\EntityManager $em = null) {
		if(!empty($em)) {
			// user
			if(isset($options['user']))
				$options['user'] = $em->getReference('Entity\User', $options['user']);
			else if(isset($options['user_id']))
				$options['user'] = $em->getReference('Entity\User', $options['user_id']);
						
		}
		
		$hydrator = new Hydrator\ClassMethods();
		$hydrator->hydrate($options, $this);
	}

	/**
	 * 
	 * @return \Entity\User
	 */
	public function getUser() {
		return $this->user;
	}

	/**
	 * 
	 * @param \Entity\User $user
	 * @return \Entity\FieldWorker
	 */
	public function setUser(\Entity\User $user) {
		$this->user = $user;
		$this->id = $user->getId();
		return $this;
	}
	
	/**
	 * 
	 * @return array
	 */
	public function toArray() {
		return $this->getUser()->toArray();
	}
}
Stage.php
<?php

namespace Obra\Entity;

use Doctrine\ORM\Mapping as ORM;
use Zend\Stdlib\Hydrator;
use Doctrine\Common\Collections\Criteria;

/**
 * Description of Stage
 *
 * @ORM\Table(name="stage")
 * @ORM\Entity(repositoryClass="Entity\StageRepository")
 * @ORM\HasLifecycleCallbacks
 * @author domanski
 */
class Stage {

	/**
	 *
	 * @ORM\Id
	 * @ORM\Column(name="id", type="integer", nullable=false)
	 * @ORM\GeneratedValue(strategy="AUTO")
	 * @var integer
	 */
	private $id;

	/**
	 * @ORM\ManyToMany(targetEntity="Entity\FieldWorker")
	 * @ORM\JoinTable(name="stage_field_worker",
	 * 		joinColumns={@ORM\JoinColumn(name="stage_id", referencedColumnName="id")},
	 * 		inverseJoinColumns={@ORM\JoinColumn(name="field_worker_id", referencedColumnName="user_id")}
	 * 	)
	 * @var \Doctrine\Common\Collections\ArrayCollection
	 */
	private $fieldWorkers;

	public function __construct(array $options = array()) {
		$this->fieldWorkers = new \Doctrine\Common\Collections\ArrayCollection();

		if (!empty($options))
			$this->hydrate($options);
	}

	public function hydrate(array $options = array(), \Doctrine\ORM\EntityManager $em = null) {
		$hydrator = new Hydrator\ClassMethods();
		$hydrator->hydrate($options, $this);
	}

	/**
	 * 
	 * @return int
	 */
	public function getId() {
		return $this->id;
	}

	/**
	 * 
	 * @param int $id
	 * @return \Entity\Stage
	 */
	public function setId($id) {
		$this->id = $id;
		return $this;
	}

	/**
	 * 
	 * @return \Doctrine\Common\Collections\ArrayCollection
	 */
	public function getFieldWorkers() {
		$criteria = Criteria::create()
				->where(Criteria::expr()->isNull("user.deleteDate"))
				->orderBy(array("user.name" => Criteria::ASC));

		return $this->fieldWorkers->matching($criteria);
	}

	/**
	 * 
	 * @return \Entity\Stage
	 */
	public function clearFieldWorkers() {
		$this->fieldWorkers->clear();
		return $this;
	}

	/**
	 * 
	 * @param \Entity\FieldWorker $fieldWorker
	 * @return \Entity\Stage
	 */
	public function addFiscal(\Entity\FieldWorker $fieldWorker) {
		$this->fieldWorkers->add($fieldWorker);
		return $this;
	}

	/**
	 * 
	 * @return array
	 */
	public function toArray() {
		$result = array(
			"id" => $this->getId(),
			"field_workers" => array()
		);

		foreach ($this->getFieldWorkers() as $fieldWorker) {
			$result['field_workers'][] = $fieldWorker->toArray();
		}

		return $result;
	}
}

The problem is that whenever the Stage::getFieldWorkers() method is invoked, the list of associated field workers is returned correctly, however if I try to retrieve the respective user of any field worker, it is NULL.

For example:

$stageEntity = $em->getRerefence('Entity\Stage', 1);
$fieldWorkers = $stageEntity->getFieldWorkers();

foreach($fieldWorkers as $fieldWorker) {
   $userId = $fieldWorker->getUser()->getId(); // This throws an error message saying that the result of getUser() is NULL
}

Another example would be if I try to call $stageEntity->toArray() (because it does the same thing as show above).

The database tables are as following:

Database tables creation
CREATE TABLE `user` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `delete_date` datetime DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE `field_worker` (
  `user_id` int(10) unsigned NOT NULL,
  PRIMARY KEY (`user_id`),
  CONSTRAINT `fk_field_worker_user1` FOREIGN KEY (`user_id`) REFERENCES `user` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;


CREATE TABLE `stage` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;


CREATE TABLE `stage_field_worker` (
  `stage_id` int(10) unsigned NOT NULL,
  `field_worker_id` int(10) unsigned NOT NULL,
  PRIMARY KEY (`stage_id`,`field_worker_id`),
  KEY `fk_stage_field_worker_stage_idx` (`stage_id`),
  KEY `fk_stage_field_worker_field_worker_idx` (`field_worker_id`),
  CONSTRAINT `fk_stage_field_worker_field_worker` FOREIGN KEY (`field_worker_id`) REFERENCES `field_worker` (`user_id`) ON DELETE CASCADE ON UPDATE CASCADE,
  CONSTRAINT `fk_stage_field_worker_stage` FOREIGN KEY (`stage_id`) REFERENCES `stage` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

INSERT INTO `user` SET `id` = 1;
INSERT INTO `field_worker` SET `user_id` = 1;
INSERT INTO `stage` SET `id` = 1;
INSERT INTO `stage_field_worker` SET `stage_id` = 1, `field_worker_id` = 1;

After hours trying to understand what was wrong, I decided to make a test and modify the Stage::getFieldWorkers() method by removing the filtering Criteria:

public function getFieldWorkers() {
    return $this->fieldWorkers;
}

By simply doing that, the getUser() method started to return an entity of type User (as expected).

I am not a Doctrine ORM expert, but there seems to be something wrong with ArrayCollection filtering (matching() method)



 Comments   
Comment by Diogo Domanski de Souza [ 30/Jul/14 ]

The same problem occurs with QueryBuilder. For example:

StageRepository.php
<?php

namespace Entity;

use Doctrine\ORM\EntityRepository;

/**
 * Description of StageRepository
 *
 * @author domanski
 */
class StageRepository extends EntityRepository 
{

	public function findByFieldWorkerId($fieldWorkerId) {
		$qb = $this->getEntityManager()->createQueryBuilder()
			->select('s')
			->from('Entity\Stage', 's')
			->innerJoin('s.fieldWorkers', 'f')
			->innerJoin('f.user', 'u', \Doctrine\ORM\Query\Expr\Join::WITH, "u.deleteDate IS NULL AND u.id = :field_worker_id")
				->setParameter('field_worker_id', $fieldWorkerId);

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

If I try to iterate over the result of StageRepository::findByFieldWorkerId() and call toArray() of any element, I get the same error. I've even tried to remove the inner join with User entity from query:

	public function findByFieldWorkerId($fieldWorkerId) {
		$qb = $this->getEntityManager()->createQueryBuilder()
			->select('s')
			->from('Entity\Stage', 's')
			->innerJoin('s.fieldWorkers', 'f');

		return $qb->getQuery()->getResult();
	 }
Comment by Marco Pivetta [ 30/Jul/14 ]

I suspect that something is wrong in your mappings then...

Comment by Diogo Domanski de Souza [ 31/Jul/14 ]

Hi Marco,

The mappings are shown above. The only thing I did was to omit some entities/tables properties/columns that don't have to see with the associations - except the field worker (table and Entity) and stage_field_worker table, that are fully presented.

Maybe is important to notice that the field_worker table has only one column (user_id) that is primary key and foreign key (referencing user.id).

Thanks for you support

Comment by Marco Pivetta [ 31/Jul/14 ]

Diogo Domanski de Souza we can't debug this as it is. We'd need a functional test case to be added to https://github.com/doctrine/doctrine2/tree/0650bb954f5e8d05776f99abd04c81948413299f/tests/Doctrine/Tests/ORM/Functional/Ticket first, in order to see the failure

Comment by Diogo Domanski de Souza [ 31/Jul/14 ]

Marco Pivetta is there any documentation (tutorial, instructions, guide, etc) that I can use to learn how to write the functional test cases that I need?

Comment by Marco Pivetta [ 31/Jul/14 ]

Diogo Domanski de Souza you need to look at the existing ones.

For running the test suite:

git clone git@github.com:doctrine/doctrine2.git
cd doctrine2 
curl -s https://getcomposer.org/installer | php --
./composer.phar install
./vendor/bin/phpunit
Comment by Diogo Domanski de Souza [ 20/Aug/14 ]

I solved the problem by removing the property $id from FieldWorker entity and add annotation @ORM\Id to $user property (in this same entity).

I didn't understand why the previous definition of FieldWorker entity was not working. I have another similar relationship scenario, between 3 different entities, and the error does not occur.

Thanks to all for the support





[DDC-2277] [GH-570] Deprecation of PEAR/GIT/TAR autoloading Created: 04/Feb/13  Updated: 19/Oct/14  Resolved: 14/Feb/13

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

Type: Improvement Priority: Major
Reporter: Benjamin Eberlei Assignee: Marco Pivetta
Resolution: Fixed 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/570

Message:

Updates the test suite to use composer based autoloading



 Comments   
Comment by Benjamin Eberlei [ 14/Feb/13 ]

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

Comment by Marco Pivetta [ 14/Feb/13 ]

Merged

Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-2701] Collections in originalEntityData gets over written Created: 23/Sep/13  Updated: 19/Oct/14  Resolved: 19/Oct/14

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

Type: Bug Priority: Major
Reporter: Thomas Klein Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

I was trying to use the UnitOfWork::getOriginalEntityData method and i noticed that if there is a collection in that object, it changes in the uow original datas when i change it on my original object

In my case the collection is ManyToMany unidirectional

I think this happens because both the uow and the object work with the same reference to the collection
maybe adding a clone of the collection instead of the real one, i don't know if it is possible

Thank you for taking a look and for Doctrine!

Tom



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

This issue needs a test case in order to be reproduced.

Comment by Thomas Klein [ 20/Aug/14 ]

Here is how i get to this bug:

2 entities with a many to many unidirectional relation:

class Conversation
{
    // ...........

    /**
     * @ORM\ManyToMany(targetEntity="User")
     * @ORM\JoinTable(name="Conversations_To_Users",
     *      joinColumns={@ORM\JoinColumn(name="conversation_id", referencedColumnName="id")},
     *      inverseJoinColumns={@ORM\JoinColumn(name="user_id", referencedColumnName="id")}
     * )
     *
     * @var ArrayCollection
     */
    private $users;

    public function getUsers()
    {
        return $this->users();
    }

    // .....
}

class User
{
    // .....
}

Load the Conversation entity joined with the associated users: you get a Conversation entity with the users property filled with a PersistentCollection initialized. You can find this object in the originalEntityData property of the unit of work.

Then do:

$users = $conversation->getUsers();
$users->remove(0);

In the conversation object, the first user of the collection has been removed. In the unit of work, find the corresponding object in the originalEntityData array and you'll see that the first user has been removed from the collection too. It is then not possible to use the originalEntityData on joined collection to check for changes

Comment by Marco Pivetta [ 20/Aug/14 ]

Thomas Klein still not sure what the problem is:

$user         = new User();
$conversation = new Conversation();

$conversation->addUser($user);

$em->persist($user);
$em->persist($conversation);
$em->flush();
$em->clear();

$conversation1   = $em->find('Conversation', $conversation->id);
$usersCollection = $conversation->getUsers();

$usersCollection->remove(0);

var_dump($em->getUnitOfWork()->getOriginalEntityData($conversation1));

// what is failing after this point?

This is also how a test case should look like when thrown at the ORM functional test suite: https://github.com/doctrine/doctrine2/tree/v2.4.4/tests/Doctrine/Tests/ORM/Functional/Ticket

Comment by Thomas Klein [ 20/Aug/14 ]

Sorry i'll try to write a real test case asap ...

What is failing after this point ?

$origConversationData = $em->getUnitOfWork()->getOriginalEntityData($conversation1);
var_dump(count($origConversationData['users'])); // should be equal to 1, i get 0 ...

The only diff i can see with your example is that i'm not using find but a query with the relation fetched-joined in it so the collection is initialized

Comment by Marco Pivetta [ 20/Aug/14 ]

Collections are not tracked within entity data, but separately in the UoW

Comment by Thomas Klein [ 20/Aug/14 ]

Ok so i guess we can close this ticket if this is an expected behavior ...

In your last comment, did you mean:
Collections are not tracked within entity data, but each element of the collection is tracked separately in the UoW ?

Anyway thanks for your help

Comment by Marco Pivetta [ 19/Oct/14 ]

I mean that collections are tracked by specific properties/states in the UoW: https://github.com/doctrine/doctrine2/blob/9bf8f6ed4cc6590def5b5e8ba739ecdfa62fb717/lib/Doctrine/ORM/UnitOfWork.php#L180-L192

Yes, collection items are still single entities tracked in the UoW





[DDC-3263] setFetchmode for ClassMetaData temorarily instead of Query Created: 21/Aug/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

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

Type: Improvement Priority: Minor
Reporter: Andreas Dyballa Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

SetFetchmode is now woriking in AbstractQuery.

Why dont implement setFetchMode and perhaps further temporarily changes in an ClassMetadata-managing Object. Perhaps to work with a temporarily copy to allow a reset after some action.



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

Contextual changes in the entire UoW can lead to hard to predict situation that we don't want nor need to implement, as they represent additional complexity.





[DDC-3261] Bad link in 34.3 Advanced Configuration - Connection Options Created: 20/Aug/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Documentation
Affects Version/s: None
Fix Version/s: 2.5

Type: Documentation Priority: Minor
Reporter: Matthew Turland Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: documentation, orm


 Description   

The link to the DBAL section from 34.3 Advanced Configuration - Connection Options results in a 404 HTTP response. This line appears to be responsible.

Link URL as it appears in the current documentation:
http://docs.doctrine-project.org/dbal/2.0/docs/reference/configuration/en






[DDC-3264] setFetchMode Signature and Documentation Created: 21/Aug/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

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

Type: Improvement Priority: Minor
Reporter: Andreas Dyballa Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

The signature in AbstractQuery should be boolean for fetchmode and the documentation on
http://docs.doctrine-project.org/en/2.1/reference/dql-doctrine-query-language.html
setFetchMode(...,"EAGER"); is not according to the signature.
This is confusing.



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

2.2 is a very old version of the ORM which we don't support anymore. The new documentation is at http://docs.doctrine-project.org/en/latest/reference/dql-doctrine-query-language.html





[DDC-2445] [GH-665] oo Add Null in ScalarExpression Created: 12/May/13  Updated: 19/Oct/14  Resolved: 26/May/13

Status: Resolved
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: Invalid Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of vahid-sohrabloo:

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

Message:



 Comments   
Comment by Doctrine Bot [ 22/May/13 ]

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-2356] [GH-619] [DDC-2090] Fix MultiTableUpdateExecutor with query cache Created: 17/Mar/13  Updated: 19/Oct/14  Resolved: 17/Mar/13

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

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


 Description   

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

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

Message:

http://www.doctrine-project.org/jira/browse/DDC-2090



 Comments   
Comment by Benjamin Eberlei [ 17/Mar/13 ]

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

Comment by Fabio B. Silva [ 17/Mar/13 ]

Merged : https://github.com/doctrine/doctrine2/commit/60b8bc63a1a4819cf112cfbbc7cca06b5792aba6

Comment by Doctrine Bot [ 21/Aug/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-2446] [GH-666] [DDC-2429] Fix xsd definition Created: 13/May/13  Updated: 19/Oct/14  Resolved: 26/May/13

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

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


 Description   

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

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

Message:

http://www.doctrine-project.org/jira/browse/DDC-2429



 Comments   
Comment by Doctrine Bot [ 26/May/13 ]

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

Comment by Doctrine Bot [ 21/Aug/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-3304] [EntityGenerator] Embeddables properties and methods are broken Created: 11/Sep/14  Updated: 19/Oct/14  Resolved: 12/Sep/14

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

Type: Improvement Priority: Major
Reporter: Phansys Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: embeddables, entityGenerator, generation, mapping, orm

Issue Links:
Dependency
depends on DDC-3307 [GH-1135] [DDC-3304] Add support for ... Resolved

 Description   

EntityGenerator creates broken properties for embeddables. Given the example classes exposed in http://docs.doctrine-project.org/en/latest/tutorials/embeddables.html (User, Address), EntityGenerator creates wrong associations in User entity. Instead of this:

```php
/**

  • Address
    *
  • @var Address
    */
    private $address;
    ```

I get this:
```php
/**

  • Address.street
    *
  • @var string
    */
    private $address.street;
    /**
  • Address.postalCode
    *
  • @var string
    */
    private $address.postalCode;
    /**
  • Address.city
    *
  • @var string
    */
    private $address.city;
    /**
  • Address.country
    *
  • @var string
    */
    private $address.country;
    ```

And the same for its getters and setters.
I'll try to do a PR when I found a way to solve this.



 Comments   
Comment by Steve Müller [ 11/Sep/14 ]

Phansys which version of ORM are you using? If you are using latest master, this might be related to PR: https://github.com/doctrine/doctrine2/pull/1105
It looks like it broke the EntityGenerator. Can you confirm?

Comment by Phansys [ 11/Sep/14 ]

Confirmed @deeky666, on rev d9b43dc6492b163fc46f40c0555e2a7015ef5b68 (https://github.com/doctrine/doctrine2/tree/d9b43dc6492b163fc46f40c0555e2a7015ef5b68).
Thank you!

Comment by Phansys [ 11/Sep/14 ]

I've tried with rev 8a3def097f9ebd773ee298f5611ce8bf7007fa7e (previous to PR#1105) and the result is the same broken structure.

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

Phansys thanks for your feedback. I will see if I have time tomorrow to look into this issue.

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

Had a quick look into the issue and recognized that embeddables are not taken into account at all at the moment. Working on a solution...

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

Patch provided in PR: https://github.com/doctrine/doctrine2/pull/1135

Comment by Doctrine Bot [ 12/Sep/14 ]

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

Comment by Doctrine Bot [ 12/Sep/14 ]

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

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

Fixed in commit: https://github.com/doctrine/doctrine2/commit/f12c311a795b69a5f4853b079b3f8ad2c9867181

Comment by Phansys [ 13/Sep/14 ]

Thanks Steve Müller.

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-3249] [GH-1105] Add support for nesting embeddables Created: 11/Aug/14  Updated: 19/Oct/14  Resolved: 22/Aug/14

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed 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/1105

Message:

This is a possible approach towards adding support for nesting embeddables (embeddables inside embeddables). I'm not sure whether this implementation is the best solution but I think it is something to start with. It seems to work flawlessly so far but I'm not sure if I missed something, so any feedback is welcome



 Comments   
Comment by Doctrine Bot [ 21/Aug/14 ]

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

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

Fixed in commit: https://github.com/doctrine/doctrine2/commit/400acad53355f24137e18d5cd55ccf6ff828cfbe

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-3205] [DX] Interactive Management Command Created: 05/Jul/14  Updated: 19/Oct/14

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

Type: New Feature Priority: Minor
Reporter: Ryan Weaver Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Duplicate
is duplicated by DDC-3357 [GH-1165] [DDC-3205] #1120 - metadata... Resolved

 Description   

Hi guys!

This is part of the Symfony Developer Experience Initiative, which I hope can help Doctrine as well . This is a vision for a console tool to help visualize and manage your Doctrine entities. There are so many options and configuration that I think sometimes either (A) people don't even realize what options are available to them or (B) it's difficult to set everything up correctly (especially with relationships).

Imagine an interactive command that did things like:

  • listed your entities
  • listed fields in your entities (and their options, nullable, unique, etc)
  • Allowed you to change field options (e.g. change a field from nullable true to false
  • Allowed you to see your relationships and change options (cascade, JoinColumn stuff, etc)
  • Allowed you to setup relationships or setup the inverse side of a one-sided relationship
  • Added getters/setters
  • Generated helper methods into repositories (e.g. a method to create a query builder that joins a Product over to ProductImages after creating that relationship).

Does anyone see any issues with this? Obviously, this is HUGE, but it wouldn't need to start huge - it could start simply with some visualization and move from there. I think this could bring down the barrier to entry tremendously, and offer (via generation and visualization) some of the benefits of AR magic without that darn magic .

Thanks!



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

TL;DR: dumping details, yes please! modifying files/mappings, no-go.

A couple of things here:

  • listing entities is already available, see orm:info
  • listing all fields and additional details may be useful as an addition to orm:info via a flag. Implementation is also trivial
  • changing mappings via CLI - I'm really against this proposal. I've already tried getting rid of anything codegen-related from the symfony documentation, and I would not want codegen to land in the ORM. Mappings may come from annotations, from xml configs, from yaml or plain PHP files. They may also be processed by listeners and look completely different from the file counterparts. No, let's stay away from any ORM-driven mapping modification.
  • adding getters/setters, generating repositories, adding fields/associations: Doctrine's codegen is actually ONLY meant to provide an easy migration from a legacy DB to ORM entities+mappings, and we're also trying to get away from it in core.

Note that for mappings there's http://www.pulpo18.com/, which eases the path for newcomers. I also developed something for the ZF2 packages (which I must move to a separate library), see http://stackoverflow.com/a/14574952/347063





[DDC-2279] [GH-571] Update lib/Doctrine/ORM/EntityRepository.php Created: 05/Feb/13  Updated: 19/Oct/14  Resolved: 12/Mar/13

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

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

Issue Links:
Reference
relates to DBAL-947 [GH-634] Transaction object definition Open

 Description   

This issue is created automatically through a Github pull request on behalf of flo-ITN:

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

Message:

Add "indexby" missing parameter that permit an "index by" easily.

Ex :��
#Acme\AcmeBundle\Repository
#Before
public function findAllIndexById()

{ �� �� $qb = $this->_em->createQueryBuilder() �� �� �� �� �� �� �� �� �� �� ->select('root') �� �� �� �� �� �� �� �� �� �� ->from('Acme', 'root', 'root.id'); �� �� /*...*/ }

#After
public function findAllIndexById()

{ �� �� $qb = $this->createQueryBuilder('root','root.id'); �� ����/*...*/ }

 Comments   
Comment by Doctrine Bot [ 23/Aug/14 ]

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





[DDC-3270] abstract class database entity generation Created: 23/Aug/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

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

Type: Bug Priority: Minor
Reporter: Yan Ni Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: mysql, orm
Environment:

WAMP symfony2



 Description   

I create an abstract class A using @ORM annotations, then create class B which is a subclass of class A. When I use these to update the mysql database, however, a table for class A was also generated, which shouldn't have happened(because class A is an abstract class).



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

abstract types in the ORM are called MappedSuperclass}}es. The fact that a class is {{abstract doesn't mean that it has no concrete table representing it.





[DDC-3273] EntityGenerator writes @ORM\Table annotation for mapped superclass Created: 26/Aug/14  Updated: 19/Oct/14

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

Type: Bug Priority: Minor
Reporter: Jakab Adam Balazs Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: generation, orm, tools
Environment:

not relevant



 Description   

file /doctrine/orm/lib/Doctrine/ORM/Tools/EntityGenerator.php method: generateTableAnnotation returns @ORM\Table annotation even for mapped superclass entities. Since classes with annotation @ORM\MappedSuperclass are only to be extended and will NOT have a database table associated to them they should not have '@ORM\Table' annotation at all.
It would be enough to wrap the method body with `if ($metadata->isMappedSuperclass)

{ ... }

`.






[DDC-3283] [GH-1125] Update improving-performance.rst Created: 29/Aug/14  Updated: 19/Oct/14  Resolved: 30/Aug/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

Add change tracking policies chapter



 Comments   
Comment by Doctrine Bot [ 29/Aug/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-2352] [GH-615] Update SqlWalker.php Created: 15/Mar/13  Updated: 19/Oct/14  Resolved: 19/Oct/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: DQL
Affects Version/s: 2.3.5, 2.4.6
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: aliases, escaping, postgresql, query


 Description   

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

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

Message:

Always be sure that only a-z characters are used for table alias, otherwise use generic "t" for "table"



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

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-2362] [GH-624] Fix getSQLTableAlias for postgre camelized table name Created: 22/Mar/13  Updated: 19/Oct/14  Resolved: 01/May/13

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

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


 Description   

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

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

Message:

In postgreSQL with old databases we can have camelized model names to query on we need to add quote around the table name like :

```

  • @ORM\Table(name="""someThing""")
    ```

But when query is built the alias taken will be `"` this fix will find the good alias to use enabling to query camelized tables



 Comments   
Comment by Benjamin Eberlei [ 22/Mar/13 ]

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

Comment by Benjamin Eberlei [ 01/May/13 ]

PR was fixed in favor of Doctrine ORM GH-615

Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-3271] Impossible to set-up Two relations one-to-one which share the same target Created: 25/Aug/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

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

Type: Bug Priority: Major
Reporter: Grégoire Pineau Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

I reproduced my issue in a SF2 standard edition.

https://github.com/lyrixx/symfony-standard/blob/doctrine-many/test.php

So basically:

I have a "dude" table, with 2 FK: "delivery_address" and "billing_address".
But I'm not able to set-up doctrine to make it work, because when I set-up
the "Address" Entity, doctrine add a "unique" constraint on this table.
So I can insert one of the two addresses, but not two addresses.



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

This is actually how one-to-one works: you are probably looking for a different association type here.





[DDC-2456] [GH-669] Fixed generating column names for self referencing entity. Created: 17/May/13  Updated: 19/Oct/14  Resolved: 26/May/13

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

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


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 26/May/13 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-3350] [GH-1160] #1159 - multiple entity managers per repository factory should be supported Created: 13/Oct/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed 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/1160

Message:



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

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

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

Fixed as of https://github.com/doctrine/doctrine2/commit/06b5c847287ab4dec7c8a758be0f683cbbe3946d





[DDC-2458] [GH-671] [DDC-2435] Fix column name with numbers and non alphanumeric characters. Created: 17/May/13  Updated: 19/Oct/14  Resolved: 17/May/13

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

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


 Description   

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

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

Message:

http://www.doctrine-project.org/jira/browse/DDC-2435



 Comments   
Comment by Doctrine Bot [ 17/May/13 ]

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

Comment by Fabio B. Silva [ 17/May/13 ]

Merged : https://github.com/doctrine/doctrine2/commit/c9d9b68fa9937218aad05dfca4b3f96b409cfc8e

Comment by Doctrine Bot [ 29/Aug/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-3323] Add user managed parameters bag to UnitOfWork Created: 24/Sep/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

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

Type: Improvement Priority: Trivial
Reporter: Krzysztof Lechowski Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

User Story:
1. User has Article:Tags entities.
2. There is sort order attribute of a tag.
3. after any tag is removed, sort orders should be recalculated.

The intuitive place for it is postRemove, but technically we don't want to do any flushes in LifeCycle event. Below suggested solution is pass the handling of sort orders update to postFlush. For this sake postFlush needs to receive information from postRemove.

No global state is good idea I have 2 candidates:
1. Passet around event args
2. Unit of Work.

I'd prefer UnitOfWork because it's of more general use and more logical. This kind of information is unit-of-work context related. I'd like to call $unitOfWork->setParam('param_name', $value); and $unitOfWork->getParam('param_name');

Another person who stumbled upon the same situation, not sure how he handled it:

http://stackoverflow.com/questions/13095083/symfony2-doctrine2-throwing-index-error-when-flushing-the-entity-manager#answer-16701360



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

This doesn't seem to be the responsibility of the UoW: Won't be implemented.





[DDC-3325] No exception thrown when passing invalid option to mapXToY() in ClassMetadataInfo Created: 25/Sep/14  Updated: 19/Oct/14

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

Type: Bug Priority: Minor
Reporter: Thomas Konrad Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mapping, orm
Environment:

Symfony2, Windows 7, PHP 5.4



 Description   

I recently ran into the problem that I wrongly specified the `joinColumn` option passed to the method `mapManyToOne` in the `ClassMetadataInfo` class:

    $metadata->mapManyToOne(array(
        // ...
        'joinColumn'   => array(
            'name' => 'column_id',
        )
    ));

This would be the intuitive way to define that mapping, as with Annotations it is also called `JoinColumn` (but yeah I know, there could possibly be multiple `JoinColumn` definitions). The right way to do it is:

    $metadata->mapManyToOne(array(
        // ...
        'joinColumns'   => array(array(
            'name' => 'column_id',
        ))
    ));

The actual bad experience that I had as a developer here is that no exception was through even though I had definitely passed a wrong configuration option to the mapping function. In fact, nothing happended, the `joinColumn` option was just ignored. It would be great in this case if an exception would be thrown so that it is clear to the developer that there is something wrong.

Thanks!






[DDC-3326] [GH-1148] [DWEB-118] Fixed small typo in documentation about extra lazy associations Created: 26/Sep/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

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

Type: Documentation Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

Fixed small documentation issue http://www.doctrine-project.org/jira/browse/DWEB-118



 Comments   
Comment by Doctrine Bot [ 27/Sep/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-3329] Comment on clumn is passed when creating self-reference association Created: 28/Sep/14  Updated: 19/Oct/14

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

Type: Bug Priority: Minor
Reporter: Steve Todorov Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm
Environment:

PostgreSQL 9.1, possibly other databases as well.



 Description   

The example below will pass the comment from the column group_id to parent_id. Unfortunately that is not what I would like because the comment would confuse that parent_id has the same purpose as group_id which is not the case.

Group.php
class Group {

    /**
     * @var integer
     *
     * @ORM\Id
     * @ORM\Column(name="group_id", type="integer", options={"comment" = "This column is a relation to atable.z, btable.y, rtable.k, or whatever long comment we have here."})
     * @ORM\GeneratedValue(strategy="IDENTITY")
     */
    private $id;

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

    /**
     * @var integer
     *
     * @ORM\JoinColumn(name="parent_id", referencedColumnName="group_id", nullable=true)
     * @ORM\ManyToOne(targetEntity="Acme\MyBundle\Entity\Group")
     */
    private $parent;

    /**
     * Get id
     *
     * @return integer
     */
    public function getId() {
        return $this->id;
    }

    /**
     * Get name
     *
     * @return string
     */
    public function getName() {
        return $this->name;
    }

    /**
     * Set name
     *
     * @param string $name
     *
     * @return Group
     */
    public function setName( $name ) {
        $this->name = $name;

        return $this;
    }

    /**
     * Get parent
     *
     * @return Group
     */
    public function getParent() {
        return $this->parent;
    }

    /**
     * Set parent
     *
     * @param Group $parent
     *
     * @return Group
     */
    public function setParent( Group $parent ) {
        $this->parent = $parent;

        return $this;
    }
}


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

Steve Todorov can you rephrase the issue? What's the DDL for that table? And What exactly is broken about it?





[DDC-3331] DQL parsing fail when using COUNT with "Simple Derived Identity" primary key Created: 29/Sep/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

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

Type: Bug Priority: Major
Reporter: Mickael Zhu Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: bidirectional, count, onetoone, parser
Environment:

Mac osx Maverick
PHP 5.5.13
Nginx 1.6.0
Mysql 5.6.19



 Description   
Member.php

namespace DoctrineOrmTest\Assets\Entity;

use Doctrine\ORM\Mapping as ORM;

/**
 * @ORM\Entity
 * @ORM\Table(name="member")
 */
class Member
{
    /**
     * @ORM\Id
     * @ORM\Column(type="integer");
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;

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

    /**
     * @var Student
     *
     * @ORM\OneToOne(targetEntity="DoctrineOrmTest\Assets\Entity\Student", mappedBy="member")
     */
    protected $student;

}

Student.php

namespace DoctrineOrmTest\Assets\Entity;

use Doctrine\ORM\Mapping as ORM;

/**
 * @ORM\Entity
 * @ORM\Table(name="student")
 */
class Student
{
    /**
     * @var Member
     *
     * @ORM\Id
     * @ORM\OneToOne(targetEntity="DoctrineOrmTest\Assets\Entity\Member")
     * @ORM\JoinColumn(name="id", referencedColumnName="id", nullable=false)
     */
    private $member;
}

When I use a oneToOne relation as primary key, the following dql request fail :

SELECT COUNT(a) FROM DoctrineOrmTest\Assets\Entity\Student a

I have the following message :

[Semantical Error] line 0, col 13 near 'a) FROM DoctrineOrmTest\Assets\Entity\Student': Error: Invalid PathExpression. Must be a StateFieldPathExpression

I can fix it with this workaround

SELECT COUNT(a.member) FROM DoctrineOrmTest\Assets\Entity\Student a

But it mess with one of my auto-generation script.



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

You can just COUNT(a.id) here. I don't really see what the problem is.

If you look at the EBNF at http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/dql-doctrine-query-language.html#ebnf, your current DQL is indeed invalid.

Comment by Marco Pivetta [ 19/Oct/14 ]

To clarify:

AggregateExpression ::= ("AVG" | "MAX" | "MIN" | "SUM" | "COUNT") "(" ["DISTINCT"] SimpleArithmeticExpression ")"

A SimpleArithmeticExpression boils down to a set of ArithmeticPrimary, which is:

ArithmeticPrimary          ::= SingleValuedPathExpression | Literal | "(" SimpleArithmeticExpression ")"

And therefore does not support an entity alias, but only either a Literal (constant value, like a number or a string) or a SingleValuedPathExpression, which is indeed a field of your entity.





[DDC-2726] EventSubscriber PreUpdate Error Bug? Created: 06/Oct/13  Updated: 19/Oct/14  Resolved: 19/Oct/14

Status: Resolved
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: Nelson Ford Assignee: Marco Pivetta
Resolution: Incomplete Votes: 1
Labels: orm

Attachments: PNG File caca.png    

 Description   

Should this:

public function preUpdate(PreUpdateEventArgs $eventArgs)
{
    $entity = $eventArgs->getEntity();
    $em = $eventArgs->getEntityManager();
    $uow = $em->getUnitOfWork();

    if ($entity instanceof User) {
        if ($eventArgs->hasChangedField('finalStatus')) {
            $entity->setFinalStatusDate(new \DateTime('now'));
            $uow->recomputeSingleEntityChangeSet(
                $em->getClassMetadata("MyAdminBundle:User"),
                $entity
            );
        }
        if ($eventArgs->hasChangedField('membershipCode')) {
            $entity->setMembershipCodeDate(new \DateTime('now'));
            $uow->recomputeSingleEntityChangeSet(
                $em->getClassMetadata("MyAdminBundle:User"),
                $entity
            );
        }
    }
}

...result in this?

Catchable Fatal Error: Argument 3 passed to Doctrine\ORM\Event\PreUpdateEventArgs::__construct() must be an array, null given, called in /var/www/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php on line 995 and defined in /var/www/vendor/doctrine/orm/lib/Doctrine/ORM/Event/PreUpdateEventArgs.php line 47

I'm just setting a time stamp for two updated values. Dumping the 3rd argument in PreUpdateEventArgs.php on line 47 reveals an array of changes. I'm not sure if this is a bug or if I'm performing this simple operation incorrectly.



 Comments   
Comment by Marco Pivetta [ 17/Oct/13 ]

Can you write an integration test around it? Looks like the changeset is removed in a particular edge case, but it's hard to figure it out without a test.

Comment by Florin [ 29/Sep/14 ]

here, solve it

Comment by Marco Pivetta [ 19/Oct/14 ]

Missing test case





[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-3287] PreUpdateEventArgs need to extend Doctrine\Common\PreUpdateEventArgs Created: 29/Aug/14  Updated: 19/Oct/14

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

Type: Improvement Priority: Trivial
Reporter: Sebastian Kuhlmann Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: inheritance, orm


 Description   

Currently the inheritance tree of the EventArgs don't allow for creating event listeners that fit both ORM- and MongoDB-driven applications.

Doctrine\Common defines base classes for Lifecycle event arguments. Doctrine\ORM uses the common library and extends it's classes. So does MongoDB. If you wanted to write something that suits both ORM and MongoDB you should be able to rely on the Common-implementations.

The provided classes to extend:

  • Doctrine\Common\Persistence\Event\LifecycleEventArgs
  • Doctrine\Common\Persistence\Event\LoadClassMetadataEventArgs
  • Doctrine\Common\Persistence\Event\ManagerEventArgs
  • Doctrine\Common\Persistence\Event\OnClearEventArgs
  • Doctrine\Common\Persistence\Event\PreUpdateEventArgs

Checking the Github repository there is no common ground for the inheritance mechanism.

  • Doctrine\ORM\Event\LifecycleEventArgs extends Doctrine\Common\Persistence\Event\LifecycleEventArgs
  • Doctrine\ORM\Event\PreUpdateEventArgs extends Doctrine\ORM\Event\LifecycleEventArgs
  • Doctrine\ORM\Event\PreFlushEventArgs extends Doctrine\Common\EventArgs
  • Doctrine\ORM\Event\PostFlushEventArgs extends Doctrine\Common\EventArgs
  • Doctrine\ORM\Event\OnFlushEventArgs extends Doctrine\Common\EventArgs
  • Doctrine\ORM\Event\OnClearEventArgs extends Doctrine\Common\EventArgs

This needs to change and ORM\PreUpdateEventArgs as well as ORM\OnClearEventArgs need to extend the respective events from Doctrine\Common.



 Comments   
Comment by Sebastian Kuhlmann [ 23/Sep/14 ]

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

Comment by Christophe Coevoet [ 04/Oct/14 ]

All flush event args should be updated to extend ManagerEventArgs (and marking their getEntityManager method as deprecated too)

Comment by Christophe Coevoet [ 04/Oct/14 ]

to be clear, the change on PreUpdateEventArgs cannot be done until 3.0 because of BC

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[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-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-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-1873] [GH-373] Grammar fix for composer.json file Created: 12/Jun/12  Updated: 19/Oct/14  Resolved: 22/Jun/12

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

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:



 Comments   
Comment by Benjamin Eberlei [ 13/Jun/12 ]

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

Comment by Guilherme Blanco [ 22/Jun/12 ]

PR was merged.

Comment by Doctrine Bot [ 13/Dec/13 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-3338] [GH-1153] Add max. This is just example. Created: 06/Oct/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

Status: Resolved
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: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

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

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

Message:



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

Won't be fixed, as this issue requires major changes in collection interfaces (not yet scheduled)





[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-3318] [GH-1143] Fixed a bug so that a versioned entity with a oneToOne id can be created Created: 23/Sep/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: hydration, hydrator, onetoone, unitofwork, versioned


 Description   

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

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

Message:

  • Fixed the basic entity persister so that versioned OneToOne entities can be created
  • Created an IdentifierConverter utility class
  • Moved the logic for the flatten identifier method into the new utility class
  • Replaced calls for private flattenIdentifier to use new utility
  • Added appropriate unit tests


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

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





[DDC-1858] LIKE and IS NULL operators not supported in HAVING clause Created: 07/Jun/12  Updated: 19/Oct/14  Resolved: 08/Sep/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: DQL
Affects Version/s: 2.2.2
Fix Version/s: 2.5
Security Level: All

Type: Improvement Priority: Major
Reporter: PETIT Yoann Assignee: Guilherme Blanco
Resolution: Fixed Votes: 4
Labels: None
Environment:

Win7, Mysql



 Description   

The LIKE and IS NULL operators are not supported in HAVING clause.

Work:
SELECT _a.id, count(_photos) as uuuu FROM Acme\CoreBundle\Entity\Member _a LEFT JOIN _a.photos _photos GROUP BY _a HAVING uuuu in (3,6)
SELECT _a.id, count(_photos) as uuuu FROM Acme\CoreBundle\Entity\Member _a LEFT JOIN _a.photos _photos GROUP BY _a HAVING uuuu = 3
SELECT _a.id, count(_photos) as uuuu FROM Acme\CoreBundle\Entity\Member _a LEFT JOIN _a.photos _photos GROUP BY _a HAVING uuuu >= 3
...

Don't work:
SELECT _a.id, count(_photos) as uuuu FROM Acme\CoreBundle\Entity\Member _a LEFT JOIN _a.photos _photos GROUP BY _a HAVING uuuu LIKE 3
SELECT _a.id, count(_photos) as uuuu FROM Acme\CoreBundle\Entity\Member _a LEFT JOIN _a.photos _photos GROUP BY _a HAVING uuuu IS NULL
SELECT _a.id, count(_photos) as uuuu FROM Acme\CoreBundle\Entity\Member _a LEFT JOIN _a.photos _photos GROUP BY _a HAVING uuuu IS NOT NULL



 Comments   
Comment by Marco Pivetta [ 08/Jun/12 ]

I think this has already been fixed in latest master and 2.1.7. Could you just give it a try and eventually confirm?

Comment by PETIT Yoann [ 08/Jun/12 ]

Already try with 2.17, 2.20 and 2.2.2. This hasn't been fixed.

Comment by Bdiang [ 04/Jul/12 ]

I'm also having this issue (2.2.2). Is there any workaround for this?

Column aliases also are not supported in HAVING clause:

$qb->select('p', 'COUNT(p.field) as FieldCount')
            ->from('Entity', 'p')
            ->groupBy('p.id')
   ->having('FieldCount IS NULL')

Above code causes error "FieldCount is not pointing to class" and IS NULL causes "Expected =, <, <=, <>, >, >=, !=, got 'IS'"

Comment by Benjamin Eberlei [ 29/Aug/12 ]

Its not a bug as the EBNF says that this is not possible.

Guilherme Blanco Is this something we should support or not?

Comment by Christophe Coevoet [ 29/Aug/12 ]

Another place where it is not supported is in the CASE clause.

I would vote +1 for supporting it

Comment by Benoit Jacquemont [ 10/Jun/13 ]

@Benjamin Eberlei
The EBNF seems to indicate that any search condition is valid on the HAVING clause:
http://savage.net.au/SQL/sql-99.bnf.html#having%20clause

If you look at the Search condition ( http://savage.net.au/SQL/sql-99.bnf.html#search%20condition ), the NULL predictate ( http://savage.net.au/SQL/sql-99.bnf.html#null%20predicate ) seems to be a part of it.

Maybe I'm misinterpreting the BNF ?

And if not, any idea of a targeted release for the fix ?

Comment by Guilherme Blanco [ 11/Jun/13 ]

Benjamin Eberlei it seems to be SQL-92 compatible. The improvement is valid.
We should support it. I'll take a look into this. =)

Cheers,

Comment by Guilherme Blanco [ 11/Jun/13 ]

Functionality is already implemented in master as per coverage added in here:

https://github.com/doctrine/doctrine2/commit/4e99c5c127c810bf63c9a371f87f0ff5c82e3e79

Closing the ticket.

Comment by Litz Ouille [ 14/Aug/13 ]

At the moment, only the `HAVING field IS [NOT] NULL` is working.

The `HAVING field LIKE` as in
(SELECT _a.id, count(_photos) as uuuu FROM Acme\CoreBundle\Entity\Member _a LEFT JOIN _a.photos _photos GROUP BY _a HAVING uuuu LIKE 3)
still does not work.

Comment by Guilherme Blanco [ 19/Aug/13 ]

I implemented support for ResultVariable in LikeExpression as of https://github.com/doctrine/doctrine2/commit/43fc8bafa766b4e924b05c74825dd30393a17f06

Comment by Litz Ouille [ 19/Aug/13 ]

It works. Thanks !

Comment by Benjamin Eberlei [ 08/Sep/13 ]

Assigned fix version

Comment by Nikolay Baklicharov [ 06/Oct/14 ]

Guilherme Blanco Please backport to released version. This is very serious issue, especially when you make search queries.

Comment by Marco Pivetta [ 06/Oct/14 ]

Nikolay Baklicharov this is an improvement, not a bug fix, therefore there will be no backporting.

Comment by Nikolay Baklicharov [ 07/Oct/14 ]

Marco Pivetta Then what workaround I can use? Lets say I do leftJoin on table and do AVG(object.value) > 3 OR object IS NULL. I.e. I want all results that have avg value higher than 3 and also results that do not have object at all?

Comment by Marco Pivetta [ 07/Oct/14 ]

The current workaround is bumping the ORM version, which may or may not be a problem depending on your stability policies and how much you need this feature.

Otherwise, NativeSQL until the functionality is available in a stable release.

Comment by Nikolay Baklicharov [ 07/Oct/14 ]

Marco Pivetta Not an option for the project. However I found workaround that I will share here in case someone come here from google search like me.

$queryBuilder->addSelect( 'COALESCE(AVG(ra.value), 0) AS HIDDEN averageRating' );
$queryBuilder->leftJoin( 'c.ratings', 'ra' );
$queryBuilder->andHaving( 'averageRating >= :avgRating' );
$queryBuilder->orHaving( 'averageRating = 0' );
$queryBuilder->setParameter( ':avgRating', $ratingFilter );




[DDC-3342] Join with child tables Created: 09/Oct/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

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

Type: New Feature Priority: Major
Reporter: Thomas Lallement Assignee: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates DDC-16 DQL Ignores properties of subclasses Closed

 Description   

Hi,

It could help a lot if we could simply join parent table with childs when the inheritance type is JOINED.

For example if you need to add clauses on child properties. For the moment we need to create sub queries to add clauses in it.



 Comments   
Comment by Thomas Lallement [ 09/Oct/14 ]

It would also be possible and useful to be able to sort on the DiscriminatorColumn





[DDC-16] DQL Ignores properties of subclasses Created: 15/Sep/09  Updated: 19/Oct/14  Resolved: 24/Feb/13

Status: Closed
Project: Doctrine 2 - ORM
Component/s: DQL
Affects Version/s: 2.0-ALPHA2
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Minor
Reporter: Avi Block Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 6
Labels: None

Issue Links:
Duplicate
is duplicated by DDC-1377 Doctrine doesn't understand associati... Closed
is duplicated by DDC-3342 Join with child tables Resolved

 Description   

I have a classes B and C which inherit from superclass A. I would like
to get a list of all A's but filter the list to ignore those in C
which have a property d set to 2.

select a from A where a.d == 2 fails because "d" is not a property of A.



 Comments   
Comment by Roman S. Borschel [ 31/Mar/10 ]

Thats indeed tricky. That syntax alone can, however, never work, because there might be several subclasses that have a field named "d", so Doctrine would not know which field you mean.

We might need special syntax for such constructs but I'm not sure it is worth it. If anyone has an idea, just shoot.

Alternatively, apart from using a native query, what about this DQL:

select a from A a where a.id not in (select c.id from C c where c.d = 2)
Comment by Benjamin Eberlei [ 01/Apr/10 ]

I am sorry, but isn't this sort of query a violation of object oriented programming, Accessing a Superclass A and checking for a property that exists on a certain child is not possible in any strict OO language without specific casting into the type beforehand.

Comment by Roman S. Borschel [ 01/Apr/10 ]

Thats why I said "we would need special syntax for such constructs", i.e. casting syntax

However, the alternative query I showed should work just fine for such purposes.

Comment by Menno Holtkamp [ 18/Jul/11 ]

+1 for this request.

When displaying data (stored in a database) to end-users using generated tables, server-side sorting and filtering on properties that belong to subclasses is a common task, for instance to provide the data presented in a JQuery Datatable: http://www.datatables.net.

For this purpose, DQL is great to generate the required queries dynamically. However, since properties of subclasses can currently not be 'accessed', sorting and filtering on these properties becomes impossible, or at least cumbersome to implement. Currently I have lifted/copied specific properties to a general 'value' property of the superclass, which CAN be used for ordering and filtering. Of course, this work-around significantly decreases the power of inheritance strategy in the originally envisioned model.

In Hibernate this seems to have been solved in HQL using downcasting, which seems a viable approach, but as Benjamin already mentioned not a best practice in a strict OO approach. Therefore a specific syntax might be required to hint on the to-be-expected casts:

For additional motivation of this subject, check a recent post of mine at the user groups: http://groups.google.com/group/doctrine-user/msg/caebf8139e06e01a

Comment by Avi Block [ 18/Jul/11 ]

Honestly I gave up on all of this a long time ago, and now use a CQRS approach. I make views, or denormalized tables for every view in my application, and just use straight SQL.

When I need to do creating or updating or whatever, I use doctrine.

Comment by Glen Ainscow [ 19/Jul/11 ]

I would like this as well (though my use case involves joining to the subclass).

Registration has one Opponent (superclass to Player and TeamSelection). I would like to count the number of registrations for a particular team within a specific tournament. For example:

SELECT COUNT(*)
FROM Registration r
INNER JOIN r.opponent CAST TeamSelection ts
INNER JOIN ts.team t
WHERE r.tournament = 1
AND t.name = "Team #1"
Comment by Glen Ainscow [ 19/Jul/11 ]

Thinking about this a bit more, it can actually improve query performance, as it would no longer be necessary to join the other subclasses. In other words, since you're casting the opponent to a TeamSelection, it's not necessary to join to the players table.

A cast should probably also restrict the result using the discriminator column, for example (SQL):

INNER JOIN opponents o ON o.id = r.opponent_d AND o.type = "TeamSelection"
Comment by Guilherme Blanco [ 15/Sep/11 ]

Possible solution:

SELECT p FROM CAST(Person AS User) p

Or:

SELECT a, p FROM Article a JOIN CAST(a.person AS User) p
Comment by Glen Ainscow [ 16/Sep/11 ]

If you're casting a Person (superclass) to a User (subclass), then shouldn't the alias be "u" and not "p"?

i.e. SELECT a, u FROM Article a JOIN CAST(a.person AS User) u

Comment by Benjamin Eberlei [ 16/Sep/11 ]

the alias is that, an alias, you can use whatever you want.

Comment by Glen Ainscow [ 16/Sep/11 ]

Yes I know that, I'm just making sure that I understand the syntax.

Comment by Jaka Jancar [ 18/Feb/12 ]

I just ran into a similar problem and am not sure the above cast solution would do.

I'm trying to do:

SELECT
    s
FROM
    Superclass s
WHERE
    s INSTANCE OF SubclassA OR
    s INSTANCE OF SubclassB AND s.foo = 'bar';

So I'd need to use CAST in a WHERE condition, not in the FROM/JOIN clause, e.g:

SELECT
    s
FROM
    Superclass s
WHERE
    s INSTANCE OF SubclassA OR
    s INSTANCE OF SubclassB AND (CAST s AS SubclassB).foo = 'bar';
Comment by Wladimir Coka [ 03/Apr/12 ]

Is there any workaround? Would be perfect if I could just:

 SELECT a, p FROM Article a JOIN CAST(a.person AS User) p 

(+1 for Guilherme Blanco possible solution)

Comment by Wladimir Coka [ 04/Apr/12 ]

I was trying a workaround:

Before executing the dql query, I change the mapping info of the association to the concrete type that I was going to use. Like this:

        $cmf = $this->em->getMetadataFactory();
        $class = $cmf->getMetadataFor("Article");
        $class->associationMappings["person"]["targetEntity"]="User";

But now my problem is that I'm actually using an inverse side (in query where this is needed), so when I change the targetEntity, the sql join that is generated, is using the table of the concrete class (User in this case) and not the base class (Person)

class Person {
...
	/**
	 * @OneToOne(targetEntity="Order",cascade={"persist"})
	 * @JoinColumn(name="order_id", referencedColumnName="orden_id")
	 */
	private $order;
...
}

class Order {
...
    /**
     * @OneToOne(targetEntity="Person", mappedBy="order")
     */
    private $person;
...
}

The SQL generated is joining as if the "user" table has orden_id field

Comment by Marco Pivetta [ 24/Feb/13 ]

I am closing this one.

The requirement of this issue is basically violating OO principles.

If you really need to filter across multiple child-entities in your inheritance, then try something as following instead:

SELECT
    r
FROM
    Root r
WHERE
    r.id IN (
        SELECT
            c.id
        FROM
            Child c
        WHERE
            c.field = :value
    )

Up-casting is not really a viable solution anyway, since it would be even more weird to cast in DQL and then have hydration still retrieve the root entity type.

Comment by Bogdan Yurov [ 17/Jul/14 ]

@Marco You are wrong. There is no way to do this. It is just not wise to deny a feature just because it violates OO principles when this is the only method.

There are usecases, when we have nothing to do. For example, we are searching through the whole table in STI. We use quick filters like "Like" so there is not need in difficult indexes/additional tables for them. We CAN NOT in ANY way overcome this limitation when we need to use fields of different classes.

This is certainly not a bug, when we may say "WONT FIX" and just ignore all those people who face it.

Comment by Marco Pivetta [ 17/Jul/14 ]

It is just not wise to deny a feature just because it violates OO principles when this is the only method.

We are working on an ORM (Object-Relational-Mapper), therefore Object-Orientation is first-class citizen and prioritized over everything else in the ORM.

There are usecases, when we have nothing to do.

There are use-cases for everything, but that doesn't mean that they should clutter the tool. This does not only apply to Doctrine ORM. An edge case functionality that has multiple workarounds and that cannot be implemented correctly within the tool does NOT need to land in the tool.

I provided a workaround that respects the OO and ORM rules and works also with the OO paradigm. Here is a pseudo-code description of what the DQL I pasted above does:

  • select all objects that are instance of Child by $someCriteria
  • select all objects that are instance of Root
  • iterate over Root instances and filter out those that are not in the results of the first selection

We CAN NOT in ANY way overcome this limitation when we need to use fields of different classes.

Yes you can: there's SQL. SQL is a "structured query language" that is weakly typed and allows this sort of operation natively. This is a problem of the SQL domain, and it should be solved with SQL whenever the DQL becomes too complex/limited. Don't try to stuff a feature that is only possible in the SQL domain into DQL just because they look similar.
They are not the same thing.

This is certainly not a bug, when we may say "WONT FIX" and just ignore all those people who face it.

We are not ignoring the problem: we just point you to the right scope/tools to solve it. DQL has one way of solving it, which may or may not be viable to you. SQL has another way of solving this same problem, and it's not going to be implemented in DQL because DQL is statically typed, and upcasts and type juggling are not going to land in DQL.

Comment by Bogdan Yurov [ 17/Jul/14 ]

If we provide a workaround, is there any way to merge it to master branch? What we can do to vote up this feature?

Comment by Marco Pivetta [ 17/Jul/14 ]

Bogdan Yurov we already tried looking into this multiple times.

The only "clean-ish" solution would be to support upcasting somehow, and the effort and complexity derived from it is not worth it.

Comment by Bogdan Yurov [ 17/Jul/14 ]

@ocramius
What about "CAST()" construction? You were talking about OO, but there are some languages, that could argue with you.

For example, Delphi. It supports casting manually to selected type (for example TObject -> TButton). Does it break best violates OO principles too? No, of course.
Another example is Java. It has exactly same language construction for exactly same purpose. Is doctrine more concentrated on OO principles than Java or Delphi?

Comment by Marco Pivetta [ 22/Jul/14 ]

Bogdan Yurov I think Guilherme Blanco is thinking of providing a cast syntax.





[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-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-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-2504] [GH-696] extra lazy joined test Created: 14/Jun/13  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 Padam87:

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

Message:

Hi,

This is just a bug report, not an actual PR, you don't have to merge.

When you have a JOINED inheritance, and you have another class, which is related to the parent class of the inheritance, and you only have an association for one of the child classes, EXTRA_LAZY fetch mode creates a fatal error, because it is not joining the parent table to the count query.

There are many ways around this fortunately, but I thought I should report it anyway.



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

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-3355] [GH-1164] [QueryBuilder] Remove unused method parameters to run on HHVM/PHP7 Created: 17/Oct/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: DQL
Affects Version/s: 2.3.5, 2.4.6
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: hhvm, querybuilder


 Description   

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

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

Message:

PHP5 treats the left part of an assignment to a method parameter as an independent local variable, while HHVM/PHP7 treats it as a reference to the method parameter. This leads to the value of the parameter being changed, which, in turn, causes func_get_args() to return not what is expected.

This commit is a part of the effort to make Symfony run flawlessly on HHVM. This issue causes a bunch of Symfony tests to fail on HHVM.

The master is currently broken, so the best thing I could do was to make sure the number of test failures remained the same after the change.

If possible, please merge this to version 2.2 used by Symfony 2.4.



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

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





[DDC-3356] Event/Entity Listener onFlush() works but not preFlush() Created: 18/Oct/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

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

Type: Bug Priority: Major
Reporter: Max Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: entity, event, flush, listener


 Description   

preFlush() example below don't do anything at all although it is 99% exactly the same as onFlush() which works as expected. Can anyone tell me what I am missing or what the reason is and the solution?

DEBUGGING TEST:

public function preFlush(PreFlushEventArgs $args)
{
    $em = $args->getEntityManager();
    $uow = $em->getUnitOfWork();
    echo '1';
    foreach ($uow->getScheduledEntityUpdates() as $entity) {
        echo '2';
        if ($entity instanceof User) {
            echo '3';
        }
    }
    exit;
}

DEBUGGING RESULT:

1 so $uow->getScheduledEntityUpdates() is an empty array!

services.yml
services:
    entity.event_listener.user:
        class:  Site\FrontBundle\EventListener\Entity\UserListener
        tags:
            - { name: doctrine.event_listener, event: preFlush }
            - { name: doctrine.event_listener, event: onFlush }

DOESN'T WORK - preFlush():

class UserListener
{
    public function preFlush(PreFlushEventArgs $args)
    {
        $em = $args->getEntityManager();
        $uow = $em->getUnitOfWork();

        foreach ($uow->getScheduledEntityUpdates() as $entity) {
            if ($entity instanceof User) {
                $userLog = new UserLog();
                $userLog->setDescription($entity->getId() . ' being updated.');

                $em->persist($userLog);
                $userLogMetadata = $em->getClassMetadata(get_class($userLog));
                $uow->computeChangeSet($userLogMetadata, $userLog);
            }
        }
    }
}

WORKS - onFlush():

class UserListener
{
    public function onFlush(OnFlushEventArgs $args)
    {
        $em = $args->getEntityManager();
        $uow = $em->getUnitOfWork();

        foreach ($uow->getScheduledEntityUpdates() as $entity) {
            if ($entity instanceof User) {
                $userLog = new UserLog();
                $userLog->setDescription($entity->getId() . ' being updated.');

                $em->persist($userLog);
                $userLogMetadata = $em->getClassMetadata(get_class($userLog));
                $uow->computeChangeSet($userLogMetadata, $userLog);
            }
        }
    }
}


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

The preFlush event is triggered BEFORE any entity changes were computed, therefore the "DOESN'T WORK" example case is invalid.





[DDC-2503] [GH-695] Implemented support for RepositoryFactory. Created: 14/Jun/13  Updated: 19/Oct/14  Resolved: 18/Jun/13

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

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


 Description   

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

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

Message:

This allows anyone to override the default behavior to load Repositories.



 Comments   
Comment by Doctrine Bot [ 14/Jun/13 ]

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

Comment by Fabio B. Silva [ 18/Jun/13 ]

Merged : https://github.com/doctrine/doctrine2/commit/7903a2b5139e51b5dd7ed5ae164f7e0f3685dea7

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-2500] [GH-692] Query\Parser: support for functions in ORDER BY clause Created: 12/Jun/13  Updated: 19/Oct/14  Resolved: 12/Jun/13

Status: Resolved
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: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 12/Jun/13 ]

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

Comment by Marco Pivetta [ 12/Jun/13 ]
ORDER BY SOME_FUNC()

is not portable across all vendors

Comment by Mr [ 31/Jul/13 ]

What about user defined functions?
It would be great to be able to include UDFs in the order by clause.

I have a sorting function that only needs to run on one column.

Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-2491] [GH-687] Fixed rendering Created: 06/Jun/13  Updated: 19/Oct/14  Resolved: 06/Jun/13

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

Type: Documentation Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

Fixed some broken rendering on http://docs.doctrine-project.org/en/latest/reference/yaml-mapping.html



 Comments   
Comment by Doctrine Bot [ 06/Jun/13 ]

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

Comment by Marco Pivetta [ 06/Jun/13 ]

Merged at https://github.com/doctrine/doctrine2/commit/5c7b98b2a990a1d7a6140e2c875f5ab6c3dc6f9f

Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-2466] [GH-676] Update UnitOfWork.php Created: 22/May/13  Updated: 19/Oct/14  Resolved: 22/May/13

Status: Resolved
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: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

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

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

Message:

Here, if a field (type date or datetime) is defined as id, I have an error because it's an object and not a string...

Can you please fix this bug ? Thank you.



 Comments   
Comment by Doctrine Bot [ 22/May/13 ]

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

Comment by Marco Pivetta [ 22/May/13 ]

Related: DDC-1209, DDC-1780

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-2501] [GH-693] Adding failing test for DDC-2214 Created: 12/Jun/13  Updated: 16/Oct/14  Resolved: 12/Jun/13

Status: Resolved
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: Marco Pivetta
Resolution: Duplicate 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/693

Message:

Parameters being bound to an SQL query should have the same type as
the identifier of the objects being bound to the placeholders of a
DQL query - this is currently broken with proxies, as this test
demonstrates.

This is a demonstration of DDC-2214(http://www.doctrine-project.org/jira/browse/DDC-2214)



 Comments   
Comment by Marco Pivetta [ 12/Jun/13 ]

Duplicate of DDC-2214

Comment by Doctrine Bot [ 12/Jun/13 ]

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

Comment by Doctrine Bot [ 16/Oct/14 ]

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

Comment by Doctrine Bot [ 16/Oct/14 ]

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





[DDC-3353] [GH-1163] Update xml-mapping.rst Created: 16/Oct/14  Updated: 16/Oct/14  Resolved: 16/Oct/14

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

Type: Documentation Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

Fixed closing entity tag.



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

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





[DDC-2477] [GH-681] Sequence generator fix Created: 29/May/13  Updated: 16/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 lighthart:

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

Message:

$this->_sequenceName=$em->getClassMetadata(get_class($entity))->sequenceGeneratorDefinition['sequenceName'];

The sequence generator does not read the class metadata, so if there is table remapping via event listeners, any new entity won't have the appropriate changes in table names.

This pull request adds a remap the Sequence Generator to read the class metadata to determine the sequence name if there is an entity passed to the generate function.

Tests: 1854, Assertions: 6224, Skipped: 96.



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

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

Comment by Doctrine Bot [ 16/Oct/14 ]

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





[DDC-2498] [GH-690] [DDC-2494] Apply type conversion to meta columns Created: 11/Jun/13  Updated: 16/Oct/14  Resolved: 12/Jun/13

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

http://www.doctrine-project.org/jira/browse/DDC-2494



 Comments   
Comment by Doctrine Bot [ 12/Jun/13 ]

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

Comment by Marco Pivetta [ 12/Jun/13 ]

Merged at https://github.com/doctrine/doctrine2/commit/6937061b23ec4de63081efac800415e09dcbcb4f

Comment by Doctrine Bot [ 14/Jul/14 ]

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

Comment by Doctrine Bot [ 16/Oct/14 ]

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

Comment by Doctrine Bot [ 16/Oct/14 ]

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





[DDC-2424] Removing an inherited entity via a delete cascade constraint does not remove the parent row Created: 02/May/13  Updated: 15/Oct/14

Status: Awaiting Feedback
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: 2.3.3, 2.4.6
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Bruno Jacquet Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 3
Labels: inheritance, postgresql
Environment:

Mysql 5.1.66 / Symfony 2.2.1



 Description   

For a parent class:

/**
 * @ORM\Entity
 * @ORM\Table(name="Base")
 * @ORM\InheritanceType("JOINED")
 * @ORM\DiscriminatorColumn(name="discr", type="string")
 * @ORM\DiscriminatorMap({"child1" = "Child1", "child2" = "Child2"})
 */

and simple Child1 & Child2 entities.

With another entity (let's call it ExternalEntity) having a bidirectional OneToOne relation owned by Child1:

class Child1 extends Base
{
  /**
   * @ORM\OneToOne(targetEntity="ExternalEntity", inversedBy="xxx")
   * @ORM\JoinColumn(onDelete="CASCADE", nullable=false)
   */
   private theForeignKey;
}

Enough for the context.
The symptoms:

$em->remove(instanceOfExternalEntity);

removes the ExternalEntity row and the Child1 row. But a dangling row in the Base table is still there for the now inexistent Child1 instance.

Though, a manual delete of either the associated Child1 OR Base row and then the ExternalEntity works.

The problem with the cascading deletion of the parent seems to be only present when deleting through a MYSQL cascading delete from another row which has a foreign key on a child. (Not tested with a foreign key on the parent though)



 Comments   
Comment by Benjamin Eberlei [ 04/May/13 ]

Can you show the CREATE TABLE and FOREIGN KEY statements of all the tables involved? It seems the cascade of the foreign keys is not propagated between multiple tables?

Comment by Bruno Jacquet [ 06/May/13 ]

CREATE TABLE Base (id INT AUTO_INCREMENT NOT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB;
CREATE TABLE Child1 (id INT NOT NULL, foreignKey INT NOT NULL, UNIQUE INDEX UNIQ_179B6E88E992F5A (foreignKey), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB;

ALTER TABLE Child1 ADD CONSTRAINT FK_179B6E88E992F5A FOREIGN KEY (foreignKey) REFERENCES ExternalEntity (id) ON DELETE CASCADE;
ALTER TABLE Child1 ADD CONSTRAINT FK_179B6E8BF396750 FOREIGN KEY (id) REFERENCES Base (id) ON DELETE CASCADE;

Comment by Bruno Jacquet [ 06/May/13 ]

The problem is that, the SQL model never explicitely tells the DB to delete the corresponding Base when Child1 gets removed. It looks like it is handled by the doctrine entity manager layer and not the actual DB engine (Base has no on delete cascade nor foreign key to its children).
So only doctrine can add the logic here because it knows the entity schema. But in this case, when it is deleted from another table, it looks like the special treatment is not triggered.

Comment by Bruno Jacquet [ 06/May/13 ]

Maybe using

cascade={"remove"}

, instead of

onDelete="CASCADE"

to force the cascading process to be handled by doctrine would workaround the bug... But I prefer to have my DB do the logic work as much as possible.

Comment by J [ 25/Apr/14 ]

I've got a similar problem but I have InheritanceType("SINGLE_TABLE") instead of JOINED.
Any updates on when this is getting fixed?





[DDC-624] Partial object query that leaves out an association to avoid loading it fetches the association anyway. Created: 03/Jun/10  Updated: 14/Oct/14

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

Type: Bug Priority: Major
Reporter: Roman S. Borschel Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 2
Labels: None

Issue Links:
Duplicate
is duplicated by DDC-1465 Fetching partial objects doesn't work... Open

 Description   

Assuming:

Customer <onetoone> Cart

where Cart is the owning side.

Since the association from Customer to Cart can not be lazy, it would make sense to leave out the association in a query to avoid loading the carts like this:

select partial c.{id,name, ... anything except cart} from Customer c"

But this is ignored and the carts of all customers are fetched anyway. Query::HINT_FORCE_PARTIAL_LOAD is an alternative solution, however it has the disadvantage that it disables lazy-loading for all queried objects. If partial querying would honor associations this would allow more fine-grained control.



 Comments   
Comment by Roman S. Borschel [ 26/Aug/10 ]

Might need to be pushed back to a 2.0.x / 2.x.x bugfix release. Not clear yet.





[DDC-612] Query\Expr::substring() third parameter should be optional Created: 25/May/10  Updated: 14/Oct/14  Resolved: 14/Oct/14

Status: Closed
Project: Doctrine 2 - ORM
Component/s: DQL
Affects Version/s: 2.0-BETA1
Fix Version/s: 2.0-BETA2
Security Level: All

Type: Improvement Priority: Major
Reporter: David Abdemoulaie Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

I'm not aware of a platform that requires all 3 arguments to SUBSTRING().

This seems to only affect queries from the QueryBuilder

The following DQL works fine:

UPDATE Common\Model\Location e SET e.path = CONCAT('00010002', SUBSTRING(e.path, 9)) WHERE e.path LIKE '00010001%'

Yet the following QueryBuilder expression:

$substr = $expr->substring('e.' . $this->getPathFieldName(), strlen($oldPath)+1);

results in:

Missing argument 3 for Doctrine\ORM\Query\Expr::substring()

If I make that argument optional, default null I get the following generated DQL and error:

"UPDATE Common\Model\Location e SET e.path = CONCAT('00010002', SUBSTRING(e.path, 9, )) WHERE e.path LIKE '00010001%'
Doctrine\ORM\Query\QueryException: [Syntax Error] line 0, col 84: Error: Expected Literal, got ')'


 Comments   
Comment by David Abdemoulaie [ 25/May/10 ]

Fixed in http://github.com/doctrine/doctrine2/commit/ece0e3ad881fae4b0cb434aaa6257cdc5da6f5fc





[DDC-2358] [GH-621] [doc] adding some more doc and examples for lifecycle event listeners and subscribers Created: 19/Mar/13  Updated: 14/Oct/14  Resolved: 06/Apr/13

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

Type: Documentation Priority: Major
Reporter: Benjamin Eberlei Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

as requested in https://github.com/symfony/symfony-docs/pull/2301



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

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





[DDC-2485] [GH-685] Functional ticket for DDC-2484 Created: 03/Jun/13  Updated: 14/Oct/14  Resolved: 10/Aug/13

Status: Resolved
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: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

This shows how the postLoad can change an entity but associations are not passed through postLoad



 Comments   
Comment by Doctrine Bot [ 10/Aug/13 ]

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

Comment by Doctrine Bot [ 06/Oct/14 ]

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

Comment by Doctrine Bot [ 14/Oct/14 ]

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





[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-3351] [GH-1161] Fixing error with from() parameters in example Created: 14/Oct/14  Updated: 14/Oct/14  Resolved: 14/Oct/14

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

Type: Documentation Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

The from method requires $from and the $alias to be separate parameters.

public function from($from, $alias, $indexBy = null);

The examples show: from('User u')



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

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

Comment by Doctrine Bot [ 14/Oct/14 ]

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





[DDC-3345] Error generating entities using docblock (with php) the EntityGenerator is not generating the class properties Created: 10/Oct/14  Updated: 13/Oct/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: Minor
Reporter: André Antônio Lemos de Moraes Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: generation

Attachments: JPEG File doctrine.jpg     JPEG File doctrine1.jpg    

 Description   

I have my files docblock (php) inside a folder named "Script" in the project root and Generated entities are in a folder called "src" inside the root of the project too, when I send generate the entities generating the EntityGenerator Entities within the "src" however without the properties.

On line 852 of EntityGenerator.php there is a validation class_exists and how I'm using docblock with php files, the class does exist and this is causing this block of code ie which existed then taking this class and the properties of it.

In doctrine.jpg image shows my directory structure.
In doctrine1.jpg image shows the block of code that is returning true, but it should return false.

I think if you change "||" to "&&" solve the problem momentarily, but think there are other cases to consider






[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-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-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