[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-3404] [GH-1188] Fixed counting exception Created: 20/Nov/14  Updated: 27/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
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-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





Generated at Fri Nov 28 00:14:29 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.