[DDC-2953] ArrayHydrator: Not all items hydrated while orderBy Created: 05/Feb/14  Updated: 18/Aug/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: Critical
Reporter: Mariusz Jaskółka Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: array, hydration
Environment:

Linux and Windows, PHP5


Attachments: File ArrayHydrator.php     File Array_Hydrator_4.2.php     File Array_hydrator_4.2_bugfix.php    
Issue Links:
Dependency
depends on DDC-2955 [GH-933] [WIP] DDC-2953 Resolved

 Description   

I will explain the problem using example and pseudo-code:

I have query like that:
SELECT (...) FROM order LEFT JOIN person LEFT JOIN identifier (...) order by (...)

The rows returned by query are following (the order is very important):
order_id|person_id|identifier_id|
12 |21 |33 |
12 |21 |34 |
11 |21 |35 |
11 |21 |33 |
11 |21 |34 |
12 |21 |35 |

After hydration the result is like:
result[0][person][identifier][0][id]=33
result[0][person][identifier][0][id]=34
result[1][person][identifier][0][id]=35
result[1][person][identifier][0][id]=34

But it should be:
result[0][person][identifier][0][id]=33
result[0][person][identifier][0][id]=34
result[0][person][identifier][0][id]=35
result[1][person][identifier][0][id]=35
result[1][person][identifier][0][id]=34
result[1][person][identifier][0][id]=33

The reason is that ArrayHydrator::_identifierMap contains only object id and parents object id. In may example there is difference in parents parent (grandparent) id.



 Comments   
Comment by Marco Pivetta [ 05/Feb/14 ]

I've started work on this at https://github.com/doctrine/doctrine2/pull/933

Comment by Mariusz Jaskółka [ 06/Feb/14 ]

This is how I temporary solved the issue, maybe it can help (attachment).

Comment by Marco Pivetta [ 06/Feb/14 ]

Mariusz Jaskółka can you provide a diff with current master? This seems to be based off 2.3 or previous versions...

Comment by Mariusz Jaskółka [ 06/Feb/14 ]

Version 2.4.2 oryginal file and bugfix

Comment by Mariusz Jaskółka [ 06/Feb/14 ]

Oh sorry it is version 2.4.1 (composer downloaded that version for me).
I hope it will be ok.

Comment by Marco Pivetta [ 06/Feb/14 ]

Mariusz Jaskółka thanks! I'm trying it right now

Comment by Mariusz Jaskółka [ 06/Feb/14 ]

I added one dimention to $this->_identifierMap to be sure that all object's children's keys will be mapped separately.

Comment by Marco Pivetta [ 06/Feb/14 ]

Mariusz Jaskółka, I've applied your hotfix at https://github.com/doctrine/doctrine2/commit/c05921032ff6947daca2d7275031e5cde4700634 and the tests seem to pass on my system and on travis. You may want to check it out and see if it works for your use case.

Comment by Mariusz Jaskółka [ 06/Feb/14 ]

It works for my use case correctly. You apparently forgot to remove/comment line 82 which is not necessary now.

Comment by Marco Pivetta [ 06/Feb/14 ]

Mariusz Jaskółka fixed, thanks!

Comment by Marco Pivetta [ 14/Jul/14 ]

I don't think we'll have a fix for this issue for 2.5, as it will probably require a complete rewrite of the array hydrator

Comment by Guilherme Blanco [ 14/Jul/14 ]

... and introducing BC breaks.

Comment by Doctrine Bot [ 18/Aug/14 ]

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





[DDC-3212] Remove ArrayHydrator logic Created: 14/Jul/14  Updated: 13/Oct/14

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

Type: Improvement Priority: Critical
Reporter: Marco Pivetta Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: hydration, hydrator


 Description   

The Doctrine\ORM\Internal\Hydration\ArrayHydrator ( https://github.com/doctrine/doctrine2/blob/85fbf684363b932a4ebaf543ef059f9ee1e512b0/lib/Doctrine/ORM/Internal/Hydration/ArrayHydrator.php ) is currently very messy and complicated due to the lack of actual Doctrine\ORM\UnitOfWork references when working with it, since we are not dealing with objects.

In order to reduce the amount of bugs and code duplication when working with array hydration, I would simply suggest making use of the Doctrine\ORM\Internal\Hydration\ObjectHydrator ( https://github.com/doctrine/doctrine2/blob/85fbf684363b932a4ebaf543ef059f9ee1e512b0/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php ) and its siblings, and then extracting data coming from the results in it as an array.

This could be a simple reflection-based extraction (pseudo):

class ArrayHydrator
{
    public function hydrateAllData()
    {
        foreach ($this->objectHydrator->hydrateAllData() as $object) {
            yield $this->extractData($object);
        }
    }
}

The point here is that array-based hydration is not the primary focus of the ORM, and users should probably rely on SQL only when they want array hydration.



 Comments   
Comment by Marco Pivetta [ 14/Jul/14 ]

Note: performance is one of our biggest requirements, and array hydration is meant to achieve that. As I stated above, plain SQL is probably better for this sort of operation, so the issue is more about deprecating the ArrayHydrator completely, providing utilities to manipulate SQL resultsets instead.





[DDC-3360] Problem custom name sequeceGenerator YAML for annotatition entities Created: 22/Oct/14  Updated: 29/Oct/14

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

Type: Bug Priority: Critical
Reporter: Sandro Cândido de Oliveira Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Hi Benjamin

Problem custom name sequeceGenerator YAML why not create the custom name you want. Being created the default postgres, where is the problem?

Note: https://groups.google.com/forum/#!topic/doctrine-user/7ctTFGWu4mo

Message:

  type: entity
  id:
    id:
      type: integer
      generator:
        strategy: SEQUENCE
      sequenceGenerator:
        sequenceName: message_sq
        allocationSize: 100
        initialValue: 1

The entity is created like this:

namespace message\models\entities;

use Doctrine\ORM\Mapping as ORM;

/**
 * Message
 *
 * @ORM\Table(name="message")
 * @ORM\Entity
 * @ORM\HasLifecycleCallbacks
 */
class Message
{
    /**
     * @var integer
     *
     * @ORM\Column(name="id", type="integer")
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="SEQUENCE")
     * @ORM\SequenceGenerator(sequenceName="message_id_seq", allocationSize=1, initialValue=1)
     */

Should be created as specify:

/**
 * Message
 *
 * @ORM\Table(name="message")
 * @ORM\Entity
 * @ORM\HasLifecycleCallbacks
 */
class Message
{
    /**
     * @var integer
     *
     * @ORM\Column(name="id", type="integer")
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="SEQUENCE")
     * @ORM\SequenceGenerator(sequenceName="message_sq", allocationSize=1, initialValue=1)
     */


 Comments   
Comment by Marco Pivetta [ 22/Oct/14 ]

Is the bug reproducible also in 2.4.6?

Comment by Steve Müller [ 22/Oct/14 ]

Moved to ORM issue tracker. This is not DBAL related.

Comment by Sandro Cândido de Oliveira [ 29/Oct/14 ]

Hi

Is the bug reproducible also in 2.4.6 and 2.5.0-DEV





[DDC-3512] Redesign ClassMetadata API as ValueObject based (for type-safety and self-documentation) Created: 17/Jan/15  Updated: 18/Jan/15

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

Type: Improvement Priority: Critical
Reporter: Marco Pivetta Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: classmetadatafactory, cleanup, metadata, performance, type-safety

Issue Links:
Reference
relates to DDC-3503 [GH-1257] Resolve target entity also ... Resolved

 Description   

The current ClassMetadata API is based on a lot of array juggling (for performance reasons).

While that was understandable with PHP 5.3, all the array access operations are currently:

  • slowing things down
  • making the code very hard to read/understand

I suggest re-coding the ClassMetadata internals (public properties and such) so that well-described properties are defined.

Additionally, as a bonus, we'd get a performance boost by just moving all the class-alias and type resolution logic from the runtime into the ClassMetadataFactory (or similar) API, saving tons of performance at every run.

In pseudo-logic, what I'd like to achieve with DDC-3512 is:

  • base metadata is loaded from the mapping driver
  • onLoadMetadata event is fired for each loaded metadata instance
  • metadata is completed by the ClassMetadataFactory logic
  • onCompleteMetadata event is fired for each loaded metadata instance

This would make metadata manipulation from events a bit messier (user needs to know which value to change during which event), but would allow using better constrained metadata structures in future, and that would disallow mistakes during event listeners execution as well (internal validation).






[DDC-3535] Allow binding `Parameter` value object to statements, removing the need for explicit value and type passing Created: 24/Jan/15  Updated: 24/Jan/15

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

Type: Task Priority: Critical
Reporter: Marco Pivetta Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: binding, criteria, parameters, persister, repository, type


 Comments   
Comment by Marco Pivetta [ 24/Jan/15 ]

We currently have a lot of locations in the code where we use list($values, $types) = $this->computeParameters(); (pseudo-code).

This leads to a lot of code duplication and complexity.

Maybe a Parameter VO may be used instead, or a ParameterCollection with a fixed $types and a mutable $values, and with minimal internal validation.





[DDC-3743] There is a BC break in the ORM 2.5 in the DQL parser Created: 22/May/15  Updated: 28/May/15

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

Type: Bug Priority: Critical
Reporter: Christophe Coevoet Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: dql


 Description   

The following DQL query is working fine on 2.4 but breaks on 2.5:

SELECT COUNT(l) FROM Incenteev\WebBundle\Entity\Discussion\Liker l INNER JOIN l.message m INNER JOIN m.thread t WHERE t.space IN (:space_ids) AND l.date >= :from

This is the exception triggered in 2.5:

[Semantical Error] line 0, col 13 near 'l) FROM Incenteev\WebBundle\Entity\Discussion\Liker': Error: Invalid PathExpression. Must be a StateFieldPathExpression. 

The exception happens in Parser->processDeferredPathExpressions.

The Liker class has a compound identifier based on 2 relations.

I suspect it is related to https://github.com/doctrine/doctrine2/pull/1122



 Comments   
Comment by Christophe Coevoet [ 22/May/15 ]

I'm not sure it is a BC break though. Looking at the SQL generated in 2.4, it was not counting the right thing (is was counting only the message ids, not the combination message id/user id being the primary key.

Comment by Christophe Coevoet [ 28/May/15 ]

Actually, it was counting the right thing when not using DISTINCT (the 2.4 generated SQL was broken for DISTINCT though)

Comment by Guilherme Blanco [ 28/May/15 ]

Yep, that PR was the culript. I can look into this issue later.





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

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

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

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

 Description   

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

  • _initializer_
  • _cloner_
  • _isInitialized_
  • lazyPropertiesDefaults

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

Pull request for failing test case



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

Let me know if anything else is needed.

Comment by Doctrine Bot [ 11/Dec/14 ]

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

Comment by Marco Pivetta [ 11/Dec/14 ]

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

Related:

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 16/Jun/15 ]

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





[DDC-3785] DBAL types are ignored in the ManyToManyPersister Created: 23/Jun/15  Updated: 23/Jun/15

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

Type: Bug Priority: Critical
Reporter: David Adams Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

If you're using custom DBAL types for id's, they are ignored and the value object is passed directly to be bound to the query.

For example, I have an Asset that has many Attributes. My asset's id is an AssetId object. I've created a custom DBAL type for AssetId. Whenever doctrine attempts to cleanse the Asset from orphaned Attributes an exception is thrown:

An exception occurred while executing 'DELETE FROM asset_attributes WHERE asset_id = ?' with params [{}]: Warning: oci_bind_by_name(): Invalid variable used for bind

The ManyToManyPersister::delete() method does not pass along any $types to the Connection::executeUpdate() method. The executeUpdate() method checks if there are types and if there are none, does not pass the params to the _bindTypedValues() method, which I think is the problem. The params(AssetId) get passed directly to the $stmt->execute($params) method call.

I believe the ManyToManyPersister::delete() method needs to look like this. This seems to work.

ManyToManyPersister.php
    /**
     * {@inheritdoc}
     */
    public function delete(PersistentCollection $collection)
    {
        $mapping = $collection->getMapping();

        if ( ! $mapping['isOwningSide']) {
            return; // ignore inverse side
        }
        $types = [];
        $class = $this->em->getClassMetadata($mapping['sourceEntity']);

        foreach ($mapping['joinTable']['joinColumns'] as $joinColumn) {
            $types[] = PersisterHelper::getTypeOfColumn($joinColumn['referencedColumnName'], $class, $this->em);
        }

        $this->conn->executeUpdate($this->getDeleteSQL($collection), $this->getDeleteSQLParameters($collection), $types);
    }





[DDC-3789] Paginator does not convert entity ids if they are value objects Created: 23/Jun/15  Updated: 23/Jun/15

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

Type: Bug Priority: Critical
Reporter: David Adams Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

If an entity uses a custom value object and DBAL type for its id, the value object is used as query parameters instead of the converted value.

Here is where $ids contains an array of value objects. This eventually gets set as parameter for the query here.

This leads to an exception like this:

An exception occurred while executing 'SELECT a0_.id AS ID_0, a0_.created_at AS CREATED_AT_1, a0_.updated_at AS UPDATED_AT_2, a0_.name AS NAME_3, a0_.primary_image_id AS PRIMARY_IMAGE_ID_4, a0_.category_id AS CATEGORY_ID_5, a0_.created_by_id AS CREATED_BY_ID_6 FROM assets a0_ WHERE a0_.created_by_id = ? AND a0_.category_id = ? AND a0_.id IN (?, ?, ?)' with params [\"9369f64a-a978-4c5c-b403-baef2576285f\", \"2f8d4a66-47af-4b14-9a3d-54c1debd084c\", {}, {}, {}]:\n\nWarning: oci_bind_by_name(): Invalid variable used for bind

The 3 empty parameters are how my value objects are being wrongly represented.

I've fixed a similar issue in this pull request but I don't know how to go about fixing this in the Paginator.

One solution could be to only allow value objects for id's if the value object class has a __toString() method and another line gets added after the id objects are retrieved:

Paginator.php
    /**
     * {@inheritdoc}
     */
    public function getIterator()
    {
        // existing code

        $ids = array_map('current', $subQuery->getScalarResult());
        $ids = array_map('strval', $ids);

        // existing code
    }





[DDC-3791] Creating a sequence results in an error using Postgres: sequences' name must be quoted Created: 23/Jun/15  Updated: 23/Jun/15

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

Type: Bug Priority: Critical
Reporter: Marcos Passos Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Postgres' sequences must be quoted. The following snippet results in a error:

$schemaManager->createSequence(new Sequence('123_foo'));

Error:

SQLSTATE[42601]: Syntax error: 7 ERROR: syntax error at or near "123"
LINE 1: CREATE SEQUENCE 123_foo INCREMENT BY 1 MINVALUE 1





[DDC-3083] Persist/Flush silently fails when CTI is applied on an existing table Created: 12/Apr/14  Updated: 13/Apr/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: Frank Liepert Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Given an existing table (= parent table) the integration of a new parent-child relationship with Class Table Inheritance (CTI) leads to a update problem.

First of all a child table is created with a foreign key to the parent table. Next, the discriminator column is added to the parent table. The discriminator map will be auto-generated.

The problem arises when trying to perform persist() and flush() on a child entity. Initially the child table is logically empty. However, the UnitOfWork triggers updateTable() which will fail since there is nothing to update. Instead, an upsert should be performed.

Another sneaky thing is that the repository will return the child class with the updated data after calling flush() on the same request. On the next request the child class is returned with the data loaded from the persister. Of course, the updated data is missing.



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

Frank Liepert do I understand this correctly if I say that you are trying to (pseudo) upcast an entity to a more specific subtype? That is unsupported by the ORM. Could you make just an example snippet of what you described in the issue?

Comment by Frank Liepert [ 13/Apr/14 ]

Marco Pivetta: You have understood really well. If you say that's not supported by the ORM then this is the answer. Still I think that upsert could solve solve the "problem" and I know that there are/have been discussions about upsert.

Right now I will continue to manually insert the missing rows in the child table. After this necessary step the ORM works as expected.

Nevertheless the real bug is that after persist() and flush() the entity manager returns the child object with the "persisted" data of the child table although there are in fact no rows in the child table.

$parentRepository = $em->getRepository('Parent');

$child = $parentRepository ->find(1);
$child->setChildPropertyA('foo');

$em->persist($child);
$em->flush();

$child = $parentRepository ->find(1);
var_dump($child->getChildPropertyA());
// string(3) "foo"

// But: There is no 'foo' in the child table!


/** 
 * NEW REQUEST
 */

$parentRepository = $em->getRepository('Parent');

$child = $parentRepository ->find(1);
var_dump($child->getChildPropertyA());
// NULL

Comment by Marco Pivetta [ 13/Apr/14 ]

Frank Liepert why are $child in the first request and $child in the second request different here? Are you manually changing the data at SQL level?

Comment by Frank Liepert [ 13/Apr/14 ]

Marco Pivetta as I have explained the persist() and flush() in the first request trigger an UPDATE command (Because there is already a row in the parent table?). Given that the child table was manually created before there are no rows on that table at that time and therefore nothing can be updated. Nevertheless the ORM triggers no error and $child looks like having been persisted. In the second request you'll notice that there haven't been persisted any of the data belonging to the child table.





[DDC-2983] TCI association not getting hydrated into sql statement Created: 14/Feb/14  Updated: 23/Mar/14

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

Type: Bug Priority: Major
Reporter: Machete Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm
Environment:

MySQL, using DoctrineORMModule (zf2 integration)



 Description   

/**
 * @ORM\Entity
 * @ORM\Table(name="base")
 * @ORM\InheritanceType("JOINED")
 * @ORM\DiscriminatorColumn(name="discriminator", type="string")
 * @ORM\DiscriminatorMap({
 * "a" = "A",
 * "b" = "B",
 * })
 */
class Base
{
    /**
     * @ORM\Id
     * @ORM\Column(type="integer")
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;
}

/**
 * @ORM\Entity
**/
class A extends Base {
    /**
     * @ORM\ManyToOne(targetEntity="B", inversedBy="as")
     */
    protected $b;

    /**
     * @ORM\OneToMany(targetEntity="C", cascade={"persist"})
     */
    protected $cs;
}

/**
 * @ORM\Entity
**/
class B Extends Base {
    /**
     * @ORM\OneToMany(targetEntity="A", mappedBy="b")
     */
    protected $as;
}

/**
 * @ORM\Entity
**/
class C {
  // ...
}

Doing this:

$a = new A();
$b = new B();

$a->setB($b);
$b->addA($a);

var_dump($a->getB()); // outputs B (b not null!)
var_dump($b->getAs()) // outputs A (private $_elements => [0] class B)

$em->persist($a);
$em->persist($b);
$em->flush();

Leads to

integrity constraint violation, b_id can not be null

aka

INSERT INTO a (id, b_id), (123, null);

I have no idea why this happens. This works:

$a = new A();
$b = new B();

$a->setB($b);
$b->addA($a);

var_dump($a->getB()); // outputs B (b not null!)
var_dump($b->getAs()) // outputs A (private $_elements => [0] class B)

$em->persist($a);
$em->flush();
$em->persist($b);
$em->flush();


 Comments   
Comment by Benjamin Eberlei [ 23/Mar/14 ]

This most likely happens because the UnitOfWork tries to set the owner and reverse incorrectly due to an ordering issue.





[DDC-2918] get statements from ORM Created: 15/Jan/14  Updated: 15/Jan/14

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

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


 Description   

When doing `persist()` and then `flush()` the statements are not accessible anymore after the operation is done.

The EntityManager uses an EntityPersister. When looking at the BasicEntityPersister->executeInserts() a new statement is created but it's not saved as part of another object.
https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php#L260

Benefit:
When having access to the statements afterwards, all the following methods would be available:
http://www.php.net/manual/en/class.pdostatement.php

Most interesting are rowCount and error related methods.



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

Flip AFAIK you can use an SQL Logger for this which has to be set in the connection. The ORM testsuite makes use of this, too. See this example: https://github.com/doctrine/doctrine2/blob/master/tests/Doctrine/Tests/ORM/Functional/OneToOneEagerLoadingTest.php#L155

Comment by Flip [ 15/Jan/14 ]

Yes sure, but using a logger will be a strange way to pipe it back into business logic.

For example it's possible to do remove() on a proxy so you don't know if the row was present or not.

or another situation ..

when dealing with concurrency .. somebody else might have deleted the row already ..





[DDC-2891] Impossible to pass a limit to a subquery Created: 07/Jan/14  Updated: 08/Jan/14

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

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


 Description   

It seems that passing the limit to a subquery is not working

 
$subquery = $em->createQueryBuilder()->from('...')->where('...')->setMaxResults(5);
$query = $em->createQueryBuilder()->from('...')->where(
   $qb->expr()->in('p.id', $subquery->getDQL())
);
$query->getQuery()->getResult();

The query works but the is no specified limit in the resulting SQL.
I am aware that DQL does not support the limits and offsets, so i guess there should be another way to get this working?



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

Can you please tell which database platform you are using? Because limiting results heavily depends on the platform used.

Comment by alex [ 08/Jan/14 ]

MySql

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

Hmmm I am not quite sure if the limit/offset is invoked for subqueries but I don't see why it shouldn't. Also I think this is not a DBAL issue because the limit/offset support for MySQL is the easiest we have on all platform. See: https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Platforms/MySqlPlatform.php#L51-L63
The query doesn't have to be modified but instead only the limit clause is appended to the query. Can you maybe provide the generated SQL for that query?

Comment by alex [ 08/Jan/14 ]

I think if you try to build any query with QueryBuilder, set a limit to it with setMaxResults then call getDQL method, you should see that the output contains no info about limit.
So if you look at my code example , at $qb->expr()>in('p.id', $subquery>getDQL()), then you will see that the getDQL passes to the IN expression a query which already DOES NOT have limit. So this is the place where any info about limits and offsets gets lost.

So I fail to see what it has to do with any specific db engine,however I can provide the mysql resulting query if you want,though it looked perfectly normal to me,just lacks the LIMIT part.





[DDC-2851] Allow set custom collection initializer at runtime Created: 12/Dec/13  Updated: 12/Dec/13

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

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


 Description   

Use case: Company, Category, CompanyCategory entities. We are loading set of companies and should initialize Company.companyCategories collection with joined categories, which ordered by Company.title.

I cann't do it via Criteria API, it doesn't supports joins. + I should return same PersistentCollection instance (Company.companyCategories used in Symfony2 forms).

Current workaround:

    public function loadCompanyCategoriesCollectionForCompany(Company $company)
    {
        $companyCategories = $this->_em->createQueryBuilder()
            ->select('cc')
            ->from('OloloCompaniesBundle:CompanyCategory', 'cc')
            ->join('cc.category', 'c')
            ->addSelect('c')
            ->orderBy('c.title')
            ->where('cc.company = :company')
            ->setParameter('company', $company)
            ->getQuery()
            ->getResult()
        ;

        $coll = $company->getCompanyCategories();
        foreach ($companyCategories as $companyCategory) { /* @var $coll \Doctrine\ORM\PersistentCollection */
            $coll->hydrateAdd($companyCategory);
        }
        $coll->setInitialized(true);
    }

What would be nice: native API for setting custom initializers.






[DDC-2852] Enclose subquery with parenthesis in from clause (QueryBuilder) Created: 12/Dec/13  Updated: 12/Dec/13

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

Type: Improvement Priority: Major
Reporter: Matthieu Pécro Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: from, orm, parenthesis, querybuilder,, subquery


 Description   

Hi

In QueryBuilder from clause, when argument is a QueryBuilder (not a string like a table), there are not parenthesis enclosure on the subquery.

Ex:
$subqb->select('myfield')->from('mytable');
$qb->from($sub, 'myalias)

DQL is : SELECT myfield FROM SELECT myField FROM mytable myalias. This is not working on MySQL.

It should be : SELECT myfield FROM (SELECT myField FROM mytable) myalias.



 Comments   
Comment by Christophe Coevoet [ 12/Dec/13 ]

I don't understand your statement This is not working on MySQL. after giving a DQL statement. MySQL does not support any DQL. It runs SQL.

And DQL does not support using a subselect in the FROM clause





[DDC-2841] Preload data for association Created: 06/Dec/13  Updated: 06/Dec/13

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

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


 Description   

Consider two classes User and Address with one-to-many association.
I would like to preload addresses for given user object so that it will be accessible via getter method like this:

1. $user = $userRepository->find($userId);
2. load some of the addresses but not all
3. $user->getAddresses() should return those loaded in step 2

Currently the only solution for step 2 I found working is to write a DQL like this:
SELECT u, a
FROM User
INNER JOIN u.addresses a
WHERE u = :user AND a.foo = 1

When the data is hydrated it is assigned to the user object and thus accessible with $user->getAddresses (which normally would return all the addresess not only those with foo set)

The only problem is that the query in step 2 unnecessarily fetches all user data that was already fetched in step 1






[DDC-2826] Add support for mapping collections of embeddable objects Created: 28/Nov/13  Updated: 08/Feb/14

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

Type: New Feature Priority: Major
Reporter: songoko songowan Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: collection, orm, value-objects


 Description   

In Hibernate we can do something like this:

    @Entity
    public class User {
       [...]
       public String getLastname() { ...}
    
       @ElementCollection
       @CollectionTable(name="Addresses", joinColumns=@JoinColumn(name="user_id"))
       @AttributeOverrides({
          @AttributeOverride(name="street1", column=@Column(name="fld_street"))
       })
       public Set<Address> getAddresses() { ... } 
    }
    
    @Embeddable
    public class Address {
       public String getStreet1() {...}
       [...]
    }

Basically a collection of value objects is mapped to a new table. Currently Doctrine2 is on its way to support value objects

However, this implementation won't support mapping a collection of objects to a new table and the only way to circumvent this issue is to treat the address an an entity and use an one-to-many unidirectional relationship through a many-to-many join table



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

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





[DDC-2816] New event: pre-execute query Created: 25/Nov/13  Updated: 25/Nov/13

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

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


 Description   

It would be useful to fire event just before each query executes. Listeners can set hints to query, for instance.






[DDC-2787] COALESCE() doesn't work with NOT IN() Created: 09/Nov/13  Updated: 09/Nov/13

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

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


 Description   

When I try running the following query:

SELECT count(c.id) FROM my\model c WHERE COALESCE(c.up, 0) NOT IN( :parent_ids)

I get

Doctrine\ORM\Query\QueryException: [Semantical Error] line 0, col 118 near 'up, 0) NOT IN(': Error: Invalid PathExpression. Must be a StateFieldPathExpression.

When I run the query as straight SQL against the database, it works as expected. Is this something that can be fixed in Doctrine or is this syntax unsupported?






[DDC-2733] DefaultQuoteStrategy BUG on Oracle Created: 10/Oct/13  Updated: 26/Oct/13

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

Type: Bug Priority: Major
Reporter: Pablo Santiago Sánchez Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Symfony on all platforms (Windows, Linux and Mac)
Oracle 11g



 Description   

There's a bug on the DefaultQuoteStrategy when used with Oracle. The getColumnAlias created an invalid alias.

The name of the column had 31 chars, with _ being the 3rd. Column was 101 on the query. Resulting name of the alias started with _, which is invalid name for Oracle.

Example:
CO_SEQ_NOMEGIGANTEPRAKCTMEUDEUS

Alias formed was
_SEQ_NOMEGIGANTEPRAKCTMEUDEUS101

HOW TO FIX:
replace the regex on line 135:
original:
$columnName = preg_replace('/[^A-Za-z0-9_]/', '', $columnName);
fixed:
$columnName = preg_replace('/[^A-Za-z0-9]/', '', $columnName);



 Comments   
Comment by Rudi Uhrig Neto [ 16/Oct/13 ]

Hi there!

I would like to do a contribuition for this issue! I'm not safe with my sugestion, but someone can be helped!

I'm working with 2.4.0 Doctrine Version and I'm facing the same problem, "invalid character" due the function that make a cut off from the begining from alias.

My sugestion to solve this problem is maintain the separator '_' between alias name, but cutting off from the ending alias and reserv the lenght to the counter.

See bellow my modification code at DefaultQuoteStrategy::getColumnAlias() line 130, just replace all lines from function by these below:

DefaultQuoteStrategy.php
public function getColumnAlias($columnName, $counter, AbstractPlatform $platform, ClassMetadata $class = null)
{
    // 1 ) Trim the column alias to the maximum identifier length of the platform.
    //     If the alias is to long, characters are cut off from the ending subtracting the chars reserved to counter.
    // 2 ) Concatenate column name and counter
    // 3 ) Strip non alphanumeric characters
    // 4 ) Prefix with "_" if the result its numeric
    $columnName = substr($columnName, 0, $platform->getMaxIdentifierLength() - strlen($counter));
    $columnName = $columnName . $counter;
    $columnName = preg_replace('/[^A-Za-z0-9_]/', '', $columnName);
    $columnName = is_numeric($columnName) ? '_' . $columnName : $columnName;
      
    return $platform->getSQLResultCasing($columnName);
}

What do you guys think?

Comment by Pablo Santiago Sánchez [ 16/Oct/13 ]

Rudi, prefixing it with _ would keep the problem on Oracle. Since that name is for aliasing pourposes only, the _ char is useless.

I just remembered another possible situation: fields should not start with numbers!

Comment by Rudi Uhrig Neto [ 16/Oct/13 ]

Pablo,

The changes in my sugestion code don't consider the prefix '_', indepedent of the characteres in alias column name, the function will remove the last characteres from alias... see an example with column name DT_VERIFICACAO_SITUACAO_ACESSO.

The current code create a sql:
DT_VERIFICACAO_SITUACAO_ACESSO AS _VERIFICACAO_SITUACAO_ACESSO23,

My sugestion will produce:
DT_VERIFICACAO_SITUACAO_ACESSO AS DT_VERIFICACAO_SITUACAO_ACES23,

Comment by Pablo Santiago Sánchez [ 18/Oct/13 ]

Oh, sorry, my mistake. Your solution sounds better.

Since there's still no solution from the Doctrine Team, I'm iusing my own QuoteStrategy. Hope this bug gets fixed soon.

Comment by Benjamin Eberlei [ 26/Oct/13 ]

Fabio B. Silva Can you comment on Rudi Uhrig Neto solution? Its easily changed, but I am wondering if this is backwards compatible. I would want to merge the fix back to 2.3 and 2.4. Branch is ready to be committed for me locally.





[DDC-2744] Inheritance - Empty value for discriminatorColumn in query Created: 16/Oct/13  Updated: 16/Oct/13

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

Type: Bug Priority: Major
Reporter: Daniel Dos Prazeres Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Hello, I have an inheritance problem with the following classes

<?php

namespace Proj\Bundle\MyBundle\Entity;

use Doctrine\ORM\Mapping as ORM;
use Symfony\Component\Validator\Constraints as Assert;

/**
 * ClassTop
 *
 * @ORM\Table()
 * @ORM\Entity(repositoryClass="Proj\Bundle\MyBundle\Repository\ClassTopRepository")
 * @ORM\InheritanceType("SINGLE_TABLE")
 * @ORM\DiscriminatorColumn(name="aVal", type="string")
 * @ORM\DiscriminatorMap({ "ValOne" = "ClassSubOne", "ValTwo" = "ClassSubTwo", "ValThree" = "ClassSubThree" })
 * 
 */
class ClassTop
{
    .....
}

class ClassSubOne extends ClassTop
{
    ....
}

class ClassSubTwo extends ClassTop
{
    ....
}

class ClassSubThree extends ClassTop
{
    ....
}

When i call findAll method my query is not correct

$entityManager->getRepository('ProjMyBundle:ClassSubOne')->findAll()

the query builded

SELECT field, field2 FROM CLASSTOP WHERE AVAL IN () 

The value for the discriminator column is not passed

Thanks for your help






[DDC-2742] 2 ManyToMany relations to the same target entity make the schema update fail by default Created: 15/Oct/13  Updated: 15/Oct/13

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

Type: Bug Priority: Major
Reporter: Christophe Coevoet Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mapping, schematool


 Description   

At some point in the Doctrine releases (I don't remember which version it was), the default naming of the join table of a ManyToMany relation changed from using the property name to using the name of the target entity.

This makes it impossible to use multiple ManyToMany relations to the same target entity in a class without naming join tables explicitly. A SchemaException is thrown by the SchemaTool when trying to update the schema.

Note that this issue is not caught by the SchemaValidator. It will display us that the mapping files are correct (before throwing the above exception in the second step when trying to compare it to the existing database)






pager produces wrong results on postgresql (DDC-1958)

[DDC-2729] Same bug affects SQLServer2008Platform Created: 07/Oct/13  Updated: 07/Oct/13

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

Type: Sub-task Priority: Major
Reporter: Rafi Adnan Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: paginator
Environment:

SQL Server 10.50.1617
unixODBC 2.2.14
PHP 5.4.19



 Description   

If the class is patched with the following:

if ($this->platform instanceof SQLServer2008Platform)

{ $this->preserveSqlOrdering($AST, $sqlIdentifier, $innerSql, $sql); }

It fixes the issue.






[DDC-2709] Defining Columns as "Updatable" or "Insertable" Created: 27/Sep/13  Updated: 27/Sep/13

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

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


 Description   

With Hibernate I can define a column as Updatable/Insertable or non-Updatable/non-Insertable so that this field is considered read-only and is not part of any update/insert statement. I'd like to have the same possibility in Doctrine.

In my use case a value is generated and maintained by database triggers. In my application I only want to read this value but the application should never try to insert or update the column.

Updatable/Insertable in the Hibernate documentation: http://docs.jboss.org/hibernate/annotations/3.5/reference/en/html_single/#entity-mapping-property-column






[DDC-2691] Test Suite: Drop other connections before dropping database PostgreSQL Created: 19/Sep/13  Updated: 19/Sep/13

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

Type: Improvement Priority: Major
Reporter: Flip Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Windows 7 Professional 64 bits
PHP 5.4.11 (cli) (built: Jan 16 2013 20:26:26)
Doctrine dev-master from 18-9-2013
PostgreSQL 9.2.4 build 1600, 64-bits



 Description   

The test suite is trying to run the command

DROP DATABASE doctrine_tests

This fails, together with lots of tests when another user is connected (for example through the pgAdmin program). It would be nice if the test suite had an option to drop existing connections, which can be done with the following command:

SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname = 'doctrine_tests';





[DDC-2697] ObjectHydrator::hydrateRowData fails to hydrate first fetch joined entity Created: 20/Sep/13  Updated: 06/Dec/13

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

Type: Bug Priority: Major
Reporter: Austin Morris Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm
Environment:

All



 Description   

Let's say I have accounts, contacts, and contact types. Any given contact can have be any kind of contact type to any account. This is all managed through an account_contacts table with a 3-way composite PK of the contact_id, account_id, and type_id.

All of this translates to 4 entities, the account, contact, type, and accountContact entity. The id of the accountContact entity is the three other entities which is holds.

When I use query builder to retrieve the accountContacts based on some condition, and also fetch join contacts, accounts, and types so that they are eagerly loaded, the ObjectHydrator fails to load the first accountContact returned.

This is because the first time through hydrateRowData, the fetch joined entities are hydrated first. The problem is $this->_rsm->parentAliasMap[$dqlAlias] does not contain an entry for the accountContact (root entity). Not until an accountContact is hydrated does that get set. In the mean time, the other three entities were set to null because there is no parent alias yet (in version 2.4, this is line 405.

Subsequent loops through hydrateRowData work because by this time the parent alias is set. But that first row returned is always an accountContact containing three null objects.



 Comments   
Comment by Benjamin Eberlei [ 26/Oct/13 ]

Austin Morris Can you show the QueryBuilder select clause you are using? Have you tried sorting the accountContacts first?

$qb->select('accountContacts, contact, account, type')

This way it should definately work, and then there is also some attempts to resort this way if you dont have that, but its not always working.

Comment by Austin Morris [ 06/Dec/13 ]

Sorry, I don't have the original select clause. I ended up doing something different and can't seem to find my original code.

Comment by Benjamin Eberlei [ 06/Dec/13 ]

I have another person that reported a simliiar bug with reproducable test case. I hope to investigate this very soon.





[DDC-2694] Hydrating with entities with the NEW operator Created: 19/Sep/13  Updated: 21/Jan/14

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

Type: New Feature Priority: Major
Reporter: Flip Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 3
Labels: None

Issue Links:
Duplicate
is duplicated by DDC-2899 Allow the NEW operator to construct o... Resolved

 Description   

It would be nice if the new function accepted objects as parameters, like this:

new Country(country, some_extra_stuff)

Alternatively another keyword could be introduced that constructs the object with the parameter and afterwards hydrates it.






[DDC-2679] SchemaTool ON DELETE CASCADE does not work with MSSQL Created: 13/Sep/13  Updated: 15/Jan/14

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

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

MSSQL 2008 R2



 Description   

The following queries are produced by:
vendor\doctrine\orm\tests\Doctrine\Tests\ORM\Functional\SchemaTool\DDC214Test.php

ALTER TABLE company_persons ADD CONSTRAINT FK_820EDD048EEC5B5C FOREIGN KEY (spouse_id) REFERENCES company_persons (id) ON DELETE CASCADE
ALTER TABLE company_persons_friends ADD CONSTRAINT FK_EAD47FE9217BBB47 FOREIGN KEY (person_id) REFERENCES company_persons (id) ON DELETE CASCADE
ALTER TABLE company_persons_friends ADD CONSTRAINT FK_EAD47FE96A5458E8 FOREIGN KEY (friend_id) REFERENCES company_persons (id) ON DELETE CASCADE
ALTER TABLE company_employees ADD CONSTRAINT FK_899949F0BF396750 FOREIGN KEY (id) REFERENCES company_persons (id) ON DELETE CASCADE
ALTER TABLE company_managers ADD CONSTRAINT FK_B1DEF56BBF396750 FOREIGN KEY (id) REFERENCES company_persons (id) ON DELETE CASCADE
ALTER TABLE company_auctions ADD CONSTRAINT FK_6A41FC6DBF396750 FOREIGN KEY (id) REFERENCES company_events (id) ON DELETE CASCADE
ALTER TABLE company_raffles ADD CONSTRAINT FK_9D157F46BF396750 FOREIGN KEY (id) REFERENCES company_events (id) ON DELETE CASCADE

The errors:

Msg 1785, Level 16, State 0, Line 1
Introducing FOREIGN KEY constraint 'FK_820EDD048EEC5B5C' on table 'company_persons' may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints.
Msg 1750, Level 16, State 0, Line 1
Could not create constraint. See previous errors.
Msg 2714, Level 16, State 5, Line 1
There is already an object named 'FK_EAD47FE9217BBB47' in the database.
Msg 1750, Level 16, State 0, Line 1
Could not create constraint. See previous errors.
Msg 1785, Level 16, State 0, Line 1
Introducing FOREIGN KEY constraint 'FK_EAD47FE96A5458E8' on table 'company_persons_friends' may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints.
Msg 1750, Level 16, State 0, Line 1
Could not create constraint. See previous errors.
Msg 2714, Level 16, State 5, Line 1
There is already an object named 'FK_899949F0BF396750' in the database.
Msg 1750, Level 16, State 0, Line 1
Could not create constraint. See previous errors.
Msg 2714, Level 16, State 5, Line 1
There is already an object named 'FK_B1DEF56BBF396750' in the database.
Msg 1750, Level 16, State 0, Line 1
Could not create constraint. See previous errors.
Msg 2714, Level 16, State 5, Line 1
There is already an object named 'FK_6A41FC6DBF396750' in the database.
Msg 1750, Level 16, State 0, Line 1
Could not create constraint. See previous errors.
Msg 2714, Level 16, State 5, Line 1
There is already an object named 'FK_9D157F46BF396750' in the database.
Msg 1750, Level 16, State 0, Line 1
Could not create constraint. See previous errors.

An explanation why this is happening:
http://stackoverflow.com/questions/851625/foreign-key-constraint-may-cause-cycles-or-multiple-cascade-paths



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

This is a SQL Server limitation as it does not support multi-path cascades for foreign keys.
See here: http://allyourdatabase.blogspot.de/2006/11/multiple-cascade-paths-error-in-sql.html

Not sure what to do about this at the moment...

Comment by Flip [ 15/Jan/14 ]

Yes there is nothing we can do to get this to work. But what we can do is:
1. Build in some detection when this happens and then throw a php exception for this kind of error (yet to be created)
2. All tests which rely on this functionality for SQL Server should be reviewed again. There are two possibilities:
A. The test can be rewritten so that it doesn't have multiple paths.
B. if not. The test has to be skipped for SQL Server.





[DDC-2672] Using fetchAll() in Hydration can improve TCP Wait Created: 11/Sep/13  Updated: 13/Dec/13

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


 Description   

Hydration currently fetches the rows and hydrates them by interleaving both operations. This can cause an increased TCP wait time, because the PHP processing takes a bit of time.

We should investigate weather changing to fetchAll() improves the overall performance.

Ping Thomas RabaixGuilherme Blanco



 Comments   
Comment by Benjamin Eberlei [ 13/Dec/13 ]

We can introduce a new query hint to allow us to support both: 'DBAL_FETCH_ALL'. If that is set, use fetchAll(), otherwise fetchRow().





[DDC-2659] Notice: Undefined index: sourceToTargetKeyColumns in /doctrine/orm/lib/Doctrine/ORM/Persisters/BasicEntityPersister .php line 1180 Created: 08/Sep/13  Updated: 08/Sep/13

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: Taylor Kaplan Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm
Environment:

Symfony2 With PHP 5.5 on Ubuntu 12.04 LTS using Apache 2


Attachments: File Client.php     File ClientFixtures.php     File User.php     File UserFixtures.php    

 Description   

I am getting this error:

 Notice: Undefined index: sourceToTargetKeyColumns

When I try to load my data fixture. There are two ordered fixtures that I'm dealing with: Clients and Users. The client datafixture looks like:

    	/**
    	 * {@inheritDoc}
    	 */
    	 public function load(ObjectManager $manager)
    	 {
    
    		for($index = 0; $index < 224; $index ++)
    		{
    			$client = new Client();
    			$manager->persist($client);
                        $this->addReference($index . 'Client', $client);
    		}
    
    		$manager->flush();
    		$manager->clear();
    	 }
    
    	 public function getOrder()
    	 {
    	 	return 0;
    	 }

While the user data fixture looks like:

     $user = New User();
     $client = $this->getReference($index . 'Client');

     // This line is causing the problem
     $client->setUser($user);

For whatever reason, I don't seem to be having issues with any of my other fixtures. Just this one. I've doubled check the entity relationships which are shown bellow.

My Client.php entity:

    /**
     * @ORM\ OneToOne(targetEntity="User", mappedBy="clientAccount")
     */
    protected $user;

My User.php entity:

    /**
     * @ORM\ OneToOne(targetEntity="Client", inversedBy="user")
     */
    protected $clientAccount;

There seems to be a bug with the return value of getAssociationMapping() for special conditions when implemented in BasicEntityPersister. The files for my fixtures and entities for this project have been attached.






[DDC-2671] YAML mapping: entity generation with inheritance does work Created: 11/Sep/13  Updated: 11/Sep/13

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

Type: Bug Priority: Major
Reporter: Peter Tulala Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: inheritance, mapping, yaml


 Description   

Entities inherited from parent entities should be defined as class Foo extends Bar. However YAML driver ignores inheritance hierarchy and does not use "extends" keyword at all.






[DDC-2649] Hydration in bidirectional, OneToOne relationship, PK as FK for owning side, is problematic Created: 04/Sep/13  Updated: 04/Sep/13

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

Type: Bug Priority: Major
Reporter: Jérôme Viveret Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: FK, OneToOne, PK, bidirectional


 Description   

I am referring to this situation https://gist.github.com/anonymous/6435032

The following problem occur:

When using HardCover as the root entity of a query, the ObjectHydrator fails to properly register the first [HardCover of the resultset]'s Book. Only the first. The following HardCover have their Books correctly linked. The inverse situation (using Book as the root entity) works fine.

When some other entity (say WoodenPart) is linked to HardCover via a ManyToOne association, using WoodenPart as a query root results in no WoodenPart have their HardCover registered.






[DDC-2642] GROUP BY with inherited entity (which is also in SELECT clause) does not list columns from inheriting entities Created: 30/Aug/13  Updated: 30/Aug/13

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

Type: Bug Priority: Major
Reporter: Ondřej Mirtes Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

PostgreSQL



 Description   

The summary pretty much sums it up.

Code example: https://gist.github.com/ondrejmirtes/6388434






[DDC-2637] [GH-769] Add Custom Persisters Created: 28/Aug/13  Updated: 15/Apr/14

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

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

Issue Links:
Duplicate
is duplicated by DDC-2629 [GH-768] DDC-391: Add support to conf... Resolved
Reference
relates to DDC-391 Allow to specifiy custom Entity and C... In Progress

 Description   

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

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

Message:

Adding support for custom persisters as defined by DDC-391.
Implementing both Entity and Collection based Persisters



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

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

Comment by Doctrine Bot [ 15/Apr/14 ]

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





[DDC-2635] Problems with Filtering SQL Queries based on schema Created: 27/Aug/13  Updated: 27/Aug/13

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


 Description   

The filtering in Schema Tool based on current database schema is not extendable very easily. We need a way to allow creating all, or only a subset of schemas in both supporting and non supporting databases.






[DDC-2630] Filters with joined inheritance Created: 22/Aug/13  Updated: 09/Jan/14

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

Type: Improvement Priority: Major
Reporter: Florian Vilpoix Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: inheritance, sql-walker, sqlfilter


 Description   

Hello,

I'm trying to use SQLFilter with a Joined Inheritance, and the sql Walker never applies filters on the sub-class, even if I make my SELECT on the sub-class or the root.

In the SqlWalker, the methods 'generateFilterConditionSQL' says :

// The classes in the inheritance will be added to the query one by one,
// but only the root node is getting filtered

I don't understand why, and I would like to know if there is any way to apply filters to subclasses in joined-inheritance.

Thanks a lot



 Comments   
Comment by Menno Holtkamp [ 09/Jan/14 ]

Are you sure you apply the filter on the root Entity? This discussion might be usefull:
https://groups.google.com/forum/#!topic/doctrine-user/e1cPZOorfaQ





[DDC-2617] OneToMany annotation should not work with MappedSuperclass Created: 18/Aug/13  Updated: 08/Sep/13

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

Type: Bug Priority: Major
Reporter: jonathan bensaid Assignee: Fabio B. Silva
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Using annotations in my model mapped to "mapped superclass" I can use one to many relations et every bidirectional relation I want.
Using yaml or xml it suddenly doesn't work and throw me an error. Annotations should work the same way and should not authorize one to many or any bidirectional relation.



 Comments   
Comment by Benjamin Eberlei [ 08/Sep/13 ]

Its actually the other way around, yml and xml need to allow this, because it works with association overrides.

Comment by Benjamin Eberlei [ 08/Sep/13 ]

Assigning Fabio





[DDC-2605] Console command generates entity stubs that break type hinting contracts. Created: 09/Aug/13  Updated: 12/Aug/13

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

Type: Bug Priority: Major
Reporter: Alex Parker Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: cli, orm, stubs, tools, type-hinting
Environment:

Debian Linux (crunchbang)
PHP 5.4.4-14+deb7u2 (cli)
MySQL Server version: 5.5.31-0+wheezy1 (Debian)


Attachments: PNG File thcontract.png    

 Description   

I've found that the doctrine cli tool seems to break PHP's type hinting contracts in the scenario outlined in the attached diagram, following a process outlined in my stack overflow post here: http://stackoverflow.com/questions/18098552/using-symfony-2-cli-tools-how-can-i-generate-getters-and-setters-with-correct-t

The result is code that throws E_STRICT notices which we are loathe to suppress for CI reasons, e.g: Runtime Notice: Declaration of ... should be compatible with ... in ... line ...

As mentioned I have asked on Stack Overflow to no avail, as well as the FreeNode IRC channels starting with #symfony. The response from #symfony is that this is a doctrine issue, with suggestions being made that my problem is that I am using the CLI tools.

I don't think it would be too difficult to fix this issue. I had a quick look at the Doctrine\ORM\Tools\EntityGenerator class and Doctrine\ORM\Tools\Console\Command\GenerateEntitiesCommand and it looks like it should be possible to find the eldest ancestor definition of a function and honour its type hints.

I am open to this being an implementation issue on my end, but I do feel this may be either a bug or an opportunity to improve the CLI tools as for most other purposes they have been a huge benefit to automating my workflow.

Thanks for your time and consideration.






[DDC-2595] UoW is not supposed to trigger the post-load event for uninitialized proxies. Created: 06/Aug/13  Updated: 06/Aug/13

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

Type: Bug Priority: Major
Reporter: Juti Noppornpitak Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None


 Description   

When one entity have multiple nested levels and associated to 700+ other entities, the ORM exhausts a large amount of memory and execution time which exceeds either the memory limit or the maximum execution time.

Prerequisite:

1. generate an entity, named "Mr. G", with 4 nested levels of association.
2. ensure that the generated entity associating to 700+ entities.
3. create a post-load event listener which may or may not be restricted to uninitialized proxies.

How to Reproduce:

1. have a code to load the "Mr. G" entity.
X. (Done)

Notes:
The initial investigation indicates that UnitOfWork should not trigger the post-load event for uninitialized proxies.

One thing worth-mentioning is that if the event listener ignores all proxies, we will not have this problem. However, some properties (e.g., ones of type TEXT/BLOB) are not loaded into normal entities but they are loaded into the proxies.






[DDC-2596] With Access to ResultSetMapping, Paginator can decide on fetchJoinCollection and useoutputWalker Created: 07/Aug/13  Updated: 07/Aug/13

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





[DDC-2567] auto generated index name cannot be overriden with annotation Created: 23/Jul/13  Updated: 23/Jul/13

Status: Open
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: Nicolas Ricci Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Hi,

I have an unexpected behaviour when generating SQL from an entity using annotation.

The default indexes name (generated by _generateIdentifierName) are automatically overwriting the name I have specified in my entity.

I have patched the following file https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Schema/Table.php

with:
// check for duplicates
foreach ($this->_indexes as $idxKey => $existingIndex) {
if ($indexCandidate->isFullfilledBy($existingIndex))

{ //return $this; // old implementation unset($this->_indexes[$idxKey]); }

}

but I don't think this is the correct way forward.

Let me know if you require more information

Thanks






[DDC-2528] Extracting entities through DQL query resets the previous associations Created: 24/Jun/13  Updated: 25/Jun/13

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

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

Windows 8



 Description   

I have the entities Purchase(owning side) and Product(inverse side) sharing bidirectional many to many relation. Now whatever associations I build between product and purchase entity, those associations are erased if by mistake I happen to run a join query between the products and purchase table. For example look at this code.

$purc = $em->find("\ZC\Entity\Purchase", 1); //Existing purchase entity
//Now this purchase entity is linked to 2 products through the join table
$prod = new \ZC\Entity\Product();
$prod->name= "newly";
$purc->addProduct($prod); //Added a new product to the collection
// print(count($purc->products));
$dql = "SELECT b,c FROM \ZC\Entity\Purchase b join b.products c where      b.id = 1";
$query = $this->entityManager->createQuery($dql);
$purc2 = $query->getResult()[0]; //Now this is same as $purc
print(count($purc->products));   //again prints 2

As you can see, when I have added a new entity $prod to the $purc, the number of products linked to $purc should have increased to 3. It seems the join overrides the previous associations formed. More strange is if I had fetched the products related to $purc from the tables before the join query(the commented code before dql), then the last print statement would have given 3.
I am facing a lot of similar issues.






[DDC-2495] Partial objects not working with STI Created: 10/Jun/13  Updated: 11/Jun/13

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

Type: Bug Priority: Major
Reporter: Radoslaw Ejsmont Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: STI, dql, orm, partial
Environment:

Symfony2 project, Doctrine ORM with MySQL database backend


Attachments: File CrossVial.php     File Entity.php     File InjectionVial.php     File Stock.php     File StockVial.php     File Vial.php    

 Description   

When I try to create a query retrieving partial objects of a root class in single table inheritance hierarchy, the resulting SQL includes all fields from the whole class hierarchy.

DQL:
SELECT partial v.

{id, setupDate, flipDate}

FROM VIB\FliesBundle\Entity\Vial v WHERE v.id IN (1,2,3,4,5,6,7,8,9,10)

SQL:
SELECT v0_.setupDate AS setupDate0, v0_.flipDate AS flipDate1, v0_.id AS id2, v0_.type AS type3, v0_.parent_id AS parent_id4, v0_.position_id AS position_id5, v0_.prevPosition_id AS prevPosition_id6, v0_.incubator_id AS incubator_id7, v0_.stock_id AS stock_id8, v0_.male_id AS male_id9, v0_.virgin_id AS virgin_id10, v0_.targetStock_id AS targetStock_id11, v0_.targetStockVial_id AS targetStockVial_id12 FROM Vial v0_ WHERE (v0_.id IN (1, 2, 3, 4, 5, 6, 7, 8, 9, 10)) AND v0_.type IN ('vial', 'stock', 'cross', 'injection')



 Comments   
Comment by Fabio B. Silva [ 10/Jun/13 ]

Could you please provide your entities ?

Thanks

Comment by Radoslaw Ejsmont [ 11/Jun/13 ]

This is the whole class hierarchy.

Comment by Radoslaw Ejsmont [ 11/Jun/13 ]

I have actually noticed, that the "partial" keyword is ignored even for entities that are not using any inheritance schema. So it seems that this keyword is generally ignored.

Right now the following query:

SELECT e, partial p.

{id}

, o, s FROM VIB\FliesBundle\Entity\StockVial e LEFT JOIN e.parent p LEFT JOIN e.position o LEFT JOIN e.stock s WHERE e.setupDate > :date AND e.trashed = false ORDER BY e.setupDate DESC ORDER BY e.id DESC

would result in the following SQL:

SELECT v0_.setupDate AS setupDate0, v0_.flipDate AS flipDate1, v0_.notes AS notes2, v0_.size AS size3, v0_.labelPrinted AS labelPrinted4, v0_.trashed AS trashed5, v0_.temperature AS temperature6, v0_.id AS id7, v1_.id AS id8, r2_.rackRow AS rackRow9, r2_.rackColumn AS rackColumn10, r2_.id AS id11, s3_.name AS name12, s3_.genotype AS genotype13, s3_.notes AS notes14, s3_.vendor AS vendor15, s3_.infoURL AS infoURL16, s3_.verified AS verified17, s3_.id AS id18, v0_.type AS type19, v0_.parent_id AS parent_id20, v0_.position_id AS position_id21, v0_.prevPosition_id AS prevPosition_id22, v0_.incubator_id AS incubator_id23, v0_.stock_id AS stock_id24, v1_.type AS type25, v1_.parent_id AS parent_id26, v1_.position_id AS position_id27, v1_.prevPosition_id AS prevPosition_id28, v1_.incubator_id AS incubator_id29, v1_.stock_id AS stock_id30, v1_.male_id AS male_id31, v1_.virgin_id AS virgin_id32, v1_.targetStock_id AS targetStock_id33, v1_.targetStockVial_id AS targetStockVial_id34, r2_.rack_id AS rack_id35, s3_.sourceCross_id AS sourceCross_id36 FROM Vial v0_ LEFT JOIN Vial v1_ ON v0_.parent_id = v1_.id AND v1_.type IN ('vial', 'stock', 'cross', 'injection') LEFT JOIN RackPosition r2_ ON v0_.position_id = r2_.id LEFT JOIN Stock s3_ ON v0_.stock_id = s3_.id WHERE (v0_.setupDate > '2013-04-11' AND v0_.trashed = 0) AND v0_.type IN ('stock') ORDER BY v0_.setupDate DESC, v0_.id DESC

Please note that ALL properties of parent have been included in the generated SQL.

You can find the whole project (Symfony2) on github: https://github.com/rejsmont/LabDB

Best,

R.

Comment by Radoslaw Ejsmont [ 11/Jun/13 ]

I have noticed that using the setHint(Doctrine\ORM\Query::HINT_FORCE_PARTIAL_LOAD, 1) forces partial load, however then even the entities I want loaded entirely (with proxied references) are partially loaded (i.e. all the references are forced to null, unless explicitly loaded via join).





[DDC-2452] Additional `WITH` condition in joins between JTI roots cause invalid SQL to be produced Created: 16/May/13  Updated: 27/Mar/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: Marco Pivetta Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: dql, sql-walker
Environment:

irrelevant



 Description   

Given a simple Joined Table Inheritance like following:

/**
 * @Entity @Table(name="foo") @InheritanceType("JOINED")
 * @DiscriminatorColumn(name="discr", type="string")
 * @DiscriminatorMap({"foo" = "DDC2452Foo", "bar" = "DDC2452Bar"})
 */
class DDC2452Foo
{
    /** @Id @Column(type="integer") @GeneratedValue */
    public $id;
}

/** @Entity @Table(name="bar") */
class DDC2452Bar extends DDC2452Foo
{
}

Following DQL

SELECT foo1 FROM DDC2452Foo foo1 JOIN DDC2452Foo foo2 WITH 1=1

Will produce broken SQL:

SELECT
    f0_.id AS id0, f0_.discr AS discr1 
FROM 
    foo f0_ 
LEFT JOIN bar b1_ 
    ON f0_.id = b1_.id 
LEFT JOIN foo f2_ 
LEFT JOIN bar b3_ 
    ON f2_.id = b3_.id 
    ON (1 = 1)

(please note the duplicate `ON` in the SQL)

That is caused because of the SQL walker producing the JTI filter with already the `ON` clause in it.

That happens because the JTI join conditions are added in https://github.com/doctrine/doctrine2/blob/2.4.0-BETA2/lib/Doctrine/ORM/Query/SqlWalker.php#L823-L825 (`walkRangeVariableDeclaration`), while the additional defined `WITH` conditions are considered in `walkJoinAssociationDeclaration` later on.

Added a test case and fix at https://github.com/doctrine/doctrine2/pull/668






[DDC-2411] Null values get reset when rehydrating an already managed entity Created: 23/Apr/13  Updated: 09/May/13

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

Type: Bug Priority: Major
Reporter: Simon Garner Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: hydration


 Description   

Scenario:

1) You have an entity with a ManyToOne relation (and probably other kinds too, but this is all I have tested) to another entity which is nullable. For example, let's say you have a Book entity which has an "illustrator" field which refers to a Person entity, representing the person who illustrated the book. If the book is not illustrated then you set the field to null.

2) You fetch a Book (by ID) which has its illustrator set to a particular Person.

3) You set that Book's illustrator to null.

4) Without flushing, you fetch the Book again, using different criteria: for example, by title. Because entities are Identity Mapped, this will run a query but then locate the same instance in memory, and try to hydrate that instance with the old data it just fetched.

5) Any fields on the instance that have modified values retain their new values (for example, if we changed the illustrator to a different Person, this would be retained), BUT any fields on the instance which are null get overwritten with the old data (so if we previously set the illustrator to null, without flushing, it would now be reset to the Person value that it had before).

There seems to be a mistaken assumption here that null values are fields that have not been hydrated, when this is not necessarily the case. Is this the intended behaviour?

The code that causes this behaviour is here: https://github.com/doctrine/doctrine2/blob/e561f47cb2205565eb873f0643637477bfcfc2ff/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php#L471

If you are wondering why anybody would want to fetch the entity again in step 4, my use case for this is the Symfony Validator (but I presume there could be others).

If there are any unique constraints (Symfony ones, not Doctrine ones) on the entity, e.g. if we had a unique constraint on the Book title field, then when validating the Book the Symfony Validator would check if there are already any Book entities with the same title as the Book we're validating. It will find the Book that we are working with, and because entities are identity mapped, it will act upon the same instance, and the situation above occurs.

Code example:

<?php

// Create some entities

$john = new Person();
$john->setName('John Smith');

$jane = new Person();
$jane->setName('Jane Jones');

$joe = new Person();
$joe->setName('Joe Bloggs');

$book = new Book();
$book->setId(123);
$book->setTitle('Book Title');
$book->setIllustrator($john);
$book->setAuthor($jane);

$em->persist($john);
$em->persist($jane);
$em->persist($joe);
$em->persist($book);
$em->flush();

// Now let's try modifying the book

$book = $bookRepository->find(123);
$book->getIllustrator(); // returns Person "John Smith"
$book->getAuthor(); // returns Person "Jane Jones"

// make some changes
$book->setIllustrator(null); // illustrator is now null
$book->setAuthor($joe); // author is now "Joe Bloggs"

// now validate our changes with Symfony Validator
// note: the same effect can also be observed with
// $test = $bookRepository->findBy('title', 'Book Title');
$validator->validate($book);

// what happened to our book??
$book->getIllustrator(); // returns Person "John Smith" <- should be null
$book->getAuthor(); // returns Person "Joe Bloggs" <- correctly retains the new value



 Comments   
Comment by Fabio B. Silva [ 24/Apr/13 ]

Hi Simon,

Could you please try to write a failing test case or paste your entities ?

Cheers

Comment by Benjamin Eberlei [ 09/May/13 ]

Verified by code review that this issue exists, but it will be very tricky to fix, because the null check is there for other reasons as well.





[DDC-2401] INDEX BY not working on multiple columns Created: 16/Apr/13  Updated: 18/Apr/13

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

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

Attachments: Zip Archive Testcase.zip    

 Description   

According to the docs on this page:
http://docs.doctrine-project.org/en/latest/reference/dql-doctrine-query-language.html#using-index-by

The following "multi-dimensional index" should be perfectly possible, with a default hydration mode:
SELECT b as business, p as product FROM Businesses b INDEX BY b.id JOIN Products p WITH b.id = p.businessid INDEX BY p.id

However, b.id is completely ignored (it is a numeric primary key).

I tried to go further, giving 2 products a matching barcode and indexing by barcode and then a (unique, numeric) productid. Only the barcode worked as a key and only one of the products with a matching barcode was selected. I used this query to test:
SELECT p FROM Products p INDEX BY p.barcode JOIN p.businessid b INDEX BY p.id

I also flagged the docs, because I don't think a userid should/could be starting from 0.



 Comments   
Comment by Fabio B. Silva [ 18/Apr/13 ]

Hi Quintenvk

Could you please try to write a failing test case ?

Thanks

Comment by Quintenvk [ 18/Apr/13 ]

I added a testcase. Please note that the database settings are to be configured in Core/simplys/simplys.php, and that the dump is in dummy.sql.

Apart from that all should run well immediately.

Comment by Quintenvk [ 18/Apr/13 ]

Fabio,

Please check the zip I just attached. I hope this helps you in finding the problem.

Thanks,
Quinten

Comment by Fabio B. Silva [ 18/Apr/13 ]

Thanks Quintenvk,

SELECT p.barcode, p.id, p.name FROM \core\Simplys\Entity\Products p INDEX BY p.barcode JOIN p.businessid b INDEX BY p.id

In this DQL you are trying to index by scalar values,
I think we does not support that, and a single dimensional array is the expected result in this case.

Also the INDEX BY documentations seems wrong to me.

The given DQL :

 SELECT u.id, u.status, upper(u.name) nameUpper FROM User u INDEX BY u.idJOIN u.phonenumbers p INDEX BY p.phonenumber 

Show the following result :

array
  0 =>
    array
      1 =>
        object(stdClass)[299]
          public '__CLASS__' => string 'Doctrine\Tests\Models\CMS\CmsUser' (length=33)
          public 'id' => int 1
          ..
      'nameUpper' => string 'ROMANB' (length=6)
  1 =>
    array
      2 =>
        object(stdClass)[298]
          public '__CLASS__' => string 'Doctrine\Tests\Models\CMS\CmsUser' (length=33)
          public 'id' => int 2
          ...
      'nameUpper' => string 'JWAGE' (length=5)

Which IMHO represents another DQL, something like :

 SELECT u, p , upper(u.name) nameUpper FROM User u INDEX BY u.id JOIN u.phonenumbers p INDEX BY p.phonenumber
Comment by Quintenvk [ 18/Apr/13 ]

Thanks for your reply Fabio.
Do you think there could be alternatives (apart from a foreach-loop) to achieve the expected result?

Thanks,
Quinten

Comment by Fabio B. Silva [ 18/Apr/13 ]

Not sure if it's exactly the result you need but you can try

Something like :

SELECT p, b FROM \core\Simplys\Entity\Products p INDEX BY p.barcode JOIN p.businessid b INDEX BY p.id

or something like :

SELECT PARTIAL p.{id, barcode, name}, b.{id, attributesYouNeed} FROM \core\Simplys\Entity\Products p INDEX BY p.barcode JOIN p.businessid b INDEX BY p.id

And than :

$result = $query->getArrayResult();
Comment by Quintenvk [ 18/Apr/13 ]

Both produce the same result as the query I had. I think i'll move on to loops after a bit more research, too bad it can't be done (at least for now) though... Would've been nice.

Thanks for your help though!





[DDC-2351] Entity Listener vs. Event Listener Created: 15/Mar/13  Updated: 15/Mar/13

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

Type: Improvement Priority: Major
Reporter: Fabian Spillner Assignee: Fabio B. Silva
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Entity Listener and Event Listener don't get same events. An example is the onFlush event, which Entity Listener doesn't get. Why are both listeners receiving different events and not same events?

For consistency I'd like to see that both get same events - if I understand the purpose of Entity Listener correctly: it should be an alternative to Event Listener with same functionality but is bound to an entity.



 Comments   
Comment by Benjamin Eberlei [ 15/Mar/13 ]

onFlush and postFlush should be propagated to entity listeners as well





[DDC-2337] Allow an entity to use its own persister to take advantage of DB level features if necessary Created: 06/Mar/13  Updated: 06/Mar/13

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

Attachments: Text File persister.patch    

 Description   

I have a situation where I wanted a single table to use INSERT DELAYED. Its an audit log table where I expect each http request to generate many inserts for. In an effort to not over tax the system I implemented a custom Entity Persister so that it would work. This obviously doesn't work with all mapping drivers. However if this is a feature that you think is worth integrating I will fork it on github and complete the implementation alongside any changes/improvements requested...






[DDC-2254] Exporting and restoring a query. Created: 23/Jan/13  Updated: 04/May/13

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

Type: Improvement Priority: Major
Reporter: Dries De Peuter Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dql, rebuild, restore, save
Environment:

OSX



 Description   

When you have a queryBuilder and you want to break it down using getDQLParts, You can't restore it by looping over the parts and adding them.

This is what I am doing:

$parts = $qb->getDQLParts();

// save the parts and use them in a different environment.

$newQb = $em->createQueryBuilder();
foreach ($parts as $name => $part) {
  $newQb->add($name, $part);
}


 Comments   
Comment by Dries De Peuter [ 23/Jan/13 ]

I wrote a test showing the issue.

https://github.com/NoUseFreak/doctrine2/commit/8574b79fd3d245532bbe7e310c5cbe083892057a

Comment by Benjamin Eberlei [ 04/May/13 ]

This is not a bug, because restoring queries is not yet a feature of the QueryBuilder. Marking as possible improvement for future.





[DDC-2248] Expire result cache functionality not implemented Created: 19/Jan/13  Updated: 19/Jan/13

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.3, 2.3.1, 2.3.2
Fix Version/s: None

Type: Documentation Priority: Major
Reporter: Piotr Niziniecki Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

According to documentation expireResultCache, should force cache to update but it's not working... Why? Because functionality is not implemented. You can set _expireResultCache variable, but there is no place where this variable is being checked.



 Comments   
Comment by Marco Pivetta [ 19/Jan/13 ]

A cache profile can be set and cleaned. I suppose that `expireResultCache` is an old piece of code that survived the refactoring. Should just be removed and documented accordingly





[DDC-2239] Allow dynamic modification of select queries (either filter the AST or query) Created: 11/Jan/13  Updated: 11/Jan/13

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


 Description   

I had built and used the following for doctrine 1: http://web.archive.org/web/20110705035547/http://www.doctrine-project.org/projects/orm/1.2/docs/cookbook/record-based-retrieval-security-template/en#record-based-retrieval-security-template

I'd like to build something similar for D2 based projects.

ocramius in IRC suggested a bug report/Improvement request. Figured that perhaps a custom event "dql_parse" or "ast_render" passing the AST or Query as a parameter.

I'm under a tight timeline and am willing to pay for aid/feature implementation.






[DDC-2223] unable to use scalar function when a scalar expression is expected Created: 04/Jan/13  Updated: 04/Jan/13

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

Type: Bug Priority: Major
Reporter: Alexis Lameire Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dql
Environment:

(not affected by this bug)



 Description   

the DQL Parser don't parse properly functions when a ScalarExpression is needed like of all case functions.

In fact first function token is interpreted as a T_IDENTIFIER and enter on line 1663 of Doctrine\ORM\Query\Parser class. in search of math operator, when not found this case considere that the token is a row element with no considération of the functions procession treated after.

fix of this bug consist to enclose the line 1672 by a if (!$this->_isFunction()).






[DDC-2219] computeChangeSets array_merging for associationMappings problem ? Created: 02/Jan/13  Updated: 07/Jan/13

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

Type: Documentation Priority: Major
Reporter: yohann.poli Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: unitofwork


 Description   

Is this normal that when i call "$changeset = $unitOfWork->getEntityChangeSet($myObject);", it only return changes of root Object, all changes in sub collection (OneToMany) are less (not merging in the changeset) ?

Is there an issue for that?



 Comments   
Comment by Marco Pivetta [ 02/Jan/13 ]

Changesets of collections are computed separately from those of entities.

Comment by yohann.poli [ 02/Jan/13 ]

Have to call the compute method for each collection of the entity ?

Comment by Benjamin Eberlei [ 06/Jan/13 ]

Yes you have to, but this kind of operation seems weird. What are you trying to achieve.

Comment by yohann.poli [ 07/Jan/13 ]

I manage a complex entity who have a collection entity (each entity in this collection have another collection entity) attributes and i need to now if the flush method has "really" execute an update.

For example if the level 3 entity is update, i have to know in the root entity all changes apply in child...





[DDC-2190] findBy() support finding by a single DateTime but not by multiple DateTime Created: 06/Dec/12  Updated: 09/May/13

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

Type: Bug Priority: Major
Reporter: Christophe Coevoet Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Attachments: File DDC2190Test.php    

 Description   

The following code works:

$repository->findBy(array('date' => new \DateTime()))

but the following code fails as it does not apply the conversion of the date type for each element:

$repository->findBy(array('date' => array(new \DateTime(), new \DateTime('tomorrow')))


 Comments   
Comment by Benjamin Eberlei [ 06/Jan/13 ]

This is actually very hard to implement, the problem is that we only have ARRAY constants for PDO::PARAM_INT and PDO::PARAM_STR - all the other types would require special handling.

Comment by Benjamin Eberlei [ 09/May/13 ]

Attaching failing testcase.

The idea is to have something like "datetime[]" as type and detect this in the SQLParserUtils of DBAL.

Another approach would be to convert the values in the ORM already, before passing to the DBAL.





[DDC-2185] Better explain DQL "WITH" and implications for the collection filtering API Created: 04/Dec/12  Updated: 17/Dec/12

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

Type: Documentation Priority: Major
Reporter: Matthias Pigulla Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: collection, documentation, dql, filtering


 Description   

Available documentation is a bit thin regarding the "WITH" clause on JOIN expressions. Only a single example is provided in

http://docs.doctrine-project.org/en/2.1/reference/dql-doctrine-query-language.html#dql-select-examples

WITH seems to allow to only "partially" load a collection, so the collection in memory does not fully represent the associations available in the database.

The resulting collection is marked as "initialized" and it seems there is no way to tell later on whether/how (with which expression) the collection has been initialized.

When using the collection filtering API, the "initialized" flag on the collection will lead to in-memory processing. If a collection has been loaded WITH a restricting clause and another filter is applied later, results may not be what one might expect.

I assume this is by design (no idea how the collection could be "partially" loaded and behave correctly under all conditions), so filing it as a documentation issue.



 Comments   
Comment by Matthias Pigulla [ 17/Dec/12 ]

An additional observation:

If you eager-load a collection using WITH, for the resulting entities that collection is marked as initialized as described above.

Should you happen to come across the same entity during hydration in another (later) context where you explicitly eager load the same association without the WITH restriction (or with another one), the collection on that (existing) entity won't be re-initialized and still contains the associated objects found during the first query.





[DDC-2166] Improve Identifier hashing in IdentiyMap Created: 25/Nov/12  Updated: 25/Nov/12

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


 Description   

There are currently some drawbacks with identifier hashing:

  • They only work on one level for derived keys
  • The code is suspect to high performance requirements
  • Composite Keys might be suspect to weird bugs if they contain spaces.

There is a PR by goetas (https://github.com/doctrine/doctrine2/pull/232) that solves some issues, however adds a performance hit.

We should move the conditional logic of this code out and use a strategy pattern to improve both performance and robustness of this code.






[DDC-2154] Traits and Code Generation Created: 18/Nov/12  Updated: 18/Nov/12

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


 Description   

See https://github.com/doctrine/DoctrineBundle/issues/106#issuecomment-10479116






[DDC-2119] Problem with inheritance type: INHERITANCE_TYPE_NONE and INHERITANCE_TYPE_TABLE_PER_CLASS Created: 03/Nov/12  Updated: 08/Apr/13

Status: Open
Project: Doctrine 2 - ORM
Component/s: DQL, Tools
Affects Version/s: 2.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: SergSW Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dql, schematool

Attachments: File dump.sql     File SSWTestBundle.rar    

 Description   

I tried to create inheritance entities with save policy table per class.
Simple fileds was created normally, but a field with ManyToOne type was lost.

I had found a solution.

In Doctrine\ORM\Tools\SchemaTool
...

private function _gatherRelationsSql($class, $table, $schema)
    {
        foreach ($class->associationMappings as $fieldName => $mapping) {

           // if (isset($mapping['inherited'])) { // - old version

	/**
             * SSW
             * It's the solution
             */
	if (isset($mapping['inherited']) && !$class->isInheritanceTypeNone() && !$class->isInheritanceTypeTablePerClass() ) {
                continue;
            }            

            $foreignClass = $this->_em->getClassMetadata($mapping['targetEntity']);
...

But it was enough. In DQL query a simple query was made wrong.

I had found a solution again.
In Doctrine\ORM\Query\SqlWalker
...

public function walkSelectExpression($selectExpression)
...

                // original => if (isset($mapping['inherited'])){
                // It's the solution
                if (isset($mapping['inherited']) && !$class->isInheritanceTypeNone() && !$class->isInheritanceTypeTablePerClass()) {
                    $tableName = $this->_em->getClassMetadata($mapping['inherited'])->table['name'];
                } else {
                    $tableName = $class->table['name'];
                }
...

This problems are topical for inheritance type: INHERITANCE_TYPE_NONE and INHERITANCE_TYPE_TABLE_PER_CLASS.

I don't know, may be my solutions are wrong. But some programmers want to correctly work with INHERITANCE_TYPE_TABLE_PER_CLASS.

Sorry for my english.



 Comments   
Comment by Fabio B. Silva [ 05/Nov/12 ]

Hi SergSW

Could you try to write a failing test case ?

Thanks

Comment by SergSW [ 06/Nov/12 ]

SSW/TestBundle with the problem

Comment by SergSW [ 07/Nov/12 ]

I install the Symfony v2.0.18. and made small TestBundle.
I made schema database, by CLI "console doctrine:schema:update --force"
Result: Database schema updated successfully!
But I saw that I lost a field 'user_id' in a table 'AttachTree' (see Attach)

Comment by SergSW [ 07/Nov/12 ]

MySQL dump

Comment by Benjamin Eberlei [ 12/Nov/12 ]

Adjusted example formatting, don't apologize for your English, thanks for the report!

Comment by Benjamin Eberlei [ 24/Dec/12 ]

What version of 2.1 are you using? We don't actually support 2.1 anymore. Inheritance has always worked as used in hundrets of unit-tests, this changes look quite major a bug to have been missed before. I can't really explain whats happening here.

Comment by Marco Pivetta [ 23/Jan/13 ]

SergSW news?





[DDC-2104] BasicEntityPersister::load() doesn't allow for cache usage Created: 25/Oct/12  Updated: 12/Nov/12

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

Type: New Feature Priority: Major
Reporter: Dan McFaul Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None
Environment:

This is a new feature, not a bug



 Description   

BasicEntityPersister::load() calls:
$stmt = $this->_conn->executeQuery($sql, $params, $types);
on line 665 of master/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php

The executeQuery function has an optional fourth parameter to pass a QueryCacheProfile variable to use caching on the query. This is ignored/not implemented by BasicEntityPersister::load()






[DDC-2102] Make optional SubselectFromClause Created: 25/Oct/12  Updated: 25/Oct/12

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: Martin Hasoň Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Subselect ::= SimpleSelectClause [SubselectFromClause] [WhereClause] [GroupByClause] [HavingClause] [OrderByClause]






[DDC-2100] Getting Started: Code First PHP fatal error:Call to undefined method Bug::setDescription() Created: 24/Oct/12  Updated: 24/Oct/12

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

Type: Documentation Priority: Major
Reporter: bronze1man Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

ubuntu 1204 php5.3.8



 Description   

http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/tutorials/getting-started.html
in file create_bug.php
$bug->setDescription("Something does not work!");
but the class Bug do not have setDescription function.

ps:
try find "setDescription" on that page. there is only one .






[DDC-2087] Select colum Hydration Created: 18/Oct/12  Updated: 18/Oct/12

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

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


 Description   

Simple way to select colum
for example I want select id's of entity's to save in cache or in other select query
Or i vant select one distinct field.

SELECT u.id FROM User as u

getResult give

array(
0=>array('id' => 1),
1=>array('id' => 2),
)

but how can take this

array(
0=> 1,
0=> 2,
)



 Comments   
Comment by Ivan Borzenkov [ 18/Oct/12 ]

for example

http://stackoverflow.com/questions/11327798/change-the-getresult-array-key-for-the-primary-key-value

this code would be good add in library
(and array key maybe too )





[DDC-2043] Extra cache operation in DBAL\Cache\ResultCacheStatement.php Created: 26/Sep/12  Updated: 26/Sep/12

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

Type: Improvement Priority: Major
Reporter: Bogdan Albei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

CentOS, PHP 5.3.10



 Description   

This is the closeCursor() method in DBAL\Cache\ResultCacheStatement.php:

public function closeCursor()
    {
        $this->statement->closeCursor();
        if ($this->emptied && $this->data !== null) {
            $data = $this->resultCache->fetch($this->cacheKey);
            if ( ! $data) {
                $data = array();
            }
            $data[$this->realKey] = $this->data;

            $this->resultCache->save($this->cacheKey, $data, $this->lifetime);
            unset($this->data);
        }
    }

We are using Memcache and I noticed an extra GET operation on all cache misses. In the code above I believe the fetch call is not necessary and that the code would do the same without it.
Also, may I ask why is the SQL used as a key in the cached data?



 Comments   
Comment by Christophe Coevoet [ 26/Sep/12 ]

The SQL is used as a key because it is what identifies the query which is done (well, the statement and the parameters)

Comment by Bogdan Albei [ 26/Sep/12 ]

The cacheKey already identifies the query(or at least it should). Would we have cases where different queries would want to use the same cache key?





[DDC-2042] Metadata association overriding : allow to override 'targetEntity' Created: 26/Sep/12  Updated: 31/Mar/14

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

Type: Improvement Priority: Major
Reporter: Charles Rouillon Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

While associating object to an descriminated table I wasn't enable to fix the entityTarget (only one can be set in entity annotation).

It could be resolve by adding the possibility to override 'targetEntity' value in Doctrine\ORM\Mapping\ClassMetadataInfo::ClassMetadataInfo().

Such as :

if (isset($overrideMapping['targetEntity'])) {
$mapping['targetEntity'] = $overrideMapping['targetEntity'];
}

That would need to add a control on the new targetEntity in Doctrine\ORM\Mapping\ClassMetadataInfo::_validateAndCompleteAssociationMapping().

Such as :

if ( ! ClassLoader::classExists($mapping['targetEntity']) ) {
throw MappingException::invalidTargetEntityClass($mapping['targetEntity'], $this->name, $mapping['fieldName']);
}

cro.



 Comments   
Comment by Oleg Namaka [ 31/Mar/14 ]

We need this feature too. Why is this ticket in a limbo? Someone please add a comment whether this will be fixed.

Comment by Marco Pivetta [ 31/Mar/14 ]

Oleg Namaka you can open a pull request with a test and suggested improvement for this at https://github.com/doctrine/doctrine2





[DDC-2007] [GH-434] allowed to pass filter objects to the configurator Created: 31/Aug/12  Updated: 18/Dec/13

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

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


 Description   

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

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

Message:

If DDC-2004 gets approved.



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

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





[DDC-1999] Lazy loading doesn't get the field type when generating sql Created: 29/Aug/12  Updated: 29/Aug/12

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


 Description   

When calling with lazy loading the Sql generated doesn't convert the parameters according to their types. After debugging the problem I found that the problem is in the getType($field, $value) function in the BasicEntityPersister as it is it will never be able to return the filed type when called for lazy loading for oneToMany or ManyToMany. I put a quick fix for my self

 private function getType($field, $value)
    {

        switch (true) {
           //here we have original code
            default:

            	$type = null;
               // my fix starts here
            	$fieldParts = explode('.', $field);
            	if (count($fieldParts > 1)) {
	            	foreach ($this->_class->associationMappings as $mapping) {
						if (isset($mapping['joinColumnFieldNames'][$fieldParts[1]])) {
							$targetClass  = $this->_em->getClassMetadata($mapping['targetEntity']);

							if (isset($targetClass->fieldNames[$fieldParts[1]])) {
								$type = $targetClass->fieldMappings[$targetClass->fieldNames[$fieldParts[1]]]['type'];
							}

							break;
						}
	            	}
            	}
//my fix end here
        }

       //here we have original code

        return $type;
    }


i have only added that check in the default case of the switch. I am not sure if that is the most elegant way. I hope that helps and that it will be fixed soon. Thanks for the great work .



 Comments   
Comment by Benjamin Eberlei [ 29/Aug/12 ]

Fabio B. Silva Guilherme Blanco do we have a current best practice/policy regarding casting of join column types? There are some issues regarding it, this is another one.

Comment by Guilherme Blanco [ 29/Aug/12 ]

We avoid the manual breakdown of path expressions.
Also, in BasicEntityPersister it is done behind the scenes and can get into weird scenarios. Personally speaking, I don't see how we can easily fix this issue.





[DDC-2002] [GH-432] Add DBAL\TypeAwareObject type inference. Created: 29/Aug/12  Updated: 27/Nov/13

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

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


 Description   

This issue is created automatically through a Github pull request on behalf of Romain-Geissler:

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

Message:

DBAL allows you to define custom field types for your entities, and those are seamlessly converted from PHP to SQL value. However, you can't those custom types as parameters without type hinting it :

```php
$qb->select('e')
->from('Entity', 'e')
->where('e.customField = :customFieldValue')
->setParameter('customFieldValue',$customFieldValue,$customFieldDBALType);
//this third argument is for now compulsory
:
```

In my case, ``$customFieldValue`` is an object that won't work well if converted with the default string type. I added a new DBAL interface (see doctrine/dbal#193 ) and tweaked the parameter type inference so that custom values can advertise their DBAL type.

There is currently no way to dynamically override the parameter type inference logic, this is one design that allows it in some cases.



 Comments   
Comment by Benjamin Eberlei [ 30/Aug/12 ]

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

Comment by Doctrine Bot [ 27/Nov/13 ]

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





[DDC-1991] Add parameter indexBy to EntityRepository->createQueryBuilder() Created: 20/Aug/12  Updated: 20/Aug/12

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

Type: Improvement Priority: Major
Reporter: Philipp Cordes Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

createQueryBuilder() currently doesn’t have a parameter to set the third option on the FROM fragment: indexBy. Right now you have to read it, create a new From with the read properties and your desired indexBy value and replace the existing one on the QueryBuilder.

Should be ten minutes’ work including tests. Thanks a lot!






[DDC-1971] [GH-419] Add ODM embedded-like functionality Created: 07/Aug/12  Updated: 20/Dec/13

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

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


 Description   

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

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

Message:

This PR adds ODM embedded-like functionality to the ORM.

Including the new @MappedAssociation annotation on a field having a one-to-one association adds a discriminator column to the table for storing the class name of a "mapped" entity.

This allows a class or mapped superclass with a one-to-one identifying association to be extended by additional entities without requiring any code changes (as is required with the discriminator map when using inheritance).

I apologize if this is the incorrect way to submit a feature request. Currently just the annotation driver has been updated, I wanted to get feedback before continuing with the remaining drivers. Models and tests are included.



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

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





[DDC-1960] mapping joins in native queries breaks if select columns are starting with columns from joined table Created: 31/Jul/12  Updated: 21/Nov/12

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

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

ubuntu kernel 2.6.32-40-server
php 5.3.10-1ubuntu2ppa6~lucid with Suhosin-Patch (cli)
apache 2 2.2.14-5ubuntu8.9
postgres 9.1.4-1~lucid4


Attachments: Zip Archive testcase.zip    

 Description   

Using a simple Testcase like in http://docs.doctrine-project.org/projects/doctrine-orm/en/2.1/reference/native-sql.html there are two Tables:

*) users:

   Column   |  Type   | Modifiers | Storage  | Description 
------------+---------+-----------+----------+-------------
 u_id       | integer | not null  | plain    | 
 u_name     | text    | not null  | extended | 
 address_id | integer | not null  | plain    | 

*) address:

  Column  |  Type   | Modifiers | Storage  | Description 
----------+---------+-----------+----------+-------------
 a_id     | integer | not null  | plain    | 
 a_street | text    | not null  | extended | 
 a_city   | text    | not null  | extended | 

address_id is a foreign key to address;

Now i created the Entities and setup a native query using ResultSetMappingBuilder:

$rsm = new \Doctrine\ORM\Query\ResultSetMappingBuilder($entityManager);
$rsm->addRootEntityFromClassMetadata('MyProject\Entity\Users', 'u');
$rsm->addJoinedEntityFromClassMetadata('MyProject\Entity\Address', 'a', 'u', 'address');

$query = '
    SELECT
        u.*,
        a.*
    FROM
        users u
    LEFT JOIN address a ON (u.address_id = a.a_id)
';

/** @var $native \Doctrine\ORM\NativeQuery */
$native = $entityManager->createNativeQuery($query, $rsm);

$ret = $native->getResult();

This returns the Entities correctly:

array(2) {
  [0] =>
  class MyProject\Entity\Users#61 (3) {
    protected $id =>
    int(1)
    protected $name =>
    string(5) "Smith"
    protected $address =>
    class MyProject\Entity\Address#63 (4) {
      protected $id =>
      int(1)
      protected $street =>
      string(8) "Broadway"
      protected $city =>
      string(8) "New York"
      protected $users =>
      class Doctrine\ORM\PersistentCollection#64 (9) {
        ...
      }
    }
  }
  [1] =>
  class MyProject\Entity\Users#66 (3) {
    protected $id =>
    int(2)
    protected $name =>
    string(7) "Sherlok"
    protected $address =>
    class MyProject\Entity\Address#67 (4) {
      protected $id =>
      int(2)
      protected $street =>
      string(13) "Oxford Street"
      protected $city =>
      string(6) "London"
      protected $users =>
      class Doctrine\ORM\PersistentCollection#68 (9) {
        ...
      }
    }
  }
}

BUT if you change the order of the select columns starting with ones from address you get borked Data:

$query = '
    SELECT
        a.*,
        u.*
    FROM
        users u
    LEFT JOIN address a ON (u.address_id = a.a_id)
';
array(2) {
  [0] =>
  class MyProject\Entity\Users#61 (3) {
    protected $id =>
    int(1)
    protected $name =>
    string(5) "Smith"
    protected $address =>
    class MyProject\Entity\Address#63 (4) {
      protected $id =>
      int(2)
      protected $street =>
      string(13) "Oxford Street"
      protected $city =>
      string(6) "London"
      protected $users =>
      class Doctrine\ORM\PersistentCollection#64 (9) {
        ...
      }
    }
  }
  [1] =>
  class MyProject\Entity\Users#66 (3) {
    protected $id =>
    int(2)
    protected $name =>
    string(7) "Sherlok"
    protected $address =>
    NULL
  }
}

This happens because the function Doctrine\ORM\Internal\Hydration\AbstractHydrator::_gatherRowData does not consider the Mapping i set up. Instead it just add the columns as they get starting with address ones.

Doctrine\ORM\Internal\Hydration\ObjectHydrator::_hydrateRow then knows the Mapping and ignores the first Address as there is no User to map on, cycling to the next row will then add the address of the second row to the user from the first one.

There are multiple ways to fix this. One would be to consider the mapping in _gatherRowData, the second to rewrite the _hydrateRow generating the Entities first and then the mapping in a second foreach loop.

This bugger had me for 2 days until i finally figured it out.

thanks



 Comments   
Comment by Frederic [ 21/Nov/12 ]

Hello,

Has same issue with using DQL /createQuery() ! Try all the day to find where was my mistake but seems to be a CRITICAL bug !
How did you solve this ?

Doctrine version used : 2.3.1-DEV

<code>
$query = $this->getEntityManager()->createQuery("
SELECT cc, oc
FROM category cc
JOIN cc.offer_category oc
WHERE cc.catalog = :catalog_id
ORDER BY oc.name ASC
")
->setParameter(":catalog_id", $catalog_id)
;

</code>

Problem is that the order of the Aliases (cc, oc) is not considered on building SQL .
In my case, in the ObjectHydrator::hydrateRowData method :

$rowData = $this->gatherRowData($row, $cache, $id, $nonemptyComponents);

returns

Array
(

[oc] => Array
(
[id] => 14
[name] => toto
)
[cc] => Array
(
[catalog_id] => 1
[offer_category_id] => 14
)
)

As "oc" is a mapping, on the first loop the $parentAlias is not yet known and so :
<code>
if ($this->_rsm->isMixed && isset($this->_rootAliases[$parentAlias]))

{ echo "parentObject 1\n"; $first = reset($this->_resultPointers); $parentObject = $first[key($first)]; }

else if (isset($this->_resultPointers[$parentAlias]))

{ echo $parentAlias." parentObject 2\n"; $parentObject = $this->_resultPointers[$parentAlias]; }

else

{ // HERE : on first loop, for "oc", parent not yet known so skipped !!! continue; }

</code>

using a workaround on ObjectHydrator::hydrateRowData like this :
$rowData = array_reverse($rowData);

make it work...

Sorry for my dirty explanation...





[DDC-1965] Multiple Index fails if index name not specified Created: 02/Aug/12  Updated: 02/Aug/12

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

Type: Bug Priority: Major
Reporter: Pont Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: Cli
Environment:

Ubuntu 11.04, PHP 5.3.6 with Suhosin-patch, Symfony 2.0.15



 Description   

@ORM\Table(name="applications", indexes={@ORM\Index(name="csl_idx", columns=

{"createdAt", "status", "loanType"}), @ORM\Index(name="s_idx", columns={"status"}), @ORM\Index(name="l_idx", columns={"loanType"})})

the above Annotation creates 3 different indexes BUT when:
* @ORM\Table(name="applications", indexes={@ORM\Index(columns={"createdAt", "status", "loanType"}

), @ORM\Index(columns=

{"status"}

), @ORM\Index(columns=

{"loanType"}

)})

index-names not specified Symfony2 schemaUpdate tools shows only the last Index






[DDC-1957] DB -> Entity: Reverse engeniering with two relations between two tables Created: 29/Jul/12  Updated: 29/Jul/12

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

Type: Bug Priority: Major
Reporter: sky diablo Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: Cli
Environment:

windows 7, php 5.3, symfony 2.1



 Description   

i use the cli from the symfony 2.1 project to reverse from DB to Entity:

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

and i get tis error:

[Doctrine\ORM\Mapping\MappingException]
Property "radUser" in "RadAttribute" was already declared, but it must be declared only once

so i have a table "radUser" with two m:n relations to the same table "radAttributes":

Table radUser:
check => radAttributes
reply => radAttributes

so doctrine reverse mapping try to generate the radAttribute entity with two mapping to radUser with the same field name "radUser", what can i do to prevent this issue ?






[DDC-1954] Specialized Batch Insert Mode for the Entity Manager Created: 29/Jul/12  Updated: 16/Apr/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: Johannes Schmitt Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

While it is already possible to speed up batch inserts by using raw SQL, that has the disadvantage to maintain a separate set of code that needs to be kept in sync with your schema.

Therefore, it would be nice if the entity manager would provide a special batch insert mode where it can skip the change tracking related features, collection snapshots, etc. This might already be good enough for many people.






[DDC-1947] Update EBNF with arbitrary joins Created: 26/Jul/12  Updated: 26/Jul/12

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

Type: Documentation Priority: Major
Reporter: Marco Pivetta Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Arbitrary joins need to be documented in EBNF






[DDC-1938] [GH-406] [WIP] - DCOM-96 - Moving proxy generation and autoloading to common Created: 21/Jul/12  Updated: 09/Nov/13

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


 Description   

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

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

Message:

This PR is related to doctrine/common#168.

In this PR, the `ProxyFactory` has been reduced to an object builder and it's public API has been kept intact (While the proxy `Autoloader` has been moved to doctrine/common). It would be interesting to define what this builder could do with the `ProxyFactory` to get its own customizations introduced.



 Comments   
Comment by Benjamin Eberlei [ 25/Jan/13 ]

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

Comment by Benjamin Eberlei [ 26/Jan/13 ]

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

Comment by Doctrine Bot [ 09/Nov/13 ]

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





[DDC-1923] Type conversion error with oracle Created: 12/Jul/12  Updated: 12/Jul/12

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: Alexander Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None


 Description   

https://github.com/symfony/symfony/pull/4730






[DDC-1894] Cannot view Doctrine 2.2 QueryBuilder documentation Created: 27/Jun/12  Updated: 27/Jun/12

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

Type: Documentation Priority: Major
Reporter: Douglas Teoh Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Chrome, Firefox, Safari on OS X



 Description   

Visiting the following page:

http://www.doctrine-project.org/api/orm/2.2/class-Doctrine.ORM.QueryBuilder.html

always redirects back to http://www.doctrine-project.org/api/orm/2.2/






[DDC-1899] [GH-385] set metadata for interface to be able to fetch entites by interface name Created: 29/Jun/12  Updated: 13/Nov/13

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


 Description   

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

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

Message:

using the new ResolveTargetEntity functionality we noticed we needed another feature:

From the Symfony Bundle defining the interface, we'd like to be able to fetch entities by this very interface name, e.g.:

``` php
$em->find('Foo\BarBundle\Entity\PersonInterface', 1);
```

or

``` php
$em->getRepository('Foo\BarBundle\Entity\PersonInterface')->findAll();
```

This PR sets metadata for the interface when metadata for a class is loaded that the interface is configured for



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

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





[DDC-1882] AbstractQuery#getResultCacheId() should be public to be able to manage the cache Created: 19/Jun/12  Updated: 19/Jun/12

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

Type: Improvement Priority: Major
Reporter: Ignacio Larranaga Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File AbstractQuery.patch    

 Description   

The method getResultCacheId of Doctrine\ORM\AbstractQuery should be public.

I'm trying to customize the cache refresh mechanism to clear previously cached objects in my app.
To do that I'm adding a prefix to define regions in the cache.
To be able to set the Id's correctly (adding region prefixes) I need to get the "normal" hash doctrine were used in the normal scenario (trying to avoid introduce new code).
That's why I will prefer the method to be public.



 Comments   
Comment by Ignacio Larranaga [ 19/Jun/12 ]

Attaching the patch despite is a trivial change.





[DDC-1860] Make usage of Composer for CLI optional Created: 09/Jun/12  Updated: 09/Jun/12

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


 Description   

There's two problems with current CLI implementation:

1 - composer `autoload.php` file is hardcoded, which means that it is making assumptions about where `doctrine/orm` has been installed, and it also makes the assumption that `doctrine/orm` is not the main package.
2 - composer is a requirement, while requiring it should just fail silently and allow the end user to use his own autoloading strategy



 Comments   
Comment by Marco Pivetta [ 09/Jun/12 ]

Merged at https://github.com/doctrine/doctrine2/pull/365





[DDC-1859] Implement console command to convert DQL into object running NativeQuery Created: 08/Jun/12  Updated: 08/Jun/12

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

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


 Description   

As per our conversation during SFLive Paris 2012, we should create a command that receives a DQL and exposes back to you a PHP code of an object holding a conversion to NativeQuery, which is faster.






[DDC-1829] [GH-352] Add the posibility to add a custom Comparator for Schema tool Created: 21/May/12  Updated: 22/May/12

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


 Description   

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

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

Message:

See catacgc/dbal#153






[DDC-1806] DQL with and without fetch join cause Created: 01/May/12  Updated: 01/May/12

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

Type: Bug Priority: Major
Reporter: Marco Pivetta Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Attachments: File DDC1806Test.php     GZip Archive gist2473775-d202a38fdfb91921ef010df36322fb646561593a.tar.gz    

 Description   

When running following DQL in newly cleared EntityManager, with the provided entities (see attached archive or gist at https://gist.github.com/2473775 ), results in different fetched association:

DQL without join:
SELECT a FROM Entity\A a WHERE a.id = :id

SQL without join:
SELECT a0_.a_id AS a_id0, a0_.id AS id1 FROM a a0_ WHERE a0_.a_id = ?

Result without join:
$query->getOneOrNullResult()>getB()>getName(); // 'correct'

DQL with fetch join:
SELECT a, b FROM Entity\A a LEFT JOIN a.b b WHERE a.id = :id

SQL with fetch join:
SELECT a0_.a_id AS a_id0, b1_.id AS id1, b1_.name AS name2, a0_.id AS id3 FROM a a0_ LEFT JOIN b b1_ ON a0_.id = b1_.id WHERE a0_.a_id = ?

Result with fetch join:
$query->getOneOrNullResult()>getB()>getName(); // 'wrong' (different result)

The problem seems to be strictly related with how the `@JoinColumn` is configured.



 Comments   
Comment by Marco Pivetta [ 01/May/12 ]

Attaching failing test from https://github.com/Ocramius/doctrine2/compare/DDC-1806





[DDC-1814] Save quoted info in ClassmetadataInfo#quotedColumns instead of ClassmetadataInfo#fieldmappings['fieldname']['quoted'] Created: 06/May/12  Updated: 06/May/12

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


 Description   

Similar to DDC-1813 I propose saving 'quote' status in ClassmetadataInfo#quotedColumns instead of ClassmetadataInfo#fieldmappings['fieldname']['quoted']

Otherwise you have quotation info only for fieldColumns and not association columns






[DDC-1813] Save column types in ClassMetadataInfo#columnTypes array instead of ClassMetadataInfo#fieldMappings['type'] Created: 06/May/12  Updated: 06/May/12

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


 Description   

Because you save column types in fieldmappings only, type information is not saved for join columns.

Not having type info for join columns, makes it impossible to do call 'convertToPhpValue' on join columns.

For example see a demo of problem here:
https://github.com/doctrine/doctrine2/pull/347






[DDC-1812] Modify ResultSetMapping#addMetaResult function definition Created: 06/May/12  Updated: 06/May/12

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

Type: Improvement Priority: Major
Reporter: ross neacoders Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Give correct names to arguments

    public function addMetaResult($alias, $columnName, $fieldName, $isIdentifierColumn = false)
    {

$alias - should be $tableAlias
$columnName should be $columnAlias
$fieldName should be $columnName

Here are some exmple calls from code:
AbstractEntityInheritancePersister.php
79: $this->_rsm->addMetaResult('r', $columnAlias, $joinColumnName);
SqlWalker.php
$this->_rsm->addMetaResult($dqlAlias, $columnAlias, $discrColumn['fieldName']);
$this->_rsm->addMetaResult($dqlAlias, $columnAlias, $srcColumn, (isset($assoc['id']) && $assoc['id'] === true));
$this->_rsm->addMetaResult($dqlAlias, $columnAlias, $srcColumn);






[DDC-1820] [GH-348] [DDC-1819][WIP] Arbitrary object hydrator Created: 14/May/12  Updated: 27/May/12

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


 Description   

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

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

Message:

Initial work (in progress) on a test suite for the arbitrary object hydrator, as discussed in DDC-1819[1]. Any tips are appreciated. I'm not too sure what the test suite should and should not cover.

Other questions I have include:

1. Should the `HYDRATE_ARBITRARY_OBJECT` constant be added to the `AbstractQuery` class or the `NativeQuery` class? It only makes sense in the former but it might be missed when more constants are added in the future...
2. Should I use data providers in my tests for the result set data?
3. Should my tests be added to a `DDC1819` namespace?
4. Should I add functional tests?

[1]: http://www.doctrine-project.org/jira/browse/DDC-1819






[DDC-1785] Paginator problem with SQL Server around DISTINCT keyword. Created: 18/Apr/12  Updated: 19/Jan/13

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

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


 Description   

PDOException: SQLSTATE[42000]: [Microsoft][SQL Server Native Client 10.0][SQL Server]Incorrect syntax near the keyword 'DISTINCT'. (uncaught exception)



 Comments   
Comment by Craig Mason [ 18/Oct/12 ]

There are four major issues with this:

1: SQLServerPlatform.php modifies the query to prepend 'SELECT ROW_NUMBER() OVER ($over)', which is inserted before the DISTINCT keyword.

2: The order needs to be placed inside the OVER($over) block. At this point, the regex is using the exact column name rather than the alias, so the outer query cannot ORDER.

3: The DISTINCT queries select only the ID columns - as OVER() required the sort column to be available in the outer query, IDs alone will not work.

4: SQL Server cannot DISTINCT on TEXT columns. 2005,2008 and 2012 recommend using VARCHAR(MAX) instead, which does support it. That doesn't help us with 2003. We work around that with a custom TEXT type that casts as varchar.

Incidentally, 2012 supports LIMIT, which gets rid of this issue altogether.

Edit: Added #3

Comment by Craig Mason [ 18/Oct/12 ]

I have a (very hacky) implementation working that uses regexes to correct the query so that it will execute. This also required modification in the ORM paginator, to select all columns instead of just IDs.

https://github.com/CraigMason/dbal/commit/4ecd018c73e387904f78d81f1d327e34e905c5f1
https://github.com/CraigMason/doctrine2/commit/b416d3b2a38495e4435bde872b19fec371fe5657

This is certainly not a patch - more guidance.

One interesting point... I had to wrap the whole query in a second SELECT *, as the WHERE IN confusingly returns non-distinct rows when part of the first inner query. No idea why this happens, but moving it out one layer makes it operate correctly.

Comment by Craig Mason [ 25/Oct/12 ]

Updated, view all commits for this experimental branch here:

https://github.com/CraigMason/dbal/commits/mssql-distinct

Comment by Craig Mason [ 29/Oct/12 ]

This got waaaay too messy with regex alone due to the complicated nesting. As such, I have written the basis of a new SqlWalker class which can be used to create DISTINCT queries based on the root identifiers. It's not proper DISTINCT support, but it's a step forward.

https://github.com/CraigMason/DoctrineSqlServerExtensions

I've also added a Paginator (which was the original issue I had!)

The current SqlWalker always sticks the ORDER BY on the end of the query, which just doesn't work properly with SqlServer. Is a vendor-specific walker breaking the DQL abstraction? Should this type of code be on the Platform object in the DBAL?

Anyway, this repo fixes our immediate problem, and it would be good to revisit this in a wider context. Hopefully we can get some good SQL server support - there are plenty of other issues to deal with (UTF-8/UCS2, nvarchar etc)

Comment by Benjamin Eberlei [ 19/Jan/13 ]

Craig Mason We don't have an SQL Server expert on the team, so if you want really good support you should join and help us with it.





[DDC-1760] [GH-324] simplified __call method Created: 03/Apr/12  Updated: 07/Apr/12

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


 Description   

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

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

Message:



 Comments   
Comment by Benjamin Eberlei [ 04/Apr/12 ]

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

Comment by Benjamin Eberlei [ 06/Apr/12 ]

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

Comment by Benjamin Eberlei [ 07/Apr/12 ]

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





[DDC-1750] [GH-319] [WIP] Added support to Multiple ID Generators Created: 01/Apr/12  Updated: 27/May/12

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


 Description   

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

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

Message:



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

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

Comment by Benjamin Eberlei [ 01/Apr/12 ]

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

Comment by Benjamin Eberlei [ 02/Apr/12 ]

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

Comment by Benjamin Eberlei [ 02/Apr/12 ]

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

Comment by Benjamin Eberlei [ 03/Apr/12 ]

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

Comment by Benjamin Eberlei [ 03/Apr/12 ]

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

Comment by Benjamin Eberlei [ 04/Apr/12 ]

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

Comment by Benjamin Eberlei [ 06/Apr/12 ]

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

Comment by Benjamin Eberlei [ 07/Apr/12 ]

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





[DDC-1732] Unserialized non-initialized proxy classes should throw an exception when a method is called Created: 28/Mar/12  Updated: 28/Mar/12

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

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

Attachments: Text File ProxyFactory.php.patch    

 Description   

When we serialize entities in a session, we often have pointers to uninitialized proxies.
These proxies have $_entityPersister == null.

The problem is that if you happen to call by mistake a method on such a proxy, you're not aware that this is an uninitialized proxy, and the business methods are called, with null values for every property.

I think the proxy should throw an exception in that case.
Attached, a patch with the proposed modification.






[DDC-1729] Translate queries into graphs of value objects (instead of array hydration?) Created: 27/Mar/12  Updated: 09/Jun/12

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

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


 Description   

In decoupled applications the model layer returns "data-transfer-objects" through the boundary into the controller/view layer. It would make sense to have Doctrine directly generate any data-transfer/value-object from native and dql queries.



 Comments   
Comment by Benjamin Eberlei [ 09/Jun/12 ]

Example:

$dql = "SELECT new CustomerAddressView(c.id, c.name, a.id, a.street, a.number, a.city, a.code)
             FROM Customer c INNER JOIN c.address a WHERE c.id = ?1";

This supersedes DDC-1819.

1. One additional property in ResultSetMapping => $viewModelClass?
2. Changes to Parser (new ... syntax)
3. Changes to sQL Walker?
4. Changes to Hydration (Only object hydration!)





[DDC-1728] There is no exact alternative function like MONTH in mysql Created: 27/Mar/12  Updated: 27/Mar/12

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

Type: New Feature Priority: Major
Reporter: Sudheesh MS Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Ubuntu 11.10



 Description   

i am not able to extract only month from the date field using doctrine2 using 'MONTH' function






[DDC-1720] SqlWalter private variables should be protected to allow walker extensions Created: 21/Mar/12  Updated: 21/Mar/12

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

Type: Improvement Priority: Major
Reporter: Ignacio Larranaga Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File SqlWalker.patch    

 Description   

I'm attaching a patch with the suggestion.






[DDC-1714] Prevent inverse side lazy loading owning side of the oneToOne relationsip if owning side's id is an assosiationKey of inversed side Created: 18/Mar/12  Updated: 23/Mar/14

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

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


 Description   

This issue was originally discussed in http://www.doctrine-project.org/jira/browse/DDC-357

Say there is User and UserData with oneToOne bidirectional relationship. When we fetch User objects, UserData is lazy loaded right away.

If we were to set UserData 's id as asssosiationKey of User, then user_id becomes the id of UserData and User object can already know that UserData owning side's id will equal it's own User->id.

Can this be implemented?



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

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





[DDC-1702] EBNF for IN expressions should be updated for 2.2 Created: 13/Mar/12  Updated: 13/Mar/12

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

Type: Documentation Priority: Major
Reporter: Patrick Schwisow Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 2
Labels: None


 Description   

Following the changes made for DDC-1472 and DDC-1416, the EBNF for InExpression should have been updated. It now takes an ArithmeticExpression instead of a SingleValuePathExpression.



 Comments   
Comment by Patrick Schwisow [ 13/Mar/12 ]

I marked this as "Major" because this change represents a BC break. Because EBNF was not updated, I initially believed this to be a bug in ORM and wasted a lot of time debugging Doctrine code before I discovered this change was intentional.





[DDC-1645] Paths to Annotations classes are not considered Created: 10/Feb/12  Updated: 10/Feb/12

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

Type: Improvement Priority: Major
Reporter: feathers and down Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

openSUSE 12.1 x86, Apache/2.2.21, mysql 5.5.16, PHP 5.3.8 (modules: Core, ctype, curl, date, dom, ereg, filter, gd, hash, http, iconv, json, libxml, mbstring, mcrypt, mhash, mysql, mysqli, mysqlnd, pcre, PDO, pdo_mysql, pdo_sqlite, Reflection, session, SimpleXML, SPL, SQLite, sqlite3, standard, tokenizer, xml, xmlreader, xmlwriter, zip, zlib )


Attachments: Zip Archive bugtracker.zip    

 Description   

Hi, my battle is described here: http://groups.google.com/group/doctrine-user/browse_thread/thread/db9c77b6bc000f13

When I follow bugtracker tutorial I think that there is an error when working with Annotations, see these examples:

Start a new bugtracker project as described in tutorial from scratch, create folders and files as tutorial expose, then do following changes:

1) put Product, Bug, User class files at root level, same level as bootstraps files and create_xxxxx files
2) Create 'entities' folder, but leave it empty.
3) Create 'yaml' and 'xml' at root level too and add related files.
4) Open bootstrap and edit paths to Product, Bug and User class files to read from root files as in 1) so they can be read from scripts.

1) YAML
a) When using YAML as mapping driver you need a path to Setup::createYAMLMetadataConfiguration( ) method, I use this
Setup::createYAMLMetadataConfiguration(array(_DIR_."/yaml"), $isDevMode);
where "yaml" directory is same level as bootstraps and create_xxxxx files are. When executing script to create a product
Doctrine work as expected, creating a row inside table correctly.
b) If you comment line where class Product is included, the object can't be found at runtime and will throw an exception as expected.
c) With uncommented require Product line, change yaml name folder to anything, and Doctrine throw an exception (MappingException) as expected

so Setup method path argument is considered correctly, Doctrine engine must know where yaml files for classes are.

2) XML
a) When using XML as mapping driver you need a path to Setup::createXMLMetadataConfiguration( ) method, I use this
Setup::createXMLMetadataConfiguration(array(_DIR_."/xml"), $isDevMode);
where "xml" directory is same level as bootstraps and create_xxxxx files are. When executing script to create a product
Doctrine work as expected, creating a row inside table correctly.
b) If you comment line where class Product is included, the object can't be found at runtime and will throw an exception as expected.
c) With uncommented require Product line, change xml name folder to anything, and Doctrine throw an exception (MappingException) as expected

so Setup method path argument is considered correctly again, Doctrine engine must know where xml files for classes are.

3) Annotations
a) When using Annotations as mapping driver you need a path to Setup::createAnnotationsMetadataConfiguration( ) method, I use this
Setup::createAnnotationsMetadataConfiguration(array(_DIR_."/entities"), $isDevMode);
where "entities" directory is same level as bootstraps and create_xxxxx files are (but remember THEY ARE EMPTY). When executing script to create a product
Doctrine WORK AS EXPECTED, creating a row inside table correctly and still I don't know how if THERE IS NO Annotations files.
b) If you comment line where class Product is included, the object can't be found at runtime and will throw an exception as expected.
c) With uncommented require Product line, change name folder to anything, and Doctrine WILL NOT throw an exception, continue with execution.
d) Copy /Product.php to /entities/Product.php, then comment docblocks from /Product class (using // or delete them). When running script Doctrine throw a MappingException with message: "Class Product is not a valid entity or mapped super class", when as follow concepts from 1) (yaml) and 2) (xml) it should search docblocks from /entities/Product.php file (path argument from Setup), right?

so Setup method path argument IS NOT CONSIDERED, Doctrine engine use already defined classes to get Annotations docblocks using php reflexion classes, methods and functions.

How to deal with this? I mean...

a) Erase path argument from Setup::createAnnotationMetadataConfiguration methos (and similar functions for Annotations) because is not needed, classes and annotations must be defined before.
b) Add support to find docblocks from path argument when no valid dockblock is found from class definition, so entities classes can live without docblocks because they are found inside Setup path function argument, as YAML and XML do.

I know that is easy to follow tutorial guidelines to develop applications in Annotations point of view, load them before Doctrine script start (with require/include or autoloaders, etc) and will work, but I think that is wrong how tutorial and functional logic are given, so a) and b) are my proposed solutions. I think b) should be right, get dockblocks from a class already defined and if are not defined it follow XML and YAML logic: read metadata from other files.

Attachment: My bugtracker Netbeans project.

Sorry by my english






[DDC-1602] Executors for Class Table Inheritance (JOINED) are extremely slow on MySQL Created: 15/Jan/12  Updated: 27/Jun/12

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

Type: Improvement Priority: Major
Reporter: Michael Moravec Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 3
Labels: None
Environment:

Debian, MySQL 5.5.17



 Description   

Update and delete executors for Class Table Inheritance (JOINED) are extremely slow on MySQL platform. It is most probably due to use of subselect on the temporary table.
The slowdown is really significant as the table size increases. As an example, lets have a root entity with one subclass:

/**
 * @Entity
 * @InheritanceType("JOINED")
 * @DiscriminatorColumn(name="discr", type="string")
 * @DiscriminatorMap({"root" = "Root", "a" = "SubA"})
 */
class Root
{
	/**
	 * @Column(type="integer")
	 * @Id
	 * @GeneratedValue
	 */
	private $id;

	/**
	 * @Column(type="integer")
	 */
	private $xyz;
}
/**
 * @Entity
 */
class SubA extends Root
{
	/**
	 * @Column(type="integer")
	 */
	private $foo;
}

Now lets perform a simple DQL UPDATE:

UPDATE Entities\Root r SET r.xyz = 123 WHERE r.id > ?

(note: always the upper half of entries)
Which creates following SQLs:

CREATE TEMPORARY TABLE Root_id_tmp (id INT NOT NULL)
INSERT INTO Root_id_tmp (id) SELECT t0.id FROM Root t0 LEFT JOIN SubA s0_ ON t0.id = s0_.id WHERE t0.id > 25000
UPDATE Root SET xyz = 123 WHERE (id) IN (SELECT id FROM Root_id_tmp)
DROP TEMPORARY TABLE Root_id_tmp

The time spent on this on MySQL 5.5.17 and PostgreSQL 9.1 is:

no. of entries 500 1000 2500 5000 10000 20000 50000
MySQL 0.26s 0.35s 1.1s 3.68s 14.13s 54.44s 338s
PostgreSQL 0.10s 0.10s 0.13s 0.15s 0.22s 0.35s 1.01s

As you can see, MySQL is drastically slower on even relatively small tables. This currently makes Doctrine unusable for this type of inheritance on MySQL. The solution probably would be to avoid subselect in WHERE clause in Doctrine\ORM\Query\Exec\MultiTableUpdateExecutor and Doctrine\ORM\Query\Exec\MultiTableDeleteExecutor.

Feel free to try/modify the test script yourself, it's here.



 Comments   
Comment by Benjamin Eberlei [ 15/Jan/12 ]

Its not a bug as it works. The performance drawback of JTI is discussed in the manual http://www.doctrine-project.org/docs/orm/2.1/en/reference/inheritance-mapping.html.

Changing this would be an improvement where we would hint if databases prefer subselects or joins for different operations. This would increase complexity of the SQL generation since now we are getting along with just one SQL generation strategy.

Comment by Michael Moravec [ 11/May/12 ]

Any chance to get this implemented before 2.3?

Comment by Michael Moravec [ 11/May/12 ]

I've made a change in DBAL and ORM code to implement a solution issue. It's currently more likely a proof of concept.

With the change, my results are (approximately):

no. of entries 500 1000 2500 5000 10000 20000 50000
MySQL 0.17s 0.19s 0.21s 0.26s 0.27s 0.37s 0.92s

Currently only update executor was changed.
DBAL branch with changes: https://github.com/Majkl578/doctrine-dbal/tree/DDC-1602
ORM branch with changes: https://github.com/Majkl578/doctrine2/tree/DDC-1602

Looking forward for your opinions.

Comment by Michael Moravec [ 27/Jun/12 ]

bump





[DDC-1570] GH-243: Add ProxyFactoryInterface to allow custom proxy factories Created: 28/Dec/11  Updated: 23/Dec/13

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


 Description   

Pull-Request was automatically synchronized: https://github.com/doctrine/doctrine2/pull/243

I'd love to have my custom proxy factory used with ORM, which is not possible at the moment

(my experimental proxy https://github.com/juzna/doctrine2/commit/7822446036201b066e390b2e182cac1dc0c85430 and some comments about it http://blog.juzna.cz/2011/06/lazy-loading-in-php/)



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

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





[DDC-1564] MySQL Failure when using setFirstResult() and omitting setMaxResults() Created: 25/Dec/11  Updated: 28/Dec/11

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

Type: Improvement Priority: Major
Reporter: Timo A. Hummel Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

When using setFirstResult() and omitting setMaxResults(), MySQL throws an error. This was very confusing for me until I dumped the SQL statements and found out the reason.

I know that MySQL doesn't directly support this, their manual says that you should set the second parameter to LIMIT to a very high number (18446744073709551615 in their example).

I'd recommend that either throwing an error in the specific platform driver or follow the MySQL example.



 Comments   
Comment by Benjamin Eberlei [ 28/Dec/11 ]

Changed into improvement, i am not sure how this relates to other databases.

You can just use this workaround yourself so long.





[DDC-1552] JTI Owning table for identifier columns could/should be the entitytable Created: 22/Dec/11  Updated: 22/Dec/11

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: Alexander Assignee: Alexander
Resolution: Unresolved Votes: 0
Labels: None


 Description   

When ordering a JTI entity on id, the generated SQL will use the table of the root entity. This is because the root entity is listed as owner of the field in the _owningTableMap, leading to non-optimal queries.

More information see:
https://groups.google.com/forum/#!topic/doctrine-user/znkkP7IF_Aw



 Comments   
Comment by Alexander [ 22/Dec/11 ]

I can pick this up if it's agreed upon that this could indeed be improved.

Comment by Marco Pivetta [ 22/Dec/11 ]

The problem here is that joining with a JTI causes LEFT JOINS, which don't perform very well when it comes to sorting the results.

Just as a quick reference, here's where "something" should be changed to get this working:
https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Query/SqlWalker.php#L316

When the field is part of the primary key, the field used for sorting results should be the one of the table of the entity itself, and not of the root of the CTI.





[DDC-1553] JTI Joining root tables could include ON ... AND root.id IS NOT NULL for each root in the inheritance Created: 22/Dec/11  Updated: 22/Dec/11

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: Alexander Assignee: Alexander
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Would lead to more optimal queries, while still allowing for LEFT JOIN. Also related to this:
https://groups.google.com/forum/#!topic/doctrine-user/znkkP7IF_Aw



 Comments   
Comment by Alexander [ 22/Dec/11 ]

Again I can pick this up if this improvement is agreed upon.





[DDC-1549] GH-232: Recursive check for entity identifiers and hashes Created: 20/Dec/11  Updated: 22/Mar/12

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


 Description   

Pull-Request was automatically synchronized: https://github.com/doctrine/doctrine2/pull/232

Hi all!
This PR will add a better support for entities with association keys.

getType will check recursively to find a type for the identifier.
getIndividualValue will search recursively to find the identifier value

trygetById improved, using a recursive function to find an id value instead of implode functions (that cause exceptions if the identifier is an object and do not implements __toString method).



 Comments   
Comment by Benjamin Eberlei [ 28/Dec/11 ]

Mark as improvement

Comment by Benjamin Eberlei [ 22/Mar/12 ]

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





[DDC-1538] GH-217: [BUG] Schema Manager had no way to define extra options Created: 14/Dec/11  Updated: 17/Dec/11

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

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


 Description   

Pull-Request was automatically synchronized: https://github.com/doctrine/doctrine2/pull/217

Schema Manager had no way to define extra options ("comment" option for example). It is possible to add these options via Annotations. After the fix adding `@ORM\Column(type="string", options=

{"comment" = "test"}

)` starts to work producing valid SQL schema with COMMENT output.






[DDC-1532] PostFlush lifecycle event Created: 13/Dec/11  Updated: 14/Dec/11

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

Type: New Feature Priority: Major
Reporter: Jack van Galen Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None


 Description   

In some cases, the database-id of the newly created record is needed in some postproccessing steps, like sending an e-mail containing a link to the just created entity. I've recently seen the added support for PostFlush, but this is not a lifecycle event.

class SomeEntityClass{

/** @PostFlush */
function sendSomeEmail()

{ sendEmail(' 'Hi, you're new invoice can be found online: http://www.example.com/invoices/invoice_'.$this->id '; }

}

Perhaps it's even possible to have multiple PostFlush events, that differentiate between the first time a record is created, and when the record is merely updated.



 Comments   
Comment by Jack van Galen [ 14/Dec/11 ]

Okay, please ignore this issue, as I now see that the @PostPersist does exactly what I need. I was thrown by the name, because to me, the order in which stuff happens is persist -> flush. The ID's are only known after flush, so i'd expected something like postflush to exist. Sorry.





[DDC-1530] HIDDEN values cannot be used in WhereClause Created: 12/Dec/11  Updated: 25/Jan/12

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

Type: Improvement Priority: Major
Reporter: Guilherme Blanco Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: None


 Description   
SELECT  u, u.name AS HIDDEN n FROM User u WHERE n = ?1

Is broken. Error:

SQLSTATE[42S22]: Column not found: 1054 Unknown column 'sclr16' in 'where clause

On a query like:

SELECT s0_.id AS id0, s0_.a AS a1, s0_.b AS b2, s0_.c AS c3, s0_.d AS d4, s0_.e AS e5, s0_.f AS f6, s0_.g AS g7, s0_.h AS h8, s0_.i AS i9, s0_.j AS j10, s0_.k AS k11, s0_.l AS l12, s0_.m AS m13, s0_.n AS n14, s0_.o AS o15, 123456789 AS sclr16, s0_.p AS p17 FROM myEntity s0_ WHERE s0_.a = 1 AND sclr16 <= ? ORDER BY sclr16 ASC 


 Comments   
Comment by Guilherme Blanco [ 20/Dec/11 ]

Updating fix version

Comment by Christian Raue [ 09/Jan/12 ]

It occurs even if the value is not HIDDEN.

Comment by Benjamin Eberlei [ 10/Jan/12 ]

@Christian this sounds like a completly different error, please explain why you think this belongs here or open a new ticket.

Comment by Christian Raue [ 10/Jan/12 ]

Benjamin: Because I get exactly the same error message regardless of using HIDDEN. So HIDDEN doesn't seem to be liable here.

Comment by Benjamin Eberlei [ 10/Jan/12 ]

Can you paste your DQL and SQL?

Comment by Christian Raue [ 10/Jan/12 ]

Code:

$queryBuilder
	->select('myEntity, 123456789 AS distance')
	->where('distance <= 10')
;

DQL:

SELECT myEntity, 123456789 AS distance FROM MyCompany\MyBundle\Entity\MyEntity myEntity WHERE distance <= 10

SQL:

SELECT s0_.id AS id0, s0_.a AS a1, s0_.b AS b2, s0_.c AS c3, s0_.d AS d4, s0_.e AS e5, s0_.f AS f6, s0_.g AS g7, s0_.h AS h8, s0_.i AS i9, s0_.j AS j10, s0_.k AS k11, s0_.l AS l12, s0_.m AS m13, s0_.n AS n14, s0_.o AS o15, 123456789 AS sclr16, s0_.p AS p17 FROM myEntity s0_ WHERE sclr16 <= 10
Comment by Benjamin Eberlei [ 11/Jan/12 ]

That is expected behavior, ANSI SQL defines SELECT to be evaluated AFTER WHERE.

SELECT 1234 AS foo FROM `test` HAVING foo = 1234

DQL has a HAVING clause as well, not sure it works without the group by. Please try.

Comment by Christian Raue [ 21/Jan/12 ]

So we might just close this issue then?

Comment by Benjamin Eberlei [ 25/Jan/12 ]

Its not a bug, just the error message is supposed to be improved (if possible) in a cheap way.





[DDC-1513] Missing documentation for using references in Docs Created: 28/Nov/11  Updated: 29/Nov/11

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

Type: Documentation Priority: Major
Reporter: Thomas Gray Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I am in the process of switching over from Doctrine 2.0.7 to Doctrine 2.1 and one of the major missing components in my entities was the new use of using the mapping entity.

Example:

 
<?php
namespace My\Project\Entities;
use Doctrine\ORM\Mapping\Entity as ORM;
/**
 * @ORM\Entity(...)
 */
class Something
{
// Doctrine annotations here
}

The nessecity for this to be included in the entities is (as far as I can tell) nowhere to be found in the docs, so I am a little curious as to how people are supposed to know. I have also had a look here: http://www.doctrine-project.org/blog/doctrine-2-1-beta-release and can see no references too it.

Am I missing something; or is it really just missing from the docs?



 Comments   
Comment by Erik Bernhardson [ 28/Nov/11 ]

I also glanced through the docs and didn't find it. I would suggest it be added to the Annotations Reference page: http://www.doctrine-project.org/docs/orm/2.1/en/reference/annotations-reference.html

Comment by Thomas Gray [ 29/Nov/11 ]

Ahh, so there are some docs about it; http://www.doctrine-project.org/docs/common/2.1/en/reference/annotations.html however they do not seem to be that clear; nor well linked too.





Possible Regression with OneToOne relation (DDC-1461)

[DDC-1506] Possible Regression with OneToOne relation Created: 23/Nov/11  Updated: 23/Nov/11

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

Type: Sub-task Priority: Major
Reporter: Maxim Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   
/**
 * @ORM\Entity
 */
class Top
{
    /**
     * @ORM\Id
     * @ORM\Column(type="integer")
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;
    /**
     * @ORM\OneToOne(targetEntity="LevelOne", orphanRemoval="true", cascade={"persist", "remove"})
     */
    protected $levelOne;
    
    public function getId()
    {
        return $this->id;
    }

    public function setLevelOne(LevelOne $levelOne)
    {
        $this->levelOne = $levelOne;
    }

    public function getLevelOne()
    {
        return $this->levelOne;
    }
}

/**
 * @ORM\Entity
 */
class LevelOne
{
    /**
     * @ORM\Id
     * @ORM\Column(type="integer")
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;
    /**
     * @ORM\OneToOne(targetEntity="LevelTwo", orphanRemoval="true", cascade={"persist", "remove"})
     */
    protected $levelTwo;

    public function getId()
    {
        return $this->id;
    }
    
    public function setId($id)
    {
        $this->id = $id;
    }

    public function setLevelTwo(LevelTwo $levelTwo)
    {
        $this->levelTwo = $levelTwo;
    }

    public function getLevelTwo()
    {
        return $this->levelTwo;
    }
}

/**
 * @ORM\Entity
 */
class LevelTwo
{
    /**
     * @ORM\Id
     * @ORM\Column(type="integer")
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;
    
    public function getId()
    {
        return $this->id;
    }
    
    public function setId($id)
    {
        $this->id = $id;
    }
}

trying to clone objects

$top = new Top();
        $top->setLevelOne(new LevelOne());
        $top->getLevelOne()->setLevelTwo(new LevelTwo());
        
        $this->em->persist($top);
        $this->em->flush();
        
        $newTop = new Top();
        $newTop->setLevelOne(clone $top->getLevelOne());
        $newTop->getLevelOne()->setId(null);
        $newTop->getLevelOne()->getLevelTwo()->setId(null);
        
        var_dump($newTop->getLevelOne()->getId());
        var_dump($newTop->getLevelOne()->getLevelTwo()->getId());
        
        $this->em->persist($newTop);
        $this->em->flush();

the output is:
NULL
NULL
[PDOException]
SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1' for key 'UNIQ_82A72CD0778BC57F'
(it duplicates level two entity)
I worked for a while with entities, in a certain set of entity properties it completely persisted into database, but without relation between level one and level two.






[DDC-1475] Documentation for One-To-Many, Bidirectional Association does not have YAML example Created: 07/Nov/11  Updated: 07/Nov/11

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

Type: Documentation Priority: Major
Reporter: Christian S. Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

When you are looking for a config example for the bidirectional mapping of an one-to-many association you will just find an example with XML, but not with YAML or PHP. It would be nice if somebody could add an example or a link to the bidirectional one-to-one association, because it should be the same, right?

Here the link to the example: http://www.doctrine-project.org/docs/orm/2.0/en/reference/association-mapping.html#one-to-many-bidirectional






[DDC-1465] Fetching partial objects doesn't work if HINT_FORCE_PARTIAL_LOAD is not explicitly used Created: 02/Nov/11  Updated: 11/Nov/11

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

Type: Bug Priority: Major
Reporter: Julien Pauli Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None

Issue Links:
Duplicate
duplicates DDC-624 Partial object query that leaves out ... Open

 Description   

Using the DQL "partial" keyword is not enough to get a partial entity as a result.
The DQL hint HINT_FORCE_PARTIAL_LOAD must be used as well.

$q = $em->createQuery('SELECT partial r.{id,comment} FROM Entities\Rating r WHERE r.id=3');
$r = $q->getResult() /* HYDRATE_OBJECT is the default hydration mode */

Here, $r contains the full Entity, a SELECT * has been sent

$q = $em->createQuery('SELECT partial r.{id,comment} FROM Entities\Rating r WHERE r.id=3');
$q->setHint(Doctrine\ORM\Query::HINT_FORCE_PARTIAL_LOAD, 1);

$r = $q->getResult() /* HYDRATE_OBJECT is the default hydration mode */

Here, $r contains only the selected fields, hence a true partial Entity






[DDC-1459] Move DDC-331, DDC-448, DDC-493, DDC-513, DDC-698 Tests into SQLGeneration Testsuite Created: 29/Oct/11  Updated: 01/Aug/12

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





[DDC-1450] UnitOfWork Transaction Rollback Support Created: 24/Oct/11  Updated: 20/Dec/11

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

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


 Description   

The UnitOfWork does not handle the case very well where a rollback is necessary. Can this be optimized?



 Comments   
Comment by Guilherme Blanco [ 20/Dec/11 ]

Updating fix version





[DDC-1393] Skipping tables or columns in database driver or SchemaTool Created: 24/Sep/11  Updated: 20/Dec/11

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

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


 Description   

There should be a sane way to skip sources of errors in SchemaTool and the DatabaseDriver.



 Comments   
Comment by Benjamin Eberlei [ 24/Sep/11 ]

Idea:

Develop a datastructure of sorts that allows saving information about skipping tables and columns therein when reverse engeneering.

Comment by Guilherme Blanco [ 09/Dec/11 ]

This is not possible unless you take advantage of Topological Sorting to map class dependencies like we do inside of UnitOfWork AFTER creating the ClassMetadata.

The necessity of having this is mandatory because we can never skip classes that have associations to other ones though FK.
You may try that, but it doesn't compensate the effort. I'd rather mark this bug as won't fix, but I'm leaving for you do that. =)

Comment by Guilherme Blanco [ 20/Dec/11 ]

Updating fix version





[DDC-1380] Standardize proxy class naming Created: 18/Sep/11  Updated: 18/Sep/11

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

Type: Improvement Priority: Major
Reporter: Johannes Schmitt Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

see https://github.com/doctrine/doctrine2/pull/125






[DDC-1371] Optimistic Locking using hash column or all columns Created: 10/Sep/11  Updated: 10/Sep/11

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


 Description   

We can implement optimistic locking using hash values or other all columns of an entity






[DDC-1357] Queries with multiple joins resulting in multiple scalar results for each top level entity only retain one scalar value for each entity Created: 01/Sep/11  Updated: 01/Sep/11

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

Type: Improvement Priority: Major
Reporter: Nils Adermann Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Consider this example:

select g.id, u.id, u.status, count(p.phonenumber) numPhones from Group
     * g join g.user u join u.phonenumbers p group by g.id, u.status, u.id

With data:

phonenumbers:
    [1, 2, 3, 4, 5, 6]
users:
    [{id: 1, status: developer, phonenumbers: [1, 2]},
     {id: 2, status: developer, phonenumbers: [3]},
     {id: 3, status: developer, phonenumbers: [4, 5, 6]}]
groups:
    [{id: 1, users: [1, 2]]},
     {id:2, users: [3]}]

The result currently is:

array(
    array(
        0 => object(CmsGroup) {
            'id' => 1,
            'users' => Collection(
                object(CmsUser) { 'id' => 1 },
                object(CmsUser) { 'id' => 2 }
            )
         },
        'numPhones' => 1
    ),
    array(
        0 => object(CmsGroup) {
            'id' => 2,
            'users' => Collection(
                object(CmsUser) { 'id' => 3 }
            )
        },
        'numPhones' => 3
    )
)

Note that the first entry contains only one value numPhones => 1, even though there are two users associated with that group. One of whom has 2 phone numbers and the other has 1.

The result I would expect is:

array(
    array(
        0 => object(CmsGroup) {
            'id' => 1,
            'users' => Collection(
                object(CmsUser) { 'id' => 1 },
                object(CmsUser) { 'id' => 2 }
            )
         },
        'numPhones' => array(2, 1)
    ),
    array(
        0 => object(CmsGroup) {
            'id' => 2,
            'users' => Collection(
                object(CmsUser) { 'id' => 3 }
            )
        },
        'numPhones' => array(3)
    )
)

The difference is that numPhones for each row now contains an array of the
scalar values matching the corresponding users.



 Comments   
Comment by Nils Adermann [ 01/Sep/11 ]

You can find a test case for the correct result here: https://github.com/naderman/doctrine2/commit/a1ca3d9847cbc514fc951fb0b221b26fe03a6619





[DDC-1443] Subscribers reachs maximum nesting level when creating association on pre/postPersist with cascade persist Created: 20/Oct/11  Updated: 29/Oct/11

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

Attachments: File DDC1443Test.php     File DDC1443Test.php    

 Description   

Suppose a situation where:

A -> B

Where the OneToOne unidirectional association contains cascade persist.

If I decide to save an entity B that should create an A instance, it goes into maximum nesting level no matter if I track prePersist or postPersist.



 Comments   
Comment by Guilherme Blanco [ 20/Oct/11 ]

Failing test case

Comment by Guilherme Blanco [ 20/Oct/11 ]

Uploading a new version, now passing successfully, but consuming the onFlush event (which should not be ideal).

Comment by Benjamin Eberlei [ 29/Oct/11 ]

Ah yes, this never worked. The transaction stuff will fix that. You have to use scheduleForInsert() something inside prePersist.





[DDC-1441] Metadata cannot be loaded for not registered proxy objects Created: 20/Oct/11  Updated: 05/Apr/12

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

Type: Improvement Priority: Major
Reporter: Aigars Gedroics Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

MySQL, Ubuntu, PHP 5.3.6


Attachments: File DDC1441Test.php     File not-loaded-proxy-patch.diff    

 Description   

We are using several Doctrine managers in our project with the same entity classes and different database tables.

The problem appears when we are willing to merge entity with lazy associations from one manager to another. The second entity manager instance hasn't got the proxy object metadata defined yet so it fails with Doctrine\ORM\Mapping\MappingException exception "Class EntityProxy is not a valid entity or mapped super class.".

If both entity managers share the proxy objects the problem can be fixed by calling

$em->getProxyFactory()->getProxy('Entity', -1);

which will register the entity metadata for the proxy classname as well.

Still if the proxy configuration differs, there is no fix found without changing the Doctrine ORM code.

The fix inside the Doctrine would be to detect Proxy classes before loading the metadata and load the metadata for it's parent class instead. Please see the diff attached with proposed solution.

Also I think this issue could arise when unserialized entity objects will be merged into the entity manager. I will try creating test case for this.



 Comments   
Comment by Aigars Gedroics [ 24/Nov/11 ]

Test case attached.

Comment by Aigars Gedroics [ 05/Apr/12 ]

See my pull request in https://github.com/doctrine/doctrine2/pull/332.





[DDC-1438] Add test for DDC-1437 Created: 19/Oct/11  Updated: 19/Oct/11

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


 Description   

Add test for DDC-1437






[DDC-1431] Current event system is not flexible enough Created: 18/Oct/11  Updated: 18/Oct/11

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

Type: Improvement Priority: Major
Reporter: Oleg Stepura Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None
Environment:

Doctrine 2.1


Sub-Tasks:
Key
Summary
Type
Status
Assignee
DDC-1449 Create postFlush event Sub-task Resolved Benjamin Eberlei  

 Description   

Hi!

According to http://www.doctrine-project.org/docs/orm/2.1/en/reference/events.html

Current event system seem to be not as flexible as it could be.

1. According Lifecycle Events of the entity (marked with @HasLifecycleCallbacks annotation tag):
It would be useful to have access to Entity Manager inside the callbacks. This could be achieved by passing the entity manager as a parameter to all these callbacks.

Here is the situation:
I have an entity for a news item. After somehow modifying this entity and before persisting I want to be able to change the inner association of images linked to this news (for example parsed from news body text). From the OO point of view it's a task of the News entity itself so this should be done a callback. But since inside callback I do not have access to entity manager (to find existing image entities and only if not found creating a new one) I cannot do this.
This leads to creating a separate event listener which is split from the news entity (and that is not possible, see 2.).

Passing entity manager to callbacks may improve it's usefulness.

2. Currently there is no events to be called before the changes have been computed. And there is no callback to be called after flush has been finished. (preFlush, postFlush)
The problem:
Assume we have a News entity. I want to modify external system (even not written in PHP) via remote call after any change to news being made. This has to be called AFTER the flush has persisted all the changes. Currently the only place to do this is onFlush (which is called before the persisting is done).
PostPersist, postRemove, postUpdate cannot be used as it's called after each one entity is modified and we cannot tell when all entites has been processed.

Also I faced a problem when implementing the event listener for situation 1. If I register the onFlush listener - the entites changeset is already calculated. If I change something according associations I loose this changes.
If I call $unitOfWork->computeChangeSet($classMetadata, $entity) or $unitOfWork->recomputeSingleEntityChangeSet($classMetadata, $entity); I only get the changes being made after previous changeset calculation loosing the initial changes. I think the preFlush could be a lifesaver for this (to be called before computing the changeset for the first time).






[DDC-1445] Improve error messages Created: 22/Oct/11  Updated: 20/Dec/11

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

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


 Description   

Error messages throughout ClassMetadata validation and UnitOfWork cycles can be significantly improved.

Work is being done on: https://github.com/doctrine/doctrine2/tree/ImproveErrorMessages



 Comments   
Comment by Guilherme Blanco [ 20/Dec/11 ]

Updating fix version





[DDC-1429] Add a method to the unit of work that merges any detached entity into UoW without calling SQL Created: 17/Oct/11  Updated: 17/Oct/11

Status: Open
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: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This is for those that know what they are doing






[DDC-1347] Github-PR-110 by shesek: Support NULL in EntityRepository's magic findBy and findOneBy methods Created: 25/Aug/11  Updated: 25/Aug/11

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


 Description   

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

{username}

:

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

Message:

The magic `findBy` and `findOneBy` methods don't support passing NULL as the value, because ["we cannot (yet) transform it into IS NULL"](https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/EntityRepository.php#L207).

However, `BasicEntityPersister::_getSelectConditionSQL()` [does support that](https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php#L1229). It seems like leftovers from when there was no support for it. I tried it locally (after applying this change) and it does seem to work well.






[DDC-1342] Github-PR-109: Remove trailing spaces Created: 21/Aug/11  Updated: 21/Aug/11

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


 Description   

alOneh created a pull request on Github:

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






[DDC-1320] Ship Immutable date time with Doctrine Common, use in ORM - Should implement __toString() Created: 06/Aug/11  Updated: 31/Oct/11

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

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

Issue Links:
Dependency
depends on DDC-1316 Insert statement for joined subclass ... Resolved

 Comments   
Comment by Benjamin Eberlei [ 31/Oct/11 ]

Has to be pushed back as immutable date time cannot be implemented in userland that well.





[DDC-1308] Add cache for transient information and invalidation for ClassMetadata Created: 31/Jul/11  Updated: 20/Dec/11

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

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


 Description   

Two different things have to be improved in the caching:

1. The information isTransient() has to be moved to the ClassMetadataFactory and cached there.
2. The information getAllClassMetadataNames() can be cached
3. A debug/development mode should be introduced, leading to filemtime caching and checks so that you can use ApcCache and such in development.



 Comments   
Comment by Guilherme Blanco [ 20/Dec/11 ]

Updating fix version





[DDC-1259] Atomic creation of Proxy files Created: 08/Jul/11  Updated: 09/Jul/11

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


 Description   
From 265e5086ea51ebcafc73f91abc64334d17e2f416 Mon Sep 17 00:00:00 2001
From: Karsten Dambekalns <karsten@typo3.org>
Date: Wed, 25 May 2011 12:11:55 +0200
Subject: [PATCH 4/5] Use temporary file and rename for proxy class creation

Instead of a simple file_put_contents() the proxy class code is written to a
temporary file and renamed to the final filename. This allows file access even
if only allowed by the directory permission.
---
 lib/Doctrine/ORM/Proxy/ProxyFactory.php |   10 +++++++++-
 1 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/lib/Doctrine/ORM/Proxy/ProxyFactory.php b/lib/Doctrine/ORM/Proxy/ProxyFactory.php
index f0cf19c..b2d42fb 100644
--- a/lib/Doctrine/ORM/Proxy/ProxyFactory.php
+++ b/lib/Doctrine/ORM/Proxy/ProxyFactory.php
@@ -152,7 +152,15 @@ class ProxyFactory
 
         $file = str_replace($placeholders, $replacements, $file);
 
-        file_put_contents($fileName, $file, LOCK_EX);
+        $temporaryFileName = $fileName . uniqid( ) . '.temp';
+        $result = file_put_contents( $temporaryFileName, $file );
+
+        if($result === FALSE) throw new \RuntimeException('The temporary proxy class file "' . $temporaryFileName . '" could not be written.');
+        $i = 0;
+        while(!rename( $temporaryFileName, $fileName ) && $i < 5) {
+            $i++;
+        }
+        if($result === FALSE) throw new \RuntimeException('The proxy class file "' . $fileName . '" could not be written.');
     }
 
     /**
-- 
1.7.4.1


 Comments   
Comment by Benjamin Eberlei [ 09/Jul/11 ]

Nette Framework uses a safe stream: https://github.com/nette/nette/blob/master/Nette/Utils/SafeStream.php





[DDC-1264] Add more math related DQL funcs (trig, round, stuff?) Created: 09/Jul/11  Updated: 09/Jul/11

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

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





[DDC-1263] @ManyToOne Arbitrary References Created: 09/Jul/11  Updated: 09/Jul/11

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

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


 Description   

Could it be possible to allow for arbitrary many to one entities through a "class + id" construct as join columns?






[DDC-1262] Have proxies copy docblocks aswell Created: 09/Jul/11  Updated: 09/Jul/11

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.0.6, 2.1, Git Master
Fix Version/s: 2.x
Security Level: All

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


 Description   

Whenever a Proxy is generated it does not copy the docblocks.

This means when you do something like "$refl = new ReflectionObject($proxy)" you might be in trouble.

However if we add docblocks then we have to make sure that proxies do not magically appear as entities by throwing an exception in the AnnotationDriver.






[DDC-1229] generate entity interactive dialog: id column Created: 27/Jun/11  Updated: 28/Jun/11

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

Type: Improvement Priority: Major
Reporter: David Buchmann Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

according to Stof, this bug https://github.com/sensio/SensioGeneratorBundle/issues/21 comes from the doctrine tools implementation:

in the dialog, i first specified that i want a field id of type integer. the result was

[Doctrine\ORM\Mapping\MappingException]

Duplicate definition of column 'id' on entity 'Liip\DemoBundle\Entity\Event' in a field or discriminator column mapping.

and no file was created.

The dialog should tell me i can not create a field named id. (Or better ask first if i want my id column named id or something else.)

It would be nice if it would write some file even if its not valid, with a warning on top. As it is, i lost all my work of specifying fields. (Luckily was just playing around)



 Comments   
Comment by Benjamin Eberlei [ 28/Jun/11 ]

not a bug, its a feature (though a dumb one). Improvement in a next version.





[DDC-1219] Remove dependancy on Collection interface in Domain Objects Created: 21/Jun/11  Updated: 04/Jul/11

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

Type: Improvement Priority: Major
Reporter: André R. Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Short: This issue is all about being able to use doctrine with naked domain objects without any use of doctrine classes.
I 'm not talking about PersistentCollection here, fully aware of that being tied into Doctrine, but those are injected, this is all about code dependency on ArrayCollection.

Seems like some of the UnitOfWork code is cable of handling other types of arrays, like:

    // If $actualData[$name] is not a Collection then use an ArrayCollection.
    if ( ! $actualData[$name] instanceof Collection) {
        $actualData[$name] = new ArrayCollection($actualData[$name]);
    }

But in __cascade* functions this is not the case in all but two:

    if ($relatedEntities instanceof Collection) {
        if ($relatedEntities instanceof PersistentCollection) {
            // Unwrap so that foreach() does not initialize

2 however have:

    if (($relatedEntities instanceof Collection || is_array($relatedEntities))) {
        if ($relatedEntities instanceof PersistentCollection) {
            // Unwrap so that foreach() does not initialize

Would it be an idea to do "instanceof Traversable" instead of " instanceof Collection"?



 Comments   
Comment by André R. [ 21/Jun/11 ]

Note: If the fist code block is always performed before the last 2 blocks then there is no issue here, just a need to make it more clear in Doc that this is possible but that you should not rely custom implementation as PersistentCollection will be injected when loaded from db.





[DDC-1217] Use the DBAL ReservedKeywordsValidator in orm:validate-schema Created: 20/Jun/11  Updated: 20/Jun/11

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

Type: Improvement Priority: Major
Reporter: Christophe Coevoet Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

DBAL provides a ReservedKeywordsValidator to check whether a word is reserved. But this tool is not used by the ORM when validating the schema. It would be useful to use it to avoid WTF from users getting a PDOException when creating their schema because of this.
The other solution if you don't want to add this in orm:validate-schema would be to create a dedicated command.






[DDC-1201] DQL Example about count(*) related entity is wrong Created: 10/Jun/11  Updated: 10/Oct/11

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

Type: Documentation Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None


 Description   

DQL Example about count related entity is wrong



 Comments   
Comment by Aigars Gedroics [ 10/Oct/11 ]

Also similar DQL in documentation URL http://www.doctrine-project.org/docs/orm/2.1/en/reference/dql-doctrine-query-language.html#pure-and-mixed-results fails parsing stage:

$dql = "SELECT u, 'some scalar string', count(u.groups) AS num FROM User u JOIN u.groups g GROUP BY u.id";

with error

  [Doctrine\ORM\Query\QueryException]                                                                                                                         
  [Semantical Error] line 0, col 40 near 'localizations)': Error: Invalid PathExpression. StateFieldPathExpression or SingleValuedAssociationField expected. 

Should be "count(g.id)" instead of "count(u.groups)".





[DDC-1178] Have access to "original" metadata in events subscribed to loadClassMetadata Created: 27/May/11  Updated: 27/May/11

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

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


 Description   

If you subscribe to loadClassMetadata you will usually modify the metadata for some classes.
The problem is, that that data has to be loaded from somewhere. But later down the chain you can't get to it. Now data specific to what you need in your loadClassMetadata would ideally reside in the same location.
If we take for example a file, than all data for a specific entity is in the same file.

My proposal would be to add function get(Original|Raw)MappingData into interface Doctrine\ORM\Mapping\Driver\Driver which would either return raw data or data in a object specific for that Driver or null if it doesn't make sense for that driver. Please note, that when loading from e.g XmlDriver we should return simplexmlnode or dom node as loadClassMetadata should be in its own namespace and not pollute the Doctrine one.



 Comments   
Comment by Gediminas Morkevicius [ 27/May/11 ]

Sounds logic, each driver would expect NULL or data (wrapped specifically for the driver used)





[DDC-1164] doctrine:schema:update --force == doctrine:schema:create Created: 20/May/11  Updated: 20/May/11

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


 Description   

Doctrine:schema:update --force is the same as doctrine:schema:create.

Under the hood, this may not be true, but they basically accomplish the same task. Schema:create should be removed, as it is redundant.

Just look at django, one command to update db:

./manage.py syncdb

Not saying that django gets everything correct, but the one command to synchronize the database is consistent. doctrine:schema:update should be smart enough to do all of the work, instead of relying on the redundant doctrine:schema:create.






[DDC-1154] Proxies should take convention while loading *ToOne associations to reduce 1 extra query Created: 17/May/11  Updated: 17/May/11

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


 Description   

Read the IRC log:

[2:38pm] guilhermeblanco: beberlei: ping
[2:38pm] guilhermeblanco: I'm curious about a feature if Doctrine supports
[2:38pm] guilhermeblanco: if we do this on a proxy:
[2:38pm] guilhermeblanco: $proxy->getOneToOneAssoc()
[2:39pm] guilhermeblanco: shouldn't Doctrine already populate the assoc entity?
[2:39pm] guilhermeblanco: it would be an inner join
[2:39pm] beberlei: how would doctrine know it needs it?
[2:39pm] guilhermeblanco: beberlei: it always repass the ClassMetadata to Persister
[2:40pm] guilhermeblanco: so all needed item is to also pass the fieldname/assocname
[2:40pm] beberlei: but how would doctrine know getOneToOneASsoc() really returns this assoc
[2:40pm] beberlei: it could contain any logic
[2:40pm] guilhermeblanco: it wouldn't... but as soon as we trigger __load($fieldName)
[2:40pm] guilhermeblanco: we know that we could populate not only the Proxy, but also assoc
[2:40pm] beberlei: by convention?
[2:40pm] guilhermeblanco: ya
[2:41pm] beberlei: sounds good, can you open a ticket?
[2:41pm] guilhermeblanco: getUser() would trigger __load('user')
[2:41pm] guilhermeblanco: sure!
[2:41pm] guilhermeblanco: I'll pastie this as content... it would be awesome to have
[2:41pm] guilhermeblanco: I see a lot of queries here that could be optimized 





[DDC-1137] SchemaTool#getUpdateSchemaSql() does not respect database identifier in table names Created: 05/May/11  Updated: 14/May/11

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

Type: Improvement Priority: Major
Reporter: Hugh Lomas Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Linux 2.6.18-194.32.1.el5.centos.plus x86_64 GNU/Linux



 Description   

Given two databases, 'foo' and 'bar', with entities in /Entities/Foo/ annotated as follows:

/**
 * Test
 *
 * @Table(name="foo.test")
 * @Entity
 */

Create an EntityManager instance with

$connectionOptions = array( 
    'dbname' => 'Foo', 
    'driver' => 'pdo_mysql', 
    <..etc..>
);

Use EntityManager#getClassMetaData( "Entities\\Foo
Test" ) to pass to SchemaTool#createSchema() and Doctrine appropriately creates a database table foo.test

Use EntityManager#getClassMetaData( "Entities\\Foo
Test" ) to pass to SchemaTool#updateSchema() and Doctrine fails with Exception
-> SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'test' already exists

Inserting

die( print_r( $fromSchema, 1 ) . print_r( $toSchema, 1 ) . print_r( $schemaDiff, 1 ) );

into Doctrine/ORM/Tools/SchemaTool.php line 632 shows $fromSchema outputs

[_tables:protected] => Array
        (
            [test]

but $toSchema outputs

[_tables:protected] => Array
        (
            [foo.test]

which causes $schemaDiff to output

[newTables] => Array
        (
            [foo.test]

In summary, Doctrine/DBAL/Schema/Comparator considers foo.test a new table, because Doctrine/DBAL/Schema/AbstractSchemaManager lists its table as "test" rather than "foo.test".



 Comments   
Comment by Hugh Lomas [ 05/May/11 ]

It seems that changing AbstractSchemaManager.php to the following corrected the issue for me, however I am not sure of any repercussions that may arise as a result, being unfamiliar with the codebase.

Doctrine/DBAL/Schema/AbstractSchemaManager.php line 228

return new Table( $tableName, $columns, $indexes, $foreignKeys, false, array());

Doctrine/DBAL/Schema/AbstractSchemaManager.php line 228

return new Table( $this->_conn->getDatabase() . "." . $tableName, $columns, $indexes, $foreignKeys, false, array());

Comment by Benjamin Eberlei [ 14/May/11 ]

Multi databases are not supported by schema manager and schema tool yet.





[DDC-1099] Tutorial :: Getting started code sample entity manager Created: 04/Apr/11  Updated: 11/Jul/11

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

Type: Documentation Priority: Major
Reporter: Gordon Franke Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

see pull request 24 on github.com



 Comments   
Comment by Michael Ridgway [ 11/Jul/11 ]

This issue should be closed: https://github.com/doctrine/orm-documentation/pull/24





[DDC-1089] Annotations reference examples are inaccurate and confusing Created: 30/Mar/11  Updated: 30/Mar/11

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

Type: Documentation Priority: Major
Reporter: Maarten van Leeuwen Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

N.A.



 Description   

In chapter 19 of the reference guide some coding examples seem to be inaccurate or incorrect. Especially when it comes to the bidirectional many-to-many associations, this might be confusing.

Example:
The code fragment on http://www.doctrine-project.org/docs/orm/2.0/en/reference/annotations-reference.html#annref-manytomany has the following issues:

  • it does not include class declarations although the collections associated are both mentioned. It should be clear to which target entity they belong and therefore their classes should be declared.
  • from the context it seems that the associated classes should probably be User and Group, and the owning side is User. So the association should probably be inversed by 'users', although the example mentions 'features'.
  • the mapping for the inverse side maps a collection called $features, although this should probably be $users. Also the class declaration for the Group class is missing.

Some other code fragments in chapter 19 have similar issues. I think they could easily be replaced by the examples from the earlier chapters, like for the bidirectional man-to-many association the example from chapter 5:

http://www.doctrine-project.org/docs/orm/2.0/en/reference/association-mapping.html#many-to-many-bidirectional






[DDC-1088] Description for SequenceGenerator annotation options is wrong Created: 30/Mar/11  Updated: 26/Nov/13

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

Type: Documentation Priority: Major
Reporter: Alexandre Mathieu Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

N/A



 Description   

On paragraph 4.8.1.1 SequenceGenerator, the correct example should be:

<?php
class User {
/**

  • @Id
  • @GeneratedValue(strategy="SEQUENCE")
  • @SequenceGenerator(sequenceName="tablename_seq", initialValue=1, allocationSize=100)
    */
    protected $id = null;
    }


 Comments   
Comment by Steve Müller [ 26/Nov/13 ]

Is that still an issue? Seems it is fixed...





[DDC-1072] Private property mapping can cause issues, suggest changing to protected Created: 17/Mar/11  Updated: 17/Mar/11

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

Type: Documentation Priority: Major
Reporter: Kevin Bradwick Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

not applicable



 Description   

The documentation recommends using private variables in entities. This can be problematic on entities with relations when using caching drivers as the proxy objects cannot access private variables and so the caching driver can throw notices like

...apc_store(): "_id" returned as member variable from __sleep() but
does not exist in ...

Making member variables protected resolves this issue when caching is enabled.

This information would be helpful on the documentation so others can be made aware of this issue. We spent a few days trying to debug the issue before understanding exactly what was going on.






[DDC-1016] Example code does not reflect real code Created: 03/Feb/11  Updated: 03/Feb/11

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

Type: Documentation Priority: Major
Reporter: thoth Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Website



 Description   

http://www.doctrine-project.org/docs/orm/2.0/en/reference/working-with-objects.html#entity-state

In the switch cases all the UnitOfWork constants are invalid.

Example:
UnitOfWork::NEW instead of being UnitOfWork::STATE_NEW






[DDC-1011] Finding out if a model is persist Created: 02/Feb/11  Updated: 02/Feb/11

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

Type: Documentation Priority: Major
Reporter: Ronny Deter Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

To find out if a model is persist, is missing in the documentation of doctrine 2.

To become the state of an model you must call the entitymanager->getUnitOfWork()->getEntityState(model)






[DDC-999] DQL always needs a FROM clause, should be changed Created: 23/Jan/11  Updated: 23/Jan/11

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

Type: New Feature Priority: Major
Reporter: Timo A. Hummel Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None


 Description   

Sometimes a developer needs to issue a query without a FROM clause. This especially occurs using the QueryBuilder, when you may or may not have a table to select from, but call a stored procedure always.

Example:

$query = $em>createQuery('SELECT (1+1)');

The above query fails because the lexer expects T_FROM. If you replace (1+1) with a stored procedure, this example makes more sense.

One might argue about that you should use DBAL directly, but I disagree, because it always can happen that you end up in a situation like this:

$qb = $em->createQueryBuilder();

$qb->select("SOMEFANCYPROCEDURE()");

if ($condition) {
  $qb = $qb->from("additionalTable t");
}





[DDC-998] Code example for custom AST functions incorrect Created: 23/Jan/11  Updated: 23/Jan/11

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

Type: Documentation Priority: Major
Reporter: Timo A. Hummel Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

On http://www.doctrine-project.org/docs/orm/2.0/en/reference/dql-doctrine-query-language.html#adding-your-own-functions-to-the-dql-language the code example is slightly incorrect.

Mistakes:

  • Lexer::T_ABS doesn't exist anymore, I assume Lexer::T_IDENTIFIER is what one wants to use
  • Missing use for \Doctrine\ORM\Query\Lexer

Additionally, the section should tell the user that he best has a look at lib/Doctrine/ORM/Query/AST/Functions/* to learn how to write custom functions. It also could be noted that stored procedures can be called with custom functions.






[DDC-993] Cookbook: Overriding the ID Generator during a database migration Created: 19/Jan/11  Updated: 28/Oct/12

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

Type: Documentation Priority: Major
Reporter: Timo A. Hummel Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None


 Description   

If you need to override the ID Generator, e.g. during a migration, you can do that in your migration script as follows:

Overriding the ID generator

$em->getClassMetadata('foo\bar\Entity')->setIdGenerator(new \Doctrine\ORM\Id\AssignedGenerator());
$em->getClassMetadata('foo\bar\Entity')->setIdGeneratorType(constant('Doctrine\ORM\Mapping\ClassMetadata::GENERATOR_TYPE_NONE'));

Make sure that both calls equal to the same generator type. You can now modify the @Id fields in your entities. Additionally, make sure that you set the IdGenerator after you created the database using e.g. SchemaTool->create().



 Comments   
Comment by Endre Kósa [ 27/Oct/12 ]

Hi, this doesn't seem to work for me. I have written a small database export / import utility. As long as I use the automatic ID generation, everything works flawlessly, but I'm trying to preserve the existing IDs. I do exactly what you've suggested in your post. It works for @OneToOne relations, but I get the following error messages when persisting entities that are parts of @ManyToOne relations:
Notice: Undefined index: [....] in [...]Doctrine/ORM/UnitOfWork.php on line 2655
I'm using version 2.2.2
Am I doing something wrong?

Comment by Endre Kósa [ 28/Oct/12 ]

Never mind. I've upgraded to Doctrine 2.3.0 and it works as expected.





[DDC-947] Optmize Code-Generation Strategies Created: 24/Dec/10  Updated: 29/Mar/11

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

Type: Improvement Priority: Major
Reporter: Benjamin Eberlei Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None


 Description   

We should optimize code-generation somehow.



 Comments   
Comment by