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

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

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


 Description   

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

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

Message:






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

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

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


 Description   

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

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

Message:

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



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

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

Comment by Doctrine Bot [ 27/Nov/14 ]

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





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

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

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


 Description   

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

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

Message:

Fixed case in DQL query in docs.



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

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

Comment by Doctrine Bot [ 28/Nov/14 ]

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





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

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

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

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

 Description   

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



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

Handled in DDC-3419





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

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

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

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

 Description   

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

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

Message:

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

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



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

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

Comment by Doctrine Bot [ 27/Nov/14 ]

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





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

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

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

not relevant


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

 Description   

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

{ ... }

`.






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

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

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


 Description   

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

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

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

t0.fieldName

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

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

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

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

And $cleanCriteria should be passed to expandParameters.



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

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





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

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

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


 Description   

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

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

Message:

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






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

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: configuration, entitymanager, listener, resolver


 Description   

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

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

Message:

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

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



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

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

Comment by Doctrine Bot [ 26/Nov/14 ]

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

Comment by Marco Pivetta [ 26/Nov/14 ]

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

Comment by Doctrine Bot [ 26/Nov/14 ]

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





[DDC-2559] [GH-728] Color message like the update tools Created: 19/Jul/13  Updated: 26/Nov/14  Resolved: 22/Jul/13

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

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


 Description   

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

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

Message:



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

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

Comment by Marco Pivetta [ 22/Jul/13 ]

Merged: https://github.com/doctrine/doctrine2/commit/4bc8f7be16b380b021c8aba37b7b9a78931e39f7

Comment by Doctrine Bot [ 26/Nov/14 ]

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





[DDC-3416] using getArrayResult and foreach with reference get a string at the end Created: 26/Nov/14  Updated: 26/Nov/14

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

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

doctrine2 alone, not inside symfony or any framework



 Description   

This bug is quite weird so let me explain it

I have 2 Entity

Category (language independant information)

CategoryDescription (language dependant category 1 -> N categoryDescription)

when i do

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

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

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

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

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






[DDC-490] Cannot use ORDER BY xxx ASC NULLS LAST / ORDER BY field = value DESC syntax Created: 01/Apr/10  Updated: 26/Nov/14  Resolved: 26/Jul/10

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

Type: Improvement Priority: Minor
Reporter: Michael Zach Assignee: Guilherme Blanco
Resolution: Fixed Votes: 1
Labels: None
Environment:

Debian 5.0, PostgreSQL 8.4.2


Attachments: Text File nulls.patch     File SortableNullsWalker.php    

 Description   

It is at the time of this writing not possible to use something like:

$qb = $em->createQueryBuilder()
			->select('p')
			->from('Domain\Person', 'p')
			->where('p.id = 1')
			->orderBy('p.firstname', 'ASC NULLS LAST');

or

$qb = $em->createQueryBuilder()
			->select('p')
			->from('Webges\Domain\Core\Person\Person', 'p')
			->where('p.id = 1')
			->orderBy('p.firstname', '= ?');

which is perfectly valid syntax in PostgreSQL and also standard according to: http://troels.arvin.dk/db/rdbms/#select-order_by

Question is: will this be implemented in the near future / do any plans exist to support this at all?

Currently the only way is to use a native query with a custom ResultSetMapping

I do understand that not all database systems implement this, but an improvement in this direction would be a nice feature.



 Comments   
Comment by Benjamin Eberlei [ 01/Apr/10 ]

We wont add this into the Core DQL, but you can add it yourself using a Custom SQL Walker instead of the default one and some sort of query hint or similiar, you would then extend the EntityManager and have createQuery return your own Query class that always uses the Custom Sql Walker.

There will be a Cookbook Entry on how to do something similar soonish, since this also affects Oracle Platform this would really make a nice DoctrineExtensions namespaced component. Can we interest you in such an endavour?

Comment by Michael Zach [ 01/Apr/10 ]

Actually I just finished a simple patch to allow this in Core, but surely it could fit into an extension as well - keep me posted and I'll look into it.

Modified / extended Doctrine\ORM\Query\AST\OrderByItem, Doctrine\ORM\Query\SqlWalker, Doctrine\ORM\Query\Lexer, Doctrine\ORM\Query\Parser as a proof of concept.

I suppose it is considered good practice to extend the Doctrine\ORM\Query\Lexer as well when adding custom values for said extension?

Any hints beforehand appreciated.

Comment by Benjamin Eberlei [ 01/Apr/10 ]

I just realized you posting this here it might be impossible to do in the custom walker, since you also need to change the parser. Roman any thoughts?

Comment by Roman S. Borschel [ 01/Apr/10 ]

I'm not sure. I don't think I would like adding this to the core right now as it seems a bit like bloat that only few people would use. Is this null ordering really a serious issue in practice? (I'm asking because I've never encountered it yet).

Hibernate has a similar request since 2005 (still open): http://opensource.atlassian.com/projects/hibernate/browse/HHH-465

The JPA specs say nothing about that topic. These two things make me wonder about the importance of this problem, of course they may simply have overlooked it.

If this null ordering is "essential" why not automatically pick a default (i.e. nulls last, which seems to be the default by the majority of databases) and enforce that on all order clauses. Bad idea?

Also, can the null ordering be configured in other ways, i.e. on the database side?

Comment by Michael Zach [ 02/Apr/10 ]

From what I've seen (at least in PostgreSQL), it cannot be configured on the DB side in general, but PG uses defaults for ASC / DESC - DESC is sorted NULLS FIRST, ASC is sorted NULLS LAST ( see: http://www.postgresql.org/docs/8.4/interactive/queries-order.html )

One way to solve this would be to use indexes with a default ordering (which kind of is the discussed DB configured ordering) - see: http://www.postgresql.org/docs/8.4/static/indexes-ordering.html

I could make an extension as suggested by Benjamin, although for this the Doctrine\ORM\Query\Lexer would at least need to change it's

private function _checkLiteral($identifier)

from

$name = 'Doctrine\ORM\Query\Lexer::T_' . strtoupper($identifier);

to

$name = get_class($this) . '::T_' . strtoupper($identifier);

in order to reduce duplicate code - sure, I could re-implement the functions behaviour, but this doesn't look like good OOP practice to me.

The gain of an extension would be to not only allow NULLS FIRST/LAST, but could be extended to allow

ORDER BY a + b, c
ORDER BY random()

constructs without the need to use a nativeQuery.

What do you guys think?

Comment by Benjamin Eberlei [ 02/Apr/10 ]

It could be added via QueryHints without changes to the parser and lexer, say:

    $query = $entityManager->createQuery("SELECT ... ORDER BY e.foo ASC, e.bar DESC")
    $query->setQueryHint(Query::HINT_CUSTOM_OUTPUT_WALKER, 'DoctrineExtensions\Query\SortableNullsWalker');
    $query->setQueryHint("sortableNulls.fields", array(
        "foo" => SortableNulls::NULLS_FIRST,
        "bar" => SortableNulls::NULLS_LAST,
    ));
    $results = $query->getResult();

See the latest commit with a cookbook recipe on how to write your own SQL Walker:

http://trac.doctrine-project.org/browser/docs/trunk/cookbook/en/dql-custom-walkers.txt?rev=7523

Comment by Michael Zach [ 02/Apr/10 ]

Benjamin, is it possible that this is coming in an upcoming svn commit? Currently, only a $query->setHint() implementation is available which does not call an own implementation class (DoctrineExtensions\Query\SortableNullsWalker).

The class consists of the two constants suggested by your last code example (didn't see a need to write an own class when it's only used in the walker, but can be changed) and the overwritten method "public function walkOrderByItem($orderByItem)".

Neither $query->getSql() nor $query->getResult() calls aforementioned custom walker, so I wonder if it's broken in the current svn trunk (rev. 7523) or if it's a new feature.

Comment by Benjamin Eberlei [ 02/Apr/10 ]

Hm, i used this already, it should work, the customWalker should be constructed in the Doctrine\ORM\Query\Parser::parse()

Comment by Michael Zach [ 02/Apr/10 ]

Proof of concept implementation - needs to to additional checks

Usage example can be found in class docblock

Comment by Michael Zach [ 02/Apr/10 ]

Changed attached file to an updated version, also adding patch against rev7523 to support in directly in Doctrine (if anyone is interested). Still proof of concept - feedback welcome.

Comment by Aigars Gedroics [ 21/Jul/10 ]

Is it possible to make similar SQL Walker for the 2nd problem for "ORDER BY p.id = 1" to work?

Comment by Guilherme Blanco [ 26/Jul/10 ]

I committed support to extensibility under Lexer.
Except that, nothing else can be done that is related to this ticket.

Although NULL FIRST/LAST is SQL Standard, it is not support across all RDBMS, and cannot be adapted between them. So we consider this support as "impossible" and forget about it.
But since you made a vlid request related to extensiblity of Lexer, this is one of the expected changes I was planning to do later on Doctrine. So I decided to commit it now.

Cheers,

Comment by Marc Drolet [ 20/Jun/12 ]

here is my implementaiton of the custom walker to do the trick for mysql, oracle and postgresql.

<?php
namespace DoctrineExtensions\CustomWalker;

use Doctrine\ORM\Query\SqlWalker;

/**

  • SortableNullsWalker
    */
    class SortableNullsWalker extends SqlWalker
    {
    const NULLS_FIRST = 'NULLS FIRST';
    const NULLS_LAST = 'NULLS LAST';

public function walkOrderByClause($orderByClause)
{
$sql = parent::walkOrderByClause($orderByClause);

if ($nullFields = $this->getQuery()->getHint('SortableNullsWalker.fields'))
{
if (is_array($nullFields))
{
$platform = $this->getConnection()>getDatabasePlatform()>getName();
switch ($platform)
{
case 'mysql':
// for mysql the nulls last is represented with - before the field name
foreach ($nullFields as $field => $sorting)
{
/**

  • NULLs are considered lower than any non-NULL value,
  • except if a - (minus) character is added before
  • the column name and ASC is changed to DESC, or DESC to ASC;
  • this minus-before-column-name feature seems undocumented.
    */
    if ('NULLS LAST' === $sorting) { $sql = preg_replace('/\s+([a-z])(\.' . $field . ') (ASC|DESC)?\s*/i', " -$1 $2 $3 ", $sql); }

    }
    break;
    case 'oracle':
    case 'postgresql':
    foreach ($nullFields as $field => $sorting)

    { $sql = preg_replace('/(\.' . $field . ') (ASC|DESC)?\s*/i', "$1 $2 " . $sorting, $sql); }

    break;
    default:
    // I don't know for other supported platforms.
    break;
    }
    }
    }

return $sql;
}
}

and I use it this way:
$query->setHint(Doctrine\ORM\Query::HINT_CUSTOM_OUTPUT_WALKER, 'DoctrineExtensions\CustomWalker\SortableNullsWalker')
->setHint('SortableNullsWalker.fields',
array(
'last_updated_date' => DoctrineExtensions\CustomWalker\SortableNullsWalker::NULLS_LAST,
)
);

hope this help

Comment by Israel Carberry [ 26/Nov/14 ]

Using Symfony 2.5.7 and Doctrine\ORM 2.5.0-DEV, the following changes seem to make the SortableNullsWalker work. This cleared up the errors I was getting, and the Symfony profiler shows the executable query I built using this class ending with ORDER BY b0_.example_date DESC NULLS LAST

--- old/SortableNullsWalker.php
+++ new/SortableNullsWalker.php
@@ -3,6 +3,7 @@
 namespace Webges\DoctrineExtensions\Query;
 
 use Doctrine\ORM\Query;
+use Doctrine\ORM\Query\AST\PathExpression;
 
 /**
  * The SortableNullsWalker is a TreeWalker that walks over a DQL AST and constructs
@@ -40,15 +41,11 @@
        if (is_array($hint) && count($hint)) {
            // check for a state field
            if (
-               $expr instanceof Query\AST\PathExpression &&
-               $expr->type == Query\AST\PathExpression::TYPE_STATE_FIELD
+               $expr instanceof PathExpression &&
+               $expr->type == PathExpression::TYPE_STATE_FIELD
            ) {
-               $parts = $expr->parts;
-               $fieldName = array_pop($parts);
-               $dqlAlias = $expr->identificationVariable . ( ! empty($parts) ? '.' . implode('.', $parts) : '');
-
                $search = $this->walkPathExpression($expr) . ' ' . $type;
-               $index  = $dqlAlias . '.' . $fieldName;
+               $index  = $expr->identificationVariable . '.' . $expr->field;
                $sql = str_replace($search, $search . ' ' . $hint[$index], $sql);
            }
        }




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

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

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


 Description   

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

So for example, writing this DQL:

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

produces:

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

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



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

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

Comment by Lewis Wright [ 26/Nov/14 ]

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

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

Comment by Marco Pivetta [ 26/Nov/14 ]

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

Comment by Lewis Wright [ 26/Nov/14 ]

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

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

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





[DDC-3415] [GH-1194] [DDC-3414] Add test for "Joining on a table with inheritance produces badly formed ON clause" Created: 26/Nov/14  Updated: 26/Nov/14

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

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


 Description   

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

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

Message:

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






[DDC-3181] Class Table Inheritance - wrong table order on insert with more than one level of inheritance Created: 20/Jun/14  Updated: 26/Nov/14

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

Type: Bug Priority: Major
Reporter: M. de Lange Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: orm
Environment:

oracle



 Description   

note: this issue seems the same as DDC-732

When using class table inheritance with multiple levels i.e.:
Object -> SolidObject -> Building -> House
(House inherits from Building, Building from SolidObject, SolidObject from Object)

Object has the discriminator column and mapping. When persisting a new House entity I get a foreign key error because there is no row in the Building table.

I searched in the Code and found the problem. In the class "Doctrine\ORM\Persisters\JoinedSubclassPersister" in function "executeInserts()" around line 146 the array $subTableStmts is first declared and then filled with insert statements. The statement of the House-table is first added, and then the parent-tables (except the root-table "Object", since that one is executed first).

So the order in which the insert statements are executed is:
1 Insert into Object ...
2 Insert into House ... (which causes the error)
3 insert into Building ...
4 Insert into SolidObject

I edited the source to insert into the parent-tables (first SolidObject, then Building) before inserting into the table that belongs to the class that is persisted (House). And this works fine in my case.



 Comments   
Comment by mohammed [ 26/Nov/14 ]

hello, can you please send me the modified lines or just share with me the whole method executeInserts.
thanks in advance





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

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

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


 Description   

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

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

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

For instance, the generated SQL statement generated might look like

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





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

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

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


 Description   

Imagine this situation:

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

Then somewhere else in code:

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

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

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

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

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


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

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

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

Comment by Marco Pivetta [ 19/Nov/14 ]

Does the issue also affect 2.4?

Comment by Oleg Namaka [ 24/Nov/14 ]

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

Regarding your first comment:

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

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

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

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

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

Comment by Oleg Namaka [ 25/Nov/14 ]

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

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

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

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

It looks identical to Proxy::__load generated in 2.3

Comment by Oleg Namaka [ 25/Nov/14 ]

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

Comment by Marco Pivetta [ 25/Nov/14 ]

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





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

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

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


 Description   

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

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

Message:



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

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

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

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

Comment by Doctrine Bot [ 25/Nov/14 ]

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





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

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

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


 Description   

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

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

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

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

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

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

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

I can only get half way there:

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

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

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

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

A workaround for this specific scenario is this:

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

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

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

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

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

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

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

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

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

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

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

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






[DDC-2557] [GH-725] Fix for problem with WHERE CASE LIKE Created: 17/Jul/13  Updated: 24/Nov/14  Resolved: 18/Jul/13

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

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

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

Message:

See details described here: https://groups.google.com/forum/#!topic/doctrine-user/EbVMYOPnHPs

Still missing: NOT LIKE and others....



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

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

Comment by Doctrine Bot [ 24/Nov/14 ]

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

Comment by Doctrine Bot [ 24/Nov/14 ]

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





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

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

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

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

 Description   

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

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

Message:

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

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



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

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

Comment by Doctrine Bot [ 23/Nov/14 ]

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





[DDC-2846] [GH-870] Documenting interface methods (based on entity manager) Created: 10/Dec/13  Updated: 23/Nov/14  Resolved: 10/Dec/13

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

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

Issue Links:
Dependency
is required for DDC-3409 [GH-1191] [2.4] Documenting interface... Resolved

 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 10/Dec/13 ]

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

Comment by Marco Pivetta [ 10/Dec/13 ]

Merged: https://github.com/doctrine/doctrine2/commit/2cccb3cc6269261ce6d4f70d581232b90a2fdabe





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

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

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


 Description   

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

User -> Address -> Plant -> Hierarchy

User OneToOne Address
Address ManyToOne Plant
Plant OneToOne Hierarchy

(all are fetched as eager loading)

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

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



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

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





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

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

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


 Description   

Hi,

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



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

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

Comment by Marco Pivetta [ 21/Nov/14 ]

Not an issue





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

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

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


 Description   

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

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

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

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



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

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





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

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

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


 Description   

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

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

Message:

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

This PR updates the documentation and variable names.



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

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





[DDC-3400] Wrong result using php-cli Created: 19/Nov/14  Updated: 20/Nov/14

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

Type: Bug Priority: Major
Reporter: Damir Abdijevic Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: cache, cli, dql, environment, orm
Environment:

Windows 7, Debian GNU/Linux 7 PHP 5.5.15



 Description   

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

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

Country Entity:

namespace MyApp\Model\Entity;

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

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

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

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

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


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

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

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

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

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

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

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

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

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

CountryI18nEntity:

namespace MyApp\Model\Entity;

use Doctrine\ORM\Mapping as ORM;

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

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

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

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


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

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

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

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

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

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

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

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

}


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

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

Comment by Damir Abdijevic [ 20/Nov/14 ]

O.k. here some further information.

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

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

/* locale_id = 2 */

The sql result is correct

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

QueryBuilder

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

That results in following SQL:

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

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

Comment by Damir Abdijevic [ 20/Nov/14 ]

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

Comment by Marco Pivetta [ 20/Nov/14 ]

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

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

Comment by Damir Abdijevic [ 20/Nov/14 ]

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

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





[DDC-3403] [GH-1187] Fixed counting exception. Created: 20/Nov/14  Updated: 20/Nov/14  Resolved: 20/Nov/14

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

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


 Description   

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

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

Message:

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



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

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

Comment by Doctrine Bot [ 20/Nov/14 ]

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





[DDC-2989] ORM should allow custom index names for foreign associations. Created: 07/Feb/14  Updated: 20/Nov/14

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

Type: Bug Priority: Minor
Reporter: Jonathon Suggs Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm, schematool

Issue Links:
Duplicate
is duplicated by DBAL-1047 doctrine:schema:update ignores index ... Resolved
Reference
relates to DBAL-234 Index names are not synchronized by C... Resolved
relates to DBAL-566 Schema Comparator does not identify r... Resolved
is referenced by DDC-2990 [GH-956] Foreign association index names Open

 Description   

Now that the DBAL allows/checks for renamed indexes, the ORM implementation needs to be enhanced to allow custom naming of the indexes for foreign associations.



 Comments   
Comment by Jonathon Suggs [ 07/Feb/14 ]

Here is a full example
https://github.com/jsuggs/schema-issue

I think this mainly has to do with the doctrine auto-generated indexes.

Comment by Marco Pivetta [ 15/Feb/14 ]

IIRC, index names cannot currently be assigned, and are computed automatically - that's why the ORM is behaving like that.

I don't think this needs a fix right now - lowering priority

Comment by Steve Müller [ 15/Feb/14 ]

Jonathon Suggs I also could not reproduce this bug in DBAL. I wonder if that is related to foreign key declarations (ORM relations) only. In fact, you cannot define index names for relations (foreign keys) in ORM at the moment. Therefore ORM always generates index names automatically. If you use custom names for those indexes in your online schema, the comparator will surely output the index renaming statement. I guess defining the index at table level in your mapping manually won't help here either.
Whatsoever I think this is an ORM only issue. If you manually changed your index names "online", you will now get some index rename statements when using the schema tool. Other users explicitly requested this feature. Schemas not in sync have to be upgraded, I guess. So IMO this is rather a "won't fix" in DBAL. However there is a possible improvement to ORM for being able to define index names for foreign keys. The whole topic is rather tricky concerning the comparator. Imagine you have (for whatever reason) multiple indexes with different names that span the exact same columns. How would you expect the comparator to output changes here? Which indexes should be renamed, which shouldn't?

Comment by Jonathon Suggs [ 18/Feb/14 ]

I guess I get it, but its kinda a big deal and I'll have to old off upgrading as a result. I personally find this more of a regression due to the unintended consequences. The schema diff is now 100% useless (to me) as I rename all of my indexes to a more semantic name.

My off the cuff thought on ORM index naming is that you expand the naming strategy to include support for the indexes. Given the full set of criteria you should be able to come up with some sort of semantic naming and only on namespace collision to you "fallback" to a hash of the columns (solves your issues and mine).

Comment by Jonathon Suggs [ 19/Feb/14 ]

To state differently, I (personally) value the schema diff tool much more than custom index (re)naming since the (overall) ability to use custom index names is not complete (due to the ORM issues Steve outlined above).

If the support to (re)name foreign key indexes can't go out in parallel to this, I'd like to offer a middle ground of making the index renaming configurable (ie ability to opt-out of functionality).

Sorry to be negative towards a new feature, but its really an inconvenience for me, and I suspect others since Strate also expressed concerns in the PR.

Let me know how I can be of help in working towards a resolution.

Comment by Benjamin Eberlei [ 19/Feb/14 ]

Jonathon Suggs What do you mean with "just upgraded"? Which to which version? The index renaming and coverage feature is very old already, not sure what is happening. Do you define an index for a relation column?

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

Benjamin Eberlei This definitely has to do with the comparator now comparing index names also.
Jonathon Suggs Can you please confirm my assumption that this problem is only related to relations and their foreign key indexes? Also can you confirm that it only affects those foreign key indexes which you gave a custom name? Can you please check that?
I don't see any reasonable solution in DBAL for this. The real solution IMO would be to allow custom names in ORM mappings for foreign key realation indexes.

Comment by Jonathon Suggs [ 19/Feb/14 ]

Sorry for the confusion.

Here is the PR that introduced the functionality in question.
https://github.com/doctrine/dbal/pull/473

Benjamin, I had just upgraded DBAL to the latest 2.5 master. This is only indirectly related to the ORM functionality as the ORM SchemaTool uses the DBAL Comparator to generate is schema diff.
Steve, yes this is only related to relations and foreign key indexes that were given a custom name. I documented the use case/scenario here: https://github.com/jsuggs/schema-issue

Steve, I see three potential solutions (in my personal order of preference).
1) Expand the NamingStrategy to allow it to handle the default names of foreign key relation indexes
2) As you suggested, allow for ORM mappings to specify foreign key relation indexes
3) Add a configuration directive that essentially allows for you to ignore renamed indexes (ie. fallback to the previous behavior, prior to PR 473).

I realize that #1 would be a bit more work, but I think offers enhanced functionality. #2 is a good, but would require additional annotations/mappings. #3 is probably the least dev effort but just doesn't feel right (to me).

Again, I don't want to seem critical of the dev effort, but its an unintended consequence that will keep me from being able to upgrade DBAL to 2.5.

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

Jonathon Suggs You are right the comparator is somewhat responsible for the "unnecesarry" schema diffs it now creates. However its functionality is completely working IMO. Try creating and comparing your schema example on DBAL level only (without utilizing ORM). You will see that it works. I see and understand that those index name updates are annoying but they are not WRONG. If you have a mapping for a relation with an unnamed index and rename this index in your online schema manually, I would even expect the schema tool to generate this diff. Because this is the whole point of the index rename feature. The problem we have here is that there currently is no way in ORM to define the index name on association mappings. There the following happens in your example when comparing the online and offline schema with the schema tool:

(abbreviated to the important steps, chronological order)

1. Collect mapping information and evaluate offline schema
1.1. Schema tool collects relation SQL for Bar -> Foo association and adds an unnamed index "IDX_76FF8CAA8E48560F" to table "bar"
1.2. Schema tool collects custom indexes defined in the mapping for "bar", detects the custom index "IDX_MANY_TO_ONE", tries to add it to the table "bar, but discards it because there is already another index "IDX_76FF8CAA8E48560F" fulfilling the exact same columns (this is how DBAL works ever since to avoid duplicate indexes)

2. Reverse-engineer online schema from database
2.1 Fetch all defined indexes for table "bar" -> adds "idx_many_to_one" to table "bar"

3. Comapre evaluated online schema to evaluated offline schema
3.1 Compare index "idx_many_to_one" (online schema) to index "IDX_76FF8CAA8E48560F" (offline schema) -> suggest index rename from "idx_many_to_one" to "IDX_76FF8CAA8E48560F" because the mapping is your definition and takes precedence.

Just to clarify what happens under the hood and that it is an ORM issue, not DBAL!

Comment by Jonathon Suggs [ 19/Feb/14 ]

Here is a first shot at basic support for allowing the mapping of the index name.
https://github.com/jsuggs/doctrine2/compare/foreign-association-index-names

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

Jonathon Suggs I have worked on a PR for this already using the exact same approach you just mentioned. However I am not quite sure about ManyToMany yet (because you would have to be able to define both index names there) and also I talked to Benjamin Eberlei and he does not seem to be happy with this approach. So I stopped work on this for the moment.

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

Moved this to ORM issues.

Comment by Jonathon Suggs [ 19/Feb/14 ]

Steve I both agree and disagree.

I think my underlying issue is your step 1.1. The ORM creates the index named "IDX_76FF8CAA8E48560F" and there is NO extension point for being able to override that behavior. FWIW, I've never been fond of the way that the ORM uses the AbstractAsset::_generateIdentifierName for generating the index and foreign key.

So I definitely agree that its is an ORM issue not DBAL issue . However, as I stated previously, until the ORM is updated/patched to allow for index naming, this (in my opinion) is a regression despite it working the way it currently does (correct or not).

I can close out this issue and open one for ORM. Do you have a old branch and/or ORM ticket that I can reference?

Thanks for engaging in the dialog! I hope to be of assistance in helping come up with a solution that gets everyone happy.

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

Jonathon Suggs Thanks for updating the description and thanks for assisting on this issue. We will find a solution for this before the final release of 2.5. If we cannot find a good solution until then we might also consider reverting the index renaming feature on DBAL (but I would like to avoid that). I will discuss this issue with the other core devs again and see what we can come up with.

Comment by Jonathon Suggs [ 19/Feb/14 ]

No problem, here is the start of a PR to maybe address the index names
https://github.com/doctrine/doctrine2/pull/956





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

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

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

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


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

 Description   

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

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

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

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

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

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

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

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



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

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

Comment by Thorry [ 18/Nov/14 ]

Thank you for your super fast response!

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

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

Comment by Thorry [ 18/Nov/14 ]

This bug was already fixed by guilhermeblanco in this commit.

Comment by Thorry [ 18/Nov/14 ]

Bug was already fixed in dev.

Comment by Christophe Coevoet [ 18/Nov/14 ]

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

Comment by Thorry [ 18/Nov/14 ]

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

Comment by Marco Pivetta [ 18/Nov/14 ]

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

Comment by Christophe Coevoet [ 19/Nov/14 ]

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

Comment by Thorry [ 19/Nov/14 ]

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

Comment by Marco Pivetta [ 19/Nov/14 ]

Yeah, let me clear that.





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

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

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


 Description   

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

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

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

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

Does this make sense?



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

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

Comment by Christophe Coevoet [ 14/Nov/14 ]

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

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

Comment by Gonzalo Vilaseca [ 14/Nov/14 ]

You're right regarding the metadata.

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

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

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

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

Comment by Gonzalo Vilaseca [ 19/Nov/14 ]

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

Comment by Marco Pivetta [ 19/Nov/14 ]

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





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

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

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


 Description   

The following example does work:

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

	use IDTrait;

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

}

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

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

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

}

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






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

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

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


 Description   

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

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

Message:

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



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

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





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

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

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


 Description   

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



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

Does this affect also later versions?





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

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

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

Linux, PHP 5.5.9



 Description   

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

The hierarchy is below:

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

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

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

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

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



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

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

Comment by Marco Pivetta [ 11/Nov/14 ]

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

Comment by Patrick Rose [ 12/Nov/14 ]

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

Comment by Patrick Rose [ 12/Nov/14 ]

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

Comment by Patrick Rose [ 12/Nov/14 ]

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

Comment by Marco Pivetta [ 13/Nov/14 ]

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

Comment by Patrick Rose [ 13/Nov/14 ]

Undoing monkey patch does not fully fix issue

Comment by Patrick Rose [ 13/Nov/14 ]

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

The JoinedSubclassPersister was overridden and just commented out two lines

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

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

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

Comment by Patrick Rose [ 13/Nov/14 ]

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

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

Comment by Patrick Rose [ 18/Nov/14 ]

Is there an update on how we can resolve this?

Comment by Patrick Rose [ 18/Nov/14 ]

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

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





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

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

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


 Description   

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

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

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

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

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

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






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

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

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


 Description   

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



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

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





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

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

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

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

 Description   

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

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

Message:

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

May be related/colliding with #1178

Ping @jaspernbrouwer






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

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

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


 Description   

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

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

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



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

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





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

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

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


 Description   

Hi,

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

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

Here's a quick example:

class MyInstantiator implements \Doctrine\Instantiator\InstantiatorInterface {

    private $container;

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

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

}

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

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

DoctrineORMMappingClassMetadataInfo.php
class ClassMetadataInfo implements ClassMetadata
{
    ...

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

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

    // ...

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

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

Thanks,



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

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

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

Marking as Won't Fix.

Comment by Rekamlefat [ 13/Nov/14 ]

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

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

Have a nice evening

Comment by Marco Pivetta [ 13/Nov/14 ]

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

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

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





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

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Can't Fix Votes: 0
Labels: collection, interface, iterator


 Description   

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

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

Message:

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



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

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

Comment by Doctrine Bot [ 13/Nov/14 ]

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

Comment by Marco Pivetta [ 13/Nov/14 ]

Can't be done in 2.x





[DDC-2894] on-update cascade for one-to-one association Created: 08/Jan/14  Updated: 13/Nov/14

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

Type: Bug Priority: Minor
Reporter: I. S. Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: orm, schematool, xml


 Description   

I'm trying to use on-update cascade in a one-to-one association but it ends in on-update restrict when I update the database tables.
I'm using XML Definition an my definition for this specific association looks like this:

<one-to-one field="scope" target-entity="Application\Entity\Scope">
<join-column name="scope_id" referenced-column-name="id" nullable="false" on-delete="CASCADE" on-update="CASCADE" />
<cascade>
<cascade-persist />
<cascade-remove />
</cascade>
</one-to-one>

This works pretty well when I use on-update="CASCADE" in a many-to-one association, but one-to-one just ignores it.
When I change the database manually everything works well, but the next update from command line will override it.



 Comments   
Comment by Pradeep Krishnan [ 12/Nov/14 ]

Any updates on this one?

Comment by Marco Pivetta [ 13/Nov/14 ]

We don't support on-update anymore, as identifiers should be immutable.





[DDC-2230] Changes from DDC-1690 trigger a bug in entity merging Created: 09/Jan/13  Updated: 12/Nov/14  Resolved: 26/Feb/13

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

Type: Bug Priority: Critical
Reporter: Patrick Schwisow Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

Following the changes for DDC-1690, I encountered a serious bug in how EntityManager::merge(...) functions for entities that use NOTIFY change tracking. It's related to interaction between lazy loading and calls to addPropertyChangedListener().

Scenario:

  • EntityA has a One-To-One, lazy-load association to EntityB
  • EntityB implements NotifyPropertyChanged and uses change tracking policy "NOTIFY"

Steps to reproduce:

  1. $instanceA = $em->find('EntityA', $id)
  2. $em->clear()
  3. $instanceA = $em->merge($instanceA)
  4. $instanceA->getB() will return a proxy for B that is marked as initialized by contains no data

Workaround: Mark EntityB::addPropertyChangedListener(...) as 'final', so it doesn't get proxied and lazy loading is not triggered.



 Comments   
Comment by Patrick Schwisow [ 09/Jan/13 ]

Also, the returned proxy from $instanceA->getB() is in the entityStates array but not in the identity map

Comment by Marco Pivetta [ 23/Jan/13 ]

Looks like this one is related to DDC-1734

Comment by Marco Pivetta [ 23/Feb/13 ]

I implemented a fix at https://github.com/Ocramius/doctrine2/compare/hotfix;DDC-2230

Please let me know if that branch works for you: I will open a PR tomorrow.

Comment by Benjamin Eberlei [ 23/Feb/13 ]

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

Comment by Benjamin Eberlei [ 26/Feb/13 ]

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

Comment by Doctrine Bot [ 29/Apr/14 ]

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

Comment by Doctrine Bot [ 12/Nov/14 ]

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





[DDC-1942] problem with serialize/merging entities with aggregation Created: 24/Jul/12  Updated: 12/Nov/14  Resolved: 27/Feb/13

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

Type: Bug Priority: Major
Reporter: gabriel sancho Assignee: Marco Pivetta
Resolution: Duplicate Votes: 3
Labels: merge, serialize
Environment:

linux, php 5.4.4, apache 2.2.22, mysql 5.5


Attachments: Text File project_debug.log    

 Description   

i have these two entities:

namespace nuevo_paquete;

class Clase_01{
	/**
	* @Id
	* @Column(name="id",type="integer",nullable=false)
	* @GeneratedValue
	*/
	protected $id;
        
        /**
	* @ManyToOne(targetEntity="\paquete_02\Clase_03", inversedBy="clase_01", fetch="EXTRA_LAZY", cascade={"detach","merge"})
	* @JoinColumn(name="clase_03", referencedColumnName="id")
	*/
	protected $clase_03;

        /**
	* @ManyToOne(targetEntity="\paquete_02\Clase_03", inversedBy="clase_01_1", fetch="EXTRA_LAZY", cascade={"detach","merge"})
	* @JoinColumn(name="clase_03_1", referencedColumnName="id")
	*/
	protected $clase_03_1;
}
namespace paquete_02;
class Clase_03{
   /**
	* @Id
	* @Column(name="id",type="integer",nullable=false)
	* @GeneratedValue
	*/
	protected $id;

        /**
	* @OneToMany(targetEntity="\nuevo_paquete\Clase_01", mappedBy="clase_03", fetch="EXTRA_LAZY", cascade={"detach"})
	*/
	protected $clase_01;
	
	/**
	* @OneToMany(targetEntity="\nuevo_paquete\Clase_01", mappedBy="clase_03_1", fetch="EXTRA_LAZY", cascade={"detach"})
	*/
	protected $clase_01_1;
}

Clase_01 have two aggregation association with Clase_03

Clase_01 ------> Clase_03

-----> Clase_03_1

when serialize an object of class Clase_01 and then unserialize, i lost the reference to the object of class Clase_03
but i can see Clase_03_1

ej:

$aux_orm = $em->find('nuevo_paquete\Clase_01', 1);
$em->detach($aux_orm);
$aux_s = serialize($aux_orm);
$aux_orm = unserialize($aux_s);

$aux_orm = $em->merge($aux_orm);
echo '['.$aux_orm->getId().']'; // [1]
echo '['.$aux_orm->getClase_03()->getId().']'; // [] expected : [1]
echo '['.$aux_orm->getClase_03_1()->getId().']'; // [1]

when i call get_clase_03() before detach the object, i can see the object Clase_03
ej:

$aux_orm = $em->find('nuevo_paquete\Clase_01', 1);
$aux_orm->getClase_03()->getId();

$em->detach($aux_orm);
$aux_s = serialize($aux_orm);
$aux_orm = unserialize($aux_s);

$aux_orm = $em->merge($aux_orm);
echo '['.$aux_orm->getId().']'; // [1]
echo '['.$aux_orm->getClase_03()->getId().']'; // [1]
echo '['.$aux_orm->getClase_03_1()->getId().']'; // [1]


 Comments   
Comment by gabriel sancho [ 24/Jul/12 ]

if i call $em->find() i still not able to view the object

//----------------------------------------
$aux_orm = $em->find('nuevo_paquete\Clase_01', 1);
$em->detach($aux_orm);
$aux_s = serialize($aux_orm);
$aux_orm = unserialize($aux_s);

$aux_orm = $em->merge($aux_orm);
echo '['.$aux_orm->getId().']'; // [1]
echo '['.$aux_orm->getClase_03()->getId().']'; // [] expected : [1]
echo '['.$aux_orm->getClase_03_1()->getId().']'; // [1]

$aux_orm = $em->find('nuevo_paquete\Clase_01', 1);
echo '['.$aux_orm->getId().']'; // [1]
echo '['.$aux_orm->getClase_03()->getId().']'; // still empty [] expected : [1]

//----------------------------------------
and if i have another register referencing the same object of class_03, i can't view
ej:

$aux_orm = $em->find('nuevo_paquete\Clase_01', 2);
echo '['.$aux_orm->getId().']'; // [2]
echo '['.$aux_orm->getClase_03()->getId().']'; // still empty [] expected : [1]
Comment by Marquez Alejandra [ 24/Jul/12 ]

i have the same problem

Comment by Benjamin Eberlei [ 29/Jul/12 ]

formatted code

Comment by Benjamin Eberlei [ 29/Jul/12 ]

Can you paste a var_dump() of class1 after you call detach and before serialize and then another one after you called unserialize? Also a var_dump of the serialized string $aux_s

Comment by gabriel sancho [ 30/Jul/12 ]

var_dump in attached file

Comment by gabriel sancho [ 11/Sep/12 ]

i found that if the class has more than two levels have the same problem
by ex. i have to do

// class1 -> register id 1
// class2 -> register id 1
// class3 -> null, don't exist
$class2 = $class1->getClass2();
$class3 = $class2->getClass3();
$class3->getId();

otherwise doctrine insert new registers in database for class3
after unserialize

Comment by gonzalo [ 11/Sep/12 ]

I have same problems

Comment by gabriel sancho [ 11/Sep/12 ]

if i declare in the entity annotation fetch="EAGER" works fine

Comment by Valentin Claras [ 11/Dec/12 ]

I have the same problem.

From what I saw, if I use fetch: EAGER, all my distinct entities are merged indeed, but if a specific entity (instance) is in two different collections, only one collection will have this instance.

So, any news about this bug ?

Comment by Valentin Claras [ 13/Dec/12 ]

I'm still trying to get my stuff works, and I'm now pretty sure that as soon as an object have to be merge more than once in a row (because of cascade associations), it end up being only in one collection, and lost for other entities.

I hope this could help.

Comment by Marco Pivetta [ 23/Jan/13 ]

I think this one is also related with DDC-1734 (noticed a lot of un-initialized objects).

gabriel sancho can you please try initializing ALL of these related objects prior to detaching/serializing and repeat your checks?

Comment by gabriel sancho [ 24/Jan/13 ]

How do I have to initialize the objects?

Comment by Marco Pivetta [ 24/Jan/13 ]

gabriel sancho by calling any method that is not `getId` on them.
This will initialize them

Comment by Marco Pivetta [ 23/Feb/13 ]

gabriel sancho news on this one? Managed to verify it?

Comment by Marco Pivetta [ 23/Feb/13 ]

This may be a duplicate of DDC-2306

Comment by Benjamin Eberlei [ 26/Feb/13 ]

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

Comment by Marco Pivetta [ 27/Feb/13 ]

This issue is valid only before the fix introduced at DDC-2306. Duplicate confirmed

Comment by Doctrine Bot [ 29/Apr/14 ]

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

Comment by Doctrine Bot [ 12/Nov/14 ]

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





[DDC-3368] [GH-1172] Don't initialize detached proxies when merging them. Created: 02/Nov/14  Updated: 12/Nov/14

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

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


 Description   

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

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

Message:

Ticket DDC-1392 fixed an issue where uninitialized proxies could not be merged
because the merge routine couldn't get the identifier from them. The soution
was to initialize the proxy.
Ticket DDC-1734 fixed the merging of unserialized uninitialized proxies by
resetting their internals, so these proxies were able to initialize, as required
by the fix for DDC-1392.

Somehow, in the meanwhile, the fix for DDC-1392 is not needed anymore:
reverting the patch will not break the associated test (but it does break the
test for DDC-1734). This means it is not needed anymore to initialize the proxy
when merging.

Uninitialized proxies that get merged should not be loaded at all. Since they
are not initialized, the entity data for sure hasn't changed, so it can be
safely ignored. Actually, the only thing the data is needed for while merging,
is to copy it into the managed entity, but that one is already supposed to be
up to date. By not initializing the proxy, a potential database roundtrip is
saved, and the fix for DDC-1734 is not needed anymore.

Besides optimizing the merge, this patch also solves an issue with merging.
Currently, when a detached uninitialized proxy is merged while there is already a
corresponding managed entity (proxy or not), the ORM returns a blank entity
instead of returning the already managed entity. This patch makes sure that
already existing managed entities are re-used.



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

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





[DDC-3390] [GH-1185] add a new method that return the mapped properties Created: 12/Nov/14  Updated: 12/Nov/14

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

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


 Description   

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

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

Message:

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

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

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

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






[DDC-2338] Entity with composite foreign keys identifiers should be persisted after related entities without exception Created: 07/Mar/13  Updated: 12/Nov/14  Resolved: 12/Nov/14

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

Type: Improvement Priority: Minor
Reporter: Alessandro Tagliapietra Assignee: Marco Pivetta
Resolution: Can't Fix Votes: 0
Labels: autoincrement, commitorder, identifier, identity, orm, sequence, unitofwork
Environment:

Mac OSX 10.8, php 5.4.11, doctrine git master version


Issue Links:
Dependency
depends on DDC-2339 [GH-605] DDC-2338 Added failing test ... Resolved
Reference
relates to DDC-3389 [GH-1184] Postgres SERIAL is not a po... Resolved

 Description   

I've seen that when you create an entity with a composite foreign key as identifier it cannot be flushed until the related entities are already flushed to the database and not just persisted.

It would be nice to let the user flush all the entities together and just INSERT first the related entities to get the ID and then use that to INSERT the entity with composite foreign keys.

I'm going to create a pull request with the failing test.



 Comments   
Comment by Alessandro Tagliapietra [ 07/Mar/13 ]

Created pull request https://github.com/doctrine/doctrine2/pull/605

Comment by Doctrine Bot [ 12/Nov/14 ]

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

Comment by Marco Pivetta [ 12/Nov/14 ]

Known limitation affecting only post-insert ID generation (mysql et simila)





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

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

Type: Documentation Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: identifier, identity, postgresql, sequence

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

 Description   

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

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

Message:



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

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

Comment by Doctrine Bot [ 12/Nov/14 ]

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





[DDC-2339] [GH-605] DDC-2338 Added failing test for composite foreign key persistance Created: 07/Mar/13  Updated: 12/Nov/14  Resolved: 12/Nov/14

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

Type: Improvement Priority: Major
Reporter: Benjamin Eberlei Assignee: Marco Pivetta
Resolution: Can't Fix Votes: 0
Labels: autoincrement, commitorder, generation, identifier, identity, sequence

Issue Links:
Dependency
is required for DDC-2338 Entity with composite foreign keys id... Resolved
Reference
relates to DDC-3389 [GH-1184] Postgres SERIAL is not a po... Resolved

 Description   

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

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

Message:

I've added this test regarding ticket DDC-2338



 Comments   
Comment by Benjamin Eberlei [ 09/May/13 ]

This is documented behavior and would just be an improvement

Comment by Doctrine Bot [ 13/May/14 ]

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

Comment by Doctrine Bot [ 12/Nov/14 ]

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





[DDC-3388] [GH-1183] Update tools.rst Created: 12/Nov/14  Updated: 12/Nov/14  Resolved: 12/Nov/14

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

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


 Description   

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

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

Message:



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

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





[DDC-2945] [GH-925] [DDC-2310] [DDC-2675] [2.4] Fix SQL generation on table lock hint capable platforms Created: 31/Jan/14  Updated: 11/Nov/14  Resolved: 11/Nov/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: lockhints, sql

Issue Links:
Dependency
depends on DDC-2310 Recent changes to DBAL SQL Server pla... Resolved

 Description   

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

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

Message:

Backport of PR https://github.com/doctrine/doctrine2/pull/910 for 2.4 branch.



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

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

Comment by Doctrine Bot [ 11/Nov/14 ]

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





[DDC-2310] Recent changes to DBAL SQL Server platform lock hinting breaks ORM SqlWalker in DQL queries with joins Created: 21/Feb/13  Updated: 11/Nov/14  Resolved: 01/Mar/14

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

Type: Bug Priority: Critical
Reporter: William Schaller Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: dbal, lockhints, orm, sqlserver, sqlsrv
Environment:

SQL Server


Issue Links:
Dependency
depends on DDC-2914 [GH-910] [DDC-2310] Fix SQL generatio... Resolved
is required for DDC-2945 [GH-925] [DDC-2310] [DDC-2675] [2.4] ... Resolved
Duplicate
duplicates DDC-2675 WITH (NOLOCK) failing when using JOIN Awaiting Feedback
Reference
is referenced by DBAL-783 [GH-508] [DDC-2310] Fix evaluation of... Resolved
is referenced by DBAL-976 [GH-663] [DDC-2310] [2.4] Fix evaluat... Resolved
is referenced by DDC-2919 LockMode::NONE evaluation inconsisten... Resolved

 Description   

The SQL Server platform throws an error when you try to run DQL with JOIN statements.

The breaking change was in the DBAL SQL Server platform – it was changed to add a ' WITH (NOLOCK)' to the appendLockHint function. Change was in this rev. The change in DBAL is not wrong, it just highlighted the bug in the ORM...

The ORM SqlWalker runs the appendLockHint function against a generated FROM / JOIN clause in the walkFromClause func here. This is actually the wrong place to append lock hints. This is generating the FROM clause like:

 FROM foo f0_ LEFT JOIN foo_bar f1_ ON f0_.id = f1_.foo_id LEFT JOIN bar b2_ ON f1_.bar_id = b2_.id WITH (NOLOCK)

When it should actually generate something like:

 FROM foo f0_ WITH (NOLOCK) LEFT JOIN foo_bar f1_ WITH (NOLOCK) ON f0_.id = f1_.foo_id LEFT JOIN bar b2_ WITH (NOLOCK) ON f1_.bar_id = b2_.id

It should append lock hints after the table alias.

I think the only reason this hasn't shown up before is that the other lock hint types haven't been applied in this way before, if at all.



 Comments   
Comment by Christophe Coevoet [ 21/Feb/13 ]

I think the line appending the lock should be moved to this place to achieve the result displayed above.

But it may cause issues with some other vendor.

Comment by William Schaller [ 21/Feb/13 ]

@Christophe I considered that too. None of the other platforms implement the appendLockHint function. None of the other platforms implement this because it is handled differently on other platforms – with transaction isolation levels and such.

Comment by Steve Müller [ 13/Jan/14 ]

I don't know why this ticket is marked as "fixed" because it's obviously NOT.
Whatever, here is the patch: https://github.com/doctrine/doctrine2/pull/910

Comment by Steve Müller [ 13/Jan/14 ]

Complementary I provided the following patch to suppress unnecessary NOLOCK hint generation in ORM: https://github.com/doctrine/dbal/pull/508

Comment by Doctrine Bot [ 14/Jan/14 ]

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

Comment by Steve Müller [ 15/Jan/14 ]

This is not resolved, yet.

Comment by Doctrine Bot [ 31/Jan/14 ]

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

Comment by Benjamin Eberlei [ 09/Feb/14 ]

Steve Müller When is it?

Comment by Steve Müller [ 09/Feb/14 ]

Benjamin Eberlei It is fixed in PR: https://github.com/doctrine/doctrine2/pull/910





[DDC-2675] WITH (NOLOCK) failing when using JOIN Created: 12/Sep/13  Updated: 11/Nov/14

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

Type: Bug Priority: Major
Reporter: Flip Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 2
Labels: None
Environment:

MSSQL 2008 R2


Issue Links:
Duplicate
is duplicated by DDC-2310 Recent changes to DBAL SQL Server pla... Resolved
Reference
is referenced by DDC-2919 LockMode::NONE evaluation inconsisten... Resolved

 Description   

I ran the doctrine test suite and there are a lot of tests failing with

[SQL Server]Incorrect syntax near the keyword 'with'

List of failing test because of this issue:
2) Doctrine\Tests\ORM\Functional\AdvancedDqlQueryTest::testUnnamedScalarResultsAreOneBased
3) Doctrine\Tests\ORM\Functional\AdvancedDqlQueryTest::testOrderByResultVariableCollectionSize
4) Doctrine\Tests\ORM\Functional\AdvancedDqlQueryTest::testIsNullAssociation
5) Doctrine\Tests\ORM\Functional\AdvancedDqlQueryTest::testSelectSubselect
6) Doctrine\Tests\ORM\Functional\AdvancedDqlQueryTest::testInSubselect
7) Doctrine\Tests\ORM\Functional\AdvancedDqlQueryTest::testGroupByMultipleFields
8) Doctrine\Tests\ORM\Functional\AdvancedDqlQueryTest::testUpdateAs
9) Doctrine\Tests\ORM\Functional\AdvancedDqlQueryTest::testDeleteAs
10) Doctrine\Tests\ORM\Functional\ClassTableInheritanceTest::testCRUD
11) Doctrine\Tests\ORM\Functional\ClassTableInheritanceTest::testSelfReferencingOneToOne
12) Doctrine\Tests\ORM\Functional\ClassTableInheritanceTest::testSelfReferencingManyToMany
13) Doctrine\Tests\ORM\Functional\ClassTableInheritanceTest::testLazyLoading2
14) Doctrine\Tests\ORM\Functional\ClassTableInheritanceTest::testBulkUpdateIssueDDC368
15) Doctrine\Tests\ORM\Functional\ClassTableInheritanceTest::testBulkUpdateNonScalarParameterDDC1341
16) Doctrine\Tests\ORM\Functional\ClassTableInheritanceTest::testQueryForInheritedSingleValuedAssociation
17) Doctrine\Tests\ORM\Functional\Locking\OptimisticTest::testJoinedChildFailureThrowsException
18) Doctrine\Tests\ORM\Functional\Locking\OptimisticTest::testJoinedParentFailureThrowsException
19) Doctrine\Tests\ORM\Functional\OrderedJoinedTableInheritanceCollectionTest::testOrderdOneToManyCollection
20) Doctrine\Tests\ORM\Functional\QueryDqlFunctionTest::testAggregateSum
21) Doctrine\Tests\ORM\Functional\QueryDqlFunctionTest::testAggregateAvg
22) Doctrine\Tests\ORM\Functional\QueryDqlFunctionTest::testAggregateMin
23) Doctrine\Tests\ORM\Functional\QueryDqlFunctionTest::testAggregateMax
24) Doctrine\Tests\ORM\Functional\QueryDqlFunctionTest::testAggregateCount
25) Doctrine\Tests\ORM\Functional\QueryDqlFunctionTest::testFunctionAbs
26) Doctrine\Tests\ORM\Functional\QueryDqlFunctionTest::testFunctionConcat
27) Doctrine\Tests\ORM\Functional\QueryDqlFunctionTest::testFunctionLength
28) Doctrine\Tests\ORM\Functional\QueryDqlFunctionTest::testFunctionLocate
29) Doctrine\Tests\ORM\Functional\QueryDqlFunctionTest::testFunctionLower
30) Doctrine\Tests\ORM\Functional\QueryDqlFunctionTest::testFunctionMod
31) Doctrine\Tests\ORM\Functional\QueryDqlFunctionTest::testFunctionSqrt
32) Doctrine\Tests\ORM\Functional\QueryDqlFunctionTest::testFunctionUpper
33) Doctrine\Tests\ORM\Functional\QueryDqlFunctionTest::testFunctionSubstring
34) Doctrine\Tests\ORM\Functional\QueryDqlFunctionTest::testFunctionTrim
35) Doctrine\Tests\ORM\Functional\QueryDqlFunctionTest::testOperatorAdd
36) Doctrine\Tests\ORM\Functional\QueryDqlFunctionTest::testOperatorSub
37) Doctrine\Tests\ORM\Functional\QueryDqlFunctionTest::testOperatorMultiply
38) Doctrine\Tests\ORM\Functional\QueryDqlFunctionTest::testOperatorDiv
39) Doctrine\Tests\ORM\Functional\QueryDqlFunctionTest::testConcatFunction
40) Doctrine\Tests\ORM\Functional\QueryDqlFunctionTest::testDateDiff
41) Doctrine\Tests\ORM\Functional\QueryDqlFunctionTest::testDateAdd
42) Doctrine\Tests\ORM\Functional\QueryDqlFunctionTest::testDateSub
43) Doctrine\Tests\ORM\Functional\QueryDqlFunctionTest::testBitOrComparison
44) Doctrine\Tests\ORM\Functional\QueryDqlFunctionTest::testBitAndComparison
45) Doctrine\Tests\ORM\Functional\SQLFilterTest::testJoinSubclassPersister_FilterOnlyOnRootTableWhenFetchingSubEntity
46) Doctrine\Tests\ORM\Functional\SQLFilterTest::testJoinSubclassPersister_FilterOnlyOnRootTableWhenFetchingRootEntity
47) Doctrine\Tests\ORM\Functional\Ticket\DDC163Test::testQueryWithOrConditionUsingTwoRelationOnSameEntity
48) Doctrine\Tests\ORM\Functional\Ticket\DDC168Test::testJoinedSubclassPersisterRequiresSpecificOrderOfMetadataReflFieldsArray
49) Doctrine\Tests\ORM\Functional\Ticket\DDC1995Test::testIssue
50) Doctrine\Tests\ORM\Functional\Ticket\DDC1995Test::testQueryCache
51) Doctrine\Tests\ORM\Functional\Ticket\DDC2090Test::testIssue
53) Doctrine\Tests\ORM\Functional\Ticket\DDC279Test::testDDC279
54) Doctrine\Tests\ORM\Functional\Ticket\DDC933Test::testLockCTIClass

One example, test 20)
Generated SQL:

SELECT SUM(c0_.salary) AS sclr0
FROM company_managers c1_
INNER JOIN company_employees c0_ ON c1_.id = c0_.id
INNER JOIN company_persons c2_ ON c1_.id = c2_.id
WITH (NOLOCK)

Solution:
Placing WITH (NOLOCK) after the table(s), instead of after ON clause. Depending on the wanted result it should be placed several times when using JOIN. See this StackOverflow Post for more information:
http://stackoverflow.com/questions/3783525/sql-server-nolock-and-joins



 Comments   
Comment by Steve Müller [ 15/Jan/14 ]

Please refer to DDC-2310 as it describes exactly the same issue.

Comment by Doctrine Bot [ 31/Jan/14 ]

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

Comment by Doctrine Bot [ 11/Nov/14 ]

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

Comment by Doctrine Bot [ 11/Nov/14 ]

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





[DDC-2914] [GH-910] [DDC-2310] Fix SQL generation on table lock hint capable platforms Created: 13/Jan/14  Updated: 11/Nov/14  Resolved: 18/Aug/14

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

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

Issue Links:
Dependency
is required for DDC-2310 Recent changes to DBAL SQL Server pla... Resolved

 Description   

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

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

Message:

SQL Server and SQL Anywhere use table lock hints for locking. ORM generates wrong SQL when used in conjunction with joins, in a table inheritance scenario or in a subquery. It places the table lock hints after the `JOIN` clauses, which is wrong. The table lock hints have to be placed after each table alias in the `FROM` clause.

*Example (current)*
```sql
SELECT t0.id FROM users t0 INNER JOIN profiles t1 ON t0.id = t1.user_id WITH (NOLOCK)
```

*Example (expected)*
```sql
SELECT t0.id FROM users t0 WITH (NOLOCK) INNER JOIN profiles t1 ON t0.id = t1.user_id
```

The testsuites fail big time at the moment because of that and I suppose ORM is more or less unusable at the moment for those platforms without this patch.

I needed to adjust a lot of tests which compared compiled DQL, to make use of the platforms specific lock hint clauses.
Also I did not add new tests because there are already so many tests, where this fails without this patch that this is not necessary IMO.



 Comments   
Comment by Doctrine Bot [ 31/Jan/14 ]

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

Comment by Doctrine Bot [ 11/Nov/14 ]

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

Comment by Doctrine Bot [ 11/Nov/14 ]

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





[DDC-3223] Failing test (get id return string type) Created: 22/Jul/14  Updated: 11/Nov/14

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

Type: Bug Priority: Minor
Reporter: Thomas Lallement Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Linux Ubuntu 13.10 / PHP 5.5.3 / Mysql 5.5.x


Issue Links:
Dependency
depends on DDC-3387 [GH-1182] #1086 identifier type in pr... Open

 Description   

I found an issue in a specific case, when you find a child entity (JOINED) which is linked to another child entity.

If I clone the linked child entity and call getId(), it gives the value as 'string' rather than 'integer'. If I set the property id as public, there is no problem.

If I call getId on the child entity rather than the clone, it gives 'integer' as expected. So it's weird...

See failing test here: https://github.com/doctrine/doctrine2/pull/1086



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

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





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

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

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


 Description   

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

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

Message:

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

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

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



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

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





[DDC-2354] [GH-617] Wrong UnitOfWork::computeChangeSet() Created: 16/Mar/13  Updated: 11/Nov/14  Resolved: 11/Nov/14

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

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Marco Pivetta
Resolution: Cannot Reproduce Votes: 0
Labels: listener, merge, proxy


 Description   

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

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

Message:

Sometimes some fields are Proxy when compute "changeSet". If it is Proxy, some listeners - example Gedmo sortable listener - belive the value has changed and this leads to chaos.

I check the $actualValue, if it is Proxy, the value didn't change.



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

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

Comment by Doctrine Bot [ 11/Nov/14 ]

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





[DDC-3231] [GH-1089] Entity repository generator default repository Created: 27/Jul/14  Updated: 11/Nov/14  Resolved: 11/Nov/14

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


 Description   

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

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

Message:

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

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



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

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

Comment by Doctrine Bot [ 11/Nov/14 ]

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





[DDC-2167] [GH-522] [DDC-2166] Refactor identity hash generation Created: 25/Nov/12  Updated: 11/Nov/14  Resolved: 11/Nov/14

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

Type: Improvement Priority: Major
Reporter: Benjamin Eberlei Assignee: Marco Pivetta
Resolution: Incomplete Votes: 0
Labels: hashing, identifier, unitofwork


 Description   

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

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

Message:

This work prepares for the merge of GH-232, allowing more complex and robust identifier hash generation.



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

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

Comment by Doctrine Bot [ 11/Nov/14 ]

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





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

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

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


 Description   

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

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

Message:

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



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

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





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

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: Invalid Votes: 0
Labels: dql, filter-collection


 Description   

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

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

Message:

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



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

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

Comment by Doctrine Bot [ 11/Nov/14 ]

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





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

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

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

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

 Description   

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

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

Message:

See #385 (this PR supersedes it)

The final aim is allowing something like:

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

This PR depends also on doctrine/common#342






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

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: entityGenerator, postgresql, schema

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

 Description   

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

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

Message:

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

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

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

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

These data are also placed in the metadata.



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

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

Comment by Doctrine Bot [ 11/Nov/14 ]

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





[DDC-2881] [GH-895] Fix for no dot on Class Names Created: 04/Jan/14  Updated: 11/Nov/14

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

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

Issue Links:
Duplicate
is duplicated by DDC-3384 [GH-1180] Fix for no dot on Class Names Resolved

 Description   

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

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

Message:

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

Additionally, there is a variable ($schema) that must be contained in the class "Doctrine\DBAL\Schema\Table" on an $schema possible property but this is not available. (recomended)






[DDC-3370] [GH-1173] Fix merging of entities with associations to identical entities. Created: 05/Nov/14  Updated: 11/Nov/14  Resolved: 11/Nov/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: cascade, merge, unitofwork


 Description   

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

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

Message:

Without this patch, when an entity that refers multiple times to the same
associated entity gets merged, the second references becomes null.

The main issue is that even though doMerge returns a managed copy, that value
is not used while cascading the merge. These identicial entities are already
detected through the visitor map, but they are ignored. There should be some
refactoring so cascadeMerge calls a function that checks if the parent must be
updated, based on the return value of its call to doMerge. However, this patch
tries to impact the code as little as possible, and only introduces a new
function to avoid duplicate code.

The secondary issue arises when using inverted associations. In that case, it
is possible that an entity to be merged is already merged, so the the visitor
map is looked up by the hash of a managed copy instead of the original entity.
This means that in this case the visitor map entries should also be set to the
entity, instead of being set to 'true'.



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

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

Comment by Doctrine Bot [ 11/Nov/14 ]

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





[DDC-2558] [GH-727] update helper set for entity manager Created: 18/Jul/13  Updated: 11/Nov/14  Resolved: 18/Jul/13

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

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


 Description   

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

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

Message:



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

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

Comment by Doctrine Bot [ 18/Jul/13 ]

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

Comment by Doctrine Bot [ 18/Jul/13 ]

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

Comment by Doctrine Bot [ 11/Nov/14 ]

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





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

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: array-cache, cache, configuration, production-settings


 Description   

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

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

Message:

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

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

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

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

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



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

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





[DDC-3383] [GH-1179] Fix embeddables class metadata (work-in-progress) Created: 10/Nov/14  Updated: 10/Nov/14

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

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


 Description   

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

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

Message:

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

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

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

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

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





[DDC-2554] [GH-724] Remove unnecessary comment Created: 16/Jul/13  Updated: 10/Nov/14  Resolved: 16/Jul/13

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

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


 Description   

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

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

Message:



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

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

Comment by Doctrine Bot [ 10/Nov/14 ]

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





[DDC-2287] Getter/Setter: generate "isEnabled()" instead of "getEnabled()" for boolean field in entity classes Created: 08/Feb/13  Updated: 10/Nov/14

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

Type: Improvement Priority: Minor
Reporter: Sukhrob Khakimov Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Reference
relates to DDC-2924 doctrine:generate:entities docblocks ... Resolved

 Description   

It would be better if doctrine generated "isEnabled()" instead of "getEnabled()" for boolean field in entity classes. Because, it is more meaningful.



 Comments   
Comment by Marco Pivetta [ 08/Feb/13 ]

Not sure this kind of check should be handled. Starting to add all this kind of rules makes me think that it is becoming a big ball of mud

Comment by Joshua thijssen [ 31/Oct/14 ]

I agree that it would be hard to figure out which prefix to use (isEnabled() or hasEnabled() are both valid, depending on context).

However, it might be easy enough to check for a is<fieldname> or has<fieldname> method already present inside the entity, (https://github.com/doctrine/doctrine2/blob/f12c311a795b69a5f4853b079b3f8ad2c9867181/lib/Doctrine/ORM/Tools/EntityGenerator.php#L1360). If present, we could skip creating the getter as well.

This allows to (manually) change the getEnabled() into an isEnabled(), and future generations will not add the getEnabled() anymore.

It also makes it easier to confirm to PMD's booleanGetMethodName rule (http://phpmd.org/rules/naming.html#booleangetmethodname)

Comment by Marco Pivetta [ 10/Nov/14 ]

Getting back to this, I don't think we should alter codegen based on DBAL types, as per previous discussions in DDC-2924.

We're trying to decouple code generation from that, while this sort of approach increases coupling.

I'm inclined to reject the proposal until we split out the code generator into its own component.





[DDC-2924] doctrine:generate:entities docblocks for custom DBAL Types Created: 17/Jan/14  Updated: 10/Nov/14  Resolved: 20/Jan/14

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

Type: Improvement Priority: Minor
Reporter: Bogdan Yurov Assignee: Marco Pivetta
Resolution: Can't Fix Votes: 0
Labels: None

Issue Links:
Reference
is referenced by DDC-2287 Getter/Setter: generate "isEnabled()"... Open

 Description   

When I create custom type, like "foo_type", when generating entities all typehints in class are populated as-is: "@return foo_type".

Is this expected behaviour? Could I set object class name for generating?



 Comments   
Comment by Marco Pivetta [ 20/Jan/14 ]

Bogdan Yurov currently, DBAL types don't provide any kind of information on the returned type if not via docblocks. We can't rely on that.

Comment by Bogdan Yurov [ 20/Jan/14 ]

Why this is "improvement"? doctrine:generate:entities works with custom types in a buggy way - this IS a bug.

Anyways, is there a workaround? Or, maybe, more info to read?

Thanks.

Comment by Marco Pivetta [ 20/Jan/14 ]

Bogdan Yurov yes, it is an expected behavior. It is not a bug since it is not causing any actual misbehavior of the consumer code, but just an improvement in the code generator for a case that is not handled and cannot be handled right now.

Comment by Bogdan Yurov [ 20/Jan/14 ]

"for a case that is not handled and cannot be handled right now."

Why custom types can not provide Model name? For example, a method returning class name of resulting object (or primitive)?

Comment by Marco Pivetta [ 20/Jan/14 ]

Bogdan Yurov afaik, the current docblocks are generated via `Type#getName()`, which returns an arbitrary string. Works in some cases, doesn't in others.

Comment by Bogdan Yurov [ 25/Jan/14 ]

Why this is "Can't Fix"? So there would never be a way to proper create custom DBAL type, so that generating would have worked?

Comment by Marco Pivetta [ 25/Jan/14 ]

Code generation is not a primary focus of Doctrine ORM, and introducing a new API around DBAL types just for this kind of edge case (consider that code that has been generated requires accurate review anyway) is out of discussion. Therefore, since the DBAL API for types won't be altered in 2.x, this is a "won't fix"

Comment by Bogdan Yurov [ 26/Jan/14 ]

But this is not about jsut "generating entities". We NEED extra information for much more purposes: hints in IDE plugins, automated DBAL testing (for custom types), different usecases concerning model name guessing, etc.

Don't you think it is strange that the only way to find out Model name of DBAL type is reviewing its transform-class?

Guys, solution is VERY simple - just add to \Doctrine\DBAL\Types\Type new method -> getModelName, which in abstract class just would call getName method (as now model name is guessed from getName), but in custom type one can override it with something like "\Foo\DBAL\MyType".

And in doctrine DBAL Platform:
public function getDoctrineTypeComment(Type $doctrineType)

{ return '(DC2Type:' . $doctrineType->getModelName() . ')'; }

Why this can not be done in Doctrine2?

Comment by Bogdan Yurov [ 26/Jan/14 ]

Ok, seems that this is not the only use of that method. But what can be done for now?

Comment by Marco Pivetta [ 26/Jan/14 ]

But this is not about jsut "generating entities". We NEED extra information for much more purposes: hints in IDE plugins, automated DBAL testing (for custom types), different usecases concerning model name guessing, etc.

Generated code is just boilerplate code to be later edited - testing and IDE hints are secondary and are part of this subsequent editing. Code generation is supposed to ONLY give you a kickstart when importing a legacy db ONCE.

Don't you think it is strange that the only way to find out Model name of DBAL type is reviewing its transform-class?

Not strange - you are actually simply supposed to replace (for example) all docblock hints with what you actually expect the API to look like. The code generator is far from a silver bullet, and is not meant to be one either.

Guys, solution is VERY simple - just add to \Doctrine\DBAL\Types\Type new method -> getModelName, which in abstract class just would call getName method (as now model name is guessed from getName), but in custom type one can override it with something like "\Foo\DBAL\MyType".

Yes, this can be done, though it brings no real advantage until there is actually another use case that could need it (serializers, for example, and so far, serializers shouldn't be coupled to doctrine types IMO, since types can be overridden). Additionally, a DBAL type is not forced to produce one particular type of instance (for example, could return an `integer`, a `null` or a `DateTime` depending on context).

Why this can not be done in Doctrine2?

It's not about "can't be done", it's simply that it needs a better use case that isn't just a code-generation "abuse-case".

Comment by Bogdan Yurov [ 27/Jan/14 ]

Is this final decision? For example, if I make pull request with appropriate changes - it would be rejected?

I still do not understand why this can not be done, as this changes nothing in logic and api.

Comment by Marco Pivetta [ 27/Jan/14 ]

It's not final. You can propose it in a PR, but it's very likely to be rejected without a stronger use case.

Comment by Bogdan Yurov [ 27/Jan/14 ]

Ok, thanks.





[DDC-2538] [GH-713] Quick grammar fix Created: 02/Jul/13  Updated: 10/Nov/14  Resolved: 02/Jul/13

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

Type: Improvement Priority: Trivial
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

Didn't create a JIRA ticket, as it's only a tiny change - hope that's OK.



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

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

Comment by Marco Pivetta [ 02/Jul/13 ]

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

Comment by Doctrine Bot [ 10/Nov/14 ]

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





[DDC-3373] [GH-1174] Fix associations with a custom type for identifiers Created: 06/Nov/14  Updated: 10/Nov/14  Resolved: 10/Nov/14

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

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

Issue Links:
Duplicate
duplicates DDC-3380 [GH-1178] Fixing associations using U... Open

 Description   

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

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

Message:

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

I've included several tests:

  • Loading a OneToOne association
  • Loading a OneToOne association with composite identifier
  • Loading a OneToOne association with composite identifier including a foreign one
  • Loading a OneToMany association
  • Loading a OneToMany association with composite identifier
  • Loading a OneToMany association with composite identifier including a foreign one
  • Loading a ManyToMany association
  • Loading a ManyToMany association with composite identifier
  • Loading a ManyToMany association with composite identifier including a foreign one

During the "ManyToMany association tests ...", I discovered the join-table wasn't populated properly. The columns were filled with the UUID string (in stead of the 16 bytes binary string). This has been addressed as well.

I've included these tests to verify that:

  • Removing entities from a ManyToMany association
  • Removing entities from a ManyToMany association with composite identifier
  • Removing entities from a ManyToMany association with composite identifier including a foreign one

When applying a fix for the "Loading a OneToMany association with composite identifier including a foreign one" test, the "Loading a OneToOne association with composite identifier including a foreign one" test started to produce an error.

This is due to the Proxy object containing a 16 bytes binary string (in stead of the UUID string) for the foreign identifier.

Also the "Removing entities from a ManyToMany association with composite identifier including a foreign one" tests keeps failing because there's a 16 bytes binary string (in stead of the UUID string) for the foreign identifier in the Collection.

I have a feeling these last 2 cases are not because of an issue in the Persisters, but because of an issue in the Hydrators. Unfortunately I don't know where to begin looking

I could really need some help finishing this up!



 Comments   
Comment by Jasper N. Brouwer [ 07/Nov/14 ]

PS: I've applied this fix to the 2.4 branch (in stead of master) on purpose, because I'm going to use this in a project and unfortunately can't wait until it's merged back into 2.4.

If this is a problem and must be done on master, I'll look into that.

Comment by Marco Pivetta [ 07/Nov/14 ]

Jasper N. Brouwer multiple versions may be affected: we just need to be sure that the bug wasn't already fixed in master (2.5), so please check that one as well.

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

Master is also affected. I think I've got some spare time this evening, so I'll port the PR to master.

Could you perhaps look at the remaining issue and maybe give some hint on where I should start looking? I would appreciate it if I could finish that up too this evening.

Comment by Doctrine Bot [ 09/Nov/14 ]

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

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

The PR has been ported to master:

http://www.doctrine-project.org/jira/browse/DDC-3380
https://github.com/doctrine/doctrine2/pull/1178

This ticket can be closed.

Comment by Doctrine Bot [ 10/Nov/14 ]

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





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

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

Type: Bug Priority: Major
Reporter: Pieter Vogelaar Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: connection, ddl, master-slave, schematool


 Description   

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

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

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

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


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

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





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

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

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

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

 Description   

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

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

Message:

This is a port of #1174.

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

_Remaining issue_

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

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

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

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



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

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

Comment by Doctrine Bot [ 09/Nov/14 ]

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

Comment by Doctrine Bot [ 10/Nov/14 ]

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

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

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





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

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

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


 Description   

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

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

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

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

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



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

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





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

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

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

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

 Description   

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

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

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

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

For instance if the query builder looks like this:

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

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

Here is the SQL that gets generated from the DQL:

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

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

The generated query should look like this:

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

This sql works as expected.

I hope i was clear enough what the problem is.



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

This is a duplicate of DDC-1256

Comment by Benjamin Eberlei [ 12/Nov/12 ]

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

Comment by gseric [ 29/May/13 ]

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

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

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

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

Comment by gseric [ 01/Jul/13 ]

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

Comment by Doctrine Bot [ 13/Aug/13 ]

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

Comment by Artur Eshenbrener [ 22/Dec/13 ]

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

Comment by Artur Eshenbrener [ 23/Dec/13 ]

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

Comment by Doctrine Bot [ 17/Feb/14 ]

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

Comment by Doctrine Bot [ 27/Oct/14 ]

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

Comment by Doctrine Bot [ 08/Nov/14 ]

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





[DDC-2507] [GH-698] Fix for [DDC-2506] CTI JOINs and WITH conditionals Created: 14/Jun/13  Updated: 08/Nov/14  Resolved: 24/Jun/13

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

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


 Description   

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

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

Message:

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

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

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



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

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

Comment by Doctrine Bot [ 13/Aug/13 ]

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

Comment by Doctrine Bot [ 20/Oct/14 ]

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

Comment by Doctrine Bot [ 27/Oct/14 ]

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

Comment by Doctrine Bot [ 08/Nov/14 ]

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





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

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

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


 Description   

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

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

Message:

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



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

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

Comment by Marco Pivetta [ 25/Aug/13 ]

DDC-2506

Comment by Doctrine Bot [ 27/Oct/14 ]

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

Comment by Doctrine Bot [ 08/Nov/14 ]

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





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

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

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

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

 Description   

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

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

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

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

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



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

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

Comment by Jordi Forns [ 18/Feb/13 ]

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

Comment by Michel Salib [ 22/Mar/13 ]

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

Comment by Yuta Konishi [ 01/Apr/13 ]

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

$qb = $em->createQueryBuilder();

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

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

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

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

Assigned to Alexander

Comment by Benjamin Eberlei [ 14/Apr/13 ]

Duplicate of DDC-1940

Comment by Jordi Forns [ 22/Apr/13 ]

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

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

Comment by Tom Arnfeld [ 27/Apr/13 ]

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

Comment by Tom Arnfeld [ 28/Apr/13 ]

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

Would love some feedback.

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

Comment by Jordi Forns [ 29/Apr/13 ]

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

Alexander: could you please give it a look?

Comment by Jordi Forns [ 23/May/13 ]

Tom's proposal seems to fix the issue.

Comment by Gordon Forsythe [ 11/Jun/13 ]

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

Comment by Gordon Forsythe [ 24/Jun/13 ]

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

Comment by Tom Arnfeld [ 24/Jun/13 ]

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

Comment by Doctrine Bot [ 13/Aug/13 ]

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

Comment by Benjamin Eberlei [ 13/Aug/13 ]

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

Comment by Doctrine Bot [ 16/Aug/13 ]

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

Comment by Marco Pivetta [ 16/Aug/13 ]

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

Comment by Benjamin Eberlei [ 20/Aug/13 ]

merged into 2.4

Comment by Doctrine Bot [ 09/Aug/14 ]

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

Comment by Doctrine Bot [ 27/Oct/14 ]

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

Comment by Doctrine Bot [ 08/Nov/14 ]

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





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

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

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


 Description   

The following JOIN

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

generates unexpected SQL

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

when it SHOULD be generating

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


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

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

Comment by gseric [ 01/Jul/13 ]

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

Comment by Gordon Forsythe [ 03/Jul/13 ]

I've tested this PR and it does work.

Comment by Doctrine Bot [ 13/Aug/13 ]

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

Comment by Doctrine Bot [ 17/Feb/14 ]

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

Comment by Doctrine Bot [ 27/Oct/14 ]

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

Comment by Doctrine Bot [ 08/Nov/14 ]

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





[DDC-2553] [GH-723] Remove extra semicolon before ->setParameter() calls Created: 15/Jul/13  Updated: 08/Nov/14  Resolved: 16/Jul/13

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

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


 Description   

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

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

Message:

Just noticed in the query builder documentation that there are a couple of extra semicolons before the calls to `->setParameter()`.



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

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

Comment by Doctrine Bot [ 08/Nov/14 ]

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





[DDC-1037] The EntityManager is closed when an exception is thrown in UoW's commit method Created: 16/Feb/11  Updated: 08/Nov/14  Resolved: 16/Feb/11

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

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

php 5.3.2, mysql, win7


Issue Links:
Duplicate
is duplicated by DDC-3363 "The EntityManager is closed." after ... Closed

 Description   

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

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



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

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

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

Comment by John Kleijn [ 28/Feb/11 ]

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

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

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

	$this->flush();

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

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

Comment by Benjamin Eberlei [ 28/Feb/11 ]

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

Comment by Ksaveras [ 25/Oct/14 ]

It's not resolved anyway.

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

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

Comment by Marco Pivetta [ 05/Nov/14 ]

The EntityManager is in an invalid state once a failure has occurred, and there's no way for us to repair that state.

A lot of things may have happened:

  • data could be invalid
  • connection to the DB could have been lost
  • data is corrupted
  • cache had corrupted values in it
  • etc.

The simplest and cleanest solution is to simply get a new instance of the EntityManager.

Comment by Ksaveras [ 08/Nov/14 ]

Make it throw Exception and if it is not handled by other code - then could be closed.
I want to catch exception and handle errors. Creating Entity Manager can not be done in one line, especially in other frameworks.

Imagine person gives invalid money in bank - then bank should be closed forever like You do now?

Comment by Marco Pivetta [ 08/Nov/14 ]

The bank would surely have to close the bank account and start researching what went wrong before re-opening communication with that client.





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

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

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


 Description   

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

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

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

Example 1: Simple case

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

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

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

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

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

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

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

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

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

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

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

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

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



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

I don't understand what attach would do in your case. flush is about flushing the whole unit of work. I don't understand what attach() would do if it does not attach the entity to the unit of work.

Comment by Christophe Coevoet [ 06/Nov/14 ]

And actually, the opposite of detach() already exists: it is persist(). It makes the object enter the unit of work, while detach makes it leave the unit of work.

Note that merge is not making the object cross the boundary. The object passed to merge() never enters the unit of work. what happens is that the data inside this object are applied to an object inside the boundary (potentially a new one if there was no object with this identifier).
When using merge, you are explicitly asking to apply the data inside the unit of work, so it is logical that something gets flushed.

and note that in your example 1, your person is managed half of the time (when coming from find() rather than a new instance). And in such case, it will be flushed. You are not flushing only the dog.

Comment by Mathieu De Zutter [ 08/Nov/14 ]

OK, makes sense.





[DDC-2552] [GH-722] Support for order by association (for 2.3 branch) Created: 15/Jul/13  Updated: 08/Nov/14  Resolved: 15/Jul/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.3
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: collection, orm
Environment:

Symfony 2.3



 Description   

This issue is created automatically through a Github pull request on behalf of naitsirch:

Url: https://github.com/doctrine/doctrine2/pull/722

Message:

I need to `@OrderBy` an association, which does not work in `2.3` but I found the pull request https://github.com/doctrine/doctrine2/pull/549 by @FabioBatSilva who has implemented this in branch `2.4`.

I have copied the code, adjusted it for `2.3` and tested it in a real life application

The original pull request is related to Doctrine Issue #2241(http://www.doctrine-project.org/jira/browse/DDC-2241).
The ordering of associations has been implemented in Doctrine Issue #195(http://www.doctrine-project.org/jira/browse/DDC-195).

Please integrate this into `2.3` because `2.4` is not stable until now and thus it is not usable for many people.



 Comments   
Comment by Doctrine Bot [ 15/Jul/13 ]

A related Github Pull-Request [GH-722] was closed:
https://github.com/doctrine/doctrine2/pull/722

Comment by Christian S. [ 15/Jul/13 ]

Can be closed (see https://github.com/doctrine/doctrine2/pull/722#issuecomment-20960237)

Comment by Doctrine Bot [ 08/Nov/14 ]

A related Github Pull-Request [GH-722] was assigned:
https://github.com/doctrine/dbal/pull/722

Comment by Doctrine Bot [ 08/Nov/14 ]

A related Github Pull-Request [GH-722] was closed:
https://github.com/doctrine/dbal/pull/722





[DDC-3361] Doctrine error while trying to execute a DQL query on PostgreSQL 9.2.x Created: 23/Oct/14  Updated: 08/Nov/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: DQL
Affects Version/s: 2.4.6
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Reynier Perez Mira Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: postgresql, typecast
Environment:

CentOS 6.5, PostgreSQL 9.2, Symfony 2.5.5, Doctrine 2.4.6



 Description   

I have this DQL on a repository class:

    public function filterNorm($codigo = null, $anno = null, $term = null, $comite_tecnico = null)
    {
        $qb = $this->getEntityManager()->createQueryBuilder();
        $qb
                ->select('n')
                ->from("AppBundle:Norma", "n");

        if ($codigo != NULL) {
            $qb->where(
                    $qb->expr()->like('n.numero', $qb->expr()->literal('%'.$codigo.'%'))
            );
        }

        if ($anno != NULL) {
            $qb->orWhere(
                    $qb->expr()->like('n.anno', $qb->expr()->literal('%'.(int) $anno.'%'))
            );
        }

        if ($term != NULL) {
            $qb->orWhere(
                    $qb->expr()->like('n.nombre', $qb->expr()->literal('%'.$term.'%'))
            );
        }

        if ($comite_tecnico != NULL) {
            $qb->orWhere(
                    $qb->expr()->like('n.comite_tecnico', $qb->expr()->literal('%'.(int) $comite_tecnico.'%'))
            );
        }

        return $qb->getQuery()->getResult();
    }

And when I try to execute it, leaving the first paramter null, I got this error:

An exception occurred while executing 'SELECT n0_.numero AS numero0, n0_.anno AS anno1, n0_.id AS id2, n0_.nombre AS nombre3, n0_.activo AS activo4, n0_.comite_tecnico_id AS comite_tecnico_id5 FROM nomencladores.norma n0_ WHERE n0_.anno LIKE '%34%' OR n0_.nombre LIKE '%sad%'':

SQLSTATE[42883]: Undefined function: 7 ERROR: operator does not exist: integer ~~ unknown
LINE 1: ...o_id5 FROM nomencladores.norma n0_ WHERE n0_.anno LIKE '%34%...
^
HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. 

I think in somewhere Doctrine is failing or not, not so sure, if not what will be the solution around this issue I'm having?



 Comments   
Comment by Marco Pivetta [ 23/Oct/14 ]

First of all: do not hardcode parameters in your DQL, as that represents a possible DQL injection vector.

Is your schema in sync with the ORM mappings? Postresql seems to complain about a missing operator between incompatible types.

Comment by Reynier Perez Mira [ 23/Oct/14 ]

What you mean with "do not hardcode parameters in your DQL"? How should I do this? And yes schema and ORM mappings are good:

Symfony > doctrine:schema:validate
[Mapping] OK - The mapping files are correct.
[Database] OK - The database schema is in sync with the mapping files.

Comment by Marco Pivetta [ 23/Oct/14 ]

What you mean with "do not hardcode parameters in your DQL"? How should I do this?

You wrote:

$qb->where($qb->expr()->like('n.numero', $qb->expr()->literal('%'.$codigo.'%')));

Should be:

$qb->where($qb->expr()->like('n.numero', ':codigo'));
$qb->setParameter('codigo', '%' . $codigo . '%');
Comment by Reynier Perez Mira [ 08/Nov/14 ]

Hi there @ocramius any advice around this issue? Any tip to get ride of this? I have similar queries all over the application I'm working on and still don't know how to deal with this, thanks

Comment by Marco Pivetta [ 08/Nov/14 ]

Seems to be a db-side type mismatch in a comparison, not a D2 bug.

Comment by Reynier Perez Mira [ 08/Nov/14 ]

@ocramius and how I should deal with this? Any idea?





[DDC-2549] [GH-721] Updated batch-processing link extension Created: 11/Jul/13  Updated: 07/Nov/14  Resolved: 11/Jul/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.5
Security Level: All

Type: Documentation Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of alex88:

Url: https://github.com/doctrine/doctrine2/pull/721

Message:

I've changed the batch processing link adding .html else the link is broken



 Comments   
Comment by Doctrine Bot [ 11/Jul/13 ]

A related Github Pull-Request [GH-721] was closed:
https://github.com/doctrine/doctrine2/pull/721

Comment by Marco Pivetta [ 11/Jul/13 ]

Merged: https://github.com/doctrine/doctrine2/commit/0aed9595c3ceec81dcf44a4eefc24bb49051868e

Comment by Doctrine Bot [ 07/Nov/14 ]

A related Github Pull-Request [GH-721] was closed:
https://github.com/doctrine/dbal/pull/721





[DDC-3376] Only one row is returned Created: 06/Nov/14  Updated: 07/Nov/14

Status: Reopened
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4.6
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Patryyyck Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: inheritance, lazy-loading, n+1-queries, sti
Environment:

Linux Mint 17
PHP 5.5.9
Apache 2.4.7
Symfony 2.4.10
Doctrine ORM 2.4.6
Doctrine DBAL 2.4.3
Sql Server database



 Description   

Hi,

I don't know if you are the appropriate person.
I have an issue with Doctrine ORM or DBAL.
By the way, i'm not sure the issue is in one of these bundles.

I'm trying to get all the rows of on an entity A which is a SINGLE_TABLE with 3 discriminators.
This entity has a property "parent" which is a self referencing property (ManyToOne on entity A).

The getResult of my query only return the first row of my table.
When i replace getResult by getArrayResult, i have all my table.
But i want the objects

After hours of debugging, i saw that the Doctrine ORM ObjectHydrator.php loops on the result of my query (which have the good number of results):

while ($row = $this->_stmt->fetch(PDO::FETCH_ASSOC)) {
    $this->hydrateRowData($row, $cache, $result);
}

But, the hydrateRowData executes another query to get the parent of each row (Doctrine DBAL Connection.php function executeQuery).
This function prepares a query to get the parent with a param (parent id) and i think the prepare function return the same statement (stmt) as the first query (the list of all the entity A).
So, the prepared query is executed but when the Doctrine ORM ObjectHydrator.php want to fetch the second row, he considers that there's no more rows to fetch and return the first rows.

I don't know if i am clear enough. Tell me if you want more details.

Oh. I forgot. If i try the same request with the same datas but in a mySQL database (pdo_mysql), i have a good result. I don't know if that helps.

Thanks

Regards



 Comments   
Comment by Marco Pivetta [ 07/Nov/14 ]

The issue you described is very well known and it is a limitation of the ORM. What happens is following:

1. you have an inheritance A -> B | C | D (A being the root of the inheritance)
2. A has a self-referencing association to A (typically like a hierarchy of parent-child)
3. the ORM tries to load an A instance that has a reference to a parent of type A. In order to do so, the ORM has to resolve the actual type of the referenced parent, and therefore cannot lazily load it via a proxy (a query has to be executed in order to find out the value of the discriminator column)

This means that for performance reasons you should NEVER reference the root of an inheritance, but only leafs (where the ORM does not need to do this sort of resolution).

See also http://doctrine-orm.readthedocs.org/en/latest/reference/inheritance-mapping.html#id4 (Performance impact of inheritance mapping) for more details.

Comment by Patryyyck [ 07/Nov/14 ]

Thanks Marco for your quick answer.

I understand the ORM limitation.
But i still don't understand why this limitation doesn't exist when i use a MySQL database.





[DDC-3378] [GH-1176] Add test exposing UnitOfWork merge bug Created: 07/Nov/14  Updated: 07/Nov/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of adrienbrault:

Url: https://github.com/doctrine/doctrine2/pull/1176

Message:

I hope that I'm doing something wrong and that this is not a bug ...






[DDC-3372] PersistentCollection clear function takes snapshot when the collection is cleared Created: 06/Nov/14  Updated: 07/Nov/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4.6
Fix Version/s: None
Security Level: All

Type: Bug Priority: Minor
Reporter: Ward Peeters Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: collection, orm
Environment:

Symfony 2.5.6



 Description   

I'm not sure if it's a bug or you guys have a reason why you do it. The problem occurs when you do a $coll->clear() he will clear the collection and whenever it's cleared the takeSnapshot is ran as well so our snapshot is empty so we lose the prevous state of the collection.

public function clear()
    {
        if ($this->initialized && $this->isEmpty()) {
            return;
        }

        $uow = $this->em->getUnitOfWork();

        if ($this->association['type'] & ClassMetadata::TO_MANY &&
            $this->association['orphanRemoval'] &&
            $this->owner) {
            // we need to initialize here, as orphan removal acts like implicit cascadeRemove,
            // hence for event listeners we need the objects in memory.
            $this->initialize();

            foreach ($this->coll as $element) {
                $uow->scheduleOrphanRemoval($element);
            }
        }

        $this->coll->clear();

        $this->initialized = true; // direct call, {@link initialize()} is too expensive

        if ($this->association['isOwningSide'] && $this->owner) {
            $this->changed();

            $uow->scheduleCollectionDeletion($this);

            $this->takeSnapshot();
        }
    }


 Comments   
Comment by Marco Pivetta [ 07/Nov/14 ]

Can you please abstract your problem into a test case?

Comment by Ward Peeters [ 07/Nov/14 ]

if that helps yes. The problem is that i'm not sure it's a bug. It might be the way you guys wanted it to be.
I'll create a test case might be better to understand.

Comment by Marco Pivetta [ 07/Nov/14 ]

It looks like a bug to me: the snapshot should be taken only when no snapshot was there upfront, as far as I know.





[DDC-3377] DateTime columns cannot be used with @Id Created: 06/Nov/14  Updated: 07/Nov/14  Resolved: 07/Nov/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Chris Verges Assignee: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: None
Environment:

PHP 5.4.33
Symfony 2.5.6
Doctrine 2.4.x-dev


Issue Links:
Duplicate
duplicates DDC-2768 Doctrine could not work with date as ... Resolved
duplicates DDC-1471 Unable to read mySQL "DATE" field fro... Resolved
duplicates DDC-2487 UnitOfWork::getEntityIdentifier() con... Resolved
duplicates DDC-1780 Function createEntity does't support ... Closed

 Description   

DateTimeIdTest.php:

use Doctrine\ORM\Mapping as ORM;

/**
 * @ORM\Table(name="datetime_id_test")
 * @ORM\Entity
 */
class DateTimeIdTest
{
    /**
     * @ORM\Column(name="when", type="datetime")
     * @ORM\Id
     */
    public $when;

    public function __construct()
    {
        $this->when = new \DateTime();
    }
}

test.php:

require_once('DateTimeIdTest.php');

$entity = new DateTimeIdTest();
$entityManager->persist($entity);

Output:

Object of class DateTime could not be converted to string

/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1359
/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1172
/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:864
/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1635
/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1591
/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php:624
/app/cache/test/jms_diextra/doctrine/EntityManager_545bc3b10fd93.php:94
test.php:4

I was able to debug this down to where the implode() call in Doctrine\ORM\UnitOfWork::addToIdentityMap() is what is triggering this problem. It attempts to convert all contained entities in the Doctrine\ORM\UnitOfWork::entityIdentifiers array to strings. For a DateTime object, the DateTime::format() function should be used instead of relying on __toString().



 Comments   
Comment by Chris Verges [ 06/Nov/14 ]

There is a portable workaround where you create a string-based shadow key that gets updated by Doctrine events:

DateTimeIdTest.php:

use Doctrine\ORM\Mapping as ORM;
use Doctrine\ORM\Events as Events;

/**
 * @ORM\Table(name="datetime_id_test")
 * @ORM\Entity
 * @ORM\HasLifecycleCallbacks
 */
class DateTimeIdTest
{
    public $when;

    /**
     * @ORM\Column(name="when", type="string")
     * @ORM\Id
     */
    public $whenKey;

    public function __construct()
    {
        $this->when = new \DateTime();
    }

    /**
     * @Events\PrePersist
     * @Events\PreUpdate
     */
    public function syncWhenToWhenKey(LifecycleEventArgs $event)
    {
        $entityManager = $event->getEntityManager();
        $connection = $entityManager->getConnection();
        $platform = $connection->getDatabasePlatform();

        $this->whenKey = $when->format($platform->getDateTimeFormatString());
    }

    /**
     * @Events\PostLoad
     */
    public function syncWhenKeyToWhen(LifecycleEventArgs $event)
    {
        $entityManager = $event->getEntityManager();
        $connection = $entityManager->getConnection();
        $platform = $connection->getDatabasePlatform();

        $this->when = \DateTime::createFromFormat($platform->getDateTimeFormatString(), $this->whenKey);
    }
}




[DDC-2768] Doctrine could not work with date as primary key Created: 30/Oct/13  Updated: 07/Nov/14  Resolved: 14/Dec/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Critical
Reporter: Nikita Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None

Issue Links:
Duplicate
is duplicated by DDC-2912 Date column could not be PK Resolved
is duplicated by DDC-3377 DateTime columns cannot be used with @Id Resolved

 Description   

Part of my mapping:

 
id:
    statDate:
        type: date
    phrase:
        type: string
    bannerId:
        type: integer

So I've got an exception:

Object of class DateTime could not be converted to string in /Users/hell0w0rd/dev/rsol/direct/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php line 13
45



 Comments   
Comment by Marco Pivetta [ 14/Dec/13 ]

DateTime instances must implement `__toString` in order to be used as identifiers. That is a known limitation.

See http://stackoverflow.com/questions/15080573/doctrine-2-orm-datetime-field-in-identifier/15085566#comment21225419_15085566





[DDC-1471] Unable to read mySQL "DATE" field from mysql db Created: 05/Nov/11  Updated: 07/Nov/14  Resolved: 19/Nov/11

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.1.2
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Andreas Herz Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None
Environment:

OSX
mySQL 5.1.45


Issue Links:
Duplicate
is duplicated by DDC-3377 DateTime columns cannot be used with @Id Resolved

 Description   

Unable to retrieve an object with an "DATE" SQL type via the ORM mapper.
I retrieve als a convert exception like :Object of class DateTime could not be converted to string.

I add my SQL Tabel and the mapped class to the bug.

========================
CREATE TABLE SQL
========================

 
CREATE TABLE `suggestions_votes` (
  `suggestion_id` int(10) unsigned NOT NULL DEFAULT '0',
  `ip` int(10) unsigned NOT NULL DEFAULT '0',
  `day` date NOT NULL DEFAULT '0000-00-00',
  `vote` tinyint(1) NOT NULL DEFAULT '0',
  `dt` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`suggestion_id`,`ip`,`day`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

========================
Mapped PHP Class
========================

 
<?php
/**
* @Entity @HasLifecycleCallbacks
* @Table(name="suggestions_votes")
*/
class Model_votes_4eb50755dfdfe  {
 
   /**
    * @Id
    * @Column(name="`suggestion_id`", type="integer", nullable=false)
    */
    public $suggestion_id;

   /**
    * @Id
    * @Column(name="`ip`", type="integer", nullable=false)
    */
    public $ip;

   /**
    * @Id
    * @Column(name="`day`", type="date", nullable=false)
    */
    public $day;

   /**
    * @Column(name="`vote`", type="boolean", nullable=false)
    */
    public $vote;

   /**
    * @Column(name="`dt`", type="datetime", nullable=false)
    */
    public $dt;

    public function getIdFieldName(){ return 'day';}

    public function getRepresentativeFieldName(){ return 'day';}

    public function getTableName(){ return 'suggestions_votes';}

} //end class

?>

==================================================
Generated Error
==================================================
<p>Severity: 4096</p>
<p>Message: Object of class DateTime could not be converted to string</p>
<p>Filename: ORM/UnitOfWork.php</p>
<p>Line Number: 1900</p>

==================================================
Code of error message
==================================================

 
public function createEntity($className, array $data, &$hints = array())
    {
        $class = $this->em->getClassMetadata($className);
        //$isReadOnly = isset($hints[Query::HINT_READ_ONLY]);
        if ($class->isIdentifierComposite) {
            $id = array();
            foreach ($class->identifier as $fieldName) {
                if (isset($class->associationMappings[$fieldName])) {
                    $id[$fieldName] = $data[$class->associationMappings[$fieldName]['joinColumns'][0]['name']];
                } else {
                    $id[$fieldName] = $data[$fieldName];
                }
            }
            $idHash = implode(' ', $id);   <<<<<<<===== Produce the Error
        } else {
            if (isset($class->associationMappings[$class->identifier[0]])) {
                $idHash = $data[$class->associationMappings[$class->identifier[0]]['joinColumns'][0]['name']];
            } else {
                $idHash = $data[$class->identifier[0]];
            }
            $id = array($class->identifier[0] => $idHash);
        }


 Comments   
Comment by Andreas Herz [ 05/Nov/11 ]

I add some TRACE message to the code for more information

===============================================
Commented Code
===============================================

 
    public function createEntity($className, array $data, &$hints = array())
    {
        $class = $this->em->getClassMetadata($className);
        //$isReadOnly = isset($hints[Query::HINT_READ_ONLY]);
        if ($class->isIdentifierComposite) {
            $id = array();
            var_dump($class);
            foreach ($class->identifier as $fieldName) {
                echo $fieldName; 
                var_dump( $data[$fieldName]);
                echo "\n";
                if (isset($class->associationMappings[$fieldName])) {
                    echo "Try to convert with mapper....\n";
                    $id[$fieldName] = $data[$class->associationMappings[$fieldName]['joinColumns'][0]['name']];
                } else {
                    echo "no mapper found\n";
                    $id[$fieldName] = $data[$fieldName];
                }
            }
            $idHash = implode(' ', $id);
        } else {
            if (isset($class->associationMappings[$class->identifier[0]])) {
                $idHash = $data[$class->associationMappings[$class->identifier[0]]['joinColumns'][0]['name']];
            } else {
                $idHash = $data[$class->identifier[0]];
            }
            $id = array($class->identifier[0] => $idHash);
        }

===============================================
DUMP OUTPUT
===============================================

 
object(Doctrine\ORM\Mapping\ClassMetadata)#51 (32) {
  ["reflFields"]=>
  array(5) {
    ["suggestion_id"]=>
    object(ReflectionProperty)#61 (2) {
      ["name"]=>
      string(13) "suggestion_id"
      ["class"]=>
      string(27) "Model_ppppppp_4eb53138782ae"
    }
    ["ip"]=>
    object(ReflectionProperty)#62 (2) {
      ["name"]=>
      string(2) "ip"
      ["class"]=>
      string(27) "Model_ppppppp_4eb53138782ae"
    }
    ["day"]=>
    object(ReflectionProperty)#65 (2) {
      ["name"]=>
      string(3) "day"
      ["class"]=>
      string(27) "Model_ppppppp_4eb53138782ae"
    }
    ["vote"]=>
    object(ReflectionProperty)#68 (2) {
      ["name"]=>
      string(4) "vote"
      ["class"]=>
      string(27) "Model_ppppppp_4eb53138782ae"
    }
    ["dt"]=>
    object(ReflectionProperty)#71 (2) {
      ["name"]=>
      string(2) "dt"
      ["class"]=>
      string(27) "Model_ppppppp_4eb53138782ae"
    }
  }
  ["_prototype":"Doctrine\ORM\Mapping\ClassMetadata":private]=>
  NULL
  ["name"]=>
  string(27) "Model_ppppppp_4eb53138782ae"
  ["namespace"]=>
  string(0) ""
  ["rootEntityName"]=>
  string(27) "Model_ppppppp_4eb53138782ae"
  ["customRepositoryClassName"]=>
  NULL
  ["isMappedSuperclass"]=>
  bool(false)
  ["parentClasses"]=>
  array(0) {
  }
  ["subClasses"]=>
  array(0) {
  }
  ["namedQueries"]=>
  array(0) {
  }
  ["identifier"]=>
  array(3) {
    [0]=>
    string(13) "suggestion_id"
    [1]=>
    string(2) "ip"
    [2]=>
    string(3) "day"
  }
  ["inheritanceType"]=>
  int(1)
  ["generatorType"]=>
  int(5)
  ["fieldMappings"]=>
  array(5) {
    ["suggestion_id"]=>
    array(10) {
      ["fieldName"]=>
      string(13) "suggestion_id"
      ["type"]=>
      string(7) "integer"
      ["length"]=>
      NULL
      ["precision"]=>
      int(0)
      ["scale"]=>
      int(0)
      ["nullable"]=>
      bool(false)
      ["unique"]=>
      bool(false)
      ["columnName"]=>
      string(13) "suggestion_id"
      ["id"]=>
      bool(true)
      ["quoted"]=>
      bool(true)
    }
    ["ip"]=>
    array(10) {
      ["fieldName"]=>
      string(2) "ip"
      ["type"]=>
      string(7) "integer"
      ["length"]=>
      NULL
      ["precision"]=>
      int(0)
      ["scale"]=>
      int(0)
      ["nullable"]=>
      bool(false)
      ["unique"]=>
      bool(false)
      ["columnName"]=>
      string(2) "ip"
      ["id"]=>
      bool(true)
      ["quoted"]=>
      bool(true)
    }
    ["day"]=>
    array(10) {
      ["fieldName"]=>
      string(3) "day"
      ["type"]=>
      string(4) "date"
      ["length"]=>
      NULL
      ["precision"]=>
      int(0)
      ["scale"]=>
      int(0)
      ["nullable"]=>
      bool(false)
      ["unique"]=>
      bool(false)
      ["columnName"]=>
      string(3) "day"
      ["id"]=>
      bool(true)
      ["quoted"]=>
      bool(true)
    }
    ["vote"]=>
    array(9) {
      ["fieldName"]=>
      string(4) "vote"
      ["type"]=>
      string(7) "boolean"
      ["length"]=>
      NULL
      ["precision"]=>
      int(0)
      ["scale"]=>
      int(0)
      ["nullable"]=>
      bool(false)
      ["unique"]=>
      bool(false)
      ["columnName"]=>
      string(4) "vote"
      ["quoted"]=>
      bool(true)
    }
    ["dt"]=>
    array(9) {
      ["fieldName"]=>
      string(2) "dt"
      ["type"]=>
      string(8) "datetime"
      ["length"]=>
      NULL
      ["precision"]=>
      int(0)
      ["scale"]=>
      int(0)
      ["nullable"]=>
      bool(false)
      ["unique"]=>
      bool(false)
      ["columnName"]=>
      string(2) "dt"
      ["quoted"]=>
      bool(true)
    }
  }
  ["fieldNames"]=>
  array(5) {
    ["suggestion_id"]=>
    string(13) "suggestion_id"
    ["ip"]=>
    string(2) "ip"
    ["day"]=>
    string(3) "day"
    ["vote"]=>
    string(4) "vote"
    ["dt"]=>
    string(2) "dt"
  }
  ["columnNames"]=>
  array(5) {
    ["suggestion_id"]=>
    string(13) "suggestion_id"
    ["ip"]=>
    string(2) "ip"
    ["day"]=>
    string(3) "day"
    ["vote"]=>
    string(4) "vote"
    ["dt"]=>
    string(2) "dt"
  }
  ["discriminatorValue"]=>
  NULL
  ["discriminatorMap"]=>
  array(0) {
  }
  ["discriminatorColumn"]=>
  NULL
  ["table"]=>
  array(1) {
    ["name"]=>
    string(17) "suggestions_votes"
  }
  ["lifecycleCallbacks"]=>
  array(0) {
  }
  ["associationMappings"]=>
  array(0) {
  }
  ["isIdentifierComposite"]=>
  bool(true)
  ["containsForeignIdentifier"]=>
  bool(false)
  ["idGenerator"]=>
  object(Doctrine\ORM\Id\AssignedGenerator)#57 (0) {
  }
  ["sequenceGeneratorDefinition"]=>
  NULL
  ["tableGeneratorDefinition"]=>
  NULL
  ["changeTrackingPolicy"]=>
  int(1)
  ["isVersioned"]=>
  NULL
  ["versionField"]=>
  NULL
  ["reflClass"]=>
  object(ReflectionClass)#52 (1) {
    ["name"]=>
    string(27) "Model_ppppppp_4eb53138782ae"
  }
  ["isReadOnly"]=>
  bool(false)
}
suggestion_idint(0)

no mapper found
ipint(0)

no mapper found
dayobject(DateTime)#59 (3) {
  ["date"]=>
  string(20) "-0001-11-30 00:00:00"
  ["timezone_type"]=>
  int(3)
  ["timezone"]=>
  string(13) "Europe/Dublin"
}

no mapper found
<div style="border:1px solid #990000;padding-left:20px;margin:0 0 10px 0;">

<h4>A PHP Error was encountered</h4>

<p>Severity: 4096</p>
<p>Message: Object of class DateTime could not be converted to string</p>
<p>Filename: ORM/UnitOfWork.php</p>
<p>Line Number: 1905</p>

Comment by Andreas Herz [ 05/Nov/11 ]

After some codereading and debugging I think it is the problem that a "DATE" field is part
of the PKEY?

Is this possible?

Comment by Benjamin Eberlei [ 19/Nov/11 ]

Yes this is the reason.

2 workaround solutions:

1. Use a "string" instead
2. Add your own custom datetime type with a "MyDateTime extends DateTime" which implements __toString() and call new MyDateTime("...");

Comment by Andreas Palm [ 31/Jan/12 ]

Should be fixed with pull request #275





[DDC-1780] Function createEntity does't support DateTime identifier Created: 16/Apr/12  Updated: 07/Nov/14  Resolved: 07/Jul/12

Status: Closed
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: Git Master
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Tereshchenko Maxim Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 0
Labels: None

Issue Links:
Duplicate
is duplicated by DDC-3377 DateTime columns cannot be used with @Id Resolved

 Description   

When I try to get data (as objects, function getResult()) from a table with two indexes (1.Integer, 2.DateTime), Doctrine returns duplicate objects to the first index.
This bug is present only in the function getResult(), getArrayResult work correctly.
The bug is in file UnitOfWork.php, line 2323-2329.

$idHash = implode(' ', $id);

This code does not take into account that identifer may be DateTime object.



 Comments   
Comment by Alexander [ 07/Jul/12 ]

Doctrine doesn't support DateTime objects as identifiers because the objects don't implement __toString().





[DDC-2487] UnitOfWork::getEntityIdentifier() contains objects when custom mapping types are part of an entity's identity Created: 04/Jun/13  Updated: 07/Nov/14  Resolved: 22/Dec/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.3.4
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Benjamin Morel Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: identity

Issue Links:
Duplicate
is duplicated by DDC-3377 DateTime columns cannot be used with @Id Resolved

 Description   

I'm using a custom mapping type for a LocalDate class (mapped to a DATE field in the MySQL database).

Given the following entity:

/**
 * @Entity
 */
class Timeslot
{
    /**
     * @Id
     * @ManyToOne(targetEntity="Restaurant")
     */
    protected $restaurant;

    /**
     * @Id
     * @Column(type="localdate")
     */
    protected $date;
}

When var_export() -ing the result of UnitOfWork::getEntityIdentifier() on an instance of this class, the result is similar to:

array(
	'restaurant' => '5',
	'date' => LocalDate::__set_state(array('year' => 2013, 'month' => 6, 'day' => 26))
)

This is a bit weird, because as far as I understand it, it should return the identity as it maps to database fields:

array(
	'restaurant' => '5',
	'date' => '2013-06-26'
)

If we take the $restaurant example, it returns the restaurant ID, and not the Restaurant entity, so my opinion is that it should be the same for $date.

Shouldn't the UnitOfWork use Type::convertToDatabaseValue() on custom mapping types to infer their value, when computing the identity of an entity?



 Comments   
Comment by Marco Pivetta [ 04/Jun/13 ]

Benjamin Morel why would getEntityIdentifier convert types? The UoW doesn't worry about the DBAL representation of the objects - actually, the UoW doesn't know of the DBAL at all.

Comment by Benjamin Morel [ 04/Jun/13 ]

Your point is valid, but that's still annoying. Why would getEntityIdentifier() return objects?
By the way, UnitOfWork is aware of EntityManager, and thus the Connection, and thus the Platform!
It does use the Connection in commit().

Comment by Marco Pivetta [ 04/Jun/13 ]

Benjamin Morel that is because that is the identifier in your object. It's composed by the identifier of an associated entity and a datetime object (scalar)

Comment by Benjamin Morel [ 04/Jun/13 ]

Marco Pivetta Then why does it return the restaurant ID, and not the Restaurant object?

Comment by Benjamin Eberlei [ 22/Dec/13 ]

This is not a bug, it is just how it works, the docblock says nothing about how the fields have to look. The UnitOfWork API is mostly serving itself and optimized for that.





[DDC-3374] [GH-1175] removed "comments-as-vcs"-styled-comment Created: 06/Nov/14  Updated: 07/Nov/14  Resolved: 07/Nov/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4.6
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: entitymanager, final


 Description   

This issue is created automatically through a Github pull request on behalf of leberknecht:

Url: https://github.com/doctrine/doctrine2/pull/1175

Message:



 Comments   
Comment by Doctrine Bot [ 07/Nov/14 ]

A related Github Pull-Request [GH-1175] was closed:
https://github.com/doctrine/doctrine2/pull/1175

Comment by Doctrine Bot [ 07/Nov/14 ]

A related Github Pull-Request [GH-1175] was assigned:
https://github.com/doctrine/doctrine2/pull/1175





[DDC-3358] [GH-1166] Fixing HHVM+XSD validation tests as of documented HHVM inconsistencies Created: 20/Oct/14  Updated: 07/Nov/14  Resolved: 07/Nov/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Tools
Affects Version/s: 2.5
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: ci, hhvm, travis, xml


 Description   

This issue is created automatically through a Github pull request on behalf of Ocramius:

Url: https://github.com/doctrine/doctrine2/pull/1166

Message:

See https://github.com/facebook/hhvm/blob/3445a26e54faba5828eb6b8f6e74e52b472cf282/hphp/doc/inconsistencies#L131-L134 as a reference



 Comments   
Comment by Doctrine Bot [ 20/Oct/14 ]

A related Github Pull-Request [GH-1166] was assigned:
https://github.com/doctrine/doctrine2/pull/1166





[DDC-2548] [GH-720] Allow to have non-distinct queries Created: 09/Jul/13  Updated: 07/Nov/14  Resolved: 06/Aug/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4, 2.3.5
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of bakura10:

Url: https://github.com/doctrine/doctrine2/pull/720

Message:

The getHint method would return false if no hint was set for the given name. Therefore even if you set the CountWalker::HINT_DISTINCT to false, it would have been ignored and set to true by the paginator.



 Comments   
Comment by Doctrine Bot [ 06/Aug/13 ]

A related Github Pull-Request [GH-720] was closed:
https://github.com/doctrine/doctrine2/pull/720

Comment by Marco Pivetta [ 06/Aug/13 ]

Merged: https://github.com/doctrine/doctrine2/commit/354d7050dc83cab7315c95c3511f5cf8c2b567c5

Comment by Doctrine Bot [ 07/Nov/14 ]

A related Github Pull-Request [GH-720] was assigned:
https://github.com/doctrine/dbal/pull/720





[DDC-3371] MultiTableUpdateExecutor does not handle input parameters correctly within arithmetic expression assignments to updated fields Created: 05/Nov/14  Updated: 05/Nov/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: DQL, ORM
Affects Version/s: Git Master
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Michael Plomer Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

An update statement like

UPDATE MyEntity e SET e.value1 = e.value1 + :inParam1 WHERE e.value2 = :inParam2

will fail if MyEntity is part of a join table inheritance hierarchy and hence the update is handled by the MultiTableUpdateExecutor. The insert statement for the temporary ID table causes the following PDOException:

SQLSTATE[HY093]: Invalid parameter number: number of bound variables does not match number of tokens

The problem is in counting the number of input parameters in the update part of the statement. Lines 127-131 of the MultiTableUpdateExecutor:

if ($newValue instanceof AST\InputParameter) {
    $this->_sqlParameters[$i][] = $newValue->name;
    ++$this->_numParametersInUpdateClause;
}

fall short in detecting input parameters unless they are directly assigned as new values.






[DDC-3363] "The EntityManager is closed." after insert error. Created: 25/Oct/14  Updated: 05/Nov/14  Resolved: 05/Nov/14

Status: Closed
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4.6
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Ksaveras Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates DDC-1037 The EntityManager is closed when an e... Resolved

 Description   
               try {
                    $em = $this->getContainer()->get('doctrine')->getManager();
                    $em->persist($article);
                    $em->flush();
                } catch (\Exception $e) {
                    $output->writeln($e->getMessage());
                }

If flush will generate error - all other flush operations will end with error: "The EntityManager is closed.".

Internet says that recreating EM is almost imposible without using own EM management code.

WHY i have to code EM management code to use EM? It's Doctrine's task to manage EM.

I just want to use try catch and process errors - Closing and opening connections it's Doctrine's task.

This task (reopen connection) should be done by Doctrine.






[DDC-2544] [GH-717] Allow query parameters starting with an underscore Created: 04/Jul/13  Updated: 05/Nov/14  Resolved: 30/Jul/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.5
Security Level: All

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of hackedd:

Url: https://github.com/doctrine/doctrine2/pull/717

Message:

Using a query parameter of which the name starts with an underscore results in a QueryException. For example:

``` php
$q = $em->createQueryBuilder()
->select("u")
->from("User", "u")
->where("u.username = :_name")
->setParameter("_name", "bar")
->getQuery();
```

Results in:

Invalid parameter format, : given, but :<name> or ?<num> expected.

This happens because of a bug in the Lexer, which recognizes `:_name` as two tokens (the `:` as the start of a input parameter, `_name` as an identifier). The attached patch changes the regular expression for input parameters to allow identifiers starting with a letter or underscore.



 Comments   
Comment by Doctrine Bot [ 29/Jul/13 ]

A related Github Pull-Request [GH-717] was closed:
https://github.com/doctrine/doctrine2/pull/717

Comment by Fabio B. Silva [ 30/Jul/13 ]

Merged : https://github.com/doctrine/doctrine2/commit/a53fe14fa254618bc9a67296f845ec4923a13606

Comment by Doctrine Bot [ 05/Nov/14 ]

A related Github Pull-Request [GH-717] was assigned:
https://github.com/doctrine/dbal/pull/717

Comment by Doctrine Bot [ 05/Nov/14 ]

A related Github Pull-Request [GH-717] was closed:
https://github.com/doctrine/dbal/pull/717





[DDC-2535] [GH-712] Extra lazy get for inverse side of many-to-many Created: 01/Jul/13  Updated: 05/Nov/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of sandermarechal:

Url: https://github.com/doctrine/doctrine2/pull/712

Message:

This is the cange requested by @stof and @beberlei in PR #710. It implements an extra lazy get on the working side of the relationship. As mentioned in #710 the unit tests fails for reasons I don't quite understand. The error I get is:

```
1) Doctrine\Tests\ORM\Functional\ExtraLazyCollectionTest::testGetIndexByManyToMany
Exception: [PHPUnit_Framework_Error_Notice] Undefined index: joinColumns

Trace:
/home/sander/src/doctrine2/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php:1665
/home/sander/src/doctrine2/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php:1610
/home/sander/src/doctrine2/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php:1701
/home/sander/src/doctrine2/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php:1115
/home/sander/src/doctrine2/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php:746
/home/sander/src/doctrine2/lib/Doctrine/ORM/Persisters/ManyToManyPersister.php:55
/home/sander/src/doctrine2/lib/Doctrine/ORM/PersistentCollection.php:529
/home/sander/src/doctrine2/tests/Doctrine/Tests/ORM/Functional/ExtraLazyCollectionTest.php:578
```

If someone with a little more understanding of the Doctrine internals can help me fix this, then we could restore some of the functionality that PR #710 had to remove.



 Comments   
Comment by Doctrine Bot [ 05/Nov/14 ]

A related Github Pull-Request [GH-712] was assigned:
https://github.com/doctrine/dbal/pull/712





[DDC-2529] [GH-709] add getManager Created: 25/Jun/13  Updated: 05/Nov/14  Resolved: 25/Jun/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of tvlooy:

Url: https://github.com/doctrine/doctrine2/pull/709

Message:

getEntityManager is deprecated in Symfony2 (and gone in 2.3). It would be nice if Doctrine followed this (or at least added the getManager call) ot make it consistent. https://github.com/sensiolabs/SensioGeneratorBundle/pull/123



 Comments   
Comment by Doctrine Bot [ 25/Jun/13 ]

A related Github Pull-Request [GH-709] was closed:
https://github.com/doctrine/doctrine2/pull/709

Comment by Doctrine Bot [ 05/Nov/14 ]

A related Github Pull-Request [GH-709] was assigned:
https://github.com/doctrine/dbal/pull/709

Comment by Doctrine Bot [ 05/Nov/14 ]

A related Github Pull-Request [GH-709] was closed:
https://github.com/doctrine/dbal/pull/709





[DDC-2540] [GH-714] Cache results for extra lazy get Created: 03/Jul/13  Updated: 05/Nov/14  Resolved: 03/Jan/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of sandermarechal:

Url: https://github.com/doctrine/doctrine2/pull/714

Message:

Repeated getting of the same key on an extra lazy collection
should only issue a query for the first get, not for any
subsequent gets.



 Comments   
Comment by Sander Marechal [ 03/Jul/13 ]

It would be great if this can be included into 2.4 along with the extra lazy get from #DDC-1398

Comment by Doctrine Bot [ 03/Jan/14 ]

A related Github Pull-Request [GH-714] was closed:
https://github.com/doctrine/doctrine2/pull/714

Comment by Doctrine Bot [ 05/Nov/14 ]

A related Github Pull-Request [GH-714] was assigned:
https://github.com/doctrine/dbal/pull/714





[DDC-2533] [GH-710] Fix extra lazy get Created: 27/Jun/13  Updated: 05/Nov/14  Resolved: 30/Jun/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of sandermarechal:

Url: https://github.com/doctrine/doctrine2/pull/710

Message:

I made a big mistake in PR #706, my apologies. The get() function in the OneToManyPersister and ManyToManyPersister did not add the collection owner to the load query.

The first commit in this PR fixes this for the OneToMayPersister.

I could not find a way to fix this for the ManyToManyPersister. Problem is that you can only use conditions on the owning side of a ManyToMany relation, not on the inverse side. Code like `load(array($mapping['inversedBy'] => $coll->getOwner()), ...)` gave an ORMException.

Therefor, the second commit in this PR removes the extra-lazy-get for ManyToMany relations. If anyone has any ideas how to make this work for the ManyToMany side, please let me know.



 Comments   
Comment by Doctrine Bot [ 30/Jun/13 ]

A related Github Pull-Request [GH-710] was closed:
https://github.com/doctrine/doctrine2/pull/710

Comment by Doctrine Bot [ 05/Nov/14 ]

A related Github Pull-Request [GH-710] was assigned:
https://github.com/doctrine/dbal/pull/710

Comment by Doctrine Bot [ 05/Nov/14 ]

A related Github Pull-Request [GH-710] was closed:
https://github.com/doctrine/dbal/pull/710





[DDC-2520] [GH-705] [DDC-2519] Partial association identifier Created: 20/Jun/13  Updated: 05/Nov/14  Resolved: 23/Jun/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of FabioBatSilva:

Url: https://github.com/doctrine/doctrine2/pull/705

Message:

http://www.doctrine-project.org/jira/browse/DDC-2519



 Comments   
Comment by Doctrine Bot [ 23/Jun/13 ]

A related Github Pull-Request [GH-705] was closed:
https://github.com/doctrine/doctrine2/pull/705

Comment by Fabio B. Silva [ 23/Jun/13 ]

Merged : https://github.com/doctrine/doctrine2/commit/2ce72f38a2a13c665cd7e2ee5d79eb82d2c8003b

Comment by Doctrine Bot [ 05/Nov/14 ]

A related Github Pull-Request [GH-705] was assigned:
https://github.com/doctrine/dbal/pull/705

Comment by Doctrine Bot [ 05/Nov/14 ]

A related Github Pull-Request [GH-705] was closed:
https://github.com/doctrine/dbal/pull/705





[DDC-3369] Association Entity primary key composite with foreign keys Created: 04/Nov/14  Updated: 05/Nov/14  Resolved: 05/Nov/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4.6
Fix Version/s: None
Security Level: