[DDC-3454] [GH-1224] Updated setParameters function for not replace all parameters Created: 17/Dec/14  Updated: 17/Dec/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 uthopiko:

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

Message:

When you create QueryBuilder and you bind some parameters, if you use setParameters function after bind other parameters, previous parameters are removed(https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/QueryBuilder.php#L558). This would not be a problem if it was the same behaviour with the attribute $_parameterMappings (in ParserResult), but it's not the case, given that it keeps the number of parameters introduced, throwing an exception(https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Query.php#L293). To prevent this, I've made it initialize the setParameters with the existing ones.



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

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





[DDC-3453] [GH-1223] Refactored construction of the EntityManager out to an EntityManagerFactory Created: 17/Dec/14  Updated: 17/Dec/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 guiwoda:

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

Message:

Added tests for the factory (needed to refactor the OrmTestCase so I could reuse mock config and mock connections).

This pattern is well established in Hibernate, I've been wondering why we don't have it in Doctrine.






[DDC-3452] [GH-1222] Embeddables in metadata builder Created: 17/Dec/14  Updated: 17/Dec/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 guiwoda:

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

Message:

Embeddables set the `$classMetadata->isEmbeddedClass = true` and sets `$classMetadata->isMappedSuperclass = false`, imitating the `switch` in xml / yml drivers.

Embeddeds have 2 methods, as other types have: `addEmbedded` is a one-off adder with fluent behavior, and `createEmbedded` returns an instance of `EmbeddedBuilder`. The class is very thin right now, but it's a good way to lay ground for improvements on embedded creation in the future.

This one is probably more useful than the last one, @Ocramius






[DDC-3451] [GH-1221] Very simple refactoring of the setup class Created: 16/Dec/14  Updated: 17/Dec/14  Resolved: 17/Dec/14

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: 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 guiwoda:

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

Message:

Moved logic to instance methods.

This way, a project could depend on a Setup class instance (or extend it) and resolve it through a DI container.
To allow for BC, instance methods were renamed and a `__callStatic` magic method deals with finding them.
Tests were duplicated to test for static access and instance access.



 Comments   
Comment by Doctrine Bot [ 16/Dec/14 ]

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

Comment by Doctrine Bot [ 17/Dec/14 ]

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





[DDC-3450] Embeddables containing only nested embeddables are not hydrated properly Created: 16/Dec/14  Updated: 16/Dec/14

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

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


 Description   

I have the following object mapping:

Location (entity)

  • name <string>
  • bounds <Bounds>

Bounds (embeddable)

  • northeast <Coords>
  • southwest <Coords>

Coords (embeddable)

  • latitude <float>
  • longitude <float>

This setup works fine when persisting entities, the database schema is correct, etc. but when I fetch my `Location` entity afterwards the `bounds` property is wrong. It looks something like this. Calling `getBounds()` on `Location` returns something like:

Coords

  • latitude <float>
  • longitude <float>
  • northeast <Coords>
  • southwest <Coords>

As if the `Coords` embeddable has been transposed with the `Bounds` embeddable.

If I add another property to `Bounds` that isn't an embeddable (say a string) then it's hydrated correctly.



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

James Moss could you come up with a small test case in https://github.com/doctrine/doctrine2/tree/v2.4.7/tests/Doctrine/Tests/ORM/Functional/Ticket ?





[DDC-3449] Single scalar Result and Hidden field Created: 15/Dec/14  Updated: 15/Dec/14

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

Type: Bug Priority: Minor
Reporter: Thomas Gallice Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I have try to get a single scalar result but my query contains a HIDDEN field. The result is the `NonUniqueResultException` exception.






[DDC-3448] @OrderBy on eager @OneToMany does not work Created: 13/Dec/14  Updated: 13/Dec/14

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

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


 Description   

generated code when eagerly fetching:

SELECT 
  t0.id AS id_8,
  t19.category_id AS category_id_23 
FROM 
  category t0 
  LEFT JOIN attribute_category t19 ON t19.category_id = t0.id 
WHERE 
  t0.id = ?

when fetching lazy the collection query has the ORDER BY clause






[DDC-3447] Identifier Generation Strategy "UUID" is missing Created: 10/Dec/14  Updated: 10/Dec/14

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

Type: Documentation Priority: Minor
Reporter: David Fuhr Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: GeneratedValue


 Description   

The listing of the Identifier Generation Strategies as http://doctrine-orm.readthedocs.org/en/latest/reference/basic-mapping.html#identifier-generation-strategies misses the UUID.

The annotation reference contains the value for UUID http://doctrine-orm.readthedocs.org/en/latest/reference/annotations-reference.html#annref-generatedvalue

So it should be added at the "Identifier Generation Strategies"






[DDC-3446] [GH-1219] Comparison like/notlike support Created: 10/Dec/14  Updated: 10/Dec/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/1219

Message:

Support `Comparison::LIKE` and `Comparison::NOTLIKE` additionally to doctrine/collections#50

as alternative for #1150






[DDC-3445] ERROR GENERATED VALUE (UUID) Created: 10/Dec/14  Updated: 11/Dec/14

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

Type: Bug Priority: Major
Reporter: MUHAMAD SURYA IKSANUDIN Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm, postgresql


 Description   

UUID is not working (missing ID and need to set manually)

/**
 * @ORM\Entity
 * @ORM\Table(name = "utl_role")
 */
class Role implements EntityInterface
{
    /**
     * @ORM\Id
     * @ORM\Column(name = "id", type = "guid")
     * @ORM\GeneratedValue(strategy = "UUID")
     **/
    protected $id;

===============================

i need to pass the id manually

$role->setId((new UuidGenerator())->generate($this->em, $role)); 

because the id is not set and error when i try to persist.

This error is arrive when i try to persist an entity i loop

================================

I use postgresql 9.3



 Comments   
Comment by Marco Pivetta [ 11/Dec/14 ]

Can you check this also against master (2.5-dev)?

Comment by MUHAMAD SURYA IKSANUDIN [ 11/Dec/14 ]

i think it same because the uuid generator is same

https://github.com/doctrine/doctrine2/blob/master/lib%2FDoctrine%2FORM%2FId%2FUuidGenerator.php#L42

in that code, i see the uuid is generated from database provider/platform, i suggest to use code base generator like

https://github.com/ramsey/uuid/blob/master/src%2FUuid.php

it just my suggestion

thanks





[DDC-3444] [GH-1218] Failing test case for cascading refresh Created: 09/Dec/14  Updated: 09/Dec/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 MartijnDwars:

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

Message:






[DDC-3443] Doctrine Custom Type always converted as string, when not wanted Created: 09/Dec/14  Updated: 12/Dec/14

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

Type: Bug Priority: Major
Reporter: Romain Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dql, postgresql
Environment:

Symfony2, PDO_PostgreSQL



 Description   

Hello,

trying to define a Custom Type in my Symfony2 application, I can't find how to write the convertToDatabaseValue function for working with native points in PostgreSQL (!= PostGIS extension).

Wished syntax :

'SELECT [...] FROM Addresses t0 WHERE t0.location = ?' with params ['(2.352,48.857)']

I use this convertToDatabaseValue function :

    public function convertToDatabaseValue($value, AbstractPlatform $platform) {
        if (!$value) return;

        return "'(".$value->getX().','.$value->getY().")'";
    }

DQL, creates this SQL query :

'SELECT [...] FROM Addresses t0 WHERE t0.location = ?' with params ["'(2.352,48.857)'"]

-> Double quotes are automatically added, the parameter is interpreted as string.

I don't know if it is a bug or if I am doing anything wrong ?

Thank you.



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

Please check http://doctrine-orm.readthedocs.org/en/latest/cookbook/advanced-field-value-conversion-using-custom-mapping-types.html and compare it with your codebase.

Comment by Romain [ 10/Dec/14 ]

As I understand, the function convertToDatabaseValue build the format from the value into "with params (############)"

But it does always put double quotes so that my value becomes a string.

convertToDatabaseValueSQL build the format before, at the placeholder and here, I don't want to change anything.

I tried also

getBindingType()

{ return \PDO::PARAM_NULL; }

Hoping that were going to remove the quotes, but it doesn't.

Any suggestion ?

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

Not sure but I think the double quotes are just added for the debug output. What would be the native SQL that you expect?
I think you will have to define \PDO::PARAM_STRING as binding type and remove the single quotes around your database value:

public function convertToDatabaseValue($value, AbstractPlatform $platform) {
    if (!$value) return;

    return "(".$value->getX().','.$value->getY().")";
}




[DDC-3442] [GH-1217] @DDC3441 failing test cases for the ticket Created: 09/Dec/14  Updated: 11/Dec/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-3441 Unidirectional ManyToOne Not Lazy Loa... Open

 Description   

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

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

Message:

Failing test cases for the ticket DDC-3441(http://www.doctrine-project.org/jira/browse/DDC-3441)



 Comments   
Comment by Marcus Fulbright [ 09/Dec/14 ]

I didn't realize a ticket would get automatically opened when I submitted a pull request. I already put relevant details for this in DDC-3441. This is a duplicate.

Comment by Doctrine Bot [ 11/Dec/14 ]

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





[DDC-3441] Unidirectional ManyToOne Not Lazy Loading Created: 09/Dec/14  Updated: 11/Dec/14

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

Type: Bug Priority: Critical
Reporter: Marcus Fulbright Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: lazy-loading, proxy, public-properties, reflection

Issue Links:
Dependency
depends on DDC-3442 [GH-1217] @DDC3441 failing test cases... Open

 Description   

The Unidirectional ManyToOne association described in the docs does not lazy load correctly. The appropriate SQL will get executed, and the returned Proxy does pass type hinting for the correct class. However, the lazy loaded object always has the following properties:

  • _initializer_
  • _cloner_
  • _isInitialized_
  • lazyPropertiesDefaults

Any properties from the class definition do not show up. This is problematic when trying to get reflected properties and their values. Methods are correctly reflected.

Pull request for failing test case



 Comments   
Comment by Marcus Fulbright [ 09/Dec/14 ]

Let me know if anything else is needed.

Comment by Doctrine Bot [ 11/Dec/14 ]

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

Comment by Marco Pivetta [ 11/Dec/14 ]

Looks like a current ORM limitation (private properties lazy loading).

Related:





[DDC-3440] <Inheritance SINGLE_TABLE> Entity merge not working with parent entity Created: 08/Dec/14  Updated: 08/Dec/14  Resolved: 08/Dec/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: Brian Nguyen Assignee: Marco Pivetta
Resolution: Cannot Reproduce Votes: 0
Labels: None


 Description   

I have problem when try to merge the ProfilePersonEntity, all the fields in ProfilePersonEntity was merged, but all another fields of parent class cannot.
I worked fine (wonderful) when i loaded with find(entity id), the DB data mapped 100% to the entity.

Please check the code below

ProfileEntity.php
======================================================================
/**

  • @Entity
  • @Table(name="PROFILE")
  • @InheritanceType("SINGLE_TABLE")
  • @DiscriminatorColumn(name="type", type="string")
  • @DiscriminatorMap( { * "Profile" = "ProfileEntity", * "ProfilePerson" = "ProfilePersonEntity", * "ProfileCompany" = "ProfileCompanyEntity" * }

    )
    */
    class ProfileEntity extends LockableEntity

    { /** * @Column(name="TYPE", type="string", length=15) */ private $type; /** * @Column(name="NAME", type="string", length=45) */ private $name; ... }

ProfilePersonEntity.php
======================================================================
/**

  • @Entity
    */
    class ProfilePersonEntity extends ProfileEntity { /** * @Column(name="LAST_NAME", type="string", length=45) */ private $lastName; ... }

LockableEntity.php
======================================================================
/** @MappedSuperclass */
class LockableEntity extends BaseEntity

{ /** @Column(name="LOCKED", type="string", nullable=true, length=45) */ private $lockOwner; ... }

BaseEntity.php
======================================================================
/**

  • @MappedSuperclass
  • @HasLifecycleCallbacks
    */
    class BaseEntity extends AbstractEntity { /** * @Id * @GeneratedValue * @Column(name="ID", type="integer") */ private $id; /** * @Version * @Column(name="VERSION", type="integer") */ private $version; ... }

...
$this->entityManager->merge($entity);
$this->entityManager->flush();
...



 Comments   
Comment by Marco Pivetta [ 08/Dec/14 ]

Cannot reproduce: missing reproducible test case.





[DDC-3439] [GH-1216] test XML export driver, the field options, for #1214 Created: 08/Dec/14  Updated: 10/Dec/14  Resolved: 10/Dec/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: export-xml, xml


 Description   

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

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

Message:

test for #1214



 Comments   
Comment by Doctrine Bot [ 08/Dec/14 ]

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

Comment by Doctrine Bot [ 10/Dec/14 ]

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

Comment by Doctrine Bot [ 10/Dec/14 ]

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





[DDC-3438] [GH-1215] Don't make this class Final Created: 08/Dec/14  Updated: 09/Dec/14  Resolved: 08/Dec/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: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

Why: It makes testing painful

https://github.com/phpspec/prophecy/issues/102



 Comments   
Comment by Doctrine Bot [ 08/Dec/14 ]

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

Comment by Doctrine Bot [ 09/Dec/14 ]

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





[DDC-3437] [GH-1213] fix instantiation of embedded object in ReflectionEmbeddedProperty Created: 06/Dec/14  Updated: 08/Dec/14  Resolved: 08/Dec/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: abstract-class, embeddables, inheritance, reflection

Issue Links:
Reference
relates to DDC-3431 [GH-1207] Embedded classes reflection... Resolved

 Description   

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

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

Message:

Recently, ReflectionEmbeddedProperty was updated to extend ReflectionProperty. This broke any embeddable that extends an abstract class. That's because if a property is defined in the abstract class, <code>$this->class</code> is alway the abstract class and thus cannot be instantiated. The <code>$class</code> parameter that is passed into the constructor needs to be stored, and that class should be instantiated, not the the property's declaring class.



 Comments   
Comment by Doctrine Bot [ 07/Dec/14 ]

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

Comment by Doctrine Bot [ 08/Dec/14 ]

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





[DDC-3436] [GH-1212] [DDC-3108] Fix regression where join aliases were no longer accessible in Criteria expressions Created: 06/Dec/14  Updated: 08/Dec/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: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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

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

Message:

The solution to issue DDC-2764 was to blanket prefix all the fields with the root alias. The result was then impossible to use fields from multiple FROM tables or a JOIN.

This patch injects all available aliases into the comparison, if a field uses one of the aliases it will pass without modification. If it is an unknown alias it will prefix the first rootAlias listed using the same functionality as the deprecated getRootAlias() function.

Also improves the ORDER BY on Criteria expressions, again introduced by DDC-2764 using the above functionality, this was out of scope of bug DDC-3108.

Added unit tests to test new functionality.



 Comments   
Comment by Doctrine Bot [ 08/Dec/14 ]

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





[DDC-3435] [GH-1211] DDC-3434 - paginator ignores `HIDDEN` fields in `ORDER BY` query Created: 05/Dec/14  Updated: 05/Dec/14  Resolved: 05/Dec/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: dql, limitsubqueryoutputwalker, paginator

Issue Links:
Dependency
is required for DDC-3434 LimitSubqueryOutputWalker does not re... Resolved

 Description   

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

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

Message:

See DDC-3434 ( http://www.doctrine-project.org/jira/browse/DDC-3434 )



 Comments   
Comment by Doctrine Bot [ 05/Dec/14 ]

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

Comment by Doctrine Bot [ 05/Dec/14 ]

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





[DDC-3434] LimitSubqueryOutputWalker does not retain correct ORDER BY expression fields when dealing with HIDDEN sort fields Created: 05/Dec/14  Updated: 05/Dec/14  Resolved: 05/Dec/14

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

Type: Bug Priority: Major
Reporter: Marco Pivetta Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: dql, limitsubqueryoutputwalker, paginator

Issue Links:
Dependency
depends on DDC-3435 [GH-1211] DDC-3434 - paginator ignore... Resolved
Reference
relates to DDC-3336 Undefined property: Doctrine\ORM\Quer... Resolved
relates to DDC-1958 pager produces wrong results on postg... Resolved

 Description   

As per discussion in DDC-3336, the Doctrine\ORM\Tools\Pagination\LimitSubqueryOutputWalker does not retain the correct fields in the ORDER BY condition when one of the selected fields is marked as HIDDEN.

As an example, take a DQL query like:

SELECT a, a.name AS HIDDEN ord FROM Doctrine\Tests\ORM\Tools\Pagination\Author a ORDER BY ord DESC

This will result in an SQL query like:

SELECT DISTINCT id_0 FROM (SELECT a0_.id AS id_0, a0_.name AS name_1, a0_.name AS name_2 FROM Author a0_ ORDER BY name_2 DESC) dctrn_result

Removing the HIDDEN modifier will cause the query to produce the correct SQL:

SELECT DISTINCT id_0, name_2 FROM (SELECT a0_.id AS id_0, a0_.name AS name_1, a0_.name AS name_2 FROM Author a0_ ORDER BY name_2 DESC) dctrn_result ORDER BY name_2 DESC


 Comments   
Comment by Doctrine Bot [ 05/Dec/14 ]

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





[DDC-3433] [GH-1210] DDC-3336 - undefined property with paginator walker and scalar expression in ORDER BY clause Created: 05/Dec/14  Updated: 05/Dec/14  Resolved: 05/Dec/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: ast, dql, limitsubqueryoutputwalker, paginator

Issue Links:
Dependency
is required for DDC-3336 Undefined property: Doctrine\ORM\Quer... Resolved

 Description   

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

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

Message:

Ping @glen-84

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



 Comments   
Comment by Doctrine Bot [ 05/Dec/14 ]

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





[DDC-3432] [GH-1208] DDC-3427 - class metadata factory should accept `EntityManagerInterface` instances Created: 05/Dec/14  Updated: 05/Dec/14  Resolved: 05/Dec/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers, 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: classmetadatafactory, entitymanager, entitymanagerinterface

Issue Links:
Dependency
is required for DDC-3427 Doctrine\ORM\Mapping\ClassMetadataFac... Resolved

 Description   

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

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

Message:

See DDC-3427 ( http://www.doctrine-project.org/jira/browse/DDC-3427 )



 Comments   
Comment by Doctrine Bot [ 05/Dec/14 ]

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

Comment by Doctrine Bot [ 05/Dec/14 ]

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





[DDC-3431] [GH-1207] Embedded classes reflection new instance creation with internal PHP classes Created: 05/Dec/14  Updated: 08/Dec/14  Resolved: 05/Dec/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: embeddables, instantiator, internal-php-classes, reflection

Issue Links:
Reference
is referenced by DDC-3437 [GH-1213] fix instantiation of embedd... Resolved

 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 05/Dec/14 ]

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

Comment by Doctrine Bot [ 05/Dec/14 ]

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





[DDC-3430] [GH-1206] matching should not change critera Created: 04/Dec/14  Updated: 04/Dec/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 Metabor:

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

Message:

The matching should behave like in ArrayCollection, where it is not changed.
The criteria should be cloned so that it could be used for more than one matching operation.






[DDC-3429] [GH-1205] Hotfix - #1200 symfony 2.7 deprecation fixes Created: 04/Dec/14  Updated: 04/Dec/14  Resolved: 04/Dec/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers, Tools
Affects Version/s: Git Master, 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: console, symfony, yaml

Issue Links:
Reference
relates to DDC-3422 [GH-1200] Fix Yaml::parse() errors Resolved

 Description   

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

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

Message:

See #1200



 Comments   
Comment by Doctrine Bot [ 04/Dec/14 ]

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

Comment by Doctrine Bot [ 04/Dec/14 ]

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





[DDC-3428] [GH-1204] Fix sequence-generator in MetaData exporter for XML Driver. Created: 04/Dec/14  Updated: 04/Dec/14  Resolved: 04/Dec/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers, Tools
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: convert-mapping, export-xml, mapping, xml


 Description   

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

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

Message:

Make XMLExporter writes sequence-generator if a definition about it exists.



 Comments   
Comment by Doctrine Bot [ 04/Dec/14 ]

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

Comment by Doctrine Bot [ 04/Dec/14 ]

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





[DDC-3427] Doctrine\ORM\Mapping\ClassMetadataFactory explicitly accepts EntityManager Created: 04/Dec/14  Updated: 05/Dec/14  Resolved: 05/Dec/14

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

Type: Bug Priority: Major
Reporter: Frank Wallen Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: orm
Environment:

Symfony2


Issue Links:
Dependency
depends on DDC-3432 [GH-1208] DDC-3427 - class metadata f... Resolved

 Description   

The setEntityManager only accepts instances of EntityManager thus blocking any objects extending EntityManager. It should expect EntityManagerInstance.






[DDC-3426] [GH-1203] DDC3424Test.php Created: 03/Dec/14  Updated: 03/Dec/14  Resolved: 03/Dec/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: Steve Müller
Resolution: Incomplete Votes: 0
Labels: None


 Description   

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

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

Message:

the problem consists in the insert's ordre



 Comments   
Comment by Doctrine Bot [ 03/Dec/14 ]

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

Comment by Doctrine Bot [ 03/Dec/14 ]

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

Comment by Steve Müller [ 03/Dec/14 ]

Closed by the contributor.





[DDC-3425] [GH-1202] Checks key exists rather than isset Created: 03/Dec/14  Updated: 08/Dec/14  Resolved: 08/Dec/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Tools
Affects Version/s: Git Master, 2.4.6
Fix Version/s: 2.5, 2.4.7
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: column-options, null, schema, table-options


 Description   

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

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

Message:

If the default value is set to `null`, `isset` will return `false` even though the key is actually there for a reason.



 Comments   
Comment by Doctrine Bot [ 03/Dec/14 ]

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

Comment by Doctrine Bot [ 08/Dec/14 ]

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





[DDC-3424] Class Table Inheritance - wrong table order on insert with more than one level of inheritance Created: 02/Dec/14  Updated: 04/Dec/14

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

Type: Bug Priority: Major
Reporter: mohammed Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: ORM
Environment:

Mysql



 Description   

when i use class table inheritance with multiple levels in doctrine :
Account<=User<=Dealer
(Dealer inherits from User, User from Account)
Account has the discriminator column and mapping.
when i persist a new Dealer entity I get a foreign key error because there is no row in the User table.
So the order in which the insert statements are executed:
1) Insert into Account
2) Insert into Dealer (which causes the error)
3) insert into User
Can someone help me thanks in advance.



 Comments   
Comment by Marco Pivetta [ 02/Dec/14 ]

Is this also valid for 2.4.x and master? 2.3.3 is a very old version.

Additionally, could you come up with a small reproduction test case? You can check the ones at https://github.com/doctrine/doctrine2/tree/v2.4.6/tests/Doctrine/Tests/ORM/Functional/Ticket for reference

Comment by mohammed [ 03/Dec/14 ]

This is also valid for 2.4.x and master
this is the test case https://github.com/rogerghost/doctrine2/blob/patch-1/tests/Doctrine/Tests/ORM/Persisters/DDC3424Test.php





[DDC-3423] Column Ordering when creating tables using doctrine:schema:update Created: 01/Dec/14  Updated: 01/Dec/14

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

Type: Improvement Priority: Minor
Reporter: Raja Venkataraman Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

When you have a Base class (annotated with @MappedSuperClass) having some columns, say, createdById, createdDateTime and child entities deriving from the BaseClass, the ordering of the SQL when running doctrine:schema:update looks like

createdById
createdDateTime
id
field1
field2

i.e. the columns of the Base class come up first and then that of the children. It looks odd when you write a SQL to insert into these tables because the default ordering is not what you expect (Which would be derived class columns first and then base class).

I looked into ClassMetadataFactory that adds the fields to the classmetadata and figured if we could move the following
$this->addInheritedFields($class, $parent);
$this->addInheritedRelations($class, $parent);

to after the point where the local fields are added to the classmetadata, this problem is solved.

It might be even better if we have an annotation to specify the Ordering of columns but nevertheless this will help in cases where the base class columns appear after the derived class columns.

Note: Did look into columnDefinition annotation to specify a "AFTER <column>", but that cannot be used during CREATE TABLE, only for ALTER TABLE and that too, its mysql specific.






[DDC-3422] [GH-1200] Fix Yaml::parse() errors Created: 30/Nov/14  Updated: 04/Dec/14  Resolved: 04/Dec/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Incomplete Votes: 0
Labels: console, yaml

Issue Links:
Reference
is referenced by DDC-3429 [GH-1205] Hotfix - #1200 symfony 2.7 ... Resolved

 Description   

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

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

Message:

Of course this might be just a temporary fix for:

"The ability to pass file names to Yaml::parse() was deprecated in 2.7 and will be removed in 3.0. Please, pass the contents of the file instead."



 Comments   
Comment by Doctrine Bot [ 01/Dec/14 ]

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

Comment by Doctrine Bot [ 04/Dec/14 ]

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





[DDC-3421] [GH-1199] minor typo Created: 28/Nov/14  Updated: 28/Nov/14  Resolved: 28/Nov/14

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

Type: Documentation Priority: Trivial
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: dql, typo


 Description   

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

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

Message:

Fixed case in DQL query in docs.



 Comments   
Comment by Doctrine Bot [ 28/Nov/14 ]

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

Comment by Doctrine Bot [ 28/Nov/14 ]

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





[DDC-3420] [GH-1198] Tables for buttons. Created: 28/Nov/14  Updated: 28/Nov/14  Resolved: 28/Nov/14

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

Type: Documentation Priority: Trivial
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: badges


 Description   

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

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

Message:






[DDC-3419] [GH-1196] Inherit indexes from mapped superclass Created: 27/Nov/14  Updated: 27/Nov/14  Resolved: 27/Nov/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers
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: ddl, index, inheritance, mappedsuperclass, mapping

Issue Links:
Duplicate
is duplicated by DDC-3418 Indexes not inherited from mapped sup... Resolved

 Description   

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

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

Message:

Patch to allow entities to inherit indexes from their mapped superclasses.

More info here:
http://www.doctrine-project.org/jira/browse/DDC-3418



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

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

Comment by Doctrine Bot [ 27/Nov/14 ]

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





[DDC-3418] Indexes not inherited from mapped superclass Created: 27/Nov/14  Updated: 27/Nov/14  Resolved: 27/Nov/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers
Affects Version/s: 2.4.6
Fix Version/s: 2.5

Type: Improvement Priority: Minor
Reporter: Dustin Thomson Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: ddl, index, inheritance, mappedsuperclass, mapping

Issue Links:
Duplicate
duplicates DDC-3419 [GH-1196] Inherit indexes from mapped... Resolved
Reference
relates to OXM-2 Mapped-superclass, indexes not gathered Open
relates to DDC-3273 EntityGenerator writes @ORM\Table ann... Open

 Description   

Index definitions on mapped super classes are not inherited by their sub-classes.
I realize this makes the definition of the mapped super-class look a bit weird as it requires it to have a @Table element which isn't strictly valid since there is no corresponding table in the database.
However, it would be nice to set indices on the mapped superclass where the fields are actually defined as this increased comprehension and reduces maintenance.



 Comments   
Comment by Marco Pivetta [ 27/Nov/14 ]

Handled in DDC-3419





[DDC-3417] [GH-1195] Correction Events.rs - Entity Listeners Resolver Created: 27/Nov/14  Updated: 04/Dec/14  Resolved: 04/Dec/14

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

Type: Documentation Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: configuration, entitymanager, listener, resolve-target-entities, resolver, tools

Issue Links:
Reference
relates to DDC-3412 [GH-1193] Fix allow 'implementing you... Resolved

 Description   

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

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

Message:

Configuring the Entity Listener Resolver can only be done before Entity Manager is initialized as described here https://github.com/doctrine/doctrine2/pull/1193



 Comments   
Comment by Doctrine Bot [ 04/Dec/14 ]

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

Comment by Doctrine Bot [ 04/Dec/14 ]

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

Comment by Doctrine Bot [ 04/Dec/14 ]

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





[DDC-3416] using getArrayResult and foreach with reference get a string at the end Created: 26/Nov/14  Updated: 26/Nov/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: Minor
Reporter: sysko Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

doctrine2 alone, not inside symfony or any framework



 Description   

This bug is quite weird so let me explain it

I have 2 Entity

Category (language independant information)

CategoryDescription (language dependant category 1 -> N categoryDescription)

when i do

        $categories = $this->createQueryBuilder('Entity\Category')
            ->select('c')
            ->distinct()
            ->from('Entity\Category', 'c')
            ->getQuery()
            ->getArrayResult();
        ;

        foreach ($categories as &$category) {
            var_dump($category);
            $plop = $category['id'];
        }

I will get the last element of the array as a string instead of an array
and that string being the value of the column "name" of the last CategoryDescription in my database

using a normal foreach without reference does not trigger the bug
using getResult also does not trigger the bug

if needed and someone guide me I can try to furnish a "minimal code" to reproduce the issue






[DDC-3415] [GH-1194] [DDC-3414] Add test for "Joining on a table with inheritance produces badly formed ON clause" Created: 26/Nov/14  Updated: 26/Nov/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 LewisW:

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

Message:

Add a test for a bug report. The test is only simple with no assertions, since the SQL generated by Doctrine is invalid and generates an exception in SQLite.






[DDC-3414] Joining on a table with inheritance produces badly formed ON clause Created: 26/Nov/14  Updated: 26/Nov/14

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

Type: Bug Priority: Major
Reporter: Lewis Wright Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: inheritance, joins, orm, querybuilder


 Description   

When I join on a table that uses class table inheritance, Doctrine automatically joins on the parent table, but it does it before the ON clause.

So for example, writing this DQL:

SELECT uc, c FROM MyModel\Customer c LEFT JOIN MyModel\Customer uc WITH uc.customer = c

produces:

SELECT 
 # Snipped
FROM 
  customer c0_ 
  LEFT JOIN user_customer u2_ 
  INNER JOIN base_user b1_ ON u2_.id = b1_.id ON (u2_.customer_id = c0_.id)

This syntax for the ON clause looks wrong, and fails in SQLite, so I can only assume it's the result of a bug?



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

Please compare the DQL you wrote by hand with the one generated by the QueryBuilder

Comment by Lewis Wright [ 26/Nov/14 ]

The issue appears not to be with just the query builder, but with the DQL version too (see the updated bug report). Would it help if I made a bare-bones doctrine application demoing the problem?

Actually, what would probably be more helpful is if I added a test to the test suite for this bug. I'll see what I can do.

Comment by Marco Pivetta [ 26/Nov/14 ]

We'd need a functional test to add to the test suite, not a demo app. Sending a pull-request with a failing test case will expose the problem immediately.

Comment by Lewis Wright [ 26/Nov/14 ]

Apologies, I should have read the contribute readme first before submitting the ticket. I've created a pull request here with the failing SQLite tests:

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

I did put this ticket number as the PR subject, but the bot seems to have created another issue here:
http://www.doctrine-project.org/jira/browse/DDC-3415





[DDC-3413] Types are always ignored when performing a one to many statement Created: 26/Nov/14  Updated: 27/Nov/14

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

Type: Bug Priority: Major
Reporter: Edouard COLE Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: persister


 Description   

BasicEntityPersister#getOneToManyStatement() is building an array named $criteria. This array is built this way:

$criteria[$tableAlias . "." . $targetKeyColumn] = ...;

This means this array is indexed by keys looking like that:

t0.fieldName

But the function BasicEntityPersister#expandParameters() is used in this function, and this function is NOT able to handle SQL field name as keys, but PHP attributes, because it uses BasicEntityPersister#getType() which is doing this:

case (isset($this->class->fieldMappings[$field])):
case (isset($this->class->associationMappings[$field])):

I think the $criteria array should be used to call BasicEntityPersister#getSelectSQL(), but another array should be passed to expandParameters. Here is a potential fix:

$cleanCriteria[$owningAssoc['fieldName']] = $criteria[$tableAlias . "." . $targetKeyColumn] = ...;

And $cleanCriteria should be passed to expandParameters.



 Comments   
Comment by Marco Pivetta [ 27/Nov/14 ]

Edouard COLE I suggest you to open a pull request with a failing test case, otherwise this issue is hard to follow/understand.





[DDC-3412] [GH-1193] Fix allow 'implementing your own resolver' to work. Created: 25/Nov/14  Updated: 04/Dec/14  Resolved: 26/Nov/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: Git Master, 2.3.5, 2.5, 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: configuration, entitymanager, listener, resolver

Issue Links:
Reference
is referenced by DDC-3417 [GH-1195] Correction Events.rs - Enti... Resolved

 Description   

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

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

Message:

When the ListenersInvoker class is initialized, the Entity Listener Resolver is instantiated within the constructor and stored as a property onto the ListenersInvoker class; this doesn't work. When a User implements and set his or her own Entity Listener Resolver, it is ignored because because the Entity Listener Resolver has already been stored onto the class.

Instead of calling getEntityListenerResolver within the constructor, getEntityListenerResolver is called when resolving the User's EntityListenerResolver.



 Comments   
Comment by Doctrine Bot [ 26/Nov/14 ]

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

Comment by Doctrine Bot [ 26/Nov/14 ]

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

Comment by Marco Pivetta [ 26/Nov/14 ]

The listeners resolver is not supposed to be swapped out at runtime.

Comment by Doctrine Bot [ 26/Nov/14 ]

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

Comment by Doctrine Bot [ 04/Dec/14 ]

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





[DDC-3411] [GH-1192] Fixed a very minor typo Created: 25/Nov/14  Updated: 25/Nov/14  Resolved: 25/Nov/14

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

Type: Documentation Priority: Trivial
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 javiereguiluz:

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

Message:



 Comments   
Comment by Doctrine Bot [ 25/Nov/14 ]

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

Comment by Steve Müller [ 25/Nov/14 ]

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

Comment by Doctrine Bot [ 25/Nov/14 ]

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





[DDC-3410] Allow Query Builder to specify the joins of Join Inheritance entities Created: 25/Nov/14  Updated: 25/Nov/14

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

Type: Improvement Priority: Minor
Reporter: Dave Newson Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Possibly a duplicate of DDC-16 in essence; resolving this would probably resolve that issue.

Summary
When you SELECT an entity which is a superclass using Joined Inheritance, Doctrine automatically adds it's own JOINs of the superclass or subclass tables.
These automatic JOINs that are introduced can't be used in DQL/builder, so you can't do anything with them (further joins on their associations for eager loading, WHERE queries, etc).
Allow me to specify my own Joins between the superclass and subclass so I can perform further queries deeper in the associations.

Main culprit:
https://github.com/doctrine/doctrine2/blob/2.4/lib/Doctrine/ORM/Query/SqlWalker.php#L341

Long version
Superclass "Activity" uses the Joined inheritance type with a discriminator column. There are various activities such as ActivityDocument, ActivityTask, etc.
These sub-class activities have associations to other entities; ActivityDocument associates to a Document entity, and Document then associates to User.

For the query, I want to fetch all Activity where the Activities document/task is associated to a given user. If I wanted to do this in raw SQL it would look something like this:

SELECT a.*, ad.*, d.*, at.*, t.*
FROM Activity a
LEFT JOIN ActivityDocument ad ON ad.id = a.id
LEFT JOIN Document d ON d.id = ad.document_id
LEFT JOIN ActivityTask at ON at.id = a.id
LEFT JOIN Task t ON t.id = at.task_id
WHERE
t.user_id = 1 OR d.user_id = 1

Doctrine supports the joined inheritance type, so I want it to fetch the subclasses and also eagerly load the downstream Document or Task entity that's associated with them, and be able to execute clauses on the data.

I can only get half way there:

$builder
    ->select('a')
    ->from('Activity', 'a')
    ->leftJoin('ActivityDocument', 'ad', Query\Expr\Join::WITH, 'a.id = ad.id')
    ->leftJoin('ad.document', 'ad_d')
    ->orWhere('ad_d.user = :user')
    ->leftJoin('ActivityTask', 'at', Query\Expr\Join::WITH, 'a.id = at.id')
    ->leftJoin('at.task', 'at_t')
    ->orWhere('at_t.user = :user')
    ->setParameter('user', $user);

In the above I've fudged the joined inheritance association using ->leftJoin() in order to execute the deep WHERE portion, however because we're doing our own join between two entities, the association between Activity and ActivityDocument is lost.

The entities returned by this query are instances of ActivityDocument and ActivityTask; the hydrated subclasses are returned when we SELECT from Activity, and ActivityDocument and ActivityTask are LEFT JOINed automatically by Doctrine because the Activity entity is recognised as using Joined Inheritance, but there's no way to latch onto these generated LEFT JOINs.
https://github.com/doctrine/doctrine2/blob/2.4/lib/Doctrine/ORM/Query/SqlWalker.php#L376

Note that adding "ad", "at" or "at_d" or "at_t" to the select does not solve this.

A workaround for this specific scenario is this:

$builder->select('ad', 'at', 'ad_d', 'at_t')

This fetch ActivityDocument and ActivityTask specifically, plus their associations. Unfortunately because it is across multiple to-level entities, it causes null rows to be returned in the result set.

Effectively this goes the other way, and adds joins from ActivityDocument to Activity in order to provide the correct hydration of ActivityDocument.
https://github.com/doctrine/doctrine2/blob/2.4/lib/Doctrine/ORM/Query/SqlWalker.php#L348

Note that you still cannot use an alias for Activity because the builder was not the one to specify that relation.

What I want to be able to do
Allow me to define the join across the Join Inheritance entities, so I can use the alias for the superclass/subclass in the query builder!

Rather than DDC-16's idea of "casting" to a class, just let me define the join myself. Obviously this is more a "joined class" than a "joined field" , so extra notation may be required.
A painfully ugly example of this syntax could be something like:

$builder->join('Activity->ActivityDocument', 'ad')

This could then establish the Join as some form of JoinAssociation rather than a RangeVariableDeclaration.

The bigger problem is that SqlWalker::_generateClassTableInheritanceJoins doesn't have scope over any of the joins in the query, and thus can't inspect any relations that have been established in the query builder, and use those instead of generating its own.

Unfortunately I don't know the internals of Doctrine to be of any more use.

Why
Joined Inheritance is a powerful feature, but without being able to use associations across the superclass and subclass it actually creates an annoying dead-end in queries.

There is no good workaround for this issue. If you fetch a Join Inheritance entity you can only examine one side of the inheritance without performing another query.






[DDC-3409] [GH-1191] [2.4] Documenting interface methods (based on entity manager) Created: 23/Nov/14  Updated: 23/Nov/14  Resolved: 23/Nov/14

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

Type: Documentation Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: entitymanagerinterface

Issue Links:
Dependency
depends on DDC-2846 [GH-870] Documenting interface method... Resolved

 Description   

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

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

Message:

This PR follows #870 and my [comments](https://github.com/doctrine/doctrine2/pull/870#commitcomment-5702280) on it.

I think these changes are MUST for the stable release. Especially when Doctrine is used together with such high quality framework like Symfony.



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

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

Comment by Doctrine Bot [ 23/Nov/14 ]

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





[DDC-3408] [GH-1190] Document that AUTOGENERATE_ constants are allowed Created: 21/Nov/14  Updated: 21/Nov/14  Resolved: 21/Nov/14

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

Type: Documentation Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: autogeneration, documentation, proxy


 Description   

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

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

Message:

As of Doctrine Common 2.4, there are four strategies for generating proxy classes. Previously there were just two. This is supported by Doctrine ORM (implemented in bee74f898da0474b4bad44d41df84f1807036880 and 88754622419524bf92cfc18f9ab7fac148c35924), but the change is not fully reflected in the documentation and variable names used in Doctrine ORM.

This PR updates the documentation and variable names.



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

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





[DDC-3407] add possibility to prevent some entitiy methods from being proxied Created: 21/Nov/14  Updated: 21/Nov/14

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

Type: New Feature Priority: Trivial
Reporter: Oliver Hoff Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This is for optimization of lazy loading, when using entity methods that operate only on identifier values.

This issue is partially addressed via:
https://github.com/doctrine/doctrine2/commit/ba38f3e1e9d725224998af9fce42186b5ccb9641

But it makes assumptions about a certain code style, that is for an "id" identifier property the getter is named "getId". but some code styles prefer "getID".

It would be nice to have an annotation like @ORM\SkipProxy (or equivalents for xml/yaml) to mark a method that should not be proxied.



 Comments   
Comment by Marco Pivetta [ 21/Nov/14 ]

I wouldn't implement it that way. I'm actually building something (non-trivial) at https://github.com/Ocramius/ProxyManager/pull/192 and https://github.com/Ocramius/ProxyManager/issues/159, but it will take some time to get there, and also to get doctrine to use that component to generate proxy classes.





[DDC-3406] Proxy returns string instead of object Created: 21/Nov/14  Updated: 21/Nov/14

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

Type: Bug Priority: Major
Reporter: Martin Keckeis Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm, proxy


 Description   

I get an string in one case instead of an entity or proxy.

User -> Address -> Plant -> Hierarchy

User OneToOne Address
Address ManyToOne Plant
Plant OneToOne Hierarchy

(all are fetched as eager loading)

See PR with a test case here
https://github.com/doctrine/doctrine2/pull/1189

Reference
https://github.com/doctrine/DoctrineORMModule/issues/355



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

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





[DDC-3405] Join Query Related Created: 21/Nov/14  Updated: 21/Nov/14  Resolved: 21/Nov/14

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

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


 Description   

Hi,

I am new in doctrine. i Used doctrine in zend framwork 2. I tried to join user and group but i cannot do it.can u please tell whole process of join 2 table and join query



 Comments   
Comment by Oliver Hoff [ 21/Nov/14 ]

usage questions belong to the user mailing list http://groups.google.com/group/doctrine-user

Comment by Marco Pivetta [ 21/Nov/14 ]

Not an issue





[DDC-3404] [GH-1188] Fixed counting exception Created: 20/Nov/14  Updated: 28/Nov/14  Resolved: 27/Nov/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: count, paginator, parameters


 Description   

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

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

Message:

Fixed "Invalid parameter number: number of bound variables does not match number of tokens " exception during execution count on Query where select part of query contains :parameters.



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

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

Comment by Doctrine Bot [ 27/Nov/14 ]

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





[DDC-3403] [GH-1187] Fixed counting exception. Created: 20/Nov/14  Updated: 20/Nov/14  Resolved: 20/Nov/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: Incomplete Votes: 0
Labels: None


 Description   

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

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

Message:

Fixed "Invalid parameter number: number of bound variables does not match number of tokens " exception during execution count on Query where select part of query contains :parameters.



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

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

Comment by Doctrine Bot [ 20/Nov/14 ]

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





[DDC-3401] __load should not mark proxied entity as initialized when initialization fails Created: 19/Nov/14  Updated: 25/Nov/14  Resolved: 25/Nov/14

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

Type: Bug Priority: Major
Reporter: Oleg Namaka Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: lazy-loading, proxy


 Description   

Imagine this situation:

   //$entity2 is instance of \Doctrine\ORM\Proxy\Proxy which fails to load
    try {
       $entity2 = $entity->getEntity2();
   } catch (\Doctrine\ORM\EntityNotFoundException $e) {
       //the exception is caught
       // $entity2 is marked as initialized but its data is missing
   }

Then somewhere else in code:

 //$entity2 is instance of \Doctrine\ORM\Proxy\Proxy which fails to load
    try {
       $entity2 = $entity->getEntity2();
   } catch (\Doctrine\ORM\EntityNotFoundException $e) {
       //the exception is not caught since $entity2 is already initialized
   }
   foreach ($entity3->getSomeCollection() as $element) {
   // breaks since all internal data is missing

The fix to \Doctrine\Common\Persistence\Proxy::__load should look something like this:

        if (!$this->__isInitialized__ && $this->_entityPersister) {
//            $this->__isInitialized__ = true; --> this line is moved down below

            if (method_exists($this, "__wakeup")) {
                // call this after __isInitialized__to avoid infinite recursion
                // but before loading to emulate what ClassMetadata::newInstance()
                // provides.
                $this->__wakeup();
            }

            if ($this->_entityPersister->load($this->_identifier, $this) === null) {
                throw new \Doctrine\ORM\EntityNotFoundException();
            }
            unset($this->_entityPersister, $this->_identifier);
            $this->__isInitialized__ = true;
        }


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

The initialization flag has to be moved to the top, as initialization can recurse otherwise.

If you can abstract this into a test case, then I'll gladly try working on it.

Comment by Marco Pivetta [ 19/Nov/14 ]

Does the issue also affect 2.4?

Comment by Oleg Namaka [ 24/Nov/14 ]

@Marco, I do not know about 2.4 since I do not have it installed.

Regarding your first comment:

The initialization flag has to be moved to the top, as initialization can recurse otherwise.

In this case you can either introduce an independent flag to mitigate this problem or you can re-set the flag back to false in the following block right before an exception is thrown:

if ($this->_entityPersister->load($this->_identifier, $this) === null) {
    $this->__isInitialized__ = false;
    throw new \Doctrine\ORM\EntityNotFoundException();
}
Comment by Marco Pivetta [ 24/Nov/14 ]

I don't think that we are going to patch 2.3 anymore, so I suggest upgrading to 2.4, as this issue may likely have been fixed.

Consider that the entire proxy layer has been re-written: https://github.com/doctrine/doctrine2/blob/88ce68e733a02b84eb229c8447409b2ed5cf71ac/lib/Doctrine/ORM/Proxy/ProxyFactory.php#L175

Comment by Oleg Namaka [ 25/Nov/14 ]

@Marco, I installed 2.4 as you suggested but it seems that the issue is not fixed in it either. Look at a proxy __load generated in 2.4:

/** @private */
    public function __load()
    {
        if (!$this->__isInitialized__ && $this->_entityPersister) {
            $this->__isInitialized__ = true;

            if (method_exists($this, "__wakeup")) {
                // call this after __isInitialized__to avoid infinite recursion
                // but before loading to emulate what ClassMetadata::newInstance()
                // provides.
                $this->__wakeup();
            }

            if ($this->_entityPersister->load($this->_identifier, $this) === null) {
                throw new \Doctrine\ORM\EntityNotFoundException();
            }
            unset($this->_entityPersister, $this->_identifier);
        }
    } 

It looks identical to Proxy::__load generated in 2.3

Comment by Oleg Namaka [ 25/Nov/14 ]

@Marco, please disregard my previous comment as incorrect. This issue probably is fixed as a new proxy looks totally different. I will confirm it later today.

Comment by Marco Pivetta [ 25/Nov/14 ]

Marking as resolved in 2.4, won't fix for 2.3





[DDC-3400] Wrong result using php-cli Created: 19/Nov/14  Updated: 20/Nov/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: Damir Abdijevic Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: cache, cli, dql, environment, orm
Environment:

Windows 7, Debian GNU/Linux 7 PHP 5.5.15



 Description   

Same query produces different results. With apache module everything works like expected. With php-cli the join condition to i18n table is ignored and calling getCountries() returns all and not only that entity that is matched by join condition.

        $qb = $this->_em->createQueryBuilder()
                        ->select('t', 'i18n')
                        ->from($this->_entityName, 't')
                        ->innerJoin('t.countries', 'i18n')
                        ->where('i18n.locale = :localeId')
                        ->setParameter('localeId', $localeId);

Country Entity:

namespace MyApp\Model\Entity;

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

/**
 * Country entity
 *
 * @ORM\Entity(repositoryClass="MyApp\Model\Repository\Country")
 * @ORM\Table(name="country")
 *
 */
class Country
{
    /**
     * @var int
     * @ORM\Id
     * @ORM\Column(type="integer", name="id")
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;

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

    /**
     * @var int
     * @ORM\Column(type="integer", name="sort", unique=true)
     */
    protected $sort;

    /**
     * @var ArrayCollection
     * @ORM\OneToMany(targetEntity="ProductDescription\Model\Entity\CountryI18n", mappedBy="country", cascade={"all"})
     */
    protected $countries;


    /**
     * Constructor
     *
     * @return Country
     */
    public function __construct()
    {
        $this->countries = new ArrayCollection();
    }

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

    /**
     * Setter for $this->id
     *
     * @param int $id entity id
     *
     * @return void
     */
    public function setId($id)
    {
        $this->id = (int) $id;
    }

    /**
     * Getter for $this->sort
     *
     * @return int
     */
    public function getSort()
    {
        return $this->sort;
    }

    /**
     * Setter for $this->sort
     *
     * @param int $sort sort order
     *
     * @return void
     */
    public function setSort($sort)
    {
        $this->sort = (int) $sort;
    }

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

    /**
     * Setter for $this->name
     *
     * @param string $name language name in german
     *
     * @return void
     */
    public function setName($name)
    {
        $this->name = (string) $name;
    }

   /**
    * Get collection from i18n table
    *
    * @return ArrayCollection
    */
    public function getCountries()
    {
        return $this->countries;
    }

    /**
     * Proxy method. So we have working with all entities same method
     * to getting i18n data.
     *
     * @return ArrayCollection
     */
    public function getI18n()
    {
        return $this->getCountries();
    }

CountryI18nEntity:

namespace MyApp\Model\Entity;

use Doctrine\ORM\Mapping as ORM;

/**
 * CountryI18n entity
 *
 * @ORM\Entity
 * @ORM\Table(name="country_i18n", uniqueConstraints={@ORM\UniqueConstraint(name="idx_UNIQUE_country_id_locale_id", columns={"country_id", "locale_id"})})
 */
class CountryI18n
{
    /**
     * @var int
     * @ORM\Id
     * @ORM\Column(type="integer", name="id")
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;

    /**
     * @ORM\ManyToOne(targetEntity="ProductDescription\Model\Entity\Country", inversedBy="countries")
     * @ORM\JoinColumn(name="country_id", referencedColumnName="id")
     */
    protected $country;

    /**
     * @ORM\ManyToOne(targetEntity="ProductDescription\Model\Entity\Language", inversedBy="countries")
     * @ORM\JoinColumn(name="locale_id", referencedColumnName="id")
     */
    protected $locale;

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


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

    /**
     * Setter for $this->id
     *
     * @param int $id id of row primary key
     *
     * @return void
     */
    public function setId($id)
    {
        $this->id = (int) $id;
    }

    /**
     * Getter for $this->country
     *
     * @return Country
     */
    public function getCountry()
    {
        return $this->country;
    }

    /**
     * Setter for $this->country
     *
     * @param Country $country country entity to set
     *
     * @return void
     */
    public function setCountry(Country $country)
    {
        $this->country = $country;
    }

    /**
     * Getter for $this->locale
     *
     * @return Language
     */
    public function getLocale()
    {
        return $this->locale;
    }

    /**
     * Setter for $this->locale
     *
     * @param Language $locale language entity to set as locale
     *
     * @return void
     */
    public function setLocale(Language $locale)
    {
        $this->locale = $locale;
    }

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

    /**
     * Setter for $this->name
     *
     * @param string $name translation name
     *
     * @return void
     */
    public function setName($name)
    {
        $this->name = (string) $name;
    }

}


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

Looks like a caching issue. The amount of information provided is insufficient as it is. I'd suggest verifying if the generated SQL is the same, and checking that all caches were cleared both in CLI and in WEB sapis.

Comment by Damir Abdijevic [ 20/Nov/14 ]

O.k. here some further information.

No caching like Xcache or APC is enabled. PHP 5.5 integrated opcache ist not enabled. All Doctrine caches are set to Array. The sql queries are in both cases exactly the same:

sql
SELECT c0_.id AS id0, c0_.name AS name1, c0_.sort AS sort2, c1_.id AS id3, c1_.name AS name4, c1_.country_id AS country_id5, c1_.locale_id AS locale_id6 FROM country c0_ INNER JOIN country_i18n c1_ ON c0_.id = c1_.country_id WHERE c1_.locale_id = ?

/* locale_id = 2 */

The sql result is correct

Running the console script a ZF2 Initializer runs before that performs this query builder query:

QueryBuilder

$qb = $this->_em->createQueryBuilder()
                            ->select('t', 'i18n', 'l')
                            ->from($this->_entityName, 't')
                            ->innerJoin('t.countries', 'i18n')
                            ->innerJoin('i18n.locale', 'l');

That results in following SQL:

sql
SELECT c0_.id AS id0, c0_.name AS name1, c0_.sort AS sort2, c1_.id AS id3, c1_.name AS name4, l2_.id AS id5, l2_.name AS name6, l2_.full_name AS full_name7, l2_.locale AS locale8, c1_.country_id AS country_id9, c1_.locale_id AS locale_id10, l2_.country_id AS country_id11 FROM country c0_ INNER JOIN country_i18n c1_ ON c0_.id = c1_.country_id INNER JOIN language l2_ ON c1_.locale_id = l2_.id
Comment by Marco Pivetta [ 20/Nov/14 ]

What happens if you run those SQL statements via CLI (dbal:run-sql) or WEB? Same results?

Comment by Damir Abdijevic [ 20/Nov/14 ]

The sql result is correct. Can I attach it to the ticket? I have exported it to csv.

Comment by Marco Pivetta [ 20/Nov/14 ]

If the same results are produced on CLI and WEB APIs then I suggest trying to insulate the issue in a functional test to be run in both context. You probably have a different ORM bootstrap for CLI and WEB.

Attaching a CSV for same results makes no real difference here.

Comment by Damir Abdijevic [ 20/Nov/14 ]

No, I didn't want to attach two times the same result. Wanted to attach it one time to show that those entitites that are wrong in the result doesn't appear in the sql result at all. I don't have different bootstraps. After a few short tests I think it is an error in th ArrayCache mechanism. The difference was that using Apache one initializer was not called. Calling this initializer in both cases leads now to wrong results in CLI and WEB API.

When the second query is not executed everything is fine. But when the second longer query runs and selects all i18n entities and after it the first query runs then the issue appears.





[DDC-3399] indexBy expects db field names insteadof model property names Created: 19/Nov/14  Updated: 19/Nov/14

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

Type: Documentation Priority: Major
Reporter: Oliver Hoff Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

The following example does work:

Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
/**
 * @ORM\Entity
 */
class Order {

	use IDTrait;

	/**
	 * @ORM\OneToMany(
	 * 		targetEntity="OrderCategory",
	 * 		mappedBy="order",
	 * 		indexBy="my_category_id",
	 * 		fetch="EAGER",
	 * 		cascade={"all"},
	 * 		orphanRemoval=true
	 * )
	 * @var Collection
	 */
	private $categories;

}

/**
 * @ORM\Entity
 */
class OrderCategory {

	/**
	 * @ORM\ManyToOne(targetEntity="Order", inversedBy="categories")
	 * @ORM\JoinColumn(name="order_id", referencedColumnName="id", onDelete="CASCADE")
	 * @ORM\Id
	 * @var Order
	 */
	private $order;

	/**
	 * @ORM\ManyToOne(targetEntity="Category")
	 * @ORM\JoinColumn(name="my_category_id", referencedColumnName="id", onDelete="RESTRICT")
	 * @ORM\Id
	 * @var Category
	 */
	private $category;

}

If you use indexBy="category", it does not work. Why are the object property names used for referencing in most of the mapping, but for indexBy you have to use the db field name? It is nowhere mentioned in the docs.
I didnt test this with non-association properties as indexBy.






[DDC-3398] PersistentCollection doesn't check that Entity is managed before scheduling orphan removal Created: 18/Nov/14  Updated: 18/Nov/14

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

Type: Bug Priority: Major
Reporter: Nicholas Dobie Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orphanRemoval


 Description   

I am adding and removing a non-persisted entity to a PersistentCollection before flushing. The collections field is an OneToMany relation with orphanRemoval. When the entity is removed it is automatically scheduled for orphanRemoval but is never checked if it is actually a managed entity before being scheduled which causes an exception. After it has been scheduled there is no way to unschedule it other than completely clearing the UnitOfWork.



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

Does this affect also later versions?





[DDC-3397] [GH-1186] Add a EntityRepository#createQuery() method Created: 18/Nov/14  Updated: 18/Nov/14  Resolved: 18/Nov/14

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

Type: New Feature Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: createquery, custom-repository, dql, repository


 Description   

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

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

Message:

This is usefull when you don't want to use a query builder in a custom repository.



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

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





[DDC-3396] In Doctrine\ORM\Query\SqlWalker tableAliasMap and tableAliasCountershould be exposed Created: 17/Nov/14  Updated: 17/Nov/14

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

Type: Improvement Priority: Minor
Reporter: Ioan Badila Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: sql-walker


 Description   

I see that Doctrine\ORM\Query\SqlWalker::tableAliasMap and tableAliasCounter are private properties but this doesn't scale well with public Doctrine\ORM\Query\SqlWalker::getSQLTableAlias($tableName, $dqlAlias = '')

public function getSQLTableAlias($tableName, $dqlAlias = '')
{
$tableName .= ($dqlAlias) ? '@[' . $dqlAlias . ']' : '';

if ( ! isset($this->tableAliasMap[$tableName]))

{ $this->tableAliasMap[$tableName] = strtolower(substr($tableName, 0, 1)) . $this->tableAliasCounter++ . '_'; }

return $this->tableAliasMap[$tableName];
}

For me, getSQLTableAlias() is useful in my custom walker but I can't actually use it without exposing tableAliasMap and tableAliasCounter.






[DDC-3395] matching(Criteria::create()->orderBy()) is sorting in case insensitive manner Created: 17/Nov/14  Updated: 17/Nov/14

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

Type: Bug Priority: Minor
Reporter: Dona Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: case-sensitivity, collation, collection, criteria, sorting


 Description   

for example if we have two strings "IT" and "innovation" after sort by ASC , "IT" is coming before "Innovation".
I was expecting the arrayCollection to do a natural sort.



 Comments   
Comment by Marco Pivetta [ 17/Nov/14 ]

Dona this behavior may change depending on server-side collation anyway.





[DDC-3394] UOW CreateEntity failure with zerofill columns Created: 17/Nov/14  Updated: 19/Nov/14  Resolved: 18/Nov/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.2, 2.3, 2.4, 2.x
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Thorry Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: DDC-1238
Environment:

PHP 5.4.4-14+deb7u8 (CLI) MySQL Server 5.5.35-0+wheezy1 MySQL Client 5.5.35 Debian Wheezy


Issue Links:
Reference
relates to DDC-3387 [GH-1182] #1086 identifier type in pr... Open

 Description   

In the CreateEntity function of the UnitOfWork in the following commit:

https://github.com/doctrine/doctrine2/commit/2858b8290fc63ca96a31ef173c9cf128ec18bfe7

This line will fail (under a specific set of circumstances) when zerofill identity columns are used:

($unmanagedProxy = $hints[Query::HINT_REFRESH_ENTITY]) !== $entity

Within one object the identifier will be stored as a string (eg "0000001"), in the other the identifier will be stored as a int (eg 1). The following line of code will return true:

$this->isIdentifierEquals($unmanagedProxy, $entity)

This will lead the UnitOfWork to assume the proxy is invalid, resetting the identifier. This object is then returned which can cause very weird things to happen.

If needed I can provide a code sample which clearly shows the problem in action. I came upon this problem when coding against an old database with zerofill columns, since a schema change in this database is unlikely to happen I hope someone can think of a fix.



 Comments   
Comment by Marco Pivetta [ 17/Nov/14 ]

Can you please check if the problem is reproducible with https://github.com/doctrine/doctrine2/pull/1182 applied? ( DDC-3387 )

Comment by Thorry [ 18/Nov/14 ]

Thank you for your super fast response!

I'm afraid the problem is still there with the patch you referred to in place.

I will dig further into the code, the place I mentioned is the place the failure occurs, however I do not think that's the place the failure originates from. It has something to do with the way the entity gets stored in memory.

Comment by Thorry [ 18/Nov/14 ]

This bug was already fixed by guilhermeblanco in this commit.

Comment by Thorry [ 18/Nov/14 ]

Bug was already fixed in dev.

Comment by Christophe Coevoet [ 18/Nov/14 ]

The "Fix version" should be 2.5, not 3.0 (the master branch is the dev version for 2.5)

Comment by Thorry [ 18/Nov/14 ]

Really? Is there a release date for 2.5? 3.0 is scheduled for December isn't it?

Comment by Marco Pivetta [ 18/Nov/14 ]

There is no scheduled release date for 2.5, as we can't get a decent (regular) amount of time assigned to the project right now.

Comment by Christophe Coevoet [ 19/Nov/14 ]

And what we wanted to schedule for December was 2.5, not 3.0. There is no date at all for 3.0, given that the work on it has not even started (and won't start in the foreseeable future given that core developers don't have enough time for such major task currently)

Comment by Thorry [ 19/Nov/14 ]

The 3.0 release date is stated here: http://www.doctrine-project.org/jira/browse/DDC/?selectedTab=com.atlassian.jira.jira-projects-plugin:roadmap-panel

Comment by Marco Pivetta [ 19/Nov/14 ]

Yeah, let me clear that.





[DDC-3393] Cannot extend existing internal functions Created: 17/Nov/14  Updated: 17/Nov/14  Resolved: 17/Nov/14

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

Type: Bug Priority: Minor
Reporter: Rob Spick Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

On the MySQL platform, i want to use DATE_SUB with more than just DAY and MONTH, so I write a function and give it the identifier of date_sub however this is not allowed?

Why are we not able to extend the functions, surely if we're writing the function we know the platform that we're extending it on and the other platform specific functions will fail at parsing due to an unsupported type.

I don't want to have to prefix my code with MY_DATE_SUB only for an additional type to be supported at a later date, that would just lead to inconsistencies in my code.



 Comments   
Comment by Marco Pivetta [ 17/Nov/14 ]

Overriding DQL functions may have terrible and unforeseen consequences when dealing with any codebase. If you have a specific use-case, use a specific DQL function, but do not try overriding an existing one that may be used in ways that you are not aware of.





[DDC-3392] Add a way to use a custom instantiator in ClassMetadataInfo Created: 13/Nov/14  Updated: 13/Nov/14  Resolved: 13/Nov/14

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

Type: Improvement Priority: Minor
Reporter: Rekamlefat Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: inheritance, orm


 Description   

Hi,

In my project, I'm using a home made container of dependencies, that I use sometimes in my entities. I found very useful to use EntityListeners and EntityResolver to be able, on PostLoad event, to inject dependencies into the models.

Thinking of that, should it be a good idea to implement some custom instantiators that could do this, using the model's constructor?

Here's a quick example:

class MyInstantiator implements \Doctrine\Instantiator\InstantiatorInterface {

    private $container;

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

    public function instantiate($className) {
        // return a new model instance, with it's dependencies
        return $this->container->get($classname);
    }

}

// set default instantiator in entity manager
// container = your dependencies container
$entityManager->setDefaultInstantiator(new MyInstantiator($container));

Now in ClassMetadataInfo class, the instantiator cannot be overridden. Check these lines below. Instantiator is private and created via [new] in constructor and in wakeup method. Do we need to override ClassMetadataInfo to achieve this?

DoctrineORMMappingClassMetadataInfo.php
class ClassMetadataInfo implements ClassMetadata
{
    ...

    /**
     * @var \Doctrine\Instantiator\InstantiatorInterface|null
     */
    private $instantiator;

    /**
     * Initializes a new ClassMetadata instance that will hold the object-relational mapping
     * metadata of the class with the given name.
     *
     * @param string              $entityName     The name of the entity class the new instance is used for.
     * @param NamingStrategy|null $namingStrategy
     */
    public function __construct($entityName, NamingStrategy $namingStrategy = null)
    {
        $this->name = $entityName;
        $this->rootEntityName = $entityName;
        $this->namingStrategy = $namingStrategy ?: new DefaultNamingStrategy();
        $this->instantiator   = new Instantiator();
    }

    // ...

    /**
     * Restores some state that can not be serialized/unserialized.
     *
     * @param \Doctrine\Common\Persistence\Mapping\ReflectionService $reflService
     *
     * @return void
     */
    public function wakeupReflection($reflService)
    {
        // Restore ReflectionClass and properties
        $this->reflClass    = $reflService->getClass($this->name);
        $this->instantiator = $this->instantiator ?: new Instantiator();

        // ...
    }
    // ...
}

Thanks,



 Comments   
Comment by Marco Pivetta [ 13/Nov/14 ]

This is exactly the type of dependency that you DO NOT want in an entity.

Don't do this, it's discouraged and it will likely cause only headaches.

Marking as Won't Fix.

Comment by Rekamlefat [ 13/Nov/14 ]

Thanks for your feedback. I'm playing with this design pattern since a few days only, so I'm not quite confident about what is or isn't "good".

So your approach is to add a listener to the entity and manage all dependencies in the listener class? Can we say that's a best practice, or even a rule, to not ask for any dependency in any method of any entity?

Have a nice evening

Comment by Marco Pivetta [ 13/Nov/14 ]

So your approach is to add a listener to the entity and manage all dependencies in the listener class?

The idea is to NOT have dependencies in entities at all. It is arguably not necessarily an absolute, but it's a good practice to let entities only be aware of their siblings.

See also http://misko.hevery.com/2008/09/30/to-new-or-not-to-new/





[DDC-3391] RFC Allow adding extra metadata attributes Created: 13/Nov/14  Updated: 19/Nov/14

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

Type: Improvement Priority: Minor
Reporter: Gonzalo Vilaseca Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: drivers, metadata


 Description   

What I'd like to propose is a way of having custom metadata in ClassMetadata.

So the current problem is this: I want to add custom tags to doctrine metadata files, and then get this tags on a loadClassMetadata listener in order to modify the mapping.
Currently the only workaround is parsing this custom tags in the loadClassMetadata listener, going through all the files again.

I was thinking of having a new 'extra' array field in ClassMetadata, every time a driver parses a configuration, throw a new event with the read configuration (being xml, yaml...etc.). A custom listener will parse it looking for the custom tags and return an array that will be added to the 'extra' array field in ClassMetadata.

Then, on the loadClassMetadata listener we retrieve this 'extra' configuration information, and modify the mapping as we want.

Does this make sense?



 Comments   
Comment by Gonzalo Vilaseca [ 14/Nov/14 ]

Ideally instead of the 'extra' array field, it would be nice to easily extend Metadata class so that the new values are filled in the new extended Metadata class.

Comment by Christophe Coevoet [ 14/Nov/14 ]

This would be even worse. If the recommended way for extensions is to extend the Doctrine Metadata object to add their field, it means you can only use 1 extension at a time (because you cannot use the extended class of both extensions at the same time for the same object).
This is why it is much better for other libraries to store their own metadata in their own object instead of trying to put it inside the Doctrine ones.

I'm not even sure putting custom tags inside the Doctrine mapping file is the best solution. It may be better to use a separate metadata file for the mapping of the other library (just like you use a different mapping file for the Symfony validation mapping even if it applies to the same class than the Doctrine mapping for instance)

Comment by Gonzalo Vilaseca [ 14/Nov/14 ]

You're right regarding the metadata.

As for the separate files, validation in Symfony is not doctrine specific, that's why it's in a separate file. If you have a look at some doctrine extensions like ``Prezent translable`` or ``Doctrine2 behavioral extensions``, the natural location for the custom tags are the Doctrine mapping files as they are specific to doctrine, by looking at just one file you see the whole picture.

Yes, you could have your own mapping files, but then you would need to do some Symfony magic to be able to load them, and this is what would be nice to avoid.

I think of it as a way to easily extend doctrine mapping capabilities, in a 'plugin' way.

I'm currently working on a i18n bundle for Symfony, the tags I add in doctrine mapping files create associations between entities and their translations: I've had to create quite a few compiler passes for my current project to work as desired, and I see no way of abstracting this in a general way, it will need to be application specific. If I could hook into the Doctrine workflow and get those tags to populate my metadata class, that would be great, simple and reusable.

Comment by Gonzalo Vilaseca [ 19/Nov/14 ]

I've come out with another use case:
I need some custom metadata when the repository is instantiated, AFAIK there is no way of doing this right now, or is there?

Comment by Marco Pivetta [ 19/Nov/14 ]

You'd use a different metadata factory for that, specific to your use-case.
Mixing ORM mappings with the rest will just cause more coupling between the ORM and the userland use-case.





[DDC-3390] [GH-1185] add a new method that return the mapped properties Created: 12/Nov/14  Updated: 12/Nov/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 fabiocarneiro:

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

Message:

There are some implementations that use the doctrine metadata to get the properties of a entity (DoctrineObject), and it currently uses the getFieldNames and getAssociationNames methods to retrieve and merge it.

Since the embeddables feature was added, that method will return more than one metadata for each embeddable property, and then the hydrator can never find the appropriate setter for that property.

This method allows some implementation to retrieve all mapped fields from an entity, something that can't be done using get_class_vars for example.

Of course this implementation could be done in the hydrator, but i don't think it is its responsibility to filter and merge data received from the ClassMetadata. Since you have methods to retrieve the metadata formatted as the database structure, you should also have methods to retrieve the information to the other side, in object structure.






[DDC-3389] [GH-1184] Postgres SERIAL is not a post-insert identifier generation strategy Created: 12/Nov/14  Updated: 12/Nov/14  Resolved: 12/Nov/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers
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: identifier, identity, postgresql, sequence

Issue Links:
Reference
is referenced by DDC-2339 [GH-605] DDC-2338 Added failing test ... Resolved
is referenced by DDC-2338 Entity with composite foreign keys id... Resolved

 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 12/Nov/14 ]

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

Comment by Doctrine Bot [ 12/Nov/14 ]

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





[DDC-3388] [GH-1183] Update tools.rst Created: 12/Nov/14  Updated: 12/Nov/14  Resolved: 12/Nov/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: Trivial
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 NAYZO:

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

Message:



 Comments   
Comment by Doctrine Bot [ 12/Nov/14 ]

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





[DDC-3387] [GH-1182] #1086 identifier type in proxies Created: 11/Nov/14  Updated: 17/Nov/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: hydration, jti, persister, sti

Issue Links:
Dependency
is required for DDC-3223 Failing test (get id return string type) Open
Reference
is referenced by DDC-3394 UOW CreateEntity failure with zerofil... Resolved

 Description   

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

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

Message:

See #1086. This fix simply ensures that the column type for identifiers of proxies of STI/JTI are kept consistent with the DBAL types they are mapped to.

May be related/colliding with #1178

Ping @jaspernbrouwer






[DDC-3386] Multiple Level Discriminator Mapping Created: 11/Nov/14  Updated: 18/Nov/14

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

Type: Bug Priority: Minor
Reporter: Patrick Rose Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: inheritance, mapping, orm
Environment:

Linux, PHP 5.5.9



 Description   

We currently have a situation where we're required to have up to 4 levels of discriminator mappings, and we're finding that Doctrine will insert into our root entity table, and the leaf entity table correctly. However, the tables in between are not being set at all.

The hierarchy is below:

Deal -> EcommerceDeal
Deal -> EcommerceDeal -> ItemSpecific
Deal -> EcommerceDeal -> ItemSpecific -> ItemSpecificScheduled
Deal -> EcommerceDeal -> DealSet -> SetCombo
Deal -> EcommerceDeal -> DealSet -> SetMoreForLess

When inserting an ItemSpecific entity, I found that the Deal and ItemSpecific tables were filled but the EcommerceDeal was not.

There's not much documentation about trees that are slightly more complicated than the Employee, Person, Admin example in the docs so there's a chance I've misunderstood how to build the tables correctly.

Currently we only have one discriminator column on the Deal table. Should we instead be setting up several columns that are nullable and setting new discriminator columns further down the tree?

EDIT: All classes are Class Table Inheritance, in case that is unclear



 Comments   
Comment by Patrick Rose [ 11/Nov/14 ]

The thing that always confuses me while I'm working on this is the fact that I can select from the Database fine. I've got dummy data in each table and Doctrine is clever enough to select all the correct fields from the correct tables so I'm unsure whether I've made a mistake or if Doctrine has a bug.

Comment by Marco Pivetta [ 11/Nov/14 ]

This looks like normal ORM behavior to me, not really requiring any change. What's the reason for inserts on the other tables?

Comment by Patrick Rose [ 12/Nov/14 ]

We have data that's the same across all Ecommerce Deal types (things like the start time, end time etc). I'd expect to be able to set all the values on (say) an ItemSpecific deal and Doctrine to insert the generic data in the EcommerceDeal table.

Comment by Patrick Rose [ 12/Nov/14 ]

It turns out that Doctrine does support this out of the box. A predecessor had overriden the JoinedSubclassPersister with the sole purpose being to comment out the section relating to discriminator columns.

Comment by Patrick Rose [ 12/Nov/14 ]

Problem is with an overridden method not in the Doctrine core.

Comment by Marco Pivetta [ 13/Nov/14 ]

Patrick Rose do you mean that your version (local file) of the JoinedSubclassPersister was monkey-patched?

Comment by Patrick Rose [ 13/Nov/14 ]

Undoing monkey patch does not fully fix issue

Comment by Patrick Rose [ 13/Nov/14 ]

Marco: We'd overridden a whole bunch of classes to do various things, but I've got no idea what those were (these happened at least 6 months before I joined).

The JoinedSubclassPersister was overridden and just commented out two lines

$tableAlias = ($this->class->rootEntityName == $this->class->name) ? $baseTableAlias : $this->getSQLTableAlias($this->class->rootEntityName);
$columnList[] = $tableAlias . '.' . $discrColumn;

From speaking to people, it seems that the point of using that was to allow the discriminator columns to be on the incorrect tables.

However, even with undoing this, I've just tried to create a ComboDeal and it inserted into the root table and the leaf table but none of the other tables. However it looks like ItemSpecific entities are fine. I'll just retry creation of each entity type and get back to you.

Comment by Patrick Rose [ 13/Nov/14 ]

Just finished doing that. I can create EcommerceDeal entities, and ItemSpecific entities and they'll insert into the correct tables (so the EcommerceDeal entity saves into the EcommerceDeal and Deal tables, and the ItemSpecific entity saves into the ItemSpecific, EcommerceDeal and Deal tables).

The rest only insert into the Deal table and the table relating to that class.

Comment by Patrick Rose [ 18/Nov/14 ]

Is there an update on how we can resolve this?

Comment by Patrick Rose [ 18/Nov/14 ]

We've spent a day looking through and trying to work out what seems to be happening and seem to have a resolution.

It appears that the method of getting the parents was only getting those which weren't transient (and thus were entities), which in our case wasn't working since then Doctrine complains about duplicate column definitions. After overriding the getParentClass to allow us to be explicit we got it to work.





[DDC-3385] [GH-1181] Support fetching entities by aliased name Created: 11/Nov/14  Updated: 11/Nov/14

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

Type: New Feature Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: class-alias, metadata, resolve-target-entities

Issue Links:
Dependency
depends on DCOM-257 [GH-342] Class metadata loading fallb... Open

 Description   

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

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

Message:

See #385 (this PR supersedes it)

The final aim is allowing something like:

```php
$user = $em->find(UserInterface::class, 123);
```

This PR depends also on doctrine/common#342






[DDC-3384] [GH-1180] Fix for no dot on Class Names Created: 11/Nov/14  Updated: 11/Nov/14  Resolved: 11/Nov/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers, 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: Duplicate Votes: 0
Labels: entityGenerator, postgresql, schema

Issue Links:
Duplicate
duplicates DDC-2881 [GH-895] Fix for no dot on Class Names Awaiting Feedback

 Description   

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

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

Message:

If you work with PostgreSQL Schemas, You should filter the names of table to generate Correct name for PHP Classes. This way allow not write dots (.) as part of the Class Name.

In addition I have added two properties in which data from a table schema and namespace of a class are stored, this is useful when working with PostgreSQL Schemas.

Additionally, there is a variable ($schema) that must be contained in the class "Doctrine\DBAL\Schema\Table" on an $schema possible property but this is not available. Or can be the value of "name" property of the Class "Doctrine\DBAL\Schema\SchemaConfig". (This last is recomended)

This is a fix because Doctrine entityGenerate proccess is generating the name of PHP classes with dots (.) when you work with schemas on PostgreSQL. The Name of Classes on PHP can not have dot on its Name. Therefore Doctrine2 can't generate PHP Classes with dots on its names.

These data are also placed in the metadata.



 Comments   
Comment by Doctrine Bot [ 11/Nov/14 ]

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

Comment by Doctrine Bot [ 11/Nov/14 ]

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





[DDC-3383] [GH-1179] Fix embeddables class metadata (work-in-progress) Created: 10/Nov/14  Updated: 10/Nov/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 fabiocarneiro:

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

Message:

ClassMetadataInfo is returning more than one result in getFieldNames() for the embeddables properties. This method is used by DoctrineModule\Stdlib\Hydrator\DoctrineObject in the extraction process.

Since its returning a number of results equal the number of properties of the embedded object, it will never find the correct setter for the extraction and that causes that property to be removed from the extracted array.

I was able to solve the issue by hacking into the getFieldNames() for testing and merging the duplicated entries, and then the object was successfully extracted.

By digging into the code, i found out that there is a mapEmbedded(), but instead of using that for embeddeds, its using the default mapField, which may be the root cause of the problem.

  • [x] Hack into the getFieldNames() method to see if the expected solution would work
  • [x] Remove multiple class declaration in the same file from the files i'll work with
  • [x] Create a failing testcase
  • [ ] Create a solution





[DDC-3382] With orphanRemoval, cannot delete and re-add entity Created: 10/Nov/14  Updated: 10/Nov/14  Resolved: 10/Nov/14

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


 Description   

I have a one-to-many relation with orphanRemoval=true.

If I remove an entity from the related collection and add it back, the entity is removed from the database.

$employee = $company->getEmployees()->first();
$company->getEmployees()->removeElement($employee);
$company->getEmployees()->add($employee);

$em->persist($company);
$em->flush();
// Now $employee is deleted from the database.

The expected behaviour is to leave the entity in the database, because it was present in the PersistentCollection when $em->persist() was called.



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

This is expected behavior, and won't be changed for now.





[DDC-3381] orm:schema-tool:update shows incorrect changes with MasterSlaveConnection wrapper class Created: 09/Nov/14  Updated: 10/Nov/14

Status: Open
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: Pieter Vogelaar Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: connection, ddl, master-slave, schematool


 Description   

My entities and database are in sync. If I use the default Doctrine connection configuration it shows "Nothing to update - your database is already in sync with the current entity metadata.". This is what I would expect and is correct.

'doctrine' => array(
        'connection' => array(
            'orm_default' => array(
                'driverClass' => 'Doctrine\DBAL\Driver\PDOMySql\Driver',
                'params' => array(
                    'host'     => 'localhost',
                    'port'     => '3306',
                    'user'     => 'myuser',
                    'password' => 'mypassword',
                    'dbname'   => 'example',
                    'charset'  => 'utf8',
                ),
        ),
),

But with the MasterSlaveConnection configuration, I always get the same changes which are a lot, you would think the database is empty at the moment.

'doctrine' => array(
        'connection' => array(
            'orm_default' => array(
                'wrapperClass' => 'Doctrine\DBAL\Connections\MasterSlaveConnection',
                'params' => array(
                    'driver' => 'pdo_mysql',
                    'master' => array(
                        'host' => 'localhost',
                        'port' => '3306',
                        'user' => 'myuser',
                        'password' => 'mypassword',
                        'dbname' => 'example',
                        'charset' => 'utf8',
                    ),
                    'slaves' => array(
                        array(
                            'host' => 'localhost',
                            'port' => '3306',
                            'user' => 'myuser',
                            'password' => 'mypassword',
                            'dbname' => 'example',
                            'charset' => 'utf8',
                        ),
                    ),
                ),
            ),
        ),
    ),
),


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

Can you come up with a functional test case for this? Couldn't reproduce from here.





[DDC-3380] [GH-1178] Fixing associations using UUIDs Created: 09/Nov/14  Updated: 10/Nov/14

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

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

Issue Links:
Duplicate
is duplicated by DDC-3373 [GH-1174] Fix associations with a cus... Resolved

 Description   

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

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

Message:

This is a port of #1174.

I was running an experiment using a custom DBAL type, which converts a UUID string (in PHP) to 16 bytes binary string (in SQL) and vice versa, as identifier for a couple of entities. I noticed some associations weren't loaded correctly. This PR attempts to fix that issue.

_Remaining issue_

There are 2 tests that involve OneToOne and OneToMany associations with composite ids of which one is a foreign one. When the owning side is fetched from the DB, a Proxy object is created for the inversed side. But this Proxy contains incorrect identifiers:

public $id => string(36) "12345678-9abc-def0-1234-56789abcdef0"
public $foreignEntity => string(16) "????????????????"

Those question-marks represent 16 bytes of binary data. The thing is that `$foreignEntity` should contain another Proxy object (or perhaps the UUID of the foreign entity, I'm not sure).

I'm at a loss here Hopefully someone can point me to where identity through foreign Entities is managed!



 Comments   
Comment by Doctrine Bot [ 09/Nov/14 ]

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

Comment by Doctrine Bot [ 09/Nov/14 ]

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

Comment by Doctrine Bot [ 10/Nov/14 ]

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

Comment by Jasper N. Brouwer [ 10/Nov/14 ]

Affects Versions: master (2.5) and 2.4 are confirmed, but I suspect this goes back to all versions.





[DDC-3379] [GH-1177] Ensure metadata cache is not ArrayCache in production Created: 08/Nov/14  Updated: 11/Nov/14  Resolved: 11/Nov/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers, Tools
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: array-cache, cache, configuration, production-settings


 Description   

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

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

Message:

This PR adds a new check to Configuration::ensureProductionSettings(). It ensures that the metadata cache does not use ArrayCache in production.

The ArrayCache forgets everything at the end of each request, while the other bundled cache engines (Memcache, MongoDB, FileCache etc.) may keep entries for much longer. The metadata only changes when the source files are changed, so in production the metadata cache only needs to be cleared when new files are deployed, just like the generation of proxy classes.

It is possible to specify/modify metadata dynamically at runtime e.g. using the loadClassMetadata event so that the metadata changes without any changes to the source files, but I assume this is not a supported use-case (at least not without clearing the metadata cache manually). Agree?

The ArrayCache is the default cache engine added by e.g. Doctrine Bundle (for Symfony) and Doctrine ORM Service Provider (for Silex), so most developers are probably not aware of it. However, accessing the metadata at run-time has a significant performance impact (for some anecdotal evidence, see https://github.com/doctrine/common/pull/319#issuecomment-60945429), so a warning in ensureProductionSettings() is relevant.

The PR also fixes the units for ensureProductionSettings() that were previously not being run due to a missing "test" prefix on the ConfigurationTest::ensureProductionSettings method name.



 Comments   
Comment by Doctrine Bot [ 10/Nov/14 ]

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





[DDC-3378] [GH-1176] Add test exposing UnitOfWork merge bug Created: 07/Nov/14  Updated: 07/Nov/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 adrienbrault:

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

Message:

I hope that I'm doing something wrong and that this is not a bug ...






[DDC-3377] DateTime columns cannot be used with @Id Created: 06/Nov/14  Updated: 07/Nov/14  Resolved: 07/Nov/14

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

Type: Bug Priority: Major
Reporter: Chris Verges Assignee: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: None
Environment:

PHP 5.4.33
Symfony 2.5.6
Doctrine 2.4.x-dev


Issue Links:
Duplicate
duplicates DDC-2768 Doctrine could not work with date as ... Resolved
duplicates DDC-1471 Unable to read mySQL "DATE" field fro... Resolved
duplicates DDC-2487 UnitOfWork::getEntityIdentifier() con... Resolved
duplicates DDC-1780 Function createEntity does't support ... Closed

 Description   

DateTimeIdTest.php:

use Doctrine\ORM\Mapping as ORM;

/**
 * @ORM\Table(name="datetime_id_test")
 * @ORM\Entity
 */
class DateTimeIdTest
{
    /**
     * @ORM\Column(name="when", type="datetime")
     * @ORM\Id
     */
    public $when;

    public function __construct()
    {
        $this->when = new \DateTime();
    }
}

test.php:

require_once('DateTimeIdTest.php');

$entity = new DateTimeIdTest();
$entityManager->persist($entity);

Output:

Object of class DateTime could not be converted to string

/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1359
/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1172
/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:864
/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1635
/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1591
/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php:624
/app/cache/test/jms_diextra/doctrine/EntityManager_545bc3b10fd93.php:94
test.php:4

I was able to debug this down to where the implode() call in Doctrine\ORM\UnitOfWork::addToIdentityMap() is what is triggering this problem. It attempts to convert all contained entities in the Doctrine\ORM\UnitOfWork::entityIdentifiers array to strings. For a DateTime object, the DateTime::format() function should be used instead of relying on __toString().



 Comments   
Comment by Chris Verges [ 06/Nov/14 ]

There is a portable workaround where you create a string-based shadow key that gets updated by Doctrine events:

DateTimeIdTest.php:

use Doctrine\ORM\Mapping as ORM;
use Doctrine\ORM\Events as Events;

/**
 * @ORM\Table(name="datetime_id_test")
 * @ORM\Entity
 * @ORM\HasLifecycleCallbacks
 */
class DateTimeIdTest
{
    public $when;

    /**
     * @ORM\Column(name="when", type="string")
     * @ORM\Id
     */
    public $whenKey;

    public function __construct()
    {
        $this->when = new \DateTime();
    }

    /**
     * @Events\PrePersist
     * @Events\PreUpdate
     */
    public function syncWhenToWhenKey(LifecycleEventArgs $event)
    {
        $entityManager = $event->getEntityManager();
        $connection = $entityManager->getConnection();
        $platform = $connection->getDatabasePlatform();

        $this->whenKey = $when->format($platform->getDateTimeFormatString());
    }

    /**
     * @Events\PostLoad
     */
    public function syncWhenKeyToWhen(LifecycleEventArgs $event)
    {
        $entityManager = $event->getEntityManager();
        $connection = $entityManager->getConnection();
        $platform = $connection->getDatabasePlatform();

        $this->when = \DateTime::createFromFormat($platform->getDateTimeFormatString(), $this->whenKey);
    }
}




[DDC-3376] Only one row is returned Created: 06/Nov/14  Updated: 07/Nov/14

Status: Reopened
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: Patryyyck Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: inheritance, lazy-loading, n+1-queries, sti
Environment:

Linux Mint 17
PHP 5.5.9
Apache 2.4.7
Symfony 2.4.10
Doctrine ORM 2.4.6
Doctrine DBAL 2.4.3
Sql Server database



 Description   

Hi,

I don't know if you are the appropriate person.
I have an issue with Doctrine ORM or DBAL.
By the way, i'm not sure the issue is in one of these bundles.

I'm trying to get all the rows of on an entity A which is a SINGLE_TABLE with 3 discriminators.
This entity has a property "parent" which is a self referencing property (ManyToOne on entity A).

The getResult of my query only return the first row of my table.
When i replace getResult by getArrayResult, i have all my table.
But i want the objects

After hours of debugging, i saw that the Doctrine ORM ObjectHydrator.php loops on the result of my query (which have the good number of results):

while ($row = $this->_stmt->fetch(PDO::FETCH_ASSOC)) {
    $this->hydrateRowData($row, $cache, $result);
}

But, the hydrateRowData executes another query to get the parent of each row (Doctrine DBAL Connection.php function executeQuery).
This function prepares a query to get the parent with a param (parent id) and i think the prepare function return the same statement (stmt) as the first query (the list of all the entity A).
So, the prepared query is executed but when the Doctrine ORM ObjectHydrator.php want to fetch the second row, he considers that there's no more rows to fetch and return the first rows.

I don't know if i am clear enough. Tell me if you want more details.

Oh. I forgot. If i try the same request with the same datas but in a mySQL database (pdo_mysql), i have a good result. I don't know if that helps.

Thanks

Regards



 Comments   
Comment by Marco Pivetta [ 07/Nov/14 ]

The issue you described is very well known and it is a limitation of the ORM. What happens is following:

1. you have an inheritance A -> B | C | D (A being the root of the inheritance)
2. A has a self-referencing association to A (typically like a hierarchy of parent-child)
3. the ORM tries to load an A instance that has a reference to a parent of type A. In order to do so, the ORM has to resolve the actual type of the referenced parent, and therefore cannot lazily load it via a proxy (a query has to be executed in order to find out the value of the discriminator column)

This means that for performance reasons you should NEVER reference the root of an inheritance, but only leafs (where the ORM does not need to do this sort of resolution).

See also http://doctrine-orm.readthedocs.org/en/latest/reference/inheritance-mapping.html#id4 (Performance impact of inheritance mapping) for more details.

Comment by Patryyyck [ 07/Nov/14 ]

Thanks Marco for your quick answer.

I understand the ORM limitation.
But i still don't understand why this limitation doesn't exist when i use a MySQL database.





[DDC-3375] UnitOfWork: new operation attach(): merge without persist Created: 06/Nov/14  Updated: 08/Nov/14  Resolved: 07/Nov/14

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

Type: Improvement Priority: Major
Reporter: Mathieu De Zutter Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: unitofwork


 Description   

Currently UnitOfWork provides the following three methods that make entities cross the boundaries of being managed or not:

  • persist()
  • merge()
  • detach()

In my opinion, there's an operation missing: attach(). It would be similar to merge(), but it would not call persist(). It would be the counterpart of detach().

Example 1: Simple case

if (...)
$person = new Person;
else
$person = $em->find('Person', $id);

// At some point I decide that I don't want to store the person, so I don't call persist()

$dog = new Dog;
$em->persist($dog);

$em->flush(); // OK, commits only the dog

Example 2: Same, but the person is serialized along the way

if (...)
$person = new Person;
else
$person = $em->find('Person', $id);

// Serialize the person
$serializedPerson = serialize($person);

// At some point I want to restore the person
$person = unserialize($serializedPerson);

// Because it could have been a managed entity before, I need to merge it.
$person = $em->merge($person);

// But yet again, I decide that I don't want to store the person, so I don't call persist()

$dog = new Dog;
$em->persist($dog);

$em->flush(); // Oops, if the person was NEW, it has become managed, so it is commited now!

If merge() was replaced by attach(), flush() would not have commited the person.



 Comments   
Comment by Christophe Coevoet [ 06/Nov/14 ]

I don't understand what attach would do in your case. flush is about flushing the whole unit of work. I don't understand what attach() would do if it does not attach the entity to the unit of work.

Comment by Christophe Coevoet [ 06/Nov/14 ]

And actually, the opposite of detach() already exists: it is persist(). It makes the object enter the unit of work, while detach makes it leave the unit of work.

Note that merge is not making the object cross the boundary. The object passed to merge() never enters the unit of work. what happens is that the data inside this object are applied to an object inside the boundary (potentially a new one if there was no object with this identifier).
When using merge, you are explicitly asking to apply the data inside the unit of work, so it is logical that something gets flushed.

and note that in your example 1, your person is managed half of the time (when coming from find() rather than a new instance). And in such case, it will be flushed. You are not flushing only the dog.

Comment by Mathieu De Zutter [ 08/Nov/14 ]

OK, makes sense.





[DDC-3374] [GH-1175] removed "comments-as-vcs"-styled-comment Created: 06/Nov/14  Updated: 07/Nov/14  Resolved: 07/Nov/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: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: entitymanager, final


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 07/Nov/14 ]

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

Comment by Doctrine Bot [ 07/Nov/14 ]

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





[DDC-3373] [GH-1174] Fix associations with a custom type for identifiers Created: 06/Nov/14  Updated: 10/Nov/14  Resolved: 10/Nov/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates DDC-3380 [GH-1178] Fixing associations using U... Open

 Description   

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

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

Message:

I was running an experiment using a custom DBAL type, which converts a UUID string (in PHP) to 16 bytes binary string (in SQL) and vice versa, as identifier for a couple of entities. I noticed some associations weren't loaded correctly. This PR attempts to fix that issue.

I've included several tests:

  • Loading a OneToOne association
  • Loading a OneToOne association with composite identifier
  • Loading a OneToOne association with composite identifier including a foreign one
  • Loading a OneToMany association
  • Loading a OneToMany association with composite identifier
  • Loading a OneToMany association with composite identifier including a foreign one
  • Loading a ManyToMany association
  • Loading a ManyToMany association with composite identifier
  • Loading a ManyToMany association with composite identifier including a foreign one

During the "ManyToMany association tests ...", I discovered the join-table wasn't populated properly. The columns were filled with the UUID string (in stead of the 16 bytes binary string). This has been addressed as well.

I've included these tests to verify that:

  • Removing entities from a ManyToMany association
  • Removing entities from a ManyToMany association with composite identifier
  • Removing entities from a ManyToMany association with composite identifier including a foreign one

When applying a fix for the "Loading a OneToMany association with composite identifier including a foreign one" test, the "Loading a OneToOne association with composite identifier including a foreign one" test started to produce an error.

This is due to the Proxy object containing a 16 bytes binary string (in stead of the UUID string) for the foreign identifier.

Also the "Removing entities from a ManyToMany association with composite identifier including a foreign one" tests keeps failing because there's a 16 bytes binary string (in stead of the UUID string) for the foreign identifier in the Collection.

I have a feeling these last 2 cases are not because of an issue in the Persisters, but because of an issue in the Hydrators. Unfortunately I don't know where to begin looking

I could really need some help finishing this up!



 Comments   
Comment by Jasper N. Brouwer [ 07/Nov/14 ]

PS: I've applied this fix to the 2.4 branch (in stead of master) on purpose, because I'm going to use this in a project and unfortunately can't wait until it's merged back into 2.4.

If this is a problem and must be done on master, I'll look into that.

Comment by Marco Pivetta [ 07/Nov/14 ]

Jasper N. Brouwer multiple versions may be affected: we just need to be sure that the bug wasn't already fixed in master (2.5), so please check that one as well.

Comment by Jasper N. Brouwer [ 07/Nov/14 ]

Master is also affected. I think I've got some spare time this evening, so I'll port the PR to master.

Could you perhaps look at the remaining issue and maybe give some hint on where I should start looking? I would appreciate it if I could finish that up too this evening.

Comment by Doctrine Bot [ 09/Nov/14 ]

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

Comment by Jasper N. Brouwer [ 10/Nov/14 ]

The PR has been ported to master:

http://www.doctrine-project.org/jira/browse/DDC-3380
https://github.com/doctrine/doctrine2/pull/1178

This ticket can be closed.

Comment by Doctrine Bot [ 10/Nov/14 ]

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





[DDC-3372] PersistentCollection clear function takes snapshot when the collection is cleared Created: 06/Nov/14  Updated: 07/Nov/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: Minor
Reporter: Ward Peeters Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: collection, orm
Environment:

Symfony 2.5.6



 Description   

I'm not sure if it's a bug or you guys have a reason why you do it. The problem occurs when you do a $coll->clear() he will clear the collection and whenever it's cleared the takeSnapshot is ran as well so our snapshot is empty so we lose the prevous state of the collection.

public function clear()
    {
        if ($this->initialized && $this->isEmpty()) {
            return;
        }

        $uow = $this->em->getUnitOfWork();

        if ($this->association['type'] & ClassMetadata::TO_MANY &&
            $this->association['orphanRemoval'] &&
            $this->owner) {
            // we need to initialize here, as orphan removal acts like implicit cascadeRemove,
            // hence for event listeners we need the objects in memory.
            $this->initialize();

            foreach ($this->coll as $element) {
                $uow->scheduleOrphanRemoval($element);
            }
        }

        $this->coll->clear();

        $this->initialized = true; // direct call, {@link initialize()} is too expensive

        if ($this->association['isOwningSide'] && $this->owner) {
            $this->changed();

            $uow->scheduleCollectionDeletion($this);

            $this->takeSnapshot();
        }
    }


 Comments   
Comment by Marco Pivetta [ 07/Nov/14 ]

Can you please abstract your problem into a test case?

Comment by Ward Peeters [ 07/Nov/14 ]

if that helps yes. The problem is that i'm not sure it's a bug. It might be the way you guys wanted it to be.
I'll create a test case might be better to understand.

Comment by Marco Pivetta [ 07/Nov/14 ]

It looks like a bug to me: the snapshot should be taken only when no snapshot was there upfront, as far as I know.





[DDC-3371] MultiTableUpdateExecutor does not handle input parameters correctly within arithmetic expression assignments to updated fields Created: 05/Nov/14  Updated: 05/Nov/14

Status: Open
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: Michael Plomer Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

An update statement like

UPDATE MyEntity e SET e.value1 = e.value1 + :inParam1 WHERE e.value2 = :inParam2

will fail if MyEntity is part of a join table inheritance hierarchy and hence the update is handled by the MultiTableUpdateExecutor. The insert statement for the temporary ID table causes the following PDOException:

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

The problem is in counting the number of input parameters in the update part of the statement. Lines 127-131 of the MultiTableUpdateExecutor:

if ($newValue instanceof AST\InputParameter) {
    $this->_sqlParameters[$i][] = $newValue->name;
    ++$this->_numParametersInUpdateClause;
}

fall short in detecting input parameters unless they are directly assigned as new values.






[DDC-3370] [GH-1173] Fix merging of entities with associations to identical entities. Created: 05/Nov/14  Updated: 11/Nov/14  Resolved: 11/Nov/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
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: cascade, merge, unitofwork


 Description   

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

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

Message:

Without this patch, when an entity that refers multiple times to the same
associated entity gets merged, the second references becomes null.

The main issue is that even though doMerge returns a managed copy, that value
is not used while cascading the merge. These identicial entities are already
detected through the visitor map, but they are ignored. There should be some
refactoring so cascadeMerge calls a function that checks if the parent must be
updated, based on the return value of its call to doMerge. However, this patch
tries to impact the code as little as possible, and only introduces a new
function to avoid duplicate code.

The secondary issue arises when using inverted associations. In that case, it
is possible that an entity to be merged is already merged, so the the visitor
map is looked up by the hash of a managed copy instead of the original entity.
This means that in this case the visitor map entries should also be set to the
entity, instead of being set to 'true'.



 Comments   
Comment by Doctrine Bot [ 11/Nov/14 ]

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

Comment by Doctrine Bot [ 11/Nov/14 ]

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





[DDC-3369] Association Entity primary key composite with foreign keys Created: 04/Nov/14  Updated: 05/Nov/14  Resolved: 05/Nov/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: Saydev Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: mapping, orm
Environment:

Projet Symfony 2



 Description   

Impossible to make an association between two entities in the following cases:

Entity1 with a composite primary key :
key1 (PK)
key2 (PK)

Entity2 with a composite primary key (with foreign key) :
key1 (PK FK)
key2 (PK FK)
key3 (PK)

How to connect two entities with this scenario?



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

This actually works as long as key1, key2 and key3 are user-generated values (such as UUIDs). We cannot support the case when these values are db-side generated.

Comment by Saydev [ 05/Nov/14 ]

Can we get around this problem ?





[DDC-3368] [GH-1172] Don't initialize detached proxies when merging them. Created: 02/Nov/14  Updated: 12/Nov/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: 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 mathieudz:

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

Message:

Ticket DDC-1392 fixed an issue where uninitialized proxies could not be merged
because the merge routine couldn't get the identifier from them. The soution
was to initialize the proxy.
Ticket DDC-1734 fixed the merging of unserialized uninitialized proxies by
resetting their internals, so these proxies were able to initialize, as required
by the fix for DDC-1392.

Somehow, in the meanwhile, the fix for DDC-1392 is not needed anymore:
reverting the patch will not break the associated test (but it does break the
test for DDC-1734). This means it is not needed anymore to initialize the proxy
when merging.

Uninitialized proxies that get merged should not be loaded at all. Since they
are not initialized, the entity data for sure hasn't changed, so it can be
safely ignored. Actually, the only thing the data is needed for while merging,
is to copy it into the managed entity, but that one is already supposed to be
up to date. By not initializing the proxy, a potential database roundtrip is
saved, and the fix for DDC-1734 is not needed anymore.

Besides optimizing the merge, this patch also solves an issue with merging.
Currently, when a detached uninitialized proxy is merged while there is already a
corresponding managed entity (proxy or not), the ORM returns a blank entity
instead of returning the already managed entity. This patch makes sure that
already existing managed entities are re-used.



 Comments   
Comment by Doctrine Bot [ 12/Nov/14 ]

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





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

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

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


 Description   

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

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

Message:

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

Suppose you create a query as such:

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

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

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

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

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

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

,
'address'=>

{AddressDTO object}

,
'addressId'=>

{a.id scalar}

)
...
)
```






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

Status: Resolved
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: Doctrine Bot Assignee: Marco Pivetta
Resolution: Can't Fix Votes: 0
Labels: collection, interface, iterator


 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.



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

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

Comment by Doctrine Bot [ 13/Nov/14 ]

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

Comment by Marco Pivetta [ 13/Nov/14 ]

Can't be done in 2.x





[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-3363] "The EntityManager is closed." after insert error. Created: 25/Oct/14  Updated: 05/Nov/14  Resolved: 05/Nov/14

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

Issue Links:
Duplicate
duplicates DDC-1037 The EntityManager is closed when an e... Resolved

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

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

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

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

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

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






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

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

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


 Description   

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

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

Message:

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

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

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



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

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





[DDC-3361] Doctrine error while trying to execute a DQL query on PostgreSQL 9.2.x Created: 23/Oct/14  Updated: 08/Nov/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 . '%');
Comment by Reynier Perez Mira [ 08/Nov/14 ]

Hi there @ocramius any advice around this issue? Any tip to get ride of this? I have similar queries all over the application I'm working on and still don't know how to deal with this, thanks

Comment by Marco Pivetta [ 08/Nov/14 ]

Seems to be a db-side type mismatch in a comparison, not a D2 bug.

Comment by Reynier Perez Mira [ 08/Nov/14 ]

@ocramius and how I should deal with this? Any idea?





[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-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-3358] [GH-1166] Fixing HHVM+XSD validation tests as of documented HHVM inconsistencies Created: 20/Oct/14  Updated: 07/Nov/14  Resolved: 07/Nov/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: ci, hhvm, travis, xml


 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-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-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-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-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-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-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-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-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-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-3348] [GH-1158] Update QueryBuilder reference documentation. Created: 12/Oct/14  Updated: 13/Oct/14  Resolved: 13/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 josemalonsom:

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

Message:

  • Updated the signature of methods "from", "innerJoin" and "leftJoin"
    since it does not match the actual implementation.
  • Added reference to the "join" method.


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

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

Comment by Doctrine Bot [ 13/Oct/14 ]

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





[DDC-3347] [GH-1157] Fixing calls of schema-update tools Created: 12/Oct/14  Updated: 13/Oct/14  Resolved: 13/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 gennadiylitvinyuk:

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

Message:

composer-generated binaries should be called without php interpreter.

Added reminder to update schema.






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

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

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


 Description   

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

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

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

For instance, the generated SQL statement generated might look like

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





[DDC-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-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-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-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-3341] SessionValidator gives an error message on orderBy association, but it is no error. Created: 07/Oct/14  Updated: 13/Oct/14

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

Type: Bug Priority: Minor
Reporter: Tobias Feijten Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orderBy, orm


 Description   

For @OrderBy annotations, the \Doctrine\ORM\Tools\SchemaValidator only checks if a field with the designated name exists at the designated Entity.
In the case of ordering on an association, defined in the target Entity, this is of course not the case, rendering an error like "The association Idb\TicketBundle\Entity\Ticket#ticketReservations is ordered by a foreign field ticketreservationtype_id that is not a field on the target entity Idb\TicketBundle\Entity\TicketReservation"
However, the \Doctrine\ORM\Persisters\BasicEntityPersister\getOrderBySQL function perfectly supports associations to order on.
Therefore, the error message should not be given when using an association existing at the designated Entity, as it's working and no mistake.
Could this be fixed?



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

Tobias Feijten provide a failing test case to demonstrate the problem first

Comment by Tobias Feijten [ 07/Oct/14 ]

Idb\TicketBundle\Entity\Ticket

namespace Idb\TicketBundle\Entity;

use Doctrine\ORM\Mapping as ORM;

class Ticket {

  /**
   * @ORM\OneToMany(targetEntity="Idb\TicketBundle\Entity\TicketReservation", mappedBy="ticket", cascade={"persist","remove"})
   * @ORM\OrderBy({"ticketReservationType" = "ASC", "amount" = "DESC"})
   */
  private $ticketReservations;

}

Idb\TicketBundle\Entity\TicketReservation

namespace Idb\TicketBundle\Entity;

use Doctrine\ORM\Mapping as ORM;

class TicketReservation {

  /**
   * @ORM\ManyToOne(targetEntity="Idb\TicketBundle\Entity\TicketReservationType")
   * @ORM\JoinColumn(name="ticketreservationtype_id", referencedColumnName="id")
   */
  private $ticketReservationType;

  /**
   * @var integer
   * @ORM\Column(name="amount", type="integer", nullable=false)
   */
  private $amount;

}

The orderBy on amount gives no error when validating the schema, the orderBy on ticketReservationType does (* The association Idb\TicketBundle\Entity\Ticket#ticketReservations is ordered by a foreign field ticketReservationType that is not a field on the target entity Idb\TicketBundle\Entity\TicketReservation).
However, the orderBy statement is not wrong as it is carried out perfectly when using the code.
The only problem is when validating.

Comment by Tobias Feijten [ 13/Oct/14 ]

Marco Pivetta Any progress on this one yet? Or do you need more information?

Comment by Marco Pivetta [ 13/Oct/14 ]

Any progress on this one yet?

No, no progress so far, and I can't allocate time for D2 over the next few weeks.
As for the information amount, it seems sufficient to me: we are probably just using field mappings without checking association mappings when looking for order fields. There is still a problem about what to do with composite identifiers or derived identifiers, but it should be covered by tests first.





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

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

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


 Description   

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



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

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

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

Comment by Marco Pivetta [ 07/Oct/14 ]

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

Also, which version is affected?

Comment by Christophe Coevoet [ 13/Oct/14 ]

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

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

Comment by Marco Pivetta [ 13/Oct/14 ]

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

Comment by Marco Pivetta [ 13/Oct/14 ]

As an example:

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

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

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

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

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

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

Comment by Marco Pivetta [ 13/Oct/14 ]

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

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

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

Comment by Marco Pivetta [ 13/Oct/14 ]

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

A test for that would be (pseudo):

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

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

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

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

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

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




[DDC-3339] [GH-1154] Hotfix/php 5.6 serialization fix Created: 06/Oct/14  Updated: 06/Oct/14  Resolved: 06/Oct/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4, 2.4.1, 2.4.2, 2.4.3, 2.4.4, 2.4.5
Fix Version/s: 2.4.6
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: mapping

Issue Links:
Reference
relates to DDC-3120 Warning: Erroneous data format for un... Resolved

 Description   

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

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

Message:

See DDC-3120 ( http://www.doctrine-project.org/jira/browse/DDC-3120 )

This PR provides a backport for the 2.4 branch



 Comments   
Comment by Steve Müller [ 06/Oct/14 ]

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

Comment by Dominik Zogg [ 06/Oct/14 ]

Thx you





[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-3337] Changes in @UniqueConstraint annotation are not synced by orm:schematool Created: 06/Oct/14  Updated: 06/Oct/14

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

Type: Bug Priority: Minor
Reporter: Andreas Goetz Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

If the only metadata cahnges is the uniqueconstraint annotation, e.g. the contraint name, orm:schema is not able to sync this hcange to the database.
Instead, it claims "nothing to do".






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

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

Type: Bug Priority: Critical
Reporter: Glen Ainscow Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: ast, dql, limitsubqueryoutputwalker, paginator

Issue Links:
Dependency
depends on DDC-3433 [GH-1210] DDC-3336 - undefined proper... Resolved
Reference
relates to DDC-1958 pager produces wrong results on postg... Resolved
is referenced by DDC-3434 LimitSubqueryOutputWalker does not re... 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.

Comment by Marco Pivetta [ 05/Dec/14 ]

The first comment goes to a new issue.

Comment by Marco Pivetta [ 05/Dec/14 ]

Moved that issue to DDC-3434

Comment by Doctrine Bot [ 05/Dec/14 ]

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

Comment by Doctrine Bot [ 05/Dec/14 ]

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





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

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

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


 Description   

This:

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

causes this:

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

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






[DDC-3334] Allow to set @Id in @AttributeOverride Created: 02/Oct/14  Updated: 02/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: Improvement Priority: Minor
Reporter: Jakob Schumann Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: annotation, orm, primary-key


 Description   

Hello!

@AttributeOverride only allows to change the column definition of a property that is defined in a parent class or trait. It is not possible to define such an "foreign" column (through inheritance/trait) as ID column and also there is no possibility define the primary key through any other annotation.

It would be greatly useful to extend the @AttributeOverride to allow specification of @ID, @GeneratedValue and @CustomIdGenerator in this annotation as those are also property/attribute related and there is no reason those should not be overrideable.

Example:

trait ForeignColumn
{
    /**
     * @ORM\Column(type="string", nullable=true)
     */
    protected $foreignColum = null;
}

/**
 * @ORM\Entity()
 * @ORM\AttributeOverrides({
 *      @ORM\AttributeOverride(name="foreignColum",
 *          column=@ORM\Column(type="string", nullable=false),
 *      )
 * })
 */
class MyEntity {
  use ForeignColum;

    /**
     * @ORM\Id
     * @ORM\Column(type="string", nullable=false)
     */
    protected $myColum = null;
}

In this example it is not possible to add the property to the class again and annotate it directly as this would throw a Strict Error as trait properties cannot be overwritten.

It is also not possible to create a composite key with foreignColumn and myColumn (and it is also not be possible to define only foreignColumn as primary key without modifying the trait).






[DDC-3333] doctrine:schema:update --complete does not detect old index Created: 02/Oct/14  Updated: 02/Oct/14

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

Type: Bug Priority: Minor
Reporter: Grégoire Paris Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: postgresql, schematool
Environment:

Ubuntu 14.04, PostgreSQL 9.3



 Description   

When changing the name of an index and using the symfony proxy command doctrine:schema:update --complete --dump-sql, the output only shows a CREATE statement. I would expect to also see a DROP statement. Here is what my index definition looks like :

    indexes:
        admin_entity_created_at_index:
            columns: [ createdAt ]





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

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

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


 Description   

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

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

Message:

An example is:

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

When User has a composite key.



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

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





[DDC-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-3330] Bad Pagination - rows with sorted collection Created: 29/Sep/14  Updated: 29/Sep/14

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

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

Ubuntu 12.04, PHP 5.5.3


Attachments: File DDC3330Test.php    

 Description   

I use the Doctrine Paginator to be able to have a correct pagination with collection.
I followed the documentation here:
http://doctrine-orm.readthedocs.org/en/latest/tutorials/pagination.html

It works well in most cases but there is a problem when ordering on a property of the entity + on an other property of the collection.

See the failing unit test I joined to this ticket.






[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-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