[DDC-3647] [GH-1354] [RFC] Added support for OneToMany with orphanRemoval. Created: 01/Apr/15  Updated: 01/Apr/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 guilhermeblanco:

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

Message:

Replacing entire collection now deletes the replaced collection (scheduled for deletion). No event handling is done as it happens at DBAL level.

Fixes DDC-3644






[DDC-3646] Do not select unused columns in inner queries of Paginator Created: 31/Mar/15  Updated: 31/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: Improvement Priority: Minor
Reporter: Malte Wunsch Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: paginator
Environment:

In my case MySQL 5.1, other versions or DBMS may optimise that by themselves



 Description   

When a {{Paginator count()}}s, it fires a query like this:

SELECT COUNT(*) AS dctrn_count FROM (SELECT DISTINCT id0 FROM (%originalQuery%) dctrn_result) dctrn_table

an getIterator() does something similar for joined collections to get the ids in the first place:

SELECT DISTINCT id0, lastmod11 FROM (%originalQuery%) dctrn_result ORDER BY lastmod11 DESC LIMIT 10 OFFSET 0

My problem is that both the inner queries can be too heavy for a regular temporary table.

At first sight I noticed several LEFT JOIN s that could be stripped from the inner query without changing the result of the outer one. But that might have been a specially easy case, a general optimisation of the JOIN clauses might be harder. I think http://www.doctrine-project.org/jira/browse/DDC-2381 deals with that.

On second thought we noticed some ugly BLOB columns as part of the projection, which unhealthily bloated the temporary table. Ultimately, the BLOBs are needed for the paginated view, but they are neither needed for counting nor for getting the paginated ids.

Hence, I propose to remove unused columns from the projection in the inner queries. "Unused" means not being part of the SELECT or ORDER BY clause in the outer query (and maybe not part of GROUP BY, HAVING... - haven't checked on this yet). The key could be the $innerSql in the LimitSubqueryOutputWalker->walkSelectStatement(), but before investigating further, I'd like to hear from you what you think.



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

Please review https://github.com/doctrine/doctrine2/pull/1353, as it might solve this issue

Comment by Malte Wunsch [ 31/Mar/15 ]

Thanks for your quick reply!

To be honest, I don't fully get the PR. At least it's goals look very different to me. Anyway, in LimitSubqueryOutputWalker the $innerSQL is now being generated in getInnerSQL(). In there, some hiddenAliasResultVariable are set to false (and are later restored) so that the parent SQLWalker can reference selected fields better. This might be a requirement for implementing my idea, but as far as I understand, there are no columns removed from the select clause so far?

Comment by Doctrine Bot [ 31/Mar/15 ]

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





[DDC-3645] [GH-1353] Paginator fixes take3 Created: 27/Mar/15  Updated: 31/Mar/15  Resolved: 31/Mar/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: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: limitsubqueryoutputwalker, paginator

Issue Links:
Duplicate
is duplicated by DDC-3637 [GH-1347] problem with LimitSubqueryO... Resolved
is duplicated by DDC-3642 [GH-1351] Failing test cases regardin... Resolved

 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.



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

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

Comment by Doctrine Bot [ 31/Mar/15 ]

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

Comment by Doctrine Bot [ 31/Mar/15 ]

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





[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: 31/Mar/15  Resolved: 31/Mar/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: 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: entityGenerator, metadata


 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);`



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

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

Comment by Doctrine Bot [ 31/Mar/15 ]

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





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

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: paginator

Issue Links:
Duplicate
duplicates DDC-3645 [GH-1353] Paginator fixes take3 Resolved

 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

Comment by Doctrine Bot [ 31/Mar/15 ]

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

Comment by Doctrine Bot [ 31/Mar/15 ]

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

Comment by Marco Pivetta [ 31/Mar/15 ]

Merged into DDC-3645 (will be solved there)





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

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: DQL, 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: filter, sqlfilter


 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

Comment by Doctrine Bot [ 31/Mar/15 ]

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

Comment by Doctrine Bot [ 31/Mar/15 ]

A related Github Pull-Request [GH-1350] was closed:
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: 31/Mar/15  Resolved: 31/Mar/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: paginator

Issue Links:
Duplicate
duplicates DDC-3645 [GH-1353] Paginator fixes take3 Resolved

 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

Comment by Doctrine Bot [ 31/Mar/15 ]

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

Comment by Marco Pivetta [ 31/Mar/15 ]

Merged into DDC-3645 ( PR #1353 )





[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?





Generated at Wed Apr 01 07:59:59 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.