[DDC-3645] [GH-1353] Paginator fixes take3 Created: 27/Mar/15  Updated: 27/Mar/15

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 zeroedin-bill:

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

Message:

This PR fixes issues reported in #1347 and #1351.

  • Ordering a query by a column from an association which uses SINGLE_TABLE inheritance no longer throws an error.
  • Limiting a query which is ordered by fields from a joined -To-Many association now works as expected.

This patch converts LimitSubqueryOutputWalker to use the ROW_NUMBER window function for queries on platforms that support it. Other platforms use a modified version of the previous method. The modification is to not select the ORDER BY columns in the wrapping query. The reason those columns were selected like that in the first place is that ORDER BY on columns not in the select list is unsupported on many platforms. MySQL and SQLite are fine with it, and don't support ROW_NUMBER.

The ROW_NUMBER solution is actually much simpler.

LimitSubqueryOutputWalker SQL generation tests for PG and Oracle have been changed.

*There are 2 failing expectedException tests right now.* The LimitSubqueryWalker needs to be modified to throw an exception when it detects a query that does the following things together:

  • Joins a -To-Many association
  • Orders by a column from the associated entity
  • Limits the result

As with the previous patch, this depends on changes to SQLServerPlatform2008 that have not yet been merged. SQLServerPlatform2008 in DBAL/master currently mangles the generated queries when trying to apply LIMIT/OFFSET.






[DDC-3644] One To Many Relationships do not properly support Orphan Removal Created: 27/Mar/15  Updated: 27/Mar/15

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

Type: New Feature Priority: Major
Reporter: Jarrett Croll Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

After speaking to @guilhermeblanco you assume the following method is unreachable when in fact it is not:

https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Persisters/Collection/OneToManyPersister.php#L39

If an entity currently has a persistent collection in a 1-m relationship and that persistent collection is replaced with a new collection the entities not contained in that new collection should be scheduled for deletion but they are not.






[DDC-3643] [GH-1352] fix EntityGenerator RegenerateEntityIfExists Created: 27/Mar/15  Updated: 27/Mar/15

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/1352

Message:

Fix for Class generator,
when class already exists and `$generator->setRegenerateEntityIfExists(true);`






[DDC-3642] [GH-1351] Failing test cases regarding to #1325 #1337 Created: 27/Mar/15  Updated: 30/Mar/15

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 30/Mar/15 ]

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





[DDC-3641] [GH-1350] Assigned default value to array Created: 26/Mar/15  Updated: 27/Mar/15

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

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


 Description   

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

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

Message:

  • For strict configurations of PHP, we were accessing to a non-array element


 Comments   
Comment by Doctrine Bot [ 27/Mar/15 ]

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





[DDC-3640] Force version increment via mapped property Created: 26/Mar/15  Updated: 27/Mar/15

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

Type: Improvement Priority: Minor
Reporter: Darien Hager Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mapping, orm

Issue Links:
Reference
relates to DDC-2864 New type of lock: OPTIMISTIC_FORCE_IN... Open
relates to DDC-1507 State change detection for version in... Open

 Description   

Existing feature:

It is currently possible to use optimist-locking against an entity through a version code or timestamp, which becomes incremented when the entity changes. Unfortunately, there is no way for an entity to signal that its version should be incremented when no (direct) changes have occurred.

Problem:

Sometimes you want to control or gate wide-spread or indirect changes via a particular entity, such as the root of a tree of other mutable entities. This is particularly common in Domain Driven Design.

Proposal:

Create a new configuration option for a PHP property that identifies it as a "version incrementor flag". It is only legal on entities that also have a version-field. This field will always be set to false when an entity is hydrated.

When entities are being checked for changes and flushed, this flag will (if it evaluates to true) force the version-field to update. Note that if the entity has "real changes", it will be saved and the version-field will update regardless. At the end of this process, the field is reset back to false.

This allows the user to write code such as:

Entity example

    /** @Version @Column(type="integer") */
    private $version;

    /** @VersionIncrementFlag */
    $changed = false;

    /** @OneToMany(targetEntity="Child", mappedBy="parent") */
    private $children;    

    public function zeroChildren(){
        foreach($this->children as $child){
            $child->setValue(0);
        }
        $this->changed = true; // Where $changed is the incrementor flag
    }    

Issues with other approaches:

The current workaround of a "junk column" is... suboptimal. It requires a junk data column in the database, and its presence does not easily capture the intent of the user. It also leads to extra database operations, since the junk data has to be saved no matter what.

Adding a specialized method to EntityManager, like with $em->touchVersion($entity); is also problematic, since it means you cannot conveniently trigger the new behavior when deep inside the object-graph.



 Comments   
Comment by Darien Hager [ 26/Mar/15 ]

I'm willing to try implementing this if folks feel it could get included.

Comment by Darien Hager [ 27/Mar/15 ]

I have a proof-of-concept working based off of 2.4.7, you can see a diff here:

https://github.com/doctrine/doctrine2/compare/2.4...DHager:force_version_increment

As of this writing, it can only be configured via XML. Here's a minimal example, for a table that has only two columns, an ID and a version.

<?xml version="1.0" encoding="utf-8"?>
<doctrine-mapping xmlns="http://doctrine-project.org/schemas/orm/doctrine-mapping" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://doctrine-project.org/schemas/orm/doctrine-mapping http://doctrine-project.org/schemas/orm/doctrine-mapping.xsd">
  <entity name="Example\Foo" table="example">

    <special-properties>
        <special-property name="vflag" type="versionIncFlag"/>
    </special-properties>

    <id name="id" type="integer" column="id"/>

    <field name="version" type="integer" column="version" version="true" nullable="false"/>

  </entity>
</doctrine-mapping>

The new <special-properties> section is intended to refer to PHP object-properties which are not mapped fields, but which still have significance to Doctrine. In PHP-land, it's as simple as:

        $targetId = 1;
        /** @var $em EntityManager */                
        /** @var $foo Foo */
        $foo = $em->find("Example\Foo",$targetId); // Hardcoded ID
        $foo->vflag = true; // TODO make private, use setter
        $em->persist($foo);
        $em->flush();

Afterwards, the "version" column in the DB for the row should be incremented, even though no "real" fields were changed:

UPDATE example SET version = version + 1 WHERE id = ? AND version = ?




[DDC-3639] [GH-1349] Fix #1347 Created: 26/Mar/15  Updated: 27/Mar/15

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 zeroedin-bill:

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

Message:

This PR fixes #1347.



 Comments   
Comment by Doctrine Bot [ 27/Mar/15 ]

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





[DDC-3638] [GH-1348] Doctrine mapping:import command Created: 25/Mar/15  Updated: 25/Mar/15  Resolved: 25/Mar/15

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

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

Message:

Why I cannot find this command:

`` php app/console doctrine:mapping:import --force AcmeBlogBundle xml ``
[here](http://doctrine-orm.readthedocs.org/en/latest/reference/tools.html?highlight=command) I mean mapping:import command.

I already replace this command:

`` php app/console doctrine:mapping:convert xml ./src/Acme/BlogBundle/Resources/config/doctrine/metadata/orm --from-database --force ``
with

`` sudo vendor/bin/doctrine orm:convert-mapping xml '/var/www/html/laravel/package' --from-database --force ``
and worked well.



 Comments   
Comment by Doctrine Bot [ 25/Mar/15 ]

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

Comment by Doctrine Bot [ 25/Mar/15 ]

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





[DDC-3637] [GH-1347] problem with LimitSubqueryOutputWalker when use InheritanceType Created: 25/Mar/15  Updated: 25/Mar/15

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 alexander-orabey:

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

Message:

When we use InheritanceType ("SINGLE_TABLE") catch exception that field in joined class does not exist in base class.



 Comments   
Comment by Doctrine Bot [ 25/Mar/15 ]

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





[DDC-3636] cannot extend ClassMetadataFactory Created: 25/Mar/15  Updated: 25/Mar/15  Resolved: 25/Mar/15

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

Type: Improvement Priority: Major
Reporter: Jurj Alin Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

We cannot extend the `ClassMetadataFactory` because most of the members are private.
Use case:
I have to overwrite only the `getShortName` and because most are private i need to copy/paste all the other private methods in my extended class just to make it work



 Comments   
Comment by Marco Pivetta [ 25/Mar/15 ]

The class metadata factory is not designed to be extensible, as it is an internal doctrine component.

Comment by Jurj Alin [ 25/Mar/15 ]

i understand that, however we are talking about custom discriminator value, nothing else, for example if i have the entity Application\Entity\User as the discriminator, it will be converted to `user`. Thats what i'm trying to do, just to allow different discriminator generation

Comment by Marco Pivetta [ 25/Mar/15 ]

Can't this simply be fixed via explicit mapping or via an event handler?





[DDC-3635] QueryBuilder - INSTANCE OF with parameter not working Created: 24/Mar/15  Updated: 25/Mar/15

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

Type: Bug Priority: Major
Reporter: Wouter Wiltenburg Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: binding, dql, parameter
Environment:

Zend Framework 2



 Description   

I use single table class inheritance.
When I write my INSTANCE OF clause in my QueryBuilder like this:

    $result = $this->createQueryBuilder('o')
        ->leftJoin('o.child', 'c')
        ->where('c INSTANCE OF :entity_class')
        ->setParameter('entity_class', 'My\Entity\Class')
        ->getQuery()
        ->getResult();

It does not work correctly. The problem seems to lie in the fact that the parameter is bound to the SQL query. So if I change the entity_class to the discriminator column name it works correctly.

So if the discriminator value for My\Entity\Class would be discriminator then this does work:

    $result = $this->createQueryBuilder('o')
        ->leftJoin('o.child', 'c')
        ->where('c INSTANCE OF :entity_class')
        ->setParameter('entity_class', 'discriminator')
        ->getQuery()
        ->getResult();

So the step for getting the discriminator column from the class name is missing and instead the class name is bound to the MySql query directly.






[DDC-3634] [GH-1346] Fix: generated IDs are converted to integer Created: 23/Mar/15  Updated: 23/Mar/15  Resolved: 23/Mar/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 1
Labels: autogeneration, autoincrement, big-integer, identifier


 Description   

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

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

Message:

When I try to use type `bigint` and `@GeneratedValue` together, generated value is converted to integer.

See PHP documentation http://php.net/manual/en/language.types.array.php

> Strings containing valid integers will be cast to the integer type. E.g. the key "8" will actually be stored under 8. On the other hand "08" will not be cast, as it isn't a valid decimal integer.



 Comments   
Comment by Doctrine Bot [ 23/Mar/15 ]

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

Comment by Doctrine Bot [ 23/Mar/15 ]

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

Comment by Doctrine Bot [ 23/Mar/15 ]

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





[DDC-3633] Schema creation problem on PostgreSQL Created: 22/Mar/15  Updated: 22/Mar/15

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

Type: Bug Priority: Major
Reporter: Dmitry Korotovsky Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: schematool


 Description   

Schema tool can't create correct schema on empty database in PostgreSQL:

$ php app/console doctrine:schema:create --env=test
ATTENTION: This operation should not be executed in a production environment.

Creating database schema...

[Doctrine\ORM\Tools\ToolsException]
Schema-Tool failed with Error 'An exception occurred while executing 'CREATE SCHEMA public':
SQLSTATE[42P06]: Duplicate schema: 7 ERROR: schema "public" already exists' while executing DDL: CREATE SCHEMA public






[DDC-3632] [GH-1345] Fix crashes in ConvertMappingCommand and GenerateEntitiesCommand... Created: 20/Mar/15  Updated: 23/Mar/15  Resolved: 23/Mar/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: discriminator-map, inheritance, metadata, reflection


 Description   

This issue is created automatically through a Github pull request on behalf of zeroedin-bill:

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

Message:

... when using entities with joined table inheritance

ConvertMappingCommand and GenerateEntitiesCommand both use the DisconnectedClassMetadataFactory, which allows metadata manipulation without loading the associated classes. Commit a36bea broke these two commands by adding a bailout condition in ClassMetadataFactory::populateDiscriminatorValue which checks $metadata->reflClass->isAbstract(). If the DisconnectedClassMetadataFactory is being used, $metadata->reflClass will always be null, causing a fatal error, "Fatal error: Call to a member function isAbstract() on null".

This commit adds a check to see if $metadata->reflClass is set before checking isAbstract.



 Comments   
Comment by Doctrine Bot [ 22/Mar/15 ]

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

Comment by Doctrine Bot [ 22/Mar/15 ]

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

Comment by Doctrine Bot [ 22/Mar/15 ]

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

Comment by Doctrine Bot [ 23/Mar/15 ]

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





[DDC-3631] [GH-1344] Fix tests for SLC console commands failing due to console output decoration Created: 20/Mar/15  Updated: 22/Mar/15  Resolved: 22/Mar/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: cache, console, second-level-cache, tools


 Description   

This issue is created automatically through a Github pull request on behalf of zeroedin-bill:

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

Message:

The tests for the SLC console commands were failing on my box because the console output was being decorated with ANSI color codes, while the test assertions were using undecorated strings.

This PR turns off output decoration when these console commands are executed in the tests.



 Comments   
Comment by Doctrine Bot [ 20/Mar/15 ]

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

Comment by Doctrine Bot [ 22/Mar/15 ]

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

Comment by Doctrine Bot [ 22/Mar/15 ]

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





[DDC-3630] [GH-1343] Support embeddables in partial object query expression [DDC-3621] Created: 20/Mar/15  Updated: 25/Mar/15  Resolved: 23/Mar/15

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: dql, embeddables, hydration, partial

Issue Links:
Dependency
is required for DDC-3621 Support embeddables in partial object... Resolved

 Description   

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

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

Message:

I don't see any existing tests covering this class, but all existing tests pass with this change.



 Comments   
Comment by Doctrine Bot [ 22/Mar/15 ]

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

Comment by Doctrine Bot [ 23/Mar/15 ]

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

Comment by Doctrine Bot [ 23/Mar/15 ]

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

Comment by Doctrine Bot [ 23/Mar/15 ]

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

Comment by Doctrine Bot [ 23/Mar/15 ]

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





[DDC-3629] [GH-1342] Paginator functional tests Created: 19/Mar/15  Updated: 24/Mar/15  Resolved: 24/Mar/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: distinct, mssql, oracle, orderBy, orderby, paginator, postgresql

Issue Links:
Dependency
depends on DDC-3623 [GH-1337] Paginator OrderBy fix take 2 Resolved
is required for DDC-3606 [GH-1325] fixed PostgreSQL and Oracle... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of zeroedin-bill:

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

Message:

PaginationTest has been expanded and now covers ordering and limiting rather thoroughly.

4 tests fail on PostgreSQL and MySQL, 14 tests fail on SQL Server, and I didn't try any other DBMS.



 Comments   
Comment by Doctrine Bot [ 22/Mar/15 ]

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





[DDC-3628] Embeddable Array Hydration Issue Created: 19/Mar/15  Updated: 19/Mar/15  Resolved: 19/Mar/15

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

Type: Bug Priority: Major
Reporter: RJ Garcia Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: array, hydration, orm
Environment:

Mac OS X 10.10.2

PHP 5.6.6 (cli) (built: Mar 10 2015 14:21:21)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies
with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2015, by Zend Technologies


Attachments: File B5.Mdl.Bite5.CoverPhoto.CoverPhoto.dcm.yml     File B5.Mdl.Bite5.CoverPhoto.CoverPhotoCollection.dcm.yml    

 Description   

I've stumbled across the doctrine embeddable system, and it's been working great; however, I found an inconsistency with the array hydration.

Attached are my configuration files for my parent object and the embeddable. When doing a simple query to retrieve the parent object and use `getArrayResult`, I get the following data structure

[cover_photos] => Array
                (
                    [id] => ..
                    [url_key] => ...
                    [original.width] => ...
                    [original.height] => ...
                    [original.url] => ...
                    [original.type] => ..
                    [cropped.width] => ..
                    [cropped.height] => ..
                    ...
                )

This is inconsistent with how normal hydration works where the expected result would be something like

[coverphotos] => Array
    (
        [id] => ..
        [url_key] => ..
        [original] => Array
        (
           ...
        )
    )


 Comments   
Comment by Marco Pivetta [ 19/Mar/15 ]

This is actually expected behavior, IMO

Comment by Benjamin Eberlei [ 19/Mar/15 ]

Maybe we could document this, as it is a bit weird. But from my perspective this is ok as well. Everything else is very expensive to implement, not sure if its worth the benefit.

Comment by RJ Garcia [ 19/Mar/15 ]

Well, currently, I'm working around the issue with the following function

function array_expand(&$array, $separator = '.')
{
    $keys_to_recurse = [];
     foreach ($array as $key => $value) {
        $sep_position = strpos($key, $separator);

        if ($sep_position === false) {
            continue;
        }

        $prefix = substr($key, 0, $sep_position);
        $suffix = substr($key, $sep_position + 1);

        if (!array_key_exists($prefix, $array)) {
            $array[$prefix] = [];
            $keys_to_recurse[] = $prefix;
        }

        $array[$prefix][$suffix] = $value;
        unset($array[$key]);
     }

     foreach ($keys_to_recurse as $key) {
        array_expand($array[$key], $separator);
     }
}

Personally, as a user of this embeddable's feature, in my specific usage of the embeddables with array hydration, I need them in hierarchal format. I'm not too familiar with the hydration internals, so I can't comment on the difficulty of expanding the embeddable entities into structured hierarchal data

Comment by Marco Pivetta [ 19/Mar/15 ]

RJ Garcia is there any reason why you're using array hydration here?

Adding this change to the ArrayHydrator is actually problematic/complex (and a BC break now, since we froze 2.5.0-beta1 yesterday).

I would suggest keeping it out of the ORM.

Comment by RJ Garcia [ 19/Mar/15 ]

Yes, I was running into issues with prefetching in my query. Even though I had prefetched all of my desired associations, doctrine was still performing extra queries to load associations that I wasn't using/wanted. After I fetched my main entity collection, I needed to traverse it (perform some changes) and convert to arrays for outputting in a JSON api. When I traversed the object graph, doctrine would run queries on sub entities that I didn't want. When I switched to array hydration, naturally, I didn't get any of those extra queries when I traversed the array structure. I've also found better performance results when using array hydration, and because I'm only querying my entities to export them into JSON, I don't need full data/entity consistency.

Just recently, I stated using embeddables, and that's how I found out about the array hydration difference (because I was already using array hydration).

Comment by Marco Pivetta [ 19/Mar/15 ]

Resolving as won't fix since at this point, this is a BC break and is also quite complex/useless to solve from our perspective (we did have some internal discussion about it).





[DDC-3627] [GH-1341] [doc] Minor fixes and typos Created: 18/Mar/15  Updated: 18/Mar/15  Resolved: 18/Mar/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Documentation
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: documentation, typo


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 18/Mar/15 ]

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

Comment by Doctrine Bot [ 18/Mar/15 ]

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





[DDC-3626] [GH-1340] Add inversed by annotations on auto generate entities Created: 18/Mar/15  Updated: 23/Mar/15  Resolved: 23/Mar/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Tools
Affects Version/s: None
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: bidirectional, entityGenerator


 Description   

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

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

Message:

Add inversed by annotations on auto generate entities.

Source:
http://w3facility.org/question/symfony2-doctrine2-generate-one-to-many-annotation-from-existing-database-by-doctrinemappingimport/#answer-17881139



 Comments   
Comment by Doctrine Bot [ 23/Mar/15 ]

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





[DDC-3625] [GH-1339] [DDC-2224] Honor convertToDatabaseValueSQL() in DQL query parameters Created: 18/Mar/15  Updated: 25/Mar/15  Resolved: 25/Mar/15

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

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

Issue Links:
Dependency
is required for DDC-2224 convertToDatabaseValueSQL() is not ho... Resolved

 Description   

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

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

Message:

This is a follow-up to the abandoned #574 by @mnapoli, that fixes DDC-2224(http://www.doctrine-project.org/jira/browse/DDC-2224).

At the time, @beberlei closed the PR for the following reason, deemed unfixable:

> Passing a type into the parameters is not recognized during caching, that means, using a DQL cache, the same DQL statement with (different parameter types) will lead to the same SQL being generated, depending on if the first or the second set parameter query is executed first.

This PR re-integrates the original fix, and offers a solution to the above issue: take the parameter types into account when checking the local `ParserResult` and the query cache.

In addition to the test for the DDC-2224 issue, I added a test to ensure that changing a parameter type invalidates the cache.



 Comments   
Comment by Doctrine Bot [ 23/Mar/15 ]

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

Comment by Doctrine Bot [ 25/Mar/15 ]

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

Comment by Doctrine Bot [ 25/Mar/15 ]

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





[DDC-3624] [GH-1338] [DDC-3619] Update identityMap when entity gets managed again Created: 17/Mar/15  Updated: 17/Mar/15  Resolved: 17/Mar/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: garbage-collection, identity-map, object-hash, persist, remove, unitofwork

Issue Links:
Dependency
is required for DDC-3619 spl_object_hash collision Resolved
Reference
relates to DDC-3619 spl_object_hash collision Resolved

 Description   

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

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

Message:

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

When using SoftDeleteable doctrine extension, an entity can be scheduled
for deletion, then persisted before flushing. In such a case, the entity
was removed from the unit of work identity map and no reference was
hold. This could lead to spl_object_hash collisions, and prevent
another, new entity to be persisted later.

This fix makes sure the unit of work identity map holds a reference to
the entity after it has been soft-deleted.



 Comments   
Comment by Doctrine Bot [ 17/Mar/15 ]

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

Comment by Doctrine Bot [ 17/Mar/15 ]

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

Comment by Doctrine Bot [ 17/Mar/15 ]

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





[DDC-3623] [GH-1337] Paginator OrderBy fix take 2 Created: 17/Mar/15  Updated: 24/Mar/15  Resolved: 24/Mar/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: distinct, mssql, oracle, orderBy, paginator, postgresql

Issue Links:
Dependency
is required for DDC-3606 [GH-1325] fixed PostgreSQL and Oracle... Resolved
is required for DDC-3629 [GH-1342] Paginator functional tests Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of zeroedin-bill:

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

Message:

This PR fixes issues created in #1220, reported in #1267. The original PR was reverted in #1283.

The issue was that in queries ordered by joined association columns, the joined column aliases did not exist in the outer query created in LimitSubqueryOutputWalker.

This PR adds functionality to LimitSubqueryOutputWalker which finds any such columns referenced in the OrderBy clause, and adds them to the SelectStatement prior to SQL generation.



 Comments   
Comment by Doctrine Bot [ 17/Mar/15 ]

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

Comment by Doctrine Bot [ 17/Mar/15 ]

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

Comment by Doctrine Bot [ 24/Mar/15 ]

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





[DDC-3622] [GH-1336] Fix UoW warning with custom id object types Created: 17/Mar/15  Updated: 17/Mar/15  Resolved: 17/Mar/15

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

Type: Bug Priority: Critical
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: custom-dbal-type, identifier, identity, identity-map, object, string-cast


 Description   

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

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

Message:

`UnitOfWork::tryGetById()` and `UnitOfWork::tryGetByIdHash()` may receive an object as an id, for instance when using a custom id type like [Rhumsaa\Uuid](https://github.com/ramsey/uuid/blob/2.8.0/src/Doctrine/UuidType.php).

This PR adds a simple cast to string in these methods.

There are a couple of things I'm not sure about, tho.

First of all, I don't know if functional tests alone are deemed sufficient, but I couldn't figure out how to replicate the issue via unit tests only (apart from directly invoking the two methods above with an object as argument, which looks a bit pointless).

Furthermore, I don't know if the cast should be applied elsewhere; so far the only cases I stumbled upon where common find and fetch joins, but I saw other methods where it may be necessary (i.e. [here](https://github.com/doctrine/doctrine2/blob/878f2455eee79f1573d2bb1f8c01be93f758779b/lib/Doctrine/ORM/UnitOfWork.php#L1559) and [here](https://github.com/doctrine/doctrine2/blob/878f2455eee79f1573d2bb1f8c01be93f758779b/lib/Doctrine/ORM/UnitOfWork.php#L1625)), but I couldn't replicate the code path to reach those.
Also I wonder if an exception should be thrown if the id object doesn't implement `__toString()`, and in this case if the fix should be refactored into `Doctrine\ORM\Utility\IdentifierFlattener`, for a bit of SoC.

Let me know what you think.



 Comments   
Comment by Doctrine Bot [ 17/Mar/15 ]

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





[DDC-3621] Support embeddables in partial object query Created: 17/Mar/15  Updated: 25/Mar/15  Resolved: 23/Mar/15

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

Type: Improvement Priority: Minor
Reporter: Karl Rixon Assignee: Guilherme Blanco
Resolution: Duplicate Votes: 0
Labels: None

Issue Links:
Dependency
depends on DDC-3630 [GH-1343] Support embeddables in part... Resolved

 Description   

Hi,

Currently it's not possible to combine embeddables and partial objects - for example:

SELECT PARTIAL u.{id, name.first, name.last} FROM User

This results in an exception from the parser.

Is this just as simple as making the following change to Parser::PartialObjectExpression() line 1782?

// before
$partialFieldSet[] = $this->lexer->token['value'];

// after
$field = $this->lexer->token['value'];

while ($this->lexer->isNextToken(Lexer::T_DOT)) {
    $this->match(Lexer::T_DOT);
    $this->match(Lexer::T_IDENTIFIER);
    $field .= '.'.$this->lexer->token['value'];
}

$partialFieldSet[] = $field;


 Comments   
Comment by Karl Rixon [ 23/Mar/15 ]

doctrinebot automatically opened DDC-3621 when I issued a PR, so closing this issue as a duplicate.

Comment by Doctrine Bot [ 23/Mar/15 ]

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

Comment by Doctrine Bot [ 23/Mar/15 ]

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

Comment by Doctrine Bot [ 23/Mar/15 ]

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

Comment by Doctrine Bot [ 23/Mar/15 ]

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





[DDC-3620] [GH-1335] Fix AbstractQuery::getParameter() documented return type Created: 17/Mar/15  Updated: 17/Mar/15  Resolved: 17/Mar/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Documentation, DQL
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: docblock, dql, parameter, query, return-type


 Description   

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

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

Message:

[As documented](https://github.com/doctrine/doctrine2/blob/master/UPGRADE.md#query-querybuilder-and-nativequery-parameters-bc-break), `getParameter()` always returns a `Query\Parameter` (or `NULL`).



 Comments   
Comment by Doctrine Bot [ 17/Mar/15 ]

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

Comment by Doctrine Bot [ 17/Mar/15 ]

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





[DDC-3619] spl_object_hash collision Created: 17/Mar/15  Updated: 17/Mar/15  Resolved: 17/Mar/15

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

Type: Bug Priority: Major
Reporter: Aleksandr Khristenko Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: garbage-collection, identity-map, object-hash, persist, remove, unitofwork

Attachments: File DDC3619Test.php    
Issue Links:
Dependency
depends on DDC-3624 [GH-1338] [DDC-3619] Update identityM... Resolved
Reference
is referenced by DDC-3624 [GH-1338] [DDC-3619] Update identityM... Resolved

 Description   

The code below demonstrate problem.

$user = $entityManager->find(User::class, $id); // get entity from db
$entityManager->remove($user); // remove user
$entityManager->persist($user); // cancel remove
unset($user);
/* at this moment spl_object_hash($user) is presented in the UoW, but the $user isn't presented in the identity map in UoW */
$user2 = new User(); // spl_object_hash($user2) may be equal to spl_object_hash($user) because $user has no reference
$entityManager->persist($user2);
$entityManager->flush(); //$user2 will not be saved, because UoW think, that is already exists


 Comments   
Comment by Marco Pivetta [ 17/Mar/15 ]

spl_object_hash($user2) may be equal to spl_object_hash($user) because $user has no reference

this seems wrong, since $user won't get garbage collected

Comment by Aleksandr Khristenko [ 17/Mar/15 ]

Why? The $user has no reference to it, so it may be collected.
I use SoftDeleteabale extension and faced with this problem.
My code is look like:

function delete($id) {
  $entity = $entityManager->find(Entity::class, $id);
  $entityManager->delete($entity); // the softdeleteable extension call persist($entity) and remove $entity from sheduledForDeletion in onFlush
  $entityManager->flush($entity);
} // after this function the UoW contains spl_object_hash($entity), but not contains $entity. After leave function $entity collected.
function createAnother() {
  $anotherEntity = new AnotherEntity();
  $entityManager->persist($anotherEntity);
  $entityManager->flush($anotherEntity); // there is a spl_object_hash collision and the entity is not saved
}
function main() {
  //...
  delete($id);
  //...
  createAnother();
}
Comment by Marco Pivetta [ 17/Mar/15 ]

Aleksandr Khristenko the UoW has an internal reference to $user, so it cannot be garbage collected

Comment by Marco Pivetta [ 17/Mar/15 ]

I suggest abstracting this problem into a test case in order to remove these doubts upfront.

Comment by Aleksandr Khristenko [ 17/Mar/15 ]

Aleksandr Khristenko the UoW has an internal reference to $user, so it cannot be garbage collected

Yes, but when we call remove($entity) this internal reference move from identityMap to entityDeletions array. And when we after that call persist($entity) this internal reference remove from entityDeletions array but NOT added to identityMap. So, after that UoW has not an internal reference to $user.

Comment by Aleksandr Khristenko [ 17/Mar/15 ]

I attached the test, which demonstrates that reference to entity from UoW is lost.

Comment by Nicolas [ 17/Mar/15 ]

I am also using SoftDeleteable Doctrine extension (https://github.com/Atlantic18/DoctrineExtensions) and facing a similar issue.

My scenario is:

  • fetch 2 entities from db ;
  • soft-delete these 2 entities (then flush) ;
  • create 3 new entities and persist them (then flush).

Problem is: 1 of the 3 entities won't be persisted (same $oid than one of the soft-deleted ones).

I've created a PR here that solves my issue:
https://github.com/doctrine/doctrine2/pull/1338

Does it make sense to you?

Comment by Doctrine Bot [ 17/Mar/15 ]

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





[DDC-3618] Refactor PersistentCollection Created: 16/Mar/15  Updated: 16/Mar/15

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

Type: Improvement Priority: Major
Reporter: Varga Bence Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: collection, orm


 Description   

PersistentCollection - a final class - contains all the metadata, used to speed up updates (through $snapshot). This information should be removed from the collection object and stored elsewhere, loosely coupled.

Doctrine2 uses the data mapper pattern (instead of Doctrine1's active record approach). This tells me that the designers see the importance of freedom which comes with loose coupling. Entities don't have to extend fixed base classes, why do collections?

Use case: I would like to use a wrapper around Collection (my current environment requires collections to have a certain functionality). This is possible in theory, but as I do the first step I'm losing all the advantages coming with PersistentColelction. Since it is a final class and logically an interface by itself (see the sniffing in ObjectHydrator#initRelatedCollection) it is impossible to create a wrapper which exposes the same functionality.

A short-term solution would be to extract an interface from PersistentColelction. A long-term one would be to manage the persisted state (currently PersistentCollection#snapshot) elsewhere (accessed through the EntityManager maybe).






[DDC-3617] [GH-1334] Changed some wrong usage of the @internal phpdoc Created: 15/Mar/15  Updated: 15/Mar/15  Resolved: 15/Mar/15

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: annotation, docblock, internal


 Description   

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

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

Message:

With this PR I removed/moved some @internal phpdocs as they weren't "real" internal tags, but more like internal info which ocramius and beberlei pointed out to me on the IRC channel. The use of the @internal phpdoc shows in IDE's as if the method/class should not be used and that's not true is most of the cases



 Comments   
Comment by Doctrine Bot [ 15/Mar/15 ]

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

Comment by Doctrine Bot [ 15/Mar/15 ]

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

Comment by Doctrine Bot [ 15/Mar/15 ]

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





[DDC-3616] [GH-1333] Allow DateTimeImmutable as parameter value Created: 15/Mar/15  Updated: 17/Mar/15  Resolved: 17/Mar/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: datetime, datetimeimmutable, datetimeinterface, dql, parameter, parameters, php-5.5


 Description   

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

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

Message:

This pull request allows passing instance of DateTimeImmutable as value to `setParameter` and its correct formating in query.



 Comments   
Comment by Doctrine Bot [ 16/Mar/15 ]

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

Comment by Doctrine Bot [ 16/Mar/15 ]

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

Comment by Doctrine Bot [ 16/Mar/15 ]

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

Comment by Doctrine Bot [ 17/Mar/15 ]

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





[DDC-3615] [GH-1332] [Small Enhancement] Make scalar field separator overwritable Created: 13/Mar/15  Updated: 13/Mar/15  Resolved: 13/Mar/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: DQL, ORM
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: alias, dql, extensibility, hydrator


 Description   

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

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

Message:

I would like to have a custom Hydrator extending ScalarHydrator just to change field separator ('_'), but I dont want to overwrite all method.
It's not very risky to make it extensible.



 Comments   
Comment by Doctrine Bot [ 13/Mar/15 ]

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

Comment by Doctrine Bot [ 13/Mar/15 ]

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





[DDC-3614] [GH-1331] [DOCS] Fixed class name in aggregate fields example Created: 12/Mar/15  Updated: 12/Mar/15  Resolved: 12/Mar/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Documentation
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: documentation, embeddables


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 12/Mar/15 ]

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

Comment by Doctrine Bot [ 12/Mar/15 ]

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





[DDC-3613] [GH-1330] Fix @Column options sections in documentation Created: 12/Mar/15  Updated: 12/Mar/15  Resolved: 12/Mar/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Documentation, Mapping Drivers
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: annotation, collate, column, documentation, metadata, schema, schema-tool


 Description   

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

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

Message:

I lose hours to find out how to make column collation works, mostly because of incorrect docs.

Annotations options is the equivalent of customSchemaOptions in https://github.com/doctrine/dbal/blob/master/docs/en/reference/schema-representation.rst

See https://github.com/doctrine/doctrine2/blob/d1e5034659e7beeb11830417a4a38de6586fe960/lib/Doctrine/ORM/Tools/SchemaTool.php#L443



 Comments   
Comment by Doctrine Bot [ 12/Mar/15 ]

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

Comment by Doctrine Bot [ 12/Mar/15 ]

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





[DDC-3612] Make SQLFilter#em protected Created: 11/Mar/15  Updated: 11/Mar/15

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: Evan Owens Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

SQLFilter#em is private, which can be troublesome when extending SQLFilter. I notice, for example, that the Gedmo SoftDeleteableFilter goes to the trouble of using reflection to get access to SoftDeleteableFilter#em.






[DDC-3611] [GH-1329] Fix for inconsistent use of getSQLDeclaration Created: 11/Mar/15  Updated: 13/Mar/15  Resolved: 13/Mar/15

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: case-sensitivity, documentation, type, typo


 Description   

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

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

Message:

I found an inconsistency in naming of the getSQLDeclaration method
I changed in 5 files `getSqlDeclaration` -> `getSQLDeclaration`



 Comments   
Comment by Doctrine Bot [ 13/Mar/15 ]

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

Comment by Doctrine Bot [ 13/Mar/15 ]

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





[DDC-3610] [GH-1328] [DDC-3609] Syntax error in class table inheritance join when WITH is used in DQL query Created: 10/Mar/15  Updated: 16/Mar/15

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

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

Message:

I've added a test case to reproduce this issue. It's a bit contrived, but hopefully gives you enough to go on.



 Comments   
Comment by Doctrine Bot [ 16/Mar/15 ]

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





[DDC-3609] Syntax error in class table inheritance join when WITH is used in DQL query Created: 10/Mar/15  Updated: 16/Mar/15

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: Alex Dean Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

When using WITH on entities that use class table inheritance I'm seeing a syntax error in the generated SQL. Two "ON" statements show up:

INNER JOIN DDCNEWOrder d4_ ON d3_.id = d4_.id ON (d4_.id = d0_.id)

PR: https://github.com/doctrine/doctrine2/pull/1328



 Comments   
Comment by Doctrine Bot [ 16/Mar/15 ]

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





[DDC-3608] [GH-1327] Properly generate default value from yml & xml mapping Created: 10/Mar/15  Updated: 17/Mar/15  Resolved: 17/Mar/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 1
Labels: default, entityGenerator, metadata

Issue Links:
Reference
is referenced by DDC-2809 [GH-853] Fix for PHP entity default v... Resolved

 Description   

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

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

Message:

Yaml & Xml mapping which define default value for a field aren't properly generated in the entity class by the `EntityGenerator`.

This is how the documentation says to define a default value in [xml](http://doctrine-orm.readthedocs.org/en/latest/reference/xml-mapping.html):

```xml
<field name="login_count" type="integer" nullable="false">
<options>
<option name="default">0</option>
</options>
</field>
```

and in [yml](http://doctrine-orm.readthedocs.org/en/latest/reference/yaml-mapping.html):

```yaml
loginCount:
type: integer
column: login_count
nullable: false
options:
default: 0
```

Both generates this field mapping (aka `$fieldMapping`):

```php
array(5) {
'fieldName' =>
string(11) "login_count"
'type' =>
string(7) "integer"
'nullable' =>
bool(false)
'options' =>
array(1)

{ 'default' => string(1) "0" }

'columnName' =>
string(11) "login_count"
}
```

But the `EntityGenerator` check the default value in the wrong place, in `$fieldMapping['default']` instead of `$fieldMapping['options']['default']`.

This is related to :



 Comments   
Comment by Doctrine Bot [ 16/Mar/15 ]

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

Comment by Doctrine Bot [ 16/Mar/15 ]

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

Comment by Doctrine Bot [ 17/Mar/15 ]

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





[DDC-3607] [GH-1326] Allow AssociationBuilder to set a relation as orphan removal Created: 09/Mar/15  Updated: 09/Mar/15  Resolved: 09/Mar/15

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: association, association-builder, mapping, orphanRemoval, php-mapping


 Description   

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

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

Message:

The AssociationBuilder, part of the StaticPHP metadata driver, is missing the orphanRemoval functionality.

I know we are in the middle of 2.5 release, so let me know if you need anything from this one when you've got time for it :smile:



 Comments   
Comment by Doctrine Bot [ 09/Mar/15 ]

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

Comment by Doctrine Bot [ 09/Mar/15 ]

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





[DDC-3606] [GH-1325] fixed PostgreSQL and Oracle pagination issues Created: 09/Mar/15  Updated: 24/Mar/15  Resolved: 24/Mar/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 1
Labels: distinct, mssql, orderBy, paginator, postgresql

Issue Links:
Dependency
depends on DDC-3623 [GH-1337] Paginator OrderBy fix take 2 Resolved
depends on DDC-3629 [GH-1342] Paginator functional tests Resolved

 Description   

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

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

Message:

Pagination with ordering on 1:m and m:m relations, was not working
properly because of selecting the ordered fields in main select
statement with distinction (e.g. SELECT DISTINCT e0_.id, p1_.name from
... ) in this case we've received less rows than we've required in
query. So I've modified the subquery generation part.
In case of PostgreSQL and Oracle added the row_number in the subquery
over order by statement, then the main select is grouped by id and
selected min of row number, also ordering by rownumber asc, because they
are on right order already (e.g. select e0_.id, min(rownum) as rownum
from ..... order by rownum).
In case of MySQL, the subselect result with ids are in right order so
there is no need to select that fields(this fixes the same issue too)
In other cases I haven't tested because of that leaved the same.



 Comments   
Comment by Vahe Shadunts [ 09/Mar/15 ]

Hi Benjamin Eberlei, please let me know if I need to change something, I've used regular expression to change the doctrine's generated select statement, if there is a better way please let me know.

The code I've modified
https://github.com/vaheshadunts/doctrine2/blob/DDC-1958/lib/Doctrine/ORM/Tools/Pagination/LimitSubqueryOutputWalker.php#L221

Comment by Vahe Shadunts [ 09/Mar/15 ]

Also please let me know should I have to modify the test assertions of the queries which are have changed by my modifications? Or I have to skip the continuous integration ?

Comment by Doctrine Bot [ 16/Mar/15 ]

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

Comment by Doctrine Bot [ 16/Mar/15 ]

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

Comment by Doctrine Bot [ 24/Mar/15 ]

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

Comment by Doctrine Bot [ 24/Mar/15 ]

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





[DDC-3605] [GH-1324] load all many to many join columns Created: 08/Mar/15  Updated: 10/Mar/15

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/1324

Message:

the ```$joinColumnElement``` variable is created inside the foreach loop, and used only after it finishes, causing only the last join column to be loaded.



 Comments   
Comment by Doctrine Bot [ 10/Mar/15 ]

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

Comment by Doctrine Bot [ 10/Mar/15 ]

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





[DDC-3604] [GH-1323] - added isset validation for "inversedBy" Created: 08/Mar/15  Updated: 16/Mar/15

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 16/Mar/15 ]

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

Comment by Doctrine Bot [ 16/Mar/15 ]

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





[DDC-3603] Readonly columns Created: 06/Mar/15  Updated: 06/Mar/15

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

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


 Description   

Sometimes I have a column that is calculated (or have a default value) at the database side. When inserting a new record doctrine issues NULL into such a column that causes problems on some DBMS. I would like to annotate such columns as readonly so that doctrine would skip them in INSERT and UPDATE clauses but still fetch them in SELECT clauses.






[DDC-3602] allow regex in filter option for convert-mapping cli Created: 05/Mar/15  Updated: 05/Mar/15

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

Type: New Feature Priority: Major
Reporter: Jochem Blok Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: cli, convert-mapping, filter


 Description   

It is possible to use the filter option to filter which table is converted. It uses as strpos function of php. Please enable the power of regular expressions.






[DDC-3601] @index where annotation not filled with convert-mapping cli Created: 05/Mar/15  Updated: 05/Mar/15

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

Type: Bug Priority: Major
Reporter: Jochem Blok Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: annotation, cli, convert-mapping, index, mssql, sqlserver
Environment:

Sql Server



 Description   

When you use the CLI tool "orm:convert-mapping --from-database xml" the generated XML file does not contain the optional WHERE for the indexes. It look like this is not implemented in de Doctrine\ORM\Tools\Export\Driver\XmlExporter






[DDC-3600] Implement include columns annotation for indexes Created: 05/Mar/15  Updated: 05/Mar/15

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

Type: Bug Priority: Major
Reporter: Jochem Blok Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: annotation, index, mssql, sqlserver
Environment:

Sql Server



 Description   

Sql server has an option to include columns in an index. There is no (optional) annotation for this functionality. http://doctrine-orm.readthedocs.org/en/latest/reference/annotations-reference.html#annref-index



 Comments   
Comment by Marco Pivetta [ 05/Mar/15 ]

Why would you need this sort of feature, when an index already defines the included columns?

Comment by Jochem Blok [ 05/Mar/15 ]

the advantages are described on the MSDN website:

By including nonkey columns, you can create nonclustered indexes that cover more queries. This is because the nonkey columns have the following benefits:
They can be data types not allowed as index key columns.
They are not considered by the Database Engine when calculating the number of index key columns or index key size.





[DDC-3599] [GH-1322] Typo in documentation Created: 03/Mar/15  Updated: 04/Mar/15  Resolved: 04/Mar/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Documentation
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: documentation, typo


 Description   

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

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

Message:

Two list items where just one



 Comments   
Comment by Doctrine Bot [ 04/Mar/15 ]

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

Comment by Doctrine Bot [ 04/Mar/15 ]

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





[DDC-3598] Paginator incorrect ordering Created: 03/Mar/15  Updated: 03/Mar/15

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

Type: Bug Priority: Major
Reporter: Kris Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: paginator


 Description   

When ordering by multiple fields, with the order by fields not contained in the original select statement the paginator outputs in an incorrect order.
I found the issue is in the LimitSubqueryOutputWalker in the preserveSqlOrdering function. This is the query it generates

SELECT DISTINCT id1, date_added3 FROM (SELECT t0_.description AS description0, t0_.id AS id1, t0_.date AS date2, t0_.date_added AS date_added3 FROM Ticket t0_ INNER JOIN user u1_ ON t0_.assigned_user_id = u1_.id INNER JOIN user u2_ ON t0_.created_user_id = u2_.id WHERE t0_.project_id = ? ORDER BY u2_.first_name DESC, t0_.date_added DESC) dctrn_result ORDER BY date_added3 DESC

So it appears that it ignores any order by field that is not included in the inner select statement.






[DDC-3597] [GH-1321] embeddedClasses support in mapped superclasses Created: 03/Mar/15  Updated: 10/Mar/15  Resolved: 10/Mar/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: embeddables, inheritance, mappedsuperclass


 Description   

This issue is created to fixing this issue: https://github.com/doctrine/DoctrineModule/issues/481

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

Message:

...for JoinedSubclassPersister.php



 Comments   
Comment by Doctrine Bot [ 10/Mar/15 ]

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

Comment by Doctrine Bot [ 10/Mar/15 ]

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

Comment by Doctrine Bot [ 10/Mar/15 ]

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





[DDC-3596] Do not allow entity column name "decimal" or escape somehow Created: 02/Mar/15  Updated: 02/Mar/15

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

Type: Bug Priority: Major
Reporter: Aurimas Niekis Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Problem is that after creation and schema update of entity with property "decimal" it makes problem to insert and alter that column.

On schema update it uses this SQL to create table:

CREATE TABLE Unit (id INT AUTO_INCREMENT NOT NULL, name VARCHAR(255) NOT NULL, unit VARCHAR(255) NOT NULL, `decimal` SMALLINT NOT NULL, decimal_point VARCHAR(1) NOT NULL, thousands_separator VARCHAR(1) NOT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB;

When trying to persist entity I get exception

  [Doctrine\DBAL\DBALException]
  An exception occurred while executing 'INSERT INTO Unit (name, unit, decimal, decimal_point, thousands_separator) VALUES (?, ?, ?, ?, ?)' with params ["Cubic meters", "m\u00b3", "2", ".", ","]:
  SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'deci
  mal, decimal_point, thousands_separator) VALUES ('Cubic meters', 'm³', '2',' at line 1

Or alter table to rename column

  [Doctrine\DBAL\DBALException]
  An exception occurred while executing 'ALTER TABLE Unit CHANGE decimal decimal_numbers SMALLINT NOT NULL':
  SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'deci
  mal decimal_numbers SMALLINT NOT NULL' at line 1





[DDC-3595] [GH-1320] Fix 'entitiy' typo in Getting Started tutorial Created: 02/Mar/15  Updated: 02/Mar/15  Resolved: 02/Mar/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Documentation
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: documentation, getting-started, typo


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 02/Mar/15 ]

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

Comment by Doctrine Bot [ 02/Mar/15 ]

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





[DDC-3594] [GH-1319] travis: PHP 7.0 nightly added Created: 02/Mar/15  Updated: 11/Mar/15  Resolved: 11/Mar/15

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: ci, php-7.0, travis


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 11/Mar/15 ]

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

Comment by Doctrine Bot [ 11/Mar/15 ]

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





[DDC-3593] INDEX BY doesnt't work for NEW ArticleDTO Created: 01/Mar/15  Updated: 01/Mar/15

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: Ondřej Vodáček Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

With this query the resulting array is not indexed by id, but from zero

Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
$query = $em->createQuery('SELECT NEW ArticleDTO(a.id, a.title) FROM Article a INDEX BY a.id');
$articles = $query->getResult();





[DDC-3592] [GH-1318] Respect the "unique" property of the join column on the owning side of a... Created: 27/Feb/15  Updated: 16/Mar/15

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

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

Issue Links:
Reference
relates to DDC-1666 orphanRemoval does not work with oneT... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of ed-at-work:

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

Message:

... One to One association. Coupled with Orphan Removal on the mapped side, this should provide better compatibility for replacing the row without getting duplicate key errors.



 Comments   
Comment by Doctrine Bot [ 16/Mar/15 ]

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

Comment by Doctrine Bot [ 16/Mar/15 ]

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





[DDC-3591] [GH-1317] Respect the "unique" property of the join column on the owning side of a... Created: 27/Feb/15  Updated: 27/Feb/15  Resolved: 27/Feb/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Incomplete Votes: 0
Labels: join, metadata, one-to-one, unique


 Description   

This issue is created automatically through a Github pull request on behalf of ed-at-work:

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

Message:

... One to One association. Coupled with Orphan Removal on the mapped side, this should provide better compatibility for replacing the row without getting duplicate key errors.



 Comments   
Comment by Doctrine Bot [ 27/Feb/15 ]

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





[DDC-3590] [GH-1316] Allow to join non-public schema tables Created: 26/Feb/15  Updated: 17/Mar/15  Resolved: 17/Mar/15

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: join-table, mapping, naming-strategy, quoting, schema


 Description   

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

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

Message:

Fix joining non default schema tables in PostgreSQL



 Comments   
Comment by Doctrine Bot [ 16/Mar/15 ]

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

Comment by Doctrine Bot [ 16/Mar/15 ]

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

Comment by Doctrine Bot [ 17/Mar/15 ]

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





[DDC-3589] [GH-1315] Fixed broken url for implementing Serializable interface Created: 26/Feb/15  Updated: 26/Feb/15  Resolved: 26/Feb/15

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

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


 Description   

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

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

Message:

Fixed a broken url for implementing the Serializable interface. The link was pointing to an outdated German version of php.net manual.



 Comments   
Comment by Doctrine Bot [ 26/Feb/15 ]

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

Comment by Doctrine Bot [ 26/Feb/15 ]

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





[DDC-3588] [GH-1314] DATE_ADD - Support for seconds Created: 25/Feb/15  Updated: 26/Feb/15  Resolved: 26/Feb/15

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: custom-dql-function, date-diff, datetime, dql


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 26/Feb/15 ]

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

Comment by Doctrine Bot [ 26/Feb/15 ]

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





[DDC-3587] [GH-1313] Added programmatical support to define indexBy on root aliases. Created: 25/Feb/15  Updated: 25/Feb/15  Resolved: 25/Feb/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: index-by, querybuilder


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 25/Feb/15 ]

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

Comment by Doctrine Bot [ 25/Feb/15 ]

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





[DDC-3586] [GH-1312] Add proper pluralization into UpdateCommand Created: 24/Feb/15  Updated: 24/Feb/15  Resolved: 24/Feb/15

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

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


 Description   

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

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

Message:

This alters the UpdateCommand so that if only 1 query is was executed, it will say so.

Rather than "1 queries were executed"



 Comments   
Comment by Doctrine Bot [ 24/Feb/15 ]

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

Comment by Doctrine Bot [ 24/Feb/15 ]

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





[DDC-3585] [GH-1311] [DDC-3582] Wrong class is instantiated when using nested embeddables Created: 24/Feb/15  Updated: 27/Feb/15  Resolved: 27/Feb/15

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: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: embeddables, orm


 Description   

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

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

Message:

Consider the example where an entity contains an embeddable, that itself contains 2 different embeddables. So Entity -> Embeddable 1 -> (Embeddable 2, Embeddable 3). In this case, EmbeddableContainer will be instantiated as an Embeddable1 for some reason.

I looked at the code in the ReflectionEmbeddedProperty, and noticed that 'embeddedClass' was recently changed from 'class'. If I change it back, this test passes, but then the ReflectionEmbeddedPropertyTest fails on the scenario for abstract classes.



 Comments   
Comment by Doctrine Bot [ 27/Feb/15 ]

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

Comment by Doctrine Bot [ 27/Feb/15 ]

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





[DDC-3584] [GH-1310] Allow symfony 3.0 components Created: 22/Feb/15  Updated: 16/Mar/15

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 nicolas-grekas:

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

Message:

Tests should tell if any deprecated interfaces of Symfony are used. If not, then the bundle is defacto compatible with 3.0



 Comments   
Comment by Doctrine Bot [ 16/Mar/15 ]

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





[DDC-3583] [GH-1309] [DDC-3582] Fix hydration of nested embeddables Created: 22/Feb/15  Updated: 27/Feb/15

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

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

Message:

The wrong class is chosen when hydrating embeddables that are part of a nested structure. See `DDC3582Test` for a demonstration. The fix is to use `class` instead of `embeddedClass` to instantiate the embeddable in ReflectionEmbeddedProperty.

The test I removed from ReflectionEmbeddedPropertyTest was failing because you cannot instantiate an abstract class (and rightfully so). However, as this would not be possible in practice anyway (you always end up extending the abstract class), I think this test can be removed safely.



 Comments   
Comment by Doctrine Bot [ 22/Feb/15 ]

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

Comment by Doctrine Bot [ 27/Feb/15 ]

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

Comment by Doctrine Bot [ 27/Feb/15 ]

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





[DDC-3582] Nested embeddables are instantiated with the wrong class Created: 22/Feb/15  Updated: 27/Feb/15

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

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


 Description   

Consider the example where an entity contains an embeddable, that itself contains 2 different embeddables. So Entity -> Embeddable 1 -> (Embeddable 2, Embeddable 3). In this case, Embeddable1 will be instantiated as an Embeddable2 for some reason.

Please see https://github.com/jankramer/doctrine2/commit/5e6b02a0fa9a1216b4e4d075061619288af74e7a for a test that demonstrates this and currently fails.

I looked at the code in the ReflectionEmbeddedProperty, and noticed that 'embeddedClass' was recently changed from 'class'. If I change it back, this test passes, but then the ReflectionEmbeddedPropertyTest fails on the scenario for abstract classes. @ocramius, I saw you were the author on that change, could you please take a look? Thanks!



 Comments   
Comment by Jan Kramer [ 22/Feb/15 ]

Closing this as I can't seem to reproduce this issue anymore.

Comment by Jan Kramer [ 24/Feb/15 ]

Now able to reproduce this issue, updated the description.

Comment by Marco Pivetta [ 24/Feb/15 ]

Jan Kramer please send a PR with that diff

Comment by Jan Kramer [ 24/Feb/15 ]

@ocramius See https://github.com/doctrine/doctrine2/pull/1311

Comment by Doctrine Bot [ 27/Feb/15 ]

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

Comment by Doctrine Bot [ 27/Feb/15 ]

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





[DDC-3581] DatabaseDriver does not assert nullable on ToOne associationMappings Created: 21/Feb/15  Updated: 21/Feb/15

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

Type: Improvement Priority: Minor
Reporter: Ryan Korczykowski Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I am using the DatabaseDriver/AnnotationExporter to tweak class generation and found that JoinColumn annotations did not contain nullable=false even when the local FK column was not null. This is counter-intuitive since nullable on Column annotations is properly handled.

Here is a simple fix that checks the column of the local column in DatabaseDriver::buildToOneAssociationMappings:

for ($i = 0; $i < count($fkColumns); $i++) {
    $associationMapping['joinColumns'][] = array(
        'name'                 => $fkColumns[$i],
        'referencedColumnName' => $fkForeignColumns[$i],
        //fix here
        'nullable' => !$foreignKey->getLocalTable()->getColumn($fkColumns[$i])->getNotNull()
    );
}

Given that the database defines null / not null on FK columns, the JoinColumn nullable attribute should not be left undefined.






[DDC-3580] [GH-1308] [DDC-3579] Allow override of inversedBy Created: 20/Feb/15  Updated: 16/Mar/15

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 16/Mar/15 ]

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

Comment by Doctrine Bot [ 16/Mar/15 ]

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





[DDC-3579] Allow override of inversedBy Created: 20/Feb/15  Updated: 20/Feb/15

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

Type: New Feature Priority: Minor
Reporter: z38 Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: inheritance


 Description   

If an entity inherits a many-to-many relationship it is sometimes desirable to be allowed to override inversedBy. This way bi-directional relationships can exist without code duplication. For examples, check out this and this Stackoverflow question.

The proposed pull-request implements this feature. I'm open to any comments and suggestions. Please just let me know if this feature is opposed to any concepts/practices, I'm not sure whether the feature is needed by anyone else.






[DDC-3578] [GH-1307] Test for DDC-2988 Created: 20/Feb/15  Updated: 16/Mar/15

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

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

Issue Links:
Reference
relates to DDC-2988 Notice: Undefined index: joinColumns ... Awaiting Feedback

 Description   

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

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

Message:

This test can be merged only after fix issue DDC-2988

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



 Comments   
Comment by Doctrine Bot [ 16/Mar/15 ]

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





[DDC-3577] Inherited associations are ignored Created: 20/Feb/15  Updated: 20/Feb/15

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: Denis Vasilev Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: schematool


 Description   

Could not create schema via SchemaTool for entity, which has inherited accosiation mapping (this mapping is ignored).

ShemaTool.php
private function gatherRelationsSql($class, $table, $schema, &$addedFks, &$blacklistedFks)
{
    foreach ($class->associationMappings as $mapping) {
        if (isset($mapping['inherited'])) {
            continue;
        }
...

I have three entity types:

  • BaseType — mapping mapped-superclass, has association many-to-one, join-column pid
  • SecondType extends BaseType — mapping entity
  • ThirdType extends SecondType — mapping entity

Table for ThirdType not has pid column after created scheme via SchemeTool. Inheritance mapping not using.



 Comments   
Comment by Marco Pivetta [ 20/Feb/15 ]

This should actually be working: you probably need to provide a test case otherwise

Comment by Denis Vasilev [ 20/Feb/15 ]

https://github.com/yethee/doctrine2/commit/d55a8bc71381db1c599da682c4baca0ce39d0d62
Test case for this issue.

$ phpunit --group=DDC-3577
PHPUnit 4.7-g7c1de6a by Sebastian Bergmann and contributors.

Configuration read from D:\Projects\doctrine2\phpunit.xml.dist

F

Time: 1.97 seconds, Memory: 81.75Mb

There was 1 failure:

1) Doctrine\Tests\ORM\Tools\SchemaToolTest::testInheritedAssociationShouldBeSupported
Table "ddc3577_interviews" should has column "user_id".
Failed asserting that false is true.




[DDC-3576] [GH-1306] Add support for array hydrator in interface ObjectRepository of Doctrine... Created: 20/Feb/15  Updated: 20/Feb/15  Resolved: 20/Feb/15

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: Doctrine Bot Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: object-repository, repository


 Description   

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

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

Message:

.../Common github repo

with magic function

  • findArrayResultBy
  • findOneArrayResultBy


 Comments   
Comment by Doctrine Bot [ 20/Feb/15 ]

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

Comment by Doctrine Bot [ 20/Feb/15 ]

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





[DDC-3575] Paginator's CountOutputWalker keeps the ORDER BY in the subquery for all non-MSSQL platforms Created: 20/Feb/15  Updated: 20/Feb/15

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: John Flatness Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: paginator

Issue Links:
Reference
relates to DDC-3519 [GH-1267] Failing test for an ORDER B... Resolved
relates to DDC-3538 [GH-1283] #1267 - order by broken in ... Resolved

 Description   

The Paginator's CountOutputWalker leaves the ORDER BY clause in the subquery that's executed to get the total count.

The original (and current) version of that code included the following comment:

Note that the ORDER BY clause is not removed. Many SQL implementations (e.g. MySQL) are able to cache subqueries. By keeping the ORDER BY clause intact, the limitSubQuery that will most likely be executed next can be read from the native SQL cache.

My understanding is that MySQL does not, in fact, cache subqueries in the query cache, so cached results are not available between executions of different queries. The current MySQL manual still states that "Queries that are a subquery of an outer query" are not cached.

This pull request was merged in 2013 to address errors with mssql and paginating ordered queries. Midway through the discussion on that issue, it was determined that it would be better to just remove the ORDER BY clause for all platforms, not just MS SQL. However, that decision was reversed when it came time to merge the PR.

Does the comment on that method accurately describe the rationale for retaining the ORDER BY clause for the count query? If so, am I simply wrong about how MySQL operates, or does the comment refer to some other platform that benefits from this pattern?



 Comments   
Comment by Marco Pivetta [ 20/Feb/15 ]

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

This change was reverted because MSSQL is pretty much a niche, and fixing bugs for it is really making things complicated for all the other storages.

Comment by John Flatness [ 20/Feb/15 ]

Thanks for the reply, Marco.

I think this is getting conflated with the other Paginator-related ORDER BY changes and reversions that have happened breaking and fixing the actual sorting behavior. The pull you linked looks like its relating to the LimitSubqueryOutputWalker, not the CountOutputWalker.

The thing I'm talking about is still there, and does specifically address only a MSSQL bug: https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Tools/Pagination/CountOutputWalker.php#L82

The particular part of the discussion on PR #572 I was referring to above is here: https://github.com/doctrine/doctrine2/pull/572#discussion_r3154962

My concern is that the rationale for keeping the ORDER BY intact for all the other platforms (only when running the count query, not the "real" one) is a performance-related one, and that it's a flawed rationale. (Or, at least, that the comment about it is.)





[DDC-3574] the Paginator does not support arbitrary join should be back ported to 2.4 Created: 19/Feb/15  Updated: 24/Feb/15  Resolved: 19/Feb/15

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

Type: Improvement Priority: Major
Reporter: Sagar Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: paginator


 Description   

Using the following query with the paginator fails:

SELECT u
FROM User u
JOIN Message m WITH m.author = u
WHERE m.status = 'draft' -- a condition justifying the join

The CountWalker and the CountOutputWalker both throw a exception saying "Cannot count query which selects two FROM components, cannot make distinction"

This message is wrong (I can make distinction here. Only User is selected in the result set) and confusing (I spent some time finding the second FROM before figuring it was related to the use of an arbitrary join instead of an association join).



 Comments   
Comment by Sagar [ 19/Feb/15 ]

Though it is fixed in 2.5 "the Paginator does not support arbitrary join should be back ported to 2.4"

Comment by Marco Pivetta [ 19/Feb/15 ]

This is a new feature that won't be backported into stable versions.

Comment by Sagar [ 24/Feb/15 ]

I really don't understand How this is new feature? It is missing part of Pagination Component.

Comment by Marco Pivetta [ 24/Feb/15 ]

It was limitation that was refactored out. Since it's an improvement, it won't land in a patch release.





[DDC-3573] DateTime objects casted to string when used in aggregate functions in query results Created: 18/Feb/15  Updated: 18/Feb/15

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

Type: Bug Priority: Major
Reporter: Ameer Antar Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal, mysql, orm, querybuilder
Environment:

MySQL, possibly others



 Description   

Similar to DDC-657: http://www.doctrine-project.org/jira/browse/DDC-657

DateTime objects are converted to strings when selecting them through an aggregate function.

Example:

Update.php Column definition
    /**
     * @var \DateTime
     * @ORM\Column(name="entryDate", type="datetime")
     */
    private $entryDate;
Query Builder
		$qb = $this->getEntityManager()->createQueryBuilder();
		$qb->select('u.code, max(u.entryDate) as updateDate');
		$qb->from('Update', 'u');
		$qb->addGroupBy('u.code');

		var_dump( $qb->getQuery()->getResult() );

The result contains the date/times as strings not DateTime objects as expected. This affects the query builder. I assume it also affects DQL queries.






[DDC-3572] Versionable behavior does not work Created: 18/Feb/15  Updated: 18/Feb/15  Resolved: 18/Feb/15

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

Type: Bug Priority: Minor
Reporter: Pascal Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: orm

Attachments: Zip Archive doctrine2-versionable-bug.zip    

 Description   

I tried to set up a versionable example (see attachment). The problem is. It works random. Sometimes the old record will be submitted into the _version table. Sometimes it doesn't. Most of the time the version stay 1 in the _version table. Sometimes it works as it should. I hardly can't believe that I setup something wrong because of the random bugs.

I face the same problem which is described in the comment of the updated sample code here: http://www.doctrine-project.org/jira/browse/DDC-871?focusedCommentId=14702&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14702



 Comments   
Comment by Marco Pivetta [ 18/Feb/15 ]

Doctrine ORM 2.x does not provide a versionable behavior.





[DDC-3571] Alter ResultSetMapping on NEW DQL (typeMapping for newObjectMappings) Created: 17/Feb/15  Updated: 17/Feb/15

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

Type: Documentation Priority: Minor
Reporter: Ignace Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: None


 Description   

In the documentation it says that with the NEW operator only scalars are passed but it is limited to only string? Or is it possible to hint it to return floats and integers aswell?

Currently I hacked this together:

private function getIncomeOutgoingPerMonthQuery($year, &$rsm)
    {
        $rsm = new ResultSetMapping();
        $rsm->addScalarResult('sclr0', 'amount_sum', 'integer');

        return $this->createQueryBuilder('t')
            ->select('NEW AppBundle\ValueObject\Money(SUM(t.amount), t.currency), SUBSTRING(t.date, 6, 2) AS HIDDEN month')
            ->where('SUBSTRING(t.date, 1, 4) = :year')
            ->groupBy('t.currency')
            ->addGroupBy('month')
            ->setParameter('year', (int)$year);
    }





[DDC-3570] [GH-1305] Documentation : fix table prefix with STI Created: 16/Feb/15  Updated: 16/Feb/15  Resolved: 16/Feb/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Documentation, Tools
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: ddl, documentation, listener, metadata, schema, table-prefix


 Description   

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

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

Message:

If an Entity use STI, it gets its table name from the parent class. In this case, we need to check that the class is the root class of the hierarchy when adding prefix, otherwise children class are prefixed twice.



 Comments   
Comment by Doctrine Bot [ 16/Feb/15 ]

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

Comment by Doctrine Bot [ 16/Feb/15 ]

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





[DDC-3569] [GH-1304] Documentation : fix table prefix with STI Created: 16/Feb/15  Updated: 16/Feb/15  Resolved: 16/Feb/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers, Tools
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: sti, table, table-prefix


 Description   

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

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

Message:

If an Entity use STI, it gets its table name from the parent class. We need to check that a class is a root class of the hierarchy when adding prefix, otherwise children class are double prefixed.



 Comments   
Comment by Doctrine Bot [ 16/Feb/15 ]

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

Comment by Doctrine Bot [ 16/Feb/15 ]

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





[DDC-3568] Discriminator column in joined multiple inheritance Created: 16/Feb/15  Updated: 16/Feb/15  Resolved: 16/Feb/15

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

Type: Bug Priority: Major
Reporter: Glend Gjermeni Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: discriminator-map
Environment:

Ubuntu 14.04LTS, PHP 5.5, MySQL 5.5.41-0ubuntu0.14.04.1



 Description   

I'm facing an issue when trying to use multiple inheritance via discriminators. When generating a schema, only the superclass has a discriminator column.

See my test case: https://github.com/anooxy/doctrine-multiple-inheritance-test

The hierarchy is supposed to be (inheriting order):

TutorContact -> TutorStudentChildrenContact -> Contact
StudentContact -> StudentChildrenContact -> TutorStudentChildrenContact & StudentParentContact -> Contact
ParentContact -> StudentParentContact -> Contact
ChildrenContact -> StudentChildrenContact -> TutorStudentChildrenContact -> Contact

Only Contact table has a discriminator column, whereas the middle tables, which have been assigned a discriminator in the annotations, do not have one.



 Comments   
Comment by Marco Pivetta [ 16/Feb/15 ]

This is the expected behavior: only the root of the inheritance has the discriminator column.





[DDC-3567] [GH-1303] make QueryBuilder::getAllAliases public Created: 14/Feb/15  Updated: 17/Mar/15  Resolved: 17/Mar/15

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

Type: New Feature Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: alias, dql, query-builder, querybuilder


 Description   

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

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

Message:

Being able to get all already defined aliases in the QueryBuilder can be helpful when dynamically joining.

Funny, the DocBlock makes it seem as if this method was already public.



 Comments   
Comment by Doctrine Bot [ 17/Mar/15 ]

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

Comment by Doctrine Bot [ 17/Mar/15 ]

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





[DDC-3566] [GH-1302] Store column values of not cache-able associations Created: 11/Feb/15  Updated: 17/Mar/15  Resolved: 17/Mar/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: association, cache, non-cacheable, partial

Issue Links:
Dependency
is required for DDC-3564 [GH-1301] Add failing test with ToOne... Resolved

 Description   

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

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

Message:

Fixes #1301



 Comments   
Comment by Doctrine Bot [ 16/Feb/15 ]

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

Comment by Doctrine Bot [ 17/Mar/15 ]

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





[DDC-3565] "Missing value for primary key" error using JoinColumns Created: 11/Feb/15  Updated: 11/Feb/15

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

Type: Bug Priority: Minor
Reporter: Arran Walker Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm


 Description   

With a ManyToOne relationship to a composite foreign key and using JoinColumns, I get this error during hydration of the Branch entity when it has no associated primary Contact:

Missing value for primary key user on Contact

If there is an associated Contact, it works as expected.

I think it's related to this error on StackOverflow.

User.php
<?php

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

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

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

    public function getId()
    {
        return $this->id;
    }
}
Branch.php
<?php

use Doctrine\Common\Collections\ArrayCollection;

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

    /**
     * ORM\OneToMany(targetEntity="Contact", mappedBy="Branch", cascade={"persist", "remove"}, indexBy="user")
     */
    protected $contacts;

    /**
     * @ManyToOne(targetEntity="Contact")
     * @JoinColumns(
     *   @JoinColumn(name="primary_contact_user_id", referencedColumnName="user_id"),
     *   @JoinColumn(name="id", referencedColumnName="branch_id")
     * )
     */
    protected $primaryContact;

    public function __construct()
    {
        $this->contacts = new ArrayCollection();
    }

    public function addUserAsContact(User $user)
    {
        if (!$this->contacts[$user->getId()]) {
            $this->contacts[$user->getId()] = new Contact($this, $user);
        }

        return $this->contacts[$user->getId()];
    }

    public function setUserAsPrimaryContact(User $user)
    {
        $this->primaryContact = $this->addUserAsContact($user);
    }
}
Branch.php
<?php


/**
 * @Entity
 */
class Contact
{
    /**
     * @Id()
     * @ManyToOne(targetEntity="Branch")
     * @JoinColumn(name="branch_id", referencedColumnName="id", nullable=false)
     */
    protected $branch;

    /**
     * @Id()
     * @ManyToOne(targetEntity="User")
     * @JoinColumn(name="user_id", referencedColumnName="id", nullable=false)
     */
    protected $user;

    public function __construct(Branch $branch, User $user)
    {
        $this->branch = $branch;
        $this->user   = $user;
    }

    public function getUser()
    {
        return $this->user;
    }
}





[DDC-3564] [GH-1301] Add failing test with ToOne SL2 association Created: 11/Feb/15  Updated: 17/Mar/15  Resolved: 17/Mar/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: association, cache, non-cacheable, partial

Issue Links:
Dependency
depends on DDC-3566 [GH-1302] Store column values of not ... Resolved

 Description   

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

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

Message:

Hi,

This failing test is based on @FabioBatSilva tests here (https://github.com/FabioBatSilva/doctrine2/blob/4f7e71963f5197235fce9f87a56b02bbbba46026/tests/Doctrine/Tests/ORM/Functional/SecondLevelCacheOneToOneTest.php).

I've changed the test so that on Token association, there is no @Cache annotation.

The default behaviour would be to Doctrine set a proxy on non-cached association. Instead, it basically creates a "partial" object where any associations without the @Cache is set to null. I'm pretty sure it works the same ManyToOne association too.



 Comments   
Comment by Doctrine Bot [ 16/Feb/15 ]

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

Comment by Doctrine Bot [ 16/Feb/15 ]

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

Comment by Marco Pivetta [ 17/Mar/15 ]

Handled in DDC-3566





[DDC-3563] Wrong metadata output. One-To-Many, Bidirectional Created: 08/Feb/15  Updated: 08/Feb/15

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

Type: Bug Priority: Major
Reporter: Jason Schilling Assignee: Steve Müller
Resolution: Unresolved Votes: 1
Labels: None

Attachments: Zip Archive Data.zip    

 Description   

During observe the metadata in a One-To-Many association I've noticed that, the inversedBy value is NULL but in the annotation its assigned to something like $images (look example). I think its wrong because the EntityGenerator dont get it and dont generate the add..., remove... and get...s Method stubs or the __constructor assignment to ArrayCollections.






[DDC-3562]  Make two different join request with different join condition with Doctrine ORM Created: 06/Feb/15  Updated: 06/Feb/15

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

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

Doctrine2 symfony integration
PHP 5.5.2
MySQL 5.5.41
Linux
doctrine/annotations v1.2.3
doctrine/cache v1.4.0
doctrine/collections v1.2
doctrine/common v2.4.2
doctrine/dbal v2.5.1
doctrine/doctrine-bundle v1.3.0
doctrine/doctrine-cache-bundle v1.0.1
doctrine/inflector v1.0.1
doctrine/lexer v1.0.1
doctrine/orm v2.4.7



 Description   

I want to make two requests on an object and join a one to many relation using doctrine ORM. The first request has different condition on the joined object.
The first request should join one object, and the second one two, but both return one object when run with the same EntityManager context.

The test entity

    /**
     * TreeNode
     *
     * @ORM\Table(name="treeNode")
     */
    class TreeNode {
    	/**
    	* @var integer
    	*
    	* @ORM\Id
    	* @ORM\Column(name="id", type="integer")
    	* @ORM\GeneratedValue(strategy="AUTO")
    	*/
    	private $id;
    
    	/**
    	* @var string
    	*
    	* @ORM\Column(name="name", type="string", length=50)
    	*/
    	private $name;
    
    	/**
    	* @var \Doctrine\Common\Collections\Collection
    	*
    	* @ORM\JoinColumn(name="subdirs", nullable=true)
    	* @ORM\OneToMany(targetEntity="TestBundle\Entity\TreeNode", mappedBy="parent", cascade={"persist"})
    	*/
    	private $subdirs;
    
    	/**
    	* @var TestBundle\Entity\TreeNode
    	*
    	* @ORM\JoinColumn(name="parent", nullable=true)
    	* @ORM\ManyToOne(targetEntity="TestBundle\Entity\TreeNode", inversedBy="subdirs")
    	*/
    	private $parent;
    }

Adding some test data

    $parent = new TreeNode();
    $parent->setName('Parent');
    $parent->setParent(null);
    
    $child1 = new TreeNode();
    $child1->setName('Child1');
    $child1->setParent($parent);
    
    $child2 = new TreeNode();
    $child2->setName('Child2');
    $child2->setParent($parent);

Run the queries

    $repo = $em->getRepository('TestBundle:TreeNode');

    $qb = $repo->createQueryBuilder('t');
    $qb->innerJoin('t.subdirs', 'subnode')
    		->addSelect('subnode')
    		->where('t.name = :parentName')
    		->setParameter('childName', 'Child1')
    		->andWhere('subnode.name = :childName')
    		->setParameter('parentName', 'Parent');
    
    $result = $qb->getQuery()->getOneOrNullResult();
    var_dump($result->getSubdirs()->count()); // Gives 1, ok 
    
    
    // Get parent parent + all childs
    $qb = $repo->createQueryBuilder('t');
    $qb->innerJoin('t.subdirs', 'subnode')
    		->addSelect('subnode')
    		->where('t.name = :parentName')
    		->setParameter('parentName', 'Parent');
    $result = $qb->getQuery()->getOneOrNullResult();
    var_dump($result->getSubdirs()->count()); // Gives 1, should have been 2 !
  • The second request only returns one "subdir" object, while it should have been two.
  • If I run the second request without the first one, I get the two results, as expected. Inverting the request makes the second one return two results instead of one.
  • The correct SQL requests are run by this code, only the returned result is wrong.
  • Running `$em->clear()` between the two statements works, but I don't want to untrack my other entities.





[DDC-3561] Wrong SQL generated for Drop Foreign Key on MySQL Created: 06/Feb/15  Updated: 20/Mar/15

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: Stefan Gnann Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

operating system: osx yosemite
database driver: pdo_mysql
installed bundles:
doctrine/annotations v1.2.3
doctrine/cache v1.4.0
doctrine/collections v1.2
doctrine/common v2.4.2
doctrine/data-fixtures dev-master ac36ccc
doctrine/dbal v2.5.1
doctrine/doctrine-bundle v1.3.0
doctrine/doctrine-cache-bundle v1.0.1
doctrine/doctrine-fixtures-bundle v2.2.0
doctrine/doctrine-migrations-bundle dev-master 81575a4
doctrine/inflector v1.0.1
doctrine/instantiator 1.0.4
doctrine/lexer v1.0.1
doctrine/migrations dev-master 96f838b
doctrine/mongodb 1.1.6
doctrine/mongodb-odm dev-master 23152aa
doctrine/mongodb-odm-bundle dev-master 9748d11
doctrine/orm v2.4.7
gedmo/doctrine-extensions v2.3.9
stof/doctrine-extensions-bundle v1.1.0


Attachments: File migrate-example.php    

 Description   

i´m new to doctrine, but it seems to me that there is a problem creating statements in migrations.
Please see the //comments in the attached file!



 Comments   
Comment by Marco Pivetta [ 06/Feb/15 ]

Steve Müller I think I saw this issue already in the DBAL tracker somewhere, but I can't find it. Do you remember the issue ID?

Comment by Stefan Gnann [ 06/Feb/15 ]

The attached file was automatically generated after upgrading doctrine/dbal onto version 2.5.1 .

Now i have DOWNgraded doctrine/dbal to version 2.4.4 .
Suddenly the doctrine:migrations:diff says "No changes detected in your mapping information.".

Before downgrading i had two identical databases. One locally installed and one in a vagrant box with debian as os.
On every database i did a "doctrine:migrations:diff" to generate an actual schema update file. What i was wondering ist, that i got two different files with different ALTER xxxxx statements regarding to FOREIGN KEY and INDEXES.

Maybe this is a bug in doctrine/dbal 2.5.1?

Comment by Stefan Gnann [ 06/Feb/15 ]

actual installed bundles after downgrading:

doctrine/annotations v1.2.3
doctrine/cache v1.4.0
doctrine/collections v1.2
doctrine/common v2.4.2
doctrine/data-fixtures dev-master 80401e8
doctrine/dbal v2.4.4
doctrine/doctrine-bundle v1.3.0
doctrine/doctrine-cache-bundle v1.0.1
doctrine/doctrine-fixtures-bundle v2.2.0
doctrine/doctrine-migrations-bundle dev-master 81575a4
doctrine/inflector v1.0.1
doctrine/instantiator 1.0.4
doctrine/lexer v1.0.1
doctrine/migrations dev-master 1ac14fa
doctrine/mongodb 1.1.7
doctrine/mongodb-odm dev-master 1343375
doctrine/mongodb-odm-bundle dev-master 27e7690
doctrine/orm v2.4.7
gedmo/doctrine-extensions v2.3.11
stof/doctrine-extensions-bundle v1.1.0

Comment by Peter Rehm [ 18/Feb/15 ]

Steve Müller I did some research on that the last days and I am sure, there is still a major issue with the implementation.

The schema update creates the following sql commands:

$this->addSql('ALTER TABLE Article DROP FOREIGN KEY FK_12743CF7924C3225');
$this->addSql('ALTER TABLE Article DROP FOREIGN KEY FK_12743CF79395C3F3');
$this->addSql('ALTER TABLE Article DROP FOREIGN KEY FK_12743CF7F7C5BCDB');
$this->addSql('ALTER TABLE Article DROP FOREIGN KEY FK_93173F21A23B42D');
$this->addSql('ALTER TABLE Article DROP FOREIGN KEY FK_93173F21A5790FE9');
$this->addSql('ALTER TABLE Article ADD CONSTRAINT FK_12743CF7924C3225 FOREIGN KEY (createdUser_id) REFERENCES CoreUser (id)');

Looking at the previous SQL schema I found out that there is already e.g. the FK_12743CF7924C3225. This FK
will be dropped and newly added at the same time. It is actually not using the new FK name which doctrine would
like to see. However in the down sql it tried to drop the key which should be there.

In addition to that there is an issue with upper/lowercase Index names. This I got fixed by

return 'DROP INDEX ' . strtoupper($indexName) . ' ON ' . $table;

in MysqlPlatform:860 which is most likely not the right way. I am more concerned about the FK
issue, which I am unable to track down so far. Do you have any idea?

Comment by Peter Rehm [ 20/Mar/15 ]

@deeky666 Have you had a chance to look at this?





[DDC-3560] [GH-1300] [2.4] #1169 DDC-3343 one-to-omany persister deletes only on EXTRA_LAZY plus orphanRemoval Created: 05/Feb/15  Updated: 16/Feb/15  Resolved: 16/Feb/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Lazy Loading, ORM
Affects Version/s: 2.4.7
Fix Version/s: 2.4.8
Security Level: All

Type: Bug Priority: Blocker
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: extra-lazy, onetomany, orphanRemoval, persistent-collection, persister

Issue Links:
Dependency
is required for DDC-3343 `PersistentCollection::removeElement`... Resolved

 Description   

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

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

Message:

As per #1169 and DDC-3343 ( http://www.doctrine-project.org/jira/browse/DDC-3343 ), `EXTRA_LAZY` `PersistentCollection#removeElement()` calls should only affect the database if `orphanRemoval=true` is specified in the mappings.

Otherwise, being the `one-to-many` the inverse side, no action should be performed.



 Comments   
Comment by Doctrine Bot [ 05/Feb/15 ]

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

Comment by Doctrine Bot [ 05/Feb/15 ]

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

Comment by Doctrine Bot [ 16/Feb/15 ]

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

Comment by Doctrine Bot [ 16/Feb/15 ]

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

Comment by Doctrine Bot [ 16/Feb/15 ]

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





[DDC-3559] [GH-1299] Fixed missing quote in one DQL example Created: 04/Feb/15  Updated: 04/Feb/15  Resolved: 04/Feb/15

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/1299

Message:



 Comments   
Comment by Doctrine Bot [ 04/Feb/15 ]

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

Comment by Doctrine Bot [ 04/Feb/15 ]

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





[DDC-3558] Sequence name generation for identity strategy Created: 04/Feb/15  Updated: 05/Feb/15

Status: Open
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: Gemorroj Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: generator-strategy, identity, metadata, sequence

Attachments: PNG File Захват-1.png    

 Description   

In version 2.5 added support sequence with the strategy of identity.
But I cannot get the correct name of the sequence with the strategy of identity. With the strategy sequence produces the correct name. It is taken from the configuration sequenceName. Strategy identity name sequence will not be taken from the configuration, and is always generated is automatically (which is not working properly in my case).

see: https://github.com/doctrine/doctrine2/blob/4c68a38bd6b7d590dbfa90b2bb116129381935ce/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php#L632
the title sequence is generated automatically.

https://github.com/doctrine/doctrine2/blob/4c68a38bd6b7d590dbfa90b2bb116129381935ce/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php#L662
and in this case, it first checks its own configuration.



 Comments   
Comment by Gemorroj [ 05/Feb/15 ]

Any comments plz..?

Comment by Marco Pivetta [ 05/Feb/15 ]

Gemorroj consider writing a test case with your problem/example: I can't understand the issue as it is currently written down.

A code example is also fine.

Comment by Gemorroj [ 05/Feb/15 ]

If you use the strategy SEQUENCE, the doctrine calls the sequence specified in the configuration. And inserts a record in the database with the specified ID.
If you are using the IDENTITY strategy, doctrine inserts a record without an ID. And after a record is inserted, causes sequence (https://github.com/doctrine/dbal/blob/8cbfefe03ff2d1a2246dfb6e98b84e4b36622e6f/lib/Doctrine/DBAL/Driver/OCI8/OCI8Connection.php#L148) to learn the value of id.
But, with the IDENTITY strategy, doctrine does not know how actually called a sequence.

Comment by Marco Pivetta [ 05/Feb/15 ]

Yes, when using the IDENTITY strategy, the sequence name is not used: https://github.com/doctrine/doctrine2/blob/4c68a38bd6b7d590dbfa90b2bb116129381935ce/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php#L626-L657

That's expected behavior: what are you expecting?

Comment by Gemorroj [ 05/Feb/15 ]

If doctrine determines that the database uses the sequence, then I expect the setup sequence doctrine is taken from the configuration.
https://github.com/doctrine/doctrine2/blob/4c68a38bd6b7d590dbfa90b2bb116129381935ce/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php#L636-L638
The generated name sequence wrong for me.

Comment by Marco Pivetta [ 05/Feb/15 ]

You should rather just use the SEQUENCE strategy.

Otherwise, provide a functional test case and eventually propose a fix.





[DDC-3557] [GH-1298] Docs: Remove empty pages from TOC Created: 03/Feb/15  Updated: 14/Feb/15  Resolved: 14/Feb/15

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: documentation, rst


 Description   

This issue is created automatically through a Github pull request on behalf of eugene-dounar:

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

Message:

Remove Installation page from TOC as it was moved to "Installation and Configuration"



 Comments   
Comment by Doctrine Bot [ 14/Feb/15 ]

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

Comment by Doctrine Bot [ 14/Feb/15 ]

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

Comment by Doctrine Bot [ 14/Feb/15 ]

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





[DDC-3556] [GH-1297] [DDC-3480] Docs: Embeddable supported mappings Created: 03/Feb/15  Updated: 14/Feb/15  Resolved: 14/Feb/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Documentation
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: documentation, embeddables, mapping

Issue Links:
Reference
is referenced by DDC-3480 ORM\Embeddable does not create ManyTo... Open

 Description   

This issue is created automatically through a Github pull request on behalf of eugene-dounar:

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

Message:

Mention that only basic mapping is supported by embeddables



 Comments   
Comment by Doctrine Bot [ 14/Feb/15 ]

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

Comment by Doctrine Bot [ 14/Feb/15 ]

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





[DDC-3555] [GH-1296] Flip key value in $namespaces array Created: 03/Feb/15  Updated: 03/Feb/15  Resolved: 03/Feb/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Documentation, Mapping Drivers
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: documentation, mapping, path, xml


 Description   

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

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

Message:

Key value should be other way around.



 Comments   
Comment by Doctrine Bot [ 03/Feb/15 ]

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

Comment by Doctrine Bot [ 03/Feb/15 ]

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





[DDC-3554] [GH-1295] Fix join when recreation of query from parts. Created: 01/Feb/15  Updated: 16/Feb/15  Resolved: 16/Feb/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: clone, join, query, querybuilder


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 16/Feb/15 ]

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

Comment by Doctrine Bot [ 16/Feb/15 ]

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

Comment by Doctrine Bot [ 16/Feb/15 ]

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





[DDC-3553] Create a QueryBuilder from a Query/DQL Created: 01/Feb/15  Updated: 01/Feb/15  Resolved: 01/Feb/15

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

Type: Documentation Priority: Major
Reporter: Dries De Peuter Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: querybuilder


 Description   

Hi,

I am searching for a way to create a QueryBuilder from an existing Query or a DQL string.

Can I currently do this?

If this is not the case. I would love to create this but I don't see how to parse the DQL into parts.



 Comments   
Comment by Marco Pivetta [ 01/Feb/15 ]

.

Not an issue

Note that the QueryBuilder just assembles strings: there is currently no way to transform DQL into a query builder, as the operation is not bijective.

Comment by Dries De Peuter [ 01/Feb/15 ]

I understand. Is their any way you would suggest allowing a DQL to be altered/extended.





[DDC-3552] Code generation throws exceptions when embeddables are used Created: 30/Jan/15  Updated: 30/Jan/15

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

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


 Description   

I've created a gist showing the code you can use to reproduce the issue
https://gist.github.com/v3labs/d02244c99a87444be709

I've also included the composer.json file.

When I run php app/console doctrine:generate:entities AppBundle -v, I get the following exception:

[Symfony\Component\Debug\Exception\ContextErrorException]
Notice: Trying to get property of non-object

Exception trace:
() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php:3251
Symfony\Component\Debug\ErrorHandler->handleError() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php:3251
Doctrine\ORM\Mapping\ClassMetadataInfo->inlineEmbeddable() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php:201
Doctrine\ORM\Mapping\ClassMetadataFactory->doLoadMetadata() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php:332
Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->loadMetadata() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php:78
Doctrine\ORM\Mapping\ClassMetadataFactory->loadMetadata() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php:225
Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->getMetadataFor() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php:115
Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->getAllMetadata() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/doctrine-bundle/Mapping/DisconnectedMetadataFactory.php:201
Doctrine\Bundle\DoctrineBundle\Mapping\DisconnectedMetadataFactory->getAllMetadata() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/doctrine-bundle/Mapping/DisconnectedMetadataFactory.php:164
Doctrine\Bundle\DoctrineBundle\Mapping\DisconnectedMetadataFactory->getMetadataForNamespace() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/doctrine-bundle/Mapping/DisconnectedMetadataFactory.php:54
Doctrine\Bundle\DoctrineBundle\Mapping\DisconnectedMetadataFactory->getBundleMetadata() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/doctrine-bundle/Command/GenerateEntitiesDoctrineCommand.php:96
Doctrine\Bundle\DoctrineBundle\Command\GenerateEntitiesDoctrineCommand->execute() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/symfony/symfony/src/Symfony/Component/Console/Command/Command.php:253
Symfony\Component\Console\Command\Command->run() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:882
Symfony\Component\Console\Application->doRunCommand() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:195
Symfony\Component\Console\Application->doRun() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Console/Application.php:96
Symfony\Bundle\FrameworkBundle\Console\Application->doRun() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:126
Symfony\Component\Console\Application->run() at /Users/vladislav/Sites/doctrine2.5_tests/app/console:27

If I add columnPreffix to the @Embed annotation the exception is different:

[Symfony\Component\Debug\Exception\ContextErrorException]
Catchable Fatal Error: Argument 1 passed to Doctrine\ORM\Mapping\ReflectionEmbeddedProperty::__construct() must be an instance of ReflectionP
roperty, null given, called in /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php on
line 952 and defined

Exception trace:
() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ReflectionEmbeddedProperty.php:61
Symfony\Component\Debug\ErrorHandler->handleError() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ReflectionEmbeddedProperty.php:61
Doctrine\ORM\Mapping\ReflectionEmbeddedProperty->__construct() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php:952
Doctrine\ORM\Mapping\ClassMetadataInfo->wakeupReflection() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php:721
Doctrine\ORM\Mapping\ClassMetadataFactory->wakeupReflection() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php:343
Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->loadMetadata() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php:78
Doctrine\ORM\Mapping\ClassMetadataFactory->loadMetadata() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php:225
Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->getMetadataFor() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php:115
Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->getAllMetadata() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/doctrine-bundle/Mapping/DisconnectedMetadataFactory.php:201
Doctrine\Bundle\DoctrineBundle\Mapping\DisconnectedMetadataFactory->getAllMetadata() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/doctrine-bundle/Mapping/DisconnectedMetadataFactory.php:164
Doctrine\Bundle\DoctrineBundle\Mapping\DisconnectedMetadataFactory->getMetadataForNamespace() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/doctrine-bundle/Mapping/DisconnectedMetadataFactory.php:54
Doctrine\Bundle\DoctrineBundle\Mapping\DisconnectedMetadataFactory->getBundleMetadata() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/doctrine-bundle/Command/GenerateEntitiesDoctrineCommand.php:96
Doctrine\Bundle\DoctrineBundle\Command\GenerateEntitiesDoctrineCommand->execute() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/symfony/symfony/src/Symfony/Component/Console/Command/Command.php:253
Symfony\Component\Console\Command\Command->run() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:882
Symfony\Component\Console\Application->doRunCommand() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:195
Symfony\Component\Console\Application->doRun() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Console/Application.php:96
Symfony\Bundle\FrameworkBundle\Console\Application->doRun() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:126
Symfony\Component\Console\Application->run() at /Users/vladislav/Sites/doctrine2.5_tests/app/console:27

doctrine:generate:entities [--path="..."] [--no-backup] name

I don't think it's a Symfony specific issue. I tried using the built-in CLI tool and got the same results.



 Comments   
Comment by Marco Pivetta [ 30/Jan/15 ]

Yeah, this can't really work with code-gen, because embeddables require reflection to be initialized in order to operate, whereas the codegen cli-tools operate with a DisconnectedMetadataFactory, which skips reflection on purpose (it assumes that the class does not exist, therefore it does not start up reflection).

I think it's a can't fix for now.

Comment by Vladislav Veselinov [ 30/Jan/15 ]

Sorry for the formatting. I had never used jira before.

Comment by Marco Pivetta [ 30/Jan/15 ]

Vladislav Veselinov fixed the formatting, no big deal

Comment by Vladislav Veselinov [ 30/Jan/15 ]

Btw:

Changing line 947 in ClassMetadataInfo to:

if (isset($mapping['declaredField']) && $parentReflFields[$mapping['declaredField']]) {

seems to bypass the problem and the generation runs fine, but I don't know if it breaks something else. Doesn't seem like it but ... I'm not sure

Comment by Vladislav Veselinov [ 30/Jan/15 ]

Just figured out with it won't work in all cases. I'll keep digging. Thanks for the feedback!





[DDC-3551] [GH-1294] Avoid Connection error when calling ClassMetadataFactor::getAllMetadata() Created: 29/Jan/15  Updated: 04/Feb/15  Resolved: 04/Feb/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: disconnected-metadata, entityGenerator, generation, lazy-loading, mapping, platform


 Description   

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

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

Message:

Hi guys!

When you pair the ORM with DBAL 2.5.0, then getting the `targetPlatform` means that a connection will be made to the database. For that reason, it's really important to not get the `targetPlatform` unless it's absolutely needed. Currently, if you call `ClassMetadataFactor::getAllMetadata()`, it will try to determine `targetPlatform` (in `initialize()`), which will make a connection. And if that connection fails (e.g. no db yet), it will blow up - even though `getAllMetadata()` doesn't need the `targetPlatform`.

This fixes that, and in an absolutely BC way, since `targetPlatform` is private (yay!). This should fix a number of issues in userland, like symfony/symfony-standard#748 and symfony/symfony-standard#774.

This is a PR to master (per the guidelines), but the real target is 2.4, since it's the latest stable. The patch won't apply cleanly, but it's simple: remove from initialize, then replace all references to the new private method.

Thanks in advance! More details are on the commit message.



 Comments   
Comment by Doctrine Bot [ 04/Feb/15 ]

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

Comment by Doctrine Bot [ 04/Feb/15 ]

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





[DDC-3550] [GH-1293] EntityManager::__cosntruct() as public method Created: 28/Jan/15  Updated: 16/Feb/15

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 16/Feb/15 ]

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





[DDC-3549] [GH-1292] Mark getSelectConditionStatementColumnSQL method as private Created: 28/Jan/15  Updated: 29/Jan/15  Resolved: 29/Jan/15

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: bc, persister


 Description   

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

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

Message:

The `Doctrine/\ORM\Persisters\BasicEntityPersister::getSelectConditionStatementColumnSQL` method has been marked as `private`.

The current `protected` mark is a bit unuseful since everything is already handled into the public method `getSelectConditionStatementSQL`.



 Comments   
Comment by Doctrine Bot [ 29/Jan/15 ]

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





[DDC-3548] [GH-1291] Conversion to PHP 5.4's short array syntax Created: 28/Jan/15  Updated: 28/Jan/15

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

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


 Description   

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

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

Message:

Now that the minimum PHP version is 5.4, it would be good to encourage the use of the short array syntax `[]`.
Converting the existing codebase to this syntax will promote this good practice and encourage everyone to follow it.

I have converted the codebase with [a tool](https://gist.github.com/BenMorel/6994483) I wrote for personal projects:

find doctrine2 -type f -name '*.php' -exec php short-array-syntax-converter.php {} \;

The number of changes is quite large, but I'm confident that nothing is broken, and the passing tests confirm this.



 Comments   
Comment by Doctrine Bot [ 28/Jan/15 ]

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

Comment by Doctrine Bot [ 28/Jan/15 ]

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





[DDC-3547] [GH-1290] [Doc] [Reference] [Second Level Cache] Created: 27/Jan/15  Updated: 27/Jan/15  Resolved: 27/Jan/15

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


 Description   

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

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

Message:

Updated reference for Second Level Cache (fixed some typos and docblocks).



 Comments   
Comment by Doctrine Bot [ 27/Jan/15 ]

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

Comment by Doctrine Bot [ 27/Jan/15 ]

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





[DDC-3546] [GH-1289] Improve test suite Created: 27/Jan/15  Updated: 27/Jan/15  Resolved: 27/Jan/15

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

Type: Improvement Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: ci, performance, phpunit, testing, travis

Issue Links:
Duplicate
is duplicated by DDC-3540 [GH-1285] travis: remove unnecessary ... Resolved
Reference
relates to DDC-3540 [GH-1285] travis: remove unnecessary ... Resolved

 Description   

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

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

Message:

This PR adopts DBAL's latest test suite improvements from https://github.com/doctrine/dbal/pull/597/files, https://github.com/doctrine/dbal/pull/643/files, https://github.com/doctrine/dbal/pull/779 and https://github.com/doctrine/dbal/pull/758/files
Supersedes https://github.com/doctrine/doctrine2/pull/1285



 Comments   
Comment by Doctrine Bot [ 27/Jan/15 ]

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

Comment by Doctrine Bot [ 27/Jan/15 ]

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

Comment by Doctrine Bot [ 27/Jan/15 ]

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





[DDC-3545] Persist new object failed when it works with optimistic lock Created: 27/Jan/15  Updated: 27/Jan/15

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

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

PHP 5.5



 Description   

When I was trying to persist a new object, Doctrine reported a exception:

An exception occurred while executing 'SELECT version FROM wallet WHERE user_id = ?' with params [{}]:

Catchable Fatal Error: Object of class XXXBundle\Entity\User could not be converted to string in /Users/XXX/WebSite/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php line 91

From the stack trace information, I found the original exception is:

Catchable Fatal Error: Object of class XXXBundle\Entity\User could not be converted to string

The reason is that the entity Wallet has a OneToOne mapping to entity User, and user property is also marked as primary key. When the wallet object persists, Doctrine try to fetch the new version id and use user property to find object. But Doctrine doesn't handle the primary key is an object, not a basic type. So PDO can't use a object as a query parameter.

My Entity:

class Wallet
{
    /**
     * ID
     * @var User
     *
     * @ORM\Id
     * @ORM\OneToOne(targetEntity="XXXBundle\Entity\User")
     * @ORM\JoinColumn(name="user_id", referencedColumnName="id")
     */
    private $user;

    /**
     * @var int
     *
     * @ORM\Version()
     * @ORM\Column(name="version", type="integer")
     */
    private $version;
}

I hope Doctrine team can solve this problem. My temporary solution is to override __toString method in User object. It is not elegant, doesn't it?



 Comments   
Comment by Marco Pivetta [ 27/Jan/15 ]

What exact version of the ORM is affected? Is master also behaving like this?

Comment by Max Liu [ 27/Jan/15 ]

It works well before I add version field. I didn't try with master version.





[DDC-3544] [GH-1288] Hotfix - #1169 - extra lazy one to many must be no-op when not doing orphan removal Created: 27/Jan/15  Updated: 28/Jan/15  Resolved: 28/Jan/15

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

Type: Bug Priority: Blocker
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: collection, extra-lazy, lazy-loading, onetomany, orphanRemoval

Issue Links:
Dependency
is required for DDC-3343 `PersistentCollection::removeElement`... Resolved
is required for DDC-3536 [GH-1281] Hotfix/#1169 extra lazy one... Resolved

 Description   

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

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

Message:

See https://github.com/doctrine/doctrine2/pull/1281#issuecomment-71403668



 Comments   
Comment by Doctrine Bot [ 28/Jan/15 ]

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

Comment by Doctrine Bot [ 28/Jan/15 ]

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

Comment by Doctrine Bot [ 28/Jan/15 ]

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





[DDC-3543] How to map and use a DB View from Doctrine2 Created: 26/Jan/15  Updated: 26/Jan/15  Resolved: 26/Jan/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers, ORM
Affects Version/s: 2.4.7
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Reynier Perez Mira Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

I have a view on nomencladores schema called obtenerPaisesPorFabricanteProductoSolicitud. This is the content for the view:

    SELECT
    	ps.id AS psid,
    	ps.nombre,
    	fps.id AS fpsid
    FROM
    	(
    		(
    			nomencladores.pais ps
    			JOIN nomencladores.pais_fabricante_producto_solicitud pfps ON ((pfps.pais_id = ps.id))
    		)
    		JOIN negocio.fabricante_producto_solicitud fps ON (
    			(
    				pfps.fabricante_producto_solicitud_id = fps.id
    			)
    		)
    	);

I'm trying to map the view as follow:

    use Doctrine\ORM\Mapping as ORM;
    
    /**
     * @ORM\Entity
     * @ORM\Table(name="nomencladores.obtenerPaisesPorFabricanteProductoSolicitud", schema="nomencladores")
     */
    class ObtenerPaisesPorFabricanteProductoSolicitud
    {
        /**
         * @ORM\Id
         * @ORM\Column(name="psid", type="integer", nullable=false, unique=true)
         */
        protected $ps;
    
        /**
         * @ORM\Column(name="fpsid", type="integer")
         */
        protected $fps;
    
        /**
         * @ORM\Column(name="nombre", type="string")
         */
        protected $nombre;
    
        public function getPs()
        {
            return $this->ps;
        }
    
        public function getFps()
        {
            return $this->fps;
        }
    
        public function getNombre()
        {
            return $this->nombre;
        }
    }

But any time I run this code on it:

    $ent = $em->getRepository("AppBundle:ObtenerPaisesPorFabricanteProductoSolicitud")->findBy(
        array(
            "fps" => $entF->getId()
        )
    );

I got this result:

An exception occurred while executing 'SELECT t0.psid AS psid1,
t0.fpsid AS fpsid2, t0.nombre AS nombre3 FROM
nomencladores.obtenerPaisesPorFabricanteProductoSolicitud t0 WHERE
t0.fpsid = ?' with params [22]:
SQLSTATE[42P01]: Undefined table: 7 ERROR: relation "nomencladores.obtenerpaisesporfabricanteproductosolicitud" does not
exist LINE 1: ...d1, t0.fpsid AS fpsid2, t0.nombre AS nombre3 FROM
nomenclado...

If I remove the annotations then the error transform on this:

Class "AppBundle\Entity\ObtenerPaisesPorFabricanteProductoSolicitud" is not a valid entity or mapped super class."

Why Doctrine2 or Symfony tries to execute the query instead go through the view? How I can execute the view from Symfony2/Doctrine2 side?



 Comments   
Comment by Marco Pivetta [ 26/Jan/15 ]

Nothing wrong here: the SQL generated by the ORM is correct, but your view definition is wrong: try running the select in console, manually.





[DDC-3542] [GH-1287] Typo fix Created: 25/Jan/15  Updated: 26/Jan/15  Resolved: 26/Jan/15

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


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 26/Jan/15 ]

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

Comment by Doctrine Bot [ 26/Jan/15 ]

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





[DDC-3541] [GH-1286] Removing XDebug from non-coverage builds Created: 25/Jan/15  Updated: 25/Jan/15  Resolved: 25/Jan/15

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

Type: Improvement Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: build-speed, ci, travis, xdebug


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 25/Jan/15 ]

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

Comment by Doctrine Bot [ 25/Jan/15 ]

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

Comment by Doctrine Bot [ 25/Jan/15 ]

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

Comment by Doctrine Bot [ 25/Jan/15 ]

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





[DDC-3540] [GH-1285] travis: remove unnecessary database creation Created: 25/Jan/15  Updated: 27/Jan/15  Resolved: 27/Jan/15

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: ci, performance, setup, travis

Issue Links:
Duplicate
duplicates DDC-3546 [GH-1289] Improve test suite Resolved
Reference
relates to DDC-3532 [GH-1278] travis: remove unnecessary ... Resolved
is referenced by DDC-3546 [GH-1289] Improve test suite Resolved

 Description   

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

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

Message:

Ref: #1278



 Comments   
Comment by Doctrine Bot [ 25/Jan/15 ]

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

Comment by Doctrine Bot [ 25/Jan/15 ]

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

Comment by Doctrine Bot [ 27/Jan/15 ]

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





[DDC-3539] [GH-1284] #1189 DDC-3406 derived identity in proxy must be a proxy Created: 24/Jan/15  Updated: 16/Mar/15

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-3406 Proxy returns string instead of object Open

 Description   

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

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

Message:

This is a horrible hack for #1189.

Not happy with it, this seems like it fixes just the symptom.



 Comments   
Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 25/Jan/15 ]

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

Comment by Doctrine Bot [ 25/Jan/15 ]

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

Comment by Doctrine Bot [ 16/Mar/15 ]

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





[DDC-3538] [GH-1283] #1267 - order by broken in pagination logic (reverts #1220) Created: 24/Jan/15  Updated: 20/Feb/15  Resolved: 24/Jan/15

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

Type: Bug Priority: Critical
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: limitsubqueryoutputwalker, orderBy, orderby, paginator, subquery

Issue Links:
Duplicate
is duplicated by DDC-3519 [GH-1267] Failing test for an ORDER B... Resolved
Reference
is referenced by DDC-3575 Paginator's CountOutputWalker keeps t... Open

 Description   

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

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

Message:

This PR reverts #1220 and merges #1264



 Comments   
Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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





[DDC-3537] [GH-1282] Hotfix/#1169 extra lazy one to many should not delete referenced entities (backport to 2.4) Created: 24/Jan/15  Updated: 25/Jan/15  Resolved: 25/Jan/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Lazy Loading, ORM
Affects Version/s: 2.4.7
Fix Version/s: 2.4.8
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: delete, extra-lazy, onetomany, update

Issue Links:
Dependency
is required for DDC-3343 `PersistentCollection::removeElement`... Resolved

 Description   

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

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

Message:

See #1169

This PR backports #1281



 Comments   
Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 25/Jan/15 ]

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





[DDC-3536] [GH-1281] Hotfix/#1169 extra lazy one to many should not delete referenced entities Created: 24/Jan/15  Updated: 16/Feb/15  Resolved: 25/Jan/15

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

Type: Bug Priority: Blocker
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: delete, extra-lazy, onetomany, update

Issue Links:
Dependency
depends on DDC-3544 [GH-1288] Hotfix - #1169 - extra lazy... Resolved
is required for DDC-3343 `PersistentCollection::removeElement`... Resolved

 Description   

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

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

Message:

This is an alternate fix for #1169 (DDC-3343 http://www.doctrine-project.org/jira/browse/DDC-3343)



 Comments   
Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 25/Jan/15 ]

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

Comment by Doctrine Bot [ 05/Feb/15 ]

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

Comment by Doctrine Bot [ 05/Feb/15 ]

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

Comment by Doctrine Bot [ 16/Feb/15 ]

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

Comment by Doctrine Bot [ 16/Feb/15 ]

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

Comment by Doctrine Bot [ 16/Feb/15 ]

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





[DDC-3535] Allow binding `Parameter` value object to statements, removing the need for explicit value and type passing Created: 24/Jan/15  Updated: 24/Jan/15

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

Type: Task Priority: Critical
Reporter: Marco Pivetta Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: binding, criteria, parameters, persister, repository, type


 Comments   
Comment by Marco Pivetta [ 24/Jan/15 ]

We currently have a lot of locations in the code where we use list($values, $types) = $this->computeParameters(); (pseudo-code).

This leads to a lot of code duplication and complexity.

Maybe a Parameter VO may be used instead, or a ParameterCollection with a fixed $types and a mutable $values, and with minimal internal validation.





[DDC-3534] [GH-1280] [DDC-3346] #1277 find one with eager loads is failing Created: 23/Jan/15  Updated: 25/Mar/15  Resolved: 25/Mar/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Lazy Loading, 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: collection, eager, fetch, hydrator, lazy-loading, many-to-many, onetomany, persister

Issue Links:
Dependency
is required for DDC-3346 findOneBy returns an object with part... Resolved
is required for DDC-3531 [GH-1277] [DDC-3346] Failing test for... Resolved

 Description   

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

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

Message:

Ping @scaytrase

Note that this is a first revision and needs refactoring, so please consider helping out with that if you can.

Ping @guilhermeblanco: please check the `CachedPersisterContext` stuff: it's dirty as heck, but that's because the persister internal generated SQL caching is inconsistent as heck too.

Resolution path for 2.4.x will be to throw an exception if there is an offset or a limit.



 Comments   
Comment by Doctrine Bot [ 23/Jan/15 ]

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

Comment by Doctrine Bot [ 23/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 25/Jan/15 ]

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





[DDC-3533] [GH-1279] [Doc][Reference][2nd level cache] Created: 23/Jan/15  Updated: 23/Jan/15  Resolved: 23/Jan/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Documentation, Second Level Cache
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: documentation, rst, second-level-cache, typo


 Description   

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

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

Message:

  • Fixed typo in TimestampRegion title.
  • Normalized php snippets (comments, indentation).


 Comments   
Comment by Doctrine Bot [ 23/Jan/15 ]

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

Comment by Doctrine Bot [ 23/Jan/15 ]

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





[DDC-3532] [GH-1278] travis: remove unnecessary database creation Created: 22/Jan/15  Updated: 25/Jan/15  Resolved: 24/Jan/15

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Incomplete Votes: 0
Labels: ci, performance, setup, travis

Issue Links:
Reference
is referenced by DDC-3540 [GH-1285] travis: remove unnecessary ... Resolved

 Description   

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

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

Message:

Ref: https://github.com/doctrine/dbal/commit/a66010640cc03e73a60cee16f1da36daabd63898

https://github.com/doctrine/doctrine2/pull/1251#discussion_r23018406



 Comments   
Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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





[DDC-3531] [GH-1277] [DDC-3346] Failing test for issue (bad findOneBy behaviour with eager fetch) Created: 22/Jan/15  Updated: 25/Jan/15  Resolved: 23/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: collection, eager, fetch, hydration, many-to-many, onetomany, persister

Issue Links:
Dependency
depends on DDC-3534 [GH-1280] [DDC-3346] #1277 find one w... Resolved
is required for DDC-3346 findOneBy returns an object with part... Resolved

 Description   

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

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

Message:

Here is the test for DDC-3346(http://www.doctrine-project.org/jira/browse/DDC-3346) issue



 Comments   
Comment by Doctrine Bot [ 23/Jan/15 ]

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

Comment by Doctrine Bot [ 23/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 25/Jan/15 ]

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





[DDC-3530] [GH-1276] travis: run coverage just once Created: 22/Jan/15  Updated: 22/Jan/15  Resolved: 22/Jan/15

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: build-speed, ci, coverage, travis


 Description   

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

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

Message:

Another speedup, just for 2.4 branch. Ref: https://github.com/doctrine/doctrine2/pull/1251

2.3 and bellow don't use coverage, so that should be all.



 Comments   
Comment by Doctrine Bot [ 22/Jan/15 ]

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

Comment by Doctrine Bot [ 22/Jan/15 ]

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





[DDC-3529] [GH-1275] [WIP] Nullable embedded objects. Created: 21/Jan/15  Updated: 13/Mar/15  Resolved: 13/Mar/15

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Incomplete Votes: 0
Labels: embeddables, null, nullable


 Description   

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

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

Message:

The idea was to have a simple (and clean) way to override the nullable property of embedded objects, so I've
added the ```nullable``` attribute on the ```@Embedded``` annotation and it have 3 possible values:

  • NULL: The nullable option that was defined on the attributes of the embeddable class won't be overriden;
  • TRUE: All attributes of the embeddable class will be marked as nullable and the embeddable instance only would be created when data is not NULL;
  • FALSE: All attributes of the embeddable class will be marked as non-nullable.

There's a lot of things to be improved (mostly on UnitOfWork), but it's fully working with basic tests as you can see on ValueObjectsTest::testCRUDOfNullableEmbedded() case.

I would appreciate a lot your opinions!



 Comments   
Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 11/Mar/15 ]

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





[DDC-3528] [GH-1274] PersistentCollection now extends AbstractLazyCollection. Created: 21/Jan/15  Updated: 17/Mar/15  Resolved: 17/Mar/15

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: collection, persistent-collection


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 22/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 01/Mar/15 ]

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

Comment by Doctrine Bot [ 17/Mar/15 ]

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

Comment by Doctrine Bot [ 17/Mar/15 ]

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

Comment by Doctrine Bot [ 17/Mar/15 ]

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





[DDC-3527] Provide a method to retrieve exactly one entity out of entity repository Created: 20/Jan/15  Updated: 22/Jan/15

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: Git Master
Fix Version/s: 3.0

Type: Improvement Priority: Minor
Reporter: Dominik D Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Hello,

currently we have EntityRepository::findOneBy() method for retrieving a single or none entities out of an EntityRepository. It would be very useful, if there was a method which retrieves exactly one entity or throws NonUniqueResultException in case of multiple records returned or NoResultException in case of zero results returned (just like Query::getSingleResult() currently does).

Very often I find myself creating custom repositories for a couple of ::findOneByOrThrow() methods only. Needless to say it's quite mundane to do. The bodies of such methods follows the same pattern:

1. Query the EntityRepository using EntityRepository::findOneBy().
2. If the result is null, then throw an Exception.
3. Return the result.

It'd be very nice to have it out-of-the-box in the base EntityRepository.

Thanks.



 Comments   
Comment by Marco Pivetta [ 20/Jan/15 ]

We actually want to reduce the repository API, not expand it...

Comment by Dominik D [ 21/Jan/15 ]

Wow, ok. I guess you've got good reasons for it and I shouldn't try to convince you, that having methods for most common use cases out of the box is quite convenient?

If yes, then fine. I can create a common EntityRepository subclass for myself and put any helper methods I want there. This would at least cut down on the code duplication in my codebase.

If what you say is final, then we can close this ticket.

Cheers.

Comment by Marco Pivetta [ 22/Jan/15 ]

I guess you've got good reasons for it and I shouldn't try to convince you, that having methods for most common use cases out of the box is quite convenient?

The main problem is that adding API methods to repositories forces any subclasses to also apply eventual filtering logic to those as well.

Other than that, it's merely a question of interface segregation: the current API is hardly maintainable if we assume that many developers subclassed the EntityRepository class, therefore we should keep it locked until 3.x.

I'll actually mark this issue for 3.0 and defer discussion till then.

Comment by Dominik D [ 22/Jan/15 ]

Ok, thanks.





[DDC-3526] [GH-1273] Incorrect @throws doc. in getSingleScalarResult Created: 20/Jan/15  Updated: 20/Jan/15  Resolved: 20/Jan/15

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

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


 Description   

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

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

Message:

This method doesn't throw QueryException.

The documentation should says that it throws: "NoResultException" or "NonUniqueResultException"



 Comments   
Comment by Doctrine Bot [ 20/Jan/15 ]

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

Comment by Doctrine Bot [ 20/Jan/15 ]

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





[DDC-3525] Exception "The column id must be mapped to a field in class" when associationKey used Created: 20/Jan/15  Updated: 21/Jan/15

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

Type: Bug Priority: Major
Reporter: Ilya Antipenko Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: associationKey, foreign-key

Attachments: Text File foreign-key.log    

 Description   

I have issue when I use "associationKey"

I create test repo for reproduce this issue:
https://github.com/aivus/symfony2-foreign-bug

1. composer install
2. Set DB parameters in app/config/parameters.yml and create DB
3. php app/console doctrine:schema:create --force
4. php app/console server:run
5. Load fixtures: http://127.0.0.1:8000/app/loadFixture
6. Try to get list: http://127.0.0.1:8000/app_dev.php/admin/app/app/order/list

I make workaround, which works for me (https://github.com/aivus/doctrine2/commit/8461111e8aea98d02175f3642870a689d446beef), but I'm not sure about it



 Comments   
Comment by Ilya Antipenko [ 21/Jan/15 ]

Add stacktrace





[DDC-3524] [GH-1272] [DDC-2704] - merge inherited transient properties - merge properties into uninitialized proxies Created: 20/Jan/15  Updated: 25/Jan/15  Resolved: 25/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: inheritance, merge, private-properties, transient-properties, unitofwork

Issue Links:
Dependency
is required for DDC-2704 When using Discriminator EntityManage... Resolved

 Description   

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

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

Message:

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



 Comments   
Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 25/Jan/15 ]

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





[DDC-3523] [GH-1271] Update migration_2_5.rst Created: 20/Jan/15  Updated: 20/Jan/15  Resolved: 20/Jan/15

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

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


 Description   

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

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

Message:

Fixed some formatting issues and typos.






[DDC-3522] [GH-1270] Update composer on travis build. Created: 20/Jan/15  Updated: 20/Jan/15  Resolved: 20/Jan/15

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: Duplicate Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates DDC-3521 [GH-1269] [DDC-3520] self-update comp... Resolved

 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 20/Jan/15 ]

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





[DDC-3521] [GH-1269] [DDC-3520] self-update composer before install Created: 20/Jan/15  Updated: 20/Jan/15  Resolved: 20/Jan/15

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: composer, travis

Issue Links:
Duplicate
is duplicated by DDC-3522 [GH-1270] Update composer on travis b... Resolved

 Description   

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

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

Message:

Updating composer before install seems like a good idea. At the moment for example the travis build is failing because of the new composer syntax with '^' and it would be fixed by composer self-update.

Sorry for the spam, opened the pull request against master this time.



 Comments   
Comment by Doctrine Bot [ 20/Jan/15 ]

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





[DDC-3520] [GH-1268] Update composer before install Created: 20/Jan/15  Updated: 20/Jan/15  Resolved: 20/Jan/15

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

Type: Improvement Priority: Minor
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Incomplete Votes: 0
Labels: