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

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

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


 Description   

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

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

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

For instance, the generated SQL statement generated might look like

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





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

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

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


 Description   

Imagine this situation:

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

Then somewhere else in code:

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

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

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

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

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


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

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

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

Comment by Marco Pivetta [ 19/Nov/14 ]

Does the issue also affect 2.4?

Comment by Oleg Namaka [ 24/Nov/14 ]

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

Regarding your first comment:

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

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

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

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

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

Comment by Oleg Namaka [ 25/Nov/14 ]

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

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

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

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

It looks identical to Proxy::__load generated in 2.3

Comment by Oleg Namaka [ 25/Nov/14 ]

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

Comment by Marco Pivetta [ 25/Nov/14 ]

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





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

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

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


 Description   

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

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

Message:



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

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

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

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

Comment by Doctrine Bot [ 25/Nov/14 ]

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





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

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

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


 Description   

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

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

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

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

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

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

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

I can only get half way there:

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

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

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

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

A workaround for this specific scenario is this:

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

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

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

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

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

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

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

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

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

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

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

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






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

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

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


 Description   

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

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

Message:

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

Still missing: NOT LIKE and others....



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

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

Comment by Doctrine Bot [ 24/Nov/14 ]

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

Comment by Doctrine Bot [ 24/Nov/14 ]

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





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

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

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

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

 Description   

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

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

Message:

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

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



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

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

Comment by Doctrine Bot [ 23/Nov/14 ]

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





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

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

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

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

 Description   

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

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

Message:



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

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

Comment by Marco Pivetta [ 10/Dec/13 ]

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





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

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

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


 Description   

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

User -> Address -> Plant -> Hierarchy

User OneToOne Address
Address ManyToOne Plant
Plant OneToOne Hierarchy

(all are fetched as eager loading)

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

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



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

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





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

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

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


 Description   

Hi,

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



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

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

Comment by Marco Pivetta [ 21/Nov/14 ]

Not an issue





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

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

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


 Description   

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

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

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

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



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

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





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

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

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


 Description   

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

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

Message:

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

This PR updates the documentation and variable names.



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

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





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

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

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

Windows 7, Debian GNU/Linux 7 PHP 5.5.15



 Description   

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

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

Country Entity:

namespace MyApp\Model\Entity;

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

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

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

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

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


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

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

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

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

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

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

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

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

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

CountryI18nEntity:

namespace MyApp\Model\Entity;

use Doctrine\ORM\Mapping as ORM;

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

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

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

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


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

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

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

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

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

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

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

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

}


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

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

Comment by Damir Abdijevic [ 20/Nov/14 ]

O.k. here some further information.

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

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

/* locale_id = 2 */

The sql result is correct

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

QueryBuilder

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

That results in following SQL:

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

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

Comment by Damir Abdijevic [ 20/Nov/14 ]

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

Comment by Marco Pivetta [ 20/Nov/14 ]

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

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

Comment by Damir Abdijevic [ 20/Nov/14 ]

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

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





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

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

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


 Description   

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

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

Message:

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



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

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

Comment by Doctrine Bot [ 20/Nov/14 ]

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





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

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

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


 Description   

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

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

Message:

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






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

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

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

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

 Description   

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



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

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

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

Comment by Marco Pivetta [ 15/Feb/14 ]

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

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

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

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

Comment by Jonathon Suggs [ 18/Feb/14 ]

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

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

Comment by Jonathon Suggs [ 19/Feb/14 ]

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

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

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

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

Comment by Benjamin Eberlei [ 19/Feb/14 ]

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

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

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

Comment by Jonathon Suggs [ 19/Feb/14 ]

Sorry for the confusion.

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

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

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

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

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

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

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

(abbreviated to the important steps, chronological order)

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

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

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

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

Comment by Jonathon Suggs [ 19/Feb/14 ]

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

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

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

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

Moved this to ORM issues.

Comment by Jonathon Suggs [ 19/Feb/14 ]

Steve I both agree and disagree.

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

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

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

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

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

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

Comment by Jonathon Suggs [ 19/Feb/14 ]

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





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

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

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

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


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

 Description   

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

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

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

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

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

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

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

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



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

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

Comment by Thorry [ 18/Nov/14 ]

Thank you for your super fast response!

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

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

Comment by Thorry [ 18/Nov/14 ]

This bug was already fixed by guilhermeblanco in this commit.

Comment by Thorry [ 18/Nov/14 ]

Bug was already fixed in dev.

Comment by Christophe Coevoet [ 18/Nov/14 ]

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

Comment by Thorry [ 18/Nov/14 ]

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

Comment by Marco Pivetta [ 18/Nov/14 ]

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

Comment by Christophe Coevoet [ 19/Nov/14 ]

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

Comment by Thorry [ 19/Nov/14 ]

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

Comment by Marco Pivetta [ 19/Nov/14 ]

Yeah, let me clear that.





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

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

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


 Description   

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

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

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

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

Does this make sense?



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

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

Comment by Christophe Coevoet [ 14/Nov/14 ]

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

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

Comment by Gonzalo Vilaseca [ 14/Nov/14 ]

You're right regarding the metadata.

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

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

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

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

Comment by Gonzalo Vilaseca [ 19/Nov/14 ]

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

Comment by Marco Pivetta [ 19/Nov/14 ]

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





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

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

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


 Description   

The following example does work:

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

	use IDTrait;

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

}

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

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

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

}

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






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

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

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


 Description   

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

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

Message:

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



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

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





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

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

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


 Description   

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



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

Does this affect also later versions?





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

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

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

Linux, PHP 5.5.9



 Description   

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

The hierarchy is below:

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

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

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

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

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



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

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

Comment by Marco Pivetta [ 11/Nov/14 ]

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

Comment by Patrick Rose [ 12/Nov/14 ]

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

Comment by Patrick Rose [ 12/Nov/14 ]

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

Comment by Patrick Rose [ 12/Nov/14 ]

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

Comment by Marco Pivetta [ 13/Nov/14 ]

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

Comment by Patrick Rose [ 13/Nov/14 ]

Undoing monkey patch does not fully fix issue

Comment by Patrick Rose [ 13/Nov/14 ]

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

The JoinedSubclassPersister was overridden and just commented out two lines

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

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

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

Comment by Patrick Rose [ 13/Nov/14 ]

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

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

Comment by Patrick Rose [ 18/Nov/14 ]

Is there an update on how we can resolve this?

Comment by Patrick Rose [ 18/Nov/14 ]

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

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





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

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

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


 Description   

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

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

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

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

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

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






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

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

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


 Description   

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



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

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





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

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

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

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

 Description   

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

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

Message:

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

May be related/colliding with #1178

Ping @jaspernbrouwer






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

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

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


 Description   

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

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

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



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

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





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

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

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


 Description   

Hi,

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

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

Here's a quick example:

class MyInstantiator implements \Doctrine\Instantiator\InstantiatorInterface {

    private $container;

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

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

}

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

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

DoctrineORMMappingClassMetadataInfo.php
class ClassMetadataInfo implements ClassMetadata
{
    ...

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

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

    // ...

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

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

Thanks,



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

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

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

Marking as Won't Fix.

Comment by Rekamlefat [ 13/Nov/14 ]

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

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

Have a nice evening

Comment by Marco Pivetta [ 13/Nov/14 ]

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

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

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





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

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

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


 Description   

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

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

Message:

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



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

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

Comment by Doctrine Bot [ 13/Nov/14 ]

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

Comment by Marco Pivetta [ 13/Nov/14 ]

Can't be done in 2.x





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

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

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


 Description   

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

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

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



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

Any updates on this one?

Comment by Marco Pivetta [ 13/Nov/14 ]

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





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

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

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


 Description   

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

Scenario:

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

Steps to reproduce:

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

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



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

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

Comment by Marco Pivetta [ 23/Jan/13 ]

Looks like this one is related to DDC-1734

Comment by Marco Pivetta [ 23/Feb/13 ]

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

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

Comment by Benjamin Eberlei [ 23/Feb/13 ]

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

Comment by Benjamin Eberlei [ 26/Feb/13 ]

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

Comment by Doctrine Bot [ 29/Apr/14 ]

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

Comment by Doctrine Bot [ 12/Nov/14 ]

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





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

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

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

linux, php 5.4.4, apache 2.2.22, mysql 5.5


Attachments: Text File project_debug.log    

 Description   

i have these two entities:

namespace nuevo_paquete;

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

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

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

Clase_01 have two aggregation association with Clase_03

Clase_01 ------> Clase_03

-----> Clase_03_1

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

ej:

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

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

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

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

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

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


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

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

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

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

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

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

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

i have the same problem

Comment by Benjamin Eberlei [ 29/Jul/12 ]

formatted code

Comment by Benjamin Eberlei [ 29/Jul/12 ]

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

Comment by gabriel sancho [ 30/Jul/12 ]

var_dump in attached file

Comment by gabriel sancho [ 11/Sep/12 ]

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

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

otherwise doctrine insert new registers in database for class3
after unserialize

Comment by gonzalo [ 11/Sep/12 ]

I have same problems

Comment by gabriel sancho [ 11/Sep/12 ]

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

Comment by Valentin Claras [ 11/Dec/12 ]

I have the same problem.

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

So, any news about this bug ?

Comment by Valentin Claras [ 13/Dec/12 ]

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

I hope this could help.

Comment by Marco Pivetta [ 23/Jan/13 ]

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

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

Comment by gabriel sancho [ 24/Jan/13 ]

How do I have to initialize the objects?

Comment by Marco Pivetta [ 24/Jan/13 ]

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

Comment by Marco Pivetta [ 23/Feb/13 ]

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

Comment by Marco Pivetta [ 23/Feb/13 ]

This may be a duplicate of DDC-2306

Comment by Benjamin Eberlei [ 26/Feb/13 ]

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

Comment by Marco Pivetta [ 27/Feb/13 ]

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

Comment by Doctrine Bot [ 29/Apr/14 ]

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

Comment by Doctrine Bot [ 12/Nov/14 ]

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





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

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

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


 Description   

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

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

Message:

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

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

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

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



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

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





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

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

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


 Description   

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

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

Message:

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

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

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

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






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

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

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

Mac OSX 10.8, php 5.4.11, doctrine git master version


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

 Description   

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

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

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



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

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

Comment by Doctrine Bot [ 12/Nov/14 ]

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

Comment by Marco Pivetta [ 12/Nov/14 ]

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





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

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

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

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

 Description   

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

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

Message:



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

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

Comment by Doctrine Bot [ 12/Nov/14 ]

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





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

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

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

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

 Description   

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

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

Message:

I've added this test regarding ticket DDC-2338



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

This is documented behavior and would just be an improvement

Comment by Doctrine Bot [ 13/May/14 ]

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

Comment by Doctrine Bot [ 12/Nov/14 ]

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





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

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

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


 Description   

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

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

Message:



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

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





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

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

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

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

 Description   

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

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

Message:

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



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

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

Comment by Doctrine Bot [ 11/Nov/14 ]

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





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

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

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

SQL Server


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

 Description   

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

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

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

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

When it should actually generate something like:

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

It should append lock hints after the table alias.

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



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

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

But it may cause issues with some other vendor.

Comment by William Schaller [ 21/Feb/13 ]

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

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

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

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

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

Comment by Doctrine Bot [ 14/Jan/14 ]

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

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

This is not resolved, yet.

Comment by Doctrine Bot [ 31/Jan/14 ]

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

Comment by Benjamin Eberlei [ 09/Feb/14 ]

Steve Müller When is it?

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

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





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

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

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

MSSQL 2008 R2


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

 Description   

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

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

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

One example, test 20)
Generated SQL:

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

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



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

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

Comment by Doctrine Bot [ 31/Jan/14 ]

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

Comment by Doctrine Bot [ 11/Nov/14 ]

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

Comment by Doctrine Bot [ 11/Nov/14 ]

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





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

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

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

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

 Description   

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

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

Message:

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

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

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

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

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



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

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

Comment by Doctrine Bot [ 11/Nov/14 ]

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

Comment by Doctrine Bot [ 11/Nov/14 ]

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





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

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

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

Linux Ubuntu 13.10 / PHP 5.5.3 / Mysql 5.5.x


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

 Description   

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

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

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

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



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

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





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

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

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


 Description   

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

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

Message:

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

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

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



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

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





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

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

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


 Description   

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

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

Message:

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

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



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

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

Comment by Doctrine Bot [ 11/Nov/14 ]

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





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

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

Type: New Feature Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: default-repository, entityGenerator


 Description   

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

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

Message:

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

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



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

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

Comment by Doctrine Bot [ 11/Nov/14 ]

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





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

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

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


 Description   

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

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

Message:

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



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

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

Comment by Doctrine Bot [ 11/Nov/14 ]

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





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

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

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


 Description   

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

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

Message:

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



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

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





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

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: dql, filter-collection


 Description   

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

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

Message:

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



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

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

Comment by Doctrine Bot [ 11/Nov/14 ]

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





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

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

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

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

 Description   

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

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

Message:

See #385 (this PR supersedes it)

The final aim is allowing something like:

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

This PR depends also on doctrine/common#342






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

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

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

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

 Description   

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

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

Message:

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

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

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

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

These data are also placed in the metadata.



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

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

Comment by Doctrine Bot [ 11/Nov/14 ]

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





[DDC-2881] [GH-895] Fix for no dot on Class Names Created: 04/Jan/14  Updated: 11/Nov/14

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

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

Issue Links:
Duplicate
is duplicated by DDC-3384 [GH-1180] Fix for no dot on Class Names Resolved

 Description   

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

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

Message:

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

Additionally, there is a variable ($schema) that must be contained in the class "Doctrine\DBAL\Schema\Table" on an $schema possible property but this is not available. (recomended)






[DDC-3370] [GH-1173] Fix merging of entities with associations to identical entities. Created: 05/Nov/14  Updated: 11/Nov/14  Resolved: 11/Nov/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: cascade, merge, unitofwork


 Description   

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

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

Message:

Without this patch, when an entity that refers multiple times to the same
associated entity gets merged, the second references becomes null.

The main issue is that even though doMerge returns a managed copy, that value
is not used while cascading the merge. These identicial entities are already
detected through the visitor map, but they are ignored. There should be some
refactoring so cascadeMerge calls a function that checks if the parent must be
updated, based on the return value of its call to doMerge. However, this patch
tries to impact the code as little as possible, and only introduces a new
function to avoid duplicate code.

The secondary issue arises when using inverted associations. In that case, it
is possible that an entity to be merged is already merged, so the the visitor
map is looked up by the hash of a managed copy instead of the original entity.
This means that in this case the visitor map entries should also be set to the
entity, instead of being set to 'true'.



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

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

Comment by Doctrine Bot [ 11/Nov/14 ]

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





[DDC-2558] [GH-727] update helper set for entity manager Created: 18/Jul/13  Updated: 11/Nov/14  Resolved: 18/Jul/13

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

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


 Description   

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

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

Message:



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

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

Comment by Doctrine Bot [ 18/Jul/13 ]

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

Comment by Doctrine Bot [ 18/Jul/13 ]

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

Comment by Doctrine Bot [ 11/Nov/14 ]

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





[DDC-3379] [GH-1177] Ensure metadata cache is not ArrayCache in production Created: 08/Nov/14  Updated: 11/Nov/14  Resolved: 11/Nov/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: array-cache, cache, configuration, production-settings


 Description   

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

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

Message:

This PR adds a new check to Configuration::ensureProductionSettings(). It ensures that the metadata cache does not use ArrayCache in production.

The ArrayCache forgets everything at the end of each request, while the other bundled cache engines (Memcache, MongoDB, FileCache etc.) may keep entries for much longer. The metadata only changes when the source files are changed, so in production the metadata cache only needs to be cleared when new files are deployed, just like the generation of proxy classes.

It is possible to specify/modify metadata dynamically at runtime e.g. using the loadClassMetadata event so that the metadata changes without any changes to the source files, but I assume this is not a supported use-case (at least not without clearing the metadata cache manually). Agree?

The ArrayCache is the default cache engine added by e.g. Doctrine Bundle (for Symfony) and Doctrine ORM Service Provider (for Silex), so most developers are probably not aware of it. However, accessing the metadata at run-time has a significant performance impact (for some anecdotal evidence, see https://github.com/doctrine/common/pull/319#issuecomment-60945429), so a warning in ensureProductionSettings() is relevant.

The PR also fixes the units for ensureProductionSettings() that were previously not being run due to a missing "test" prefix on the ConfigurationTest::ensureProductionSettings method name.



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

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





[DDC-3383] [GH-1179] Fix embeddables class metadata (work-in-progress) Created: 10/Nov/14  Updated: 10/Nov/14

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

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


 Description   

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

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

Message:

ClassMetadataInfo is returning more than one result in getFieldNames() for the embeddables properties. This method is used by DoctrineModule\Stdlib\Hydrator\DoctrineObject in the extraction process.

Since its returning a number of results equal the number of properties of the embedded object, it will never find the correct setter for the extraction and that causes that property to be removed from the extracted array.

I was able to solve the issue by hacking into the getFieldNames() for testing and merging the duplicated entries, and then the object was successfully extracted.

By digging into the code, i found out that there is a mapEmbedded(), but instead of using that for embeddeds, its using the default mapField, which may be the root cause of the problem.

  • [x] Hack into the getFieldNames() method to see if the expected solution would work
  • [x] Remove multiple class declaration in the same file from the files i'll work with
  • [x] Create a failing testcase
  • [ ] Create a solution





[DDC-2554] [GH-724] Remove unnecessary comment Created: 16/Jul/13  Updated: 10/Nov/14  Resolved: 16/Jul/13

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

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


 Description   

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

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

Message:



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

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

Comment by Doctrine Bot [ 10/Nov/14 ]

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





[DDC-2287] Getter/Setter: generate "isEnabled()" instead of "getEnabled()" for boolean field in entity classes Created: 08/Feb/13  Updated: 10/Nov/14

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

Type: Improvement Priority: Minor
Reporter: Sukhrob Khakimov Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Reference
relates to DDC-2924 doctrine:generate:entities docblocks ... Resolved

 Description   

It would be better if doctrine generated "isEnabled()" instead of "getEnabled()" for boolean field in entity classes. Because, it is more meaningful.



 Comments   
Comment by Marco Pivetta [ 08/Feb/13 ]

Not sure this kind of check should be handled. Starting to add all this kind of rules makes me think that it is becoming a big ball of mud

Comment by Joshua thijssen [ 31/Oct/14 ]

I agree that it would be hard to figure out which prefix to use (isEnabled() or hasEnabled() are both valid, depending on context).

However, it might be easy enough to check for a is<fieldname> or has<fieldname> method already present inside the entity, (https://github.com/doctrine/doctrine2/blob/f12c311a795b69a5f4853b079b3f8ad2c9867181/lib/Doctrine/ORM/Tools/EntityGenerator.php#L1360). If present, we could skip creating the getter as well.

This allows to (manually) change the getEnabled() into an isEnabled(), and future generations will not add the getEnabled() anymore.

It also makes it easier to confirm to PMD's booleanGetMethodName rule (http://phpmd.org/rules/naming.html#booleangetmethodname)

Comment by Marco Pivetta [ 10/Nov/14 ]

Getting back to this, I don't think we should alter codegen based on DBAL types, as per previous discussions in DDC-2924.

We're trying to decouple code generation from that, while this sort of approach increases coupling.

I'm inclined to reject the proposal until we split out the code generator into its own component.





[DDC-2924] doctrine:generate:entities docblocks for custom DBAL Types Created: 17/Jan/14  Updated: 10/Nov/14  Resolved: 20/Jan/14

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

Type: Improvement Priority: Minor
Reporter: Bogdan Yurov Assignee: Marco Pivetta
Resolution: Can't Fix Votes: 0
Labels: None

Issue Links:
Reference
is referenced by DDC-2287 Getter/Setter: generate "isEnabled()"... Open

 Description   

When I create custom type, like "foo_type", when generating entities all typehints in class are populated as-is: "@return foo_type".

Is this expected behaviour? Could I set object class name for generating?



 Comments   
Comment by Marco Pivetta [ 20/Jan/14 ]

Bogdan Yurov currently, DBAL types don't provide any kind of information on the returned type if not via docblocks. We can't rely on that.

Comment by Bogdan Yurov [ 20/Jan/14 ]

Why this is "improvement"? doctrine:generate:entities works with custom types in a buggy way - this IS a bug.

Anyways, is there a workaround? Or, maybe, more info to read?

Thanks.

Comment by Marco Pivetta [ 20/Jan/14 ]

Bogdan Yurov yes, it is an expected behavior. It is not a bug since it is not causing any actual misbehavior of the consumer code, but just an improvement in the code generator for a case that is not handled and cannot be handled right now.

Comment by Bogdan Yurov [ 20/Jan/14 ]

"for a case that is not handled and cannot be handled right now."

Why custom types can not provide Model name? For example, a method returning class name of resulting object (or primitive)?

Comment by Marco Pivetta [ 20/Jan/14 ]

Bogdan Yurov afaik, the current docblocks are generated via `Type#getName()`, which returns an arbitrary string. Works in some cases, doesn't in others.

Comment by Bogdan Yurov [ 25/Jan/14 ]

Why this is "Can't Fix"? So there would never be a way to proper create custom DBAL type, so that generating would have worked?

Comment by Marco Pivetta [ 25/Jan/14 ]

Code generation is not a primary focus of Doctrine ORM, and introducing a new API around DBAL types just for this kind of edge case (consider that code that has been generated requires accurate review anyway) is out of discussion. Therefore, since the DBAL API for types won't be altered in 2.x, this is a "won't fix"

Comment by Bogdan Yurov [ 26/Jan/14 ]

But this is not about jsut "generating entities". We NEED extra information for much more purposes: hints in IDE plugins, automated DBAL testing (for custom types), different usecases concerning model name guessing, etc.

Don't you think it is strange that the only way to find out Model name of DBAL type is reviewing its transform-class?

Guys, solution is VERY simple - just add to \Doctrine\DBAL\Types\Type new method -> getModelName, which in abstract class just would call getName method (as now model name is guessed from getName), but in custom type one can override it with something like "\Foo\DBAL\MyType".

And in doctrine DBAL Platform:
public function getDoctrineTypeComment(Type $doctrineType)

{ return '(DC2Type:' . $doctrineType->getModelName() . ')'; }

Why this can not be done in Doctrine2?

Comment by Bogdan Yurov [ 26/Jan/14 ]

Ok, seems that this is not the only use of that method. But what can be done for now?

Comment by Marco Pivetta [ 26/Jan/14 ]

But this is not about jsut "generating entities". We NEED extra information for much more purposes: hints in IDE plugins, automated DBAL testing (for custom types), different usecases concerning model name guessing, etc.

Generated code is just boilerplate code to be later edited - testing and IDE hints are secondary and are part of this subsequent editing. Code generation is supposed to ONLY give you a kickstart when importing a legacy db ONCE.

Don't you think it is strange that the only way to find out Model name of DBAL type is reviewing its transform-class?

Not strange - you are actually simply supposed to replace (for example) all docblock hints with what you actually expect the API to look like. The code generator is far from a silver bullet, and is not meant to be one either.

Guys, solution is VERY simple - just add to \Doctrine\DBAL\Types\Type new method -> getModelName, which in abstract class just would call getName method (as now model name is guessed from getName), but in custom type one can override it with something like "\Foo\DBAL\MyType".

Yes, this can be done, though it brings no real advantage until there is actually another use case that could need it (serializers, for example, and so far, serializers shouldn't be coupled to doctrine types IMO, since types can be overridden). Additionally, a DBAL type is not forced to produce one particular type of instance (for example, could return an `integer`, a `null` or a `DateTime` depending on context).

Why this can not be done in Doctrine2?

It's not about "can't be done", it's simply that it needs a better use case that isn't just a code-generation "abuse-case".

Comment by Bogdan Yurov [ 27/Jan/14 ]

Is this final decision? For example, if I make pull request with appropriate changes - it would be rejected?

I still do not understand why this can not be done, as this changes nothing in logic and api.

Comment by Marco Pivetta [ 27/Jan/14 ]

It's not final. You can propose it in a PR, but it's very likely to be rejected without a stronger use case.

Comment by Bogdan Yurov [ 27/Jan/14 ]

Ok, thanks.





[DDC-2538] [GH-713] Quick grammar fix Created: 02/Jul/13  Updated: 10/Nov/14  Resolved: 02/Jul/13

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

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


 Description   

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

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

Message:

Didn't create a JIRA ticket, as it's only a tiny change - hope that's OK.



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

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

Comment by Marco Pivetta [ 02/Jul/13 ]

Merged: https://github.com/doctrine/doctrine2/commit/dc2be816a861265ce23d54283ec956902b0aaad9

Comment by Doctrine Bot [ 10/Nov/14 ]

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





[DDC-3373] [GH-1174] Fix associations with a custom type for identifiers Created: 06/Nov/14  Updated: 10/Nov/14  Resolved: 10/Nov/14

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

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

Issue Links:
Duplicate
duplicates DDC-3380 [GH-1178] Fixing associations using U... Open

 Description   

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

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

Message:

I was running an experiment using a custom DBAL type, which converts a UUID string (in PHP) to 16 bytes binary string (in SQL) and vice versa, as identifier for a couple of entities. I noticed some associations weren't loaded correctly. This PR attempts to fix that issue.

I've included several tests:

  • Loading a OneToOne association
  • Loading a OneToOne association with composite identifier
  • Loading a OneToOne association with composite identifier including a foreign one
  • Loading a OneToMany association
  • Loading a OneToMany association with composite identifier
  • Loading a OneToMany association with composite identifier including a foreign one
  • Loading a ManyToMany association
  • Loading a ManyToMany association with composite identifier
  • Loading a ManyToMany association with composite identifier including a foreign one

During the "ManyToMany association tests ...", I discovered the join-table wasn't populated properly. The columns were filled with the UUID string (in stead of the 16 bytes binary string). This has been addressed as well.

I've included these tests to verify that:

  • Removing entities from a ManyToMany association
  • Removing entities from a ManyToMany association with composite identifier
  • Removing entities from a ManyToMany association with composite identifier including a foreign one

When applying a fix for the "Loading a OneToMany association with composite identifier including a foreign one" test, the "Loading a OneToOne association with composite identifier including a foreign one" test started to produce an error.

This is due to the Proxy object containing a 16 bytes binary string (in stead of the UUID string) for the foreign identifier.

Also the "Removing entities from a ManyToMany association with composite identifier including a foreign one" tests keeps failing because there's a 16 bytes binary string (in stead of the UUID string) for the foreign identifier in the Collection.

I have a feeling these last 2 cases are not because of an issue in the Persisters, but because of an issue in the Hydrators. Unfortunately I don't know where to begin looking

I could really need some help finishing this up!



 Comments   
Comment by Jasper N. Brouwer [ 07/Nov/14 ]

PS: I've applied this fix to the 2.4 branch (in stead of master) on purpose, because I'm going to use this in a project and unfortunately can't wait until it's merged back into 2.4.

If this is a problem and must be done on master, I'll look into that.

Comment by Marco Pivetta [ 07/Nov/14 ]

Jasper N. Brouwer multiple versions may be affected: we just need to be sure that the bug wasn't already fixed in master (2.5), so please check that one as well.

Comment by Jasper N. Brouwer [ 07/Nov/14 ]

Master is also affected. I think I've got some spare time this evening, so I'll port the PR to master.

Could you perhaps look at the remaining issue and maybe give some hint on where I should start looking? I would appreciate it if I could finish that up too this evening.

Comment by Doctrine Bot [ 09/Nov/14 ]

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

Comment by Jasper N. Brouwer [ 10/Nov/14 ]

The PR has been ported to master:

http://www.doctrine-project.org/jira/browse/DDC-3380
https://github.com/doctrine/doctrine2/pull/1178

This ticket can be closed.

Comment by Doctrine Bot [ 10/Nov/14 ]

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





[DDC-3381] orm:schema-tool:update shows incorrect changes with MasterSlaveConnection wrapper class Created: 09/Nov/14  Updated: 10/Nov/14

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

Type: Bug Priority: Major
Reporter: Pieter Vogelaar Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: connection, ddl, master-slave, schematool


 Description   

My entities and database are in sync. If I use the default Doctrine connection configuration it shows "Nothing to update - your database is already in sync with the current entity metadata.". This is what I would expect and is correct.

'doctrine' => array(
        'connection' => array(
            'orm_default' => array(
                'driverClass' => 'Doctrine\DBAL\Driver\PDOMySql\Driver',
                'params' => array(
                    'host'     => 'localhost',
                    'port'     => '3306',
                    'user'     => 'myuser',
                    'password' => 'mypassword',
                    'dbname'   => 'example',
                    'charset'  => 'utf8',
                ),
        ),
),

But with the MasterSlaveConnection configuration, I always get the same changes which are a lot, you would think the database is empty at the moment.

'doctrine' => array(
        'connection' => array(
            'orm_default' => array(
                'wrapperClass' => 'Doctrine\DBAL\Connections\MasterSlaveConnection',
                'params' => array(
                    'driver' => 'pdo_mysql',
                    'master' => array(
                        'host' => 'localhost',
                        'port' => '3306',
                        'user' => 'myuser',
                        'password' => 'mypassword',
                        'dbname' => 'example',
                        'charset' => 'utf8',
                    ),
                    'slaves' => array(
                        array(
                            'host' => 'localhost',
                            'port' => '3306',
                            'user' => 'myuser',
                            'password' => 'mypassword',
                            'dbname' => 'example',
                            'charset' => 'utf8',
                        ),
                    ),
                ),
            ),
        ),
    ),
),


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

Can you come up with a functional test case for this? Couldn't reproduce from here.





[DDC-3380] [GH-1178] Fixing associations using UUIDs Created: 09/Nov/14  Updated: 10/Nov/14

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

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

Issue Links:
Duplicate
is duplicated by DDC-3373 [GH-1174] Fix associations with a cus... Resolved

 Description   

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

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

Message:

This is a port of #1174.

I was running an experiment using a custom DBAL type, which converts a UUID string (in PHP) to 16 bytes binary string (in SQL) and vice versa, as identifier for a couple of entities. I noticed some associations weren't loaded correctly. This PR attempts to fix that issue.

_Remaining issue_

There are 2 tests that involve OneToOne and OneToMany associations with composite ids of which one is a foreign one. When the owning side is fetched from the DB, a Proxy object is created for the inversed side. But this Proxy contains incorrect identifiers:

public $id => string(36) "12345678-9abc-def0-1234-56789abcdef0"
public $foreignEntity => string(16) "????????????????"

Those question-marks represent 16 bytes of binary data. The thing is that `$foreignEntity` should contain another Proxy object (or perhaps the UUID of the foreign entity, I'm not sure).

I'm at a loss here Hopefully someone can point me to where identity through foreign Entities is managed!



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

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

Comment by Doctrine Bot [ 09/Nov/14 ]

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

Comment by Doctrine Bot [ 10/Nov/14 ]

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

Comment by Jasper N. Brouwer [ 10/Nov/14 ]

Affects Versions: master (2.5) and 2.4 are confirmed, but I suspect this goes back to all versions.





[DDC-3382] With orphanRemoval, cannot delete and re-add entity Created: 10/Nov/14  Updated: 10/Nov/14  Resolved: 10/Nov/14

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

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


 Description   

I have a one-to-many relation with orphanRemoval=true.

If I remove an entity from the related collection and add it back, the entity is removed from the database.

$employee = $company->getEmployees()->first();
$company->getEmployees()->removeElement($employee);
$company->getEmployees()->add($employee);

$em->persist($company);
$em->flush();
// Now $employee is deleted from the database.

The expected behaviour is to leave the entity in the database, because it was present in the PersistentCollection when $em->persist() was called.



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

This is expected behavior, and won't be changed for now.





[DDC-2131] Fetch join not working on class table inheritance Created: 07/Nov/12  Updated: 08/Nov/14  Resolved: 12/Nov/12

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

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

Issue Links:
Duplicate
duplicates DDC-1256 Generated SQL error with DQL WITH and... Resolved
Reference
is referenced by DDC-2869 [GH-886] [DDC-1256] Fix applying ON/W... Resolved

 Description   

I have an entity Appointment, that is associated with application forms.
I have an abstract class AbstractApplicationForm that has multiple (6) child classes.

The mapping info for the abstract application form looks like this:

AbstractApplicationForm.php
/**
 * @ORM\Entity()
 * @ORM\Table("applicationform")
 * @ORM\InheritanceType("JOINED")
 * @ORM\DiscriminatorColumn(name="discr", type="string")
 * @ORM\DiscriminatorMap({
 *     "slc" = "SlcApplicationForm",
 *     "vsdb" = "VsdbApplicationForm",
 *     "vss" = "VssApplicationForm",
 *     "opzd" = "OpzdApplicationForm",
 *     "vzu" = "VzuApplicationForm",
 *     "opzdvzu" = "OpzdVzuApplicationForm"
 * })
 */
abstract class AbstractApplicationForm
...

I have an OneToMany connection from Appointment to AbstractApplicationForm.
When i construct an DQL, to get an appointment with only specific application forms it gets wrong translated into SQL.

For instance if the query builder looks like this:

$qb->select('ap, af')
   ->from(Appointment::getClass(), 'ap')
   ->leftJoin('ap.applicationForms', 'af', 'WITH', 'af.id = 123456789')
   ->andWhere('ap.id = :appointment')
   ->setParameter('appointment', $appointment);

So with this dql i should get an appointment with filtered application forms. In this case it whould return an appointment with only one application form (that with the id 123456789).
But it returns all associated application form instead on only that with the id 123456789, because it ignores the with clause.

Here is the SQL that gets generated from the DQL:

SELECT ...
FROM program_execution_activity_appointment p8_, program_execution_activity_appointment p0_
LEFT JOIN applicationform a1_ ON p0_.id = a1_.appointment_id 
LEFT JOIN applicationform_slc a2_ ON a1_.id = a2_.id 
LEFT JOIN applicationform_vsdb a3_ ON a1_.id = a3_.id 
LEFT JOIN applicationform_vss a4_ ON a1_.id = a4_.id 
LEFT JOIN applicationform_opzd a5_ ON a1_.id = a5_.id 
LEFT JOIN applicationform_vzu a6_ ON a1_.id = a6_.id 
LEFT JOIN applicationform_opzdvzu a7_ ON a1_.id = a7_.id AND (a1_.id = 123456789) 
WHERE p0_.id = 1

The problem i see here is that the AND is added to the last join (applicationform_opzdvzu). But it should added to the first join (applicationform). Because the first join represents the parent entity (AbstractApplicationForm).
There is also a problem in the FROM clause. The problem is that program_execution_activity_appointment p8_ is never used anywhere else, except in the from clause.

The generated query should look like this:

SELECT ...
FROM program_execution_activity_appointment p0_
LEFT JOIN applicationform a1_ ON p0_.id = a1_.appointment_id AND (a1_.id = 123456789) 
LEFT JOIN applicationform_slc a2_ ON a1_.id = a2_.id
LEFT JOIN applicationform_vsdb a3_ ON a1_.id = a3_.id
LEFT JOIN applicationform_vss a4_ ON a1_.id = a4_.id
LEFT JOIN applicationform_opzd a5_ ON a1_.id = a5_.id
LEFT JOIN applicationform_vzu a6_ ON a1_.id = a6_.id
LEFT JOIN applicationform_opzdvzu a7_ ON a1_.id = a7_.id
WHERE p0_.id = 1

This sql works as expected.

I hope i was clear enough what the problem is.



 Comments   
Comment by Benjamin Eberlei [ 12/Nov/12 ]

This is a duplicate of DDC-1256

Comment by Benjamin Eberlei [ 12/Nov/12 ]

This is not easy to fix as you can see DDC-1256 is open for a while. However in your case there is an easy solution, why not fetch the appointment form by id, and then go the association to the appointment? This is the inverse operation on that relation, but suits your needs perfectly.

Comment by gseric [ 29/May/13 ]

Benjamin, this issue is duplicate of duplicate (according to your status changes). So original issues is DDC-349, but this error was introduced in 2.3. DDC-349 was created way back in 2010 so it can't be the same problem.

As far as I can tell, the problem was introduced with "Arbitrary join support" feature:
https://github.com/doctrine/doctrine2/pull/368 (SqlWalker.php changes)
Basically, in version 2.3 and later WITH statement is wrongly handled after SqlWalker::_generateClassTableInheritanceJoins()
Before 2.3 it was handled before.

You can see it clearly in this issue's description:
should be (< 2.3):
LEFT JOIN <CTI parent entity> ON <auto condition> AND <my custom WITH part> <CTI child left joins>
but we get (>= 2.3):
LEFT JOIN <CTI parent entity> ON <auto condition> <CTI child left joins> AND <my custom WITH part>

This issue can't be easily avoided in situation where you want to SELECT only one child row per parent row (based on some condition). WITH is natural and fastest option.

Comment by gseric [ 01/Jul/13 ]

This bug seems to be recognized and fixed (pull request ATM) in DDC-2506

Comment by Doctrine Bot [ 13/Aug/13 ]

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

Comment by Artur Eshenbrener [ 22/Dec/13 ]

Why do you think that applying ON/WITH conditions only to base table is good? What if I will reference to fields from child entity in ON/WITH clause?
I think that all user conditions should be applied to last join in class table inheritance joins, because only in that join references to all tables are available. Otherwise I get sql error.

Comment by Artur Eshenbrener [ 23/Dec/13 ]

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

Comment by Doctrine Bot [ 17/Feb/14 ]

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

Comment by Doctrine Bot [ 27/Oct/14 ]

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

Comment by Doctrine Bot [ 08/Nov/14 ]

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





[DDC-2507] [GH-698] Fix for [DDC-2506] CTI JOINs and WITH conditionals Created: 14/Jun/13  Updated: 08/Nov/14  Resolved: 24/Jun/13

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

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


 Description   

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

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

Message:

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

Moved the `SqlWalker::walkConditionalExpression()` out of `walkJoin()` and into `walkJoinAssociationDeclaration()` after the base class JOIN but *before* the `_generateClassTableInheritanceJoins()`, thus allowing WITH conditions in Class Table Inheritance joins to apply correctly.

On a side note, I'm not able to get phpunit to run (even on a clean Master) so I'm leaving the testing up to Travis.



 Comments   
Comment by Doctrine Bot [ 24/Jun/13 ]

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

Comment by Doctrine Bot [ 13/Aug/13 ]

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

Comment by Doctrine Bot [ 20/Oct/14 ]

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

Comment by Doctrine Bot [ 27/Oct/14 ]

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

Comment by Doctrine Bot [ 08/Nov/14 ]

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





[DDC-2527] [GH-708] Unit test and fix for DDC-2506: CTI JOIN WITH conditionals failing. Created: 24/Jun/13  Updated: 08/Nov/14  Resolved: 25/Aug/13

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

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


 Description   

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

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

Message:

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



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

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

Comment by Marco Pivetta [ 25/Aug/13 ]

DDC-2506

Comment by Doctrine Bot [ 27/Oct/14 ]

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

Comment by Doctrine Bot [ 08/Nov/14 ]

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





[DDC-2235] Single table inheritance discriminator in WHERE when using arbitrary join syntax Created: 11/Jan/13  Updated: 08/Nov/14  Resolved: 16/Aug/13

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

Type: Bug Priority: Major
Reporter: Jordi Forns Assignee: Guilherme Blanco
Resolution: Fixed Votes: 6
Labels: None

Issue Links:
Duplicate
duplicates DDC-1940 Doctrine DQL: erroneous sql generatio... Resolved

 Description   

The condition on the discriminator column is placed in the WHERE clause when using arbitrary join syntax, which renders LEFT JOINs useless.

Given these classes:
A - no inheritance
B1 - abstract, root of a hierarchy, discriminator column is named 'type'
I setup a query builder like this:

$qb->select('a.id AS idA, b.id AS idB')
    ->from('\Entity\A', 'a')
    ->leftJoin('\Entity\B1', 'b', \Doctrine\ORM\Query\Expr\Join::WITH, 'a.something=b.something');
And the SQL Doctrine generates is something like this:
SELECT a.id, b.id FROM a LEFT JOIN b ON (a.something=b.something) WHERE b.type IN ('1', '2', '3')

The problems is that the WHERE condition makes the left join useless.

The condition on the discriminator column should be placed in the JOIN clause to avoid the problem.



 Comments   
Comment by Ondrej Hlavaty [ 10/Feb/13 ]

Can this be somehow worked around? If not, it is really serious problem...

Comment by Jordi Forns [ 18/Feb/13 ]

I couldn't find any workaround.
Trying to force the 'type' condition in the join clause resulted useless as Doctrine would add the 'where' condition regardless.

Comment by Michel Salib [ 22/Mar/13 ]

Easier way to workaround right now, is to declare a OneToMany from class A to class B on a protected field (no need of getter or setter). That way you can do classic join via relationship transversing and then the condition will be placed in the ON part of the query.

Comment by Yuta Konishi [ 01/Apr/13 ]

I could access with below codes. You should use RAW SQL it is easy solution I guess. good luck.

$qb = $em->createQueryBuilder();

$qb->select('a, b')
->from('YourEntity1', 'a')
->leftJoin('YourEntity2', 'b', \Doctrine\ORM\Query\Expr\Join::WITH, 'a.id = b.relationId');

$raw_sql = $qb->where( 
	$qb->expr()->in('a.relationId', $ids)
)
->orderBy('a.updatedAt', 'DESC')
->setMaxResults(10)
->getQuery()->getSQL();

$conn = $em->getConnection();
$stmt = $conn->query($raw_sql);

/* $stmt->fetchAll(); // access as Array */
Comment by Benjamin Eberlei [ 04/Apr/13 ]

Assigned to Alexander

Comment by Benjamin Eberlei [ 14/Apr/13 ]

Duplicate of DDC-1940

Comment by Jordi Forns [ 22/Apr/13 ]

Benjamin: this bug doesn't seem to be a dupe of DDC-1940. Actually that issue doesn't seem to be a bug at all.

As a reminder, the problem in this issue is that when performing arbitrary left joins on entities that are part of a class hierarchy, the discriminator condition is placed in the where clause instead of the join clause. This means that rows that could not be joined will have null values in the discriminator column and thus will not be returned because of the where condition (which will contain something like " where x.discriminator in (1,2,3) ").

Comment by Tom Arnfeld [ 27/Apr/13 ]

Has this issue been resolved elsewhere? From reading over DDC-1940 it doesn't seem to be a duplicate at all. I'm experiencing the same problem as Jordi and can't seem to find a solution. Is there any particular reason the `IN ()` predicate is not a part of the join, but instead placed in the main `WHERE` clause?

Comment by Tom Arnfeld [ 28/Apr/13 ]

I've been looking into the root cause of this bug (or feature..) to try and understand why it's happening, and after trying various possible fixes (a little hard without full understanding of the Doctrine/Query internals) I've ended up with a fix that seems to work well for my use case, at least. I've not run any of the unit tests (I plan to, and may adjust my fix based on that) but the top revision is my change... https://gist.github.com/tarnfeld/a6bb50ec707c7af1c5dc/revisions

Would love some feedback.

Pull request here: https://github.com/doctrine/doctrine2/pull/656

Comment by Jordi Forns [ 29/Apr/13 ]

Tom's fix moves the condition of the discriminator column to the LEFT JOIN, which is exactly what was needed.

Alexander: could you please give it a look?

Comment by Jordi Forns [ 23/May/13 ]

Tom's proposal seems to fix the issue.

Comment by Gordon Forsythe [ 11/Jun/13 ]

Agree, Tom's pull request looks like it fixes the issue. Is there a reason this hasn't been merged yet?

Comment by Gordon Forsythe [ 24/Jun/13 ]

I believe this may have been fixed by #DDC-2506 but I haven't tested it yet.
There is a pull request for it https://github.com/doctrine/doctrine2/pull/708 and there has been recent activity.
Disregard, not related.

Comment by Tom Arnfeld [ 24/Jun/13 ]

The two don't seem to be at all related to me, or maybe i'm missing something? Also, this PR has been open for two months, with no sign of being merged :/

Comment by Doctrine Bot [ 13/Aug/13 ]

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

Comment by Benjamin Eberlei [ 13/Aug/13 ]

Gordon Forsythe I don't like your tone. This is an open-source project and we do this in our free time. Please respect that we cannot offer specific response times at all.

Comment by Doctrine Bot [ 16/Aug/13 ]

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

Comment by Marco Pivetta [ 16/Aug/13 ]

Fixed at https://github.com/doctrine/doctrine2/commit/605c32dbb384e25117625a7cb4db4e7319a16bae ( https://github.com/doctrine/doctrine2/pull/758 )

Comment by Benjamin Eberlei [ 20/Aug/13 ]

merged into 2.4

Comment by Doctrine Bot [ 09/Aug/14 ]

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

Comment by Doctrine Bot [ 27/Oct/14 ]

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

Comment by Doctrine Bot [ 08/Nov/14 ]

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





[DDC-2506] WITH Conditionals on Class Table Inheritance LEFT JOINs are inserted incorrectly Created: 14/Jun/13  Updated: 08/Nov/14  Resolved: 20/Aug/13

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

Type: Bug Priority: Major
Reporter: Matt Janssen Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 2
Labels: dql, inheritance, joins, sql-walker


 Description   

The following JOIN

JOIN c.ctiRelationship cti WITH cti.id IN (42)

generates unexpected SQL

LEFT JOIN class_base p1_ ON u1_.cti_id = p1_.id 
LEFT JOIN class_child1 p2_ ON p1_.id = p2_.id
LEFT JOIN class_child2 p3_ ON p1_.id = p3_.id AND (p1_.id IN (42)) 

when it SHOULD be generating

LEFT JOIN class_base p1_ ON u1_.cti_id = p1_.id AND (p1_.id IN (42)) 
LEFT JOIN class_child1 p2_ ON p1_.id = p2_.id
LEFT JOIN class_child2 p3_ ON p1_.id = p3_.id


 Comments   
Comment by Matt Janssen [ 14/Jun/13 ]

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

Comment by gseric [ 01/Jul/13 ]

Thanks Matt, this bug prevented me to upgrade to 2.3. BTW it was originally reported in DDC-2131 (I put a comment there to redirect users here).

Comment by Gordon Forsythe [ 03/Jul/13 ]

I've tested this PR and it does work.

Comment by Doctrine Bot [ 13/Aug/13 ]

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

Comment by Doctrine Bot [ 17/Feb/14 ]

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

Comment by Doctrine Bot [ 27/Oct/14 ]

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

Comment by Doctrine Bot [ 08/Nov/14 ]

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





[DDC-2553] [GH-723] Remove extra semicolon before ->setParameter() calls Created: 15/Jul/13  Updated: 08/Nov/14  Resolved: 16/Jul/13

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

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


 Description   

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

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

Message:

Just noticed in the query builder documentation that there are a couple of extra semicolons before the calls to `->setParameter()`.



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

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

Comment by Doctrine Bot [ 08/Nov/14 ]

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





[DDC-1037] The EntityManager is closed when an exception is thrown in UoW's commit method Created: 16/Feb/11  Updated: 08/Nov/14  Resolved: 16/Feb/11

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

Type: Bug Priority: Major
Reporter: Sergei Lissovski Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None
Environment:

php 5.3.2, mysql, win7


Issue Links:
Duplicate
is duplicated by DDC-3363 "The EntityManager is closed." after ... Closed

 Description   

If an exception is thrown in commit method of UoW then the EM will be closed automatically and there's no way to restore it from the closed state rather than creating a new instance. To my mind this is a quite questionable feature. We faced this problem while executing functional tests - in our case if one of tests fails then other tests will fail as well, ORMException is thrown stating that EM is already closed.

https://github.com/doctrine/doctrine2/blob/2.0.0/lib/Doctrine/ORM/UnitOfWork.php#L290 - here is it.



 Comments   
Comment by Benjamin Eberlei [ 16/Feb/11 ]

There is absolutly no way to recover from an exception in the UnitOfWork. There is just no way to tell how to reset the UnitOfWork state to accomplish that.

For functional tests you should re-use the Database connecton but create a new EntityManager for each test!

Comment by John Kleijn [ 28/Feb/11 ]

I'm sure there is some valid reason to close the entity manager on exception, but it is a debugging nightmare. It also makes cleanup after an exception impossible. An example:

 
public function create($data)
{
	$event = $this->_factory($data);

	$events = is_array($event) ? $event : array($event);

	$this->flush();

	try {
		foreach($events as $event){
			$this->_createMessages($event);
		}
		return count($events) == 1 ? $events[0] : $events;
	}
	catch(\Exception $e){
		foreach($events as $event){
			$this->_deleteMessages($event);
			$this->getEntityManager()->remove($event);
		}
		throw $e;
	}
}

The event objects need to be persisted before the messages are created, which means they should be removed when something goes wrong.

Comment by Benjamin Eberlei [ 28/Feb/11 ]

I dont understand the code, because flush is called outside the try catch. Why cant you persist messages and events in one flush? Cant you just wrap both flushes into one transaction? See the Transaction docs. If an exception is thrown the transaction is aborted and all written data is discarded.

Comment by Ksaveras [ 25/Oct/14 ]

It's not resolved anyway.

after insert error in try catch i get error "The EntityManager is closed"

Why i have to code app to use and reuse doctrine?

Comment by Marco Pivetta [ 05/Nov/14 ]

The EntityManager is in an invalid state once a failure has occurred, and there's no way for us to repair that state.

A lot of things may have happened:

  • data could be invalid
  • connection to the DB could have been lost
  • data is corrupted
  • cache had corrupted values in it
  • etc.

The simplest and cleanest solution is to simply get a new instance of the EntityManager.

Comment by Ksaveras [ 08/Nov/14 ]

Make it throw Exception and if it is not handled by other code - then could be closed.
I want to catch exception and handle errors. Creating Entity Manager can not be done in one line, especially in other frameworks.

Imagine person gives invalid money in bank - then bank should be closed forever like You do now?

Comment by Marco Pivetta [ 08/Nov/14 ]

The bank would surely have to close the bank account and start researching what went wrong before re-opening communication with that client.





[DDC-3375] UnitOfWork: new operation attach(): merge without persist Created: 06/Nov/14  Updated: 08/Nov/14  Resolved: 07/Nov/14

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

Type: Improvement Priority: Major
Reporter: Mathieu De Zutter Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: unitofwork


 Description   

Currently UnitOfWork provides the following three methods that make entities cross the boundaries of being managed or not:

  • persist()
  • merge()
  • detach()

In my opinion, there's an operation missing: attach(). It would be similar to merge(), but it would not call persist(). It would be the counterpart of detach().

Example 1: Simple case

if (...)
$person = new Person;
else
$person = $em->find('Person', $id);

// At some point I decide that I don't want to store the person, so I don't call persist()

$dog = new Dog;
$em->persist($dog);

$em->flush(); // OK, commits only the dog

Example 2: Same, but the person is serialized along the way

if (...)
$person = new Person;
else
$person = $em->find('Person', $id);

// Serialize the person
$serializedPerson = serialize($person);

// At some point I want to restore the person
$person = unserialize($serializedPerson);

// Because it could have been a managed entity before, I need to merge it.
$person = $em->merge($person);

// But yet again, I decide that I don't want to store the person, so I don't call persist()

$dog = new Dog;
$em->persist($dog);

$em->flush(); // Oops, if the person was NEW, it has become managed, so it is commited now!

If merge() was replaced by attach(), flush() would not have commited the person.



 Comments   
Comment by Christophe Coevoet [ 06/Nov/14 ]

I don't understand what attach would do in your case. flush is about flushing the whole unit of work. I don't understand what attach() would do if it does not attach the entity to the unit of work.

Comment by Christophe Coevoet [ 06/Nov/14 ]

And actually, the opposite of detach() already exists: it is persist(). It makes the object enter the unit of work, while detach makes it leave the unit of work.

Note that merge is not making the object cross the boundary. The object passed to merge() never enters the unit of work. what happens is that the data inside this object are applied to an object inside the boundary (potentially a new one if there was no object with this identifier).
When using merge, you are explicitly asking to apply the data inside the unit of work, so it is logical that something gets flushed.

and note that in your example 1, your person is managed half of the time (when coming from find() rather than a new instance). And in such case, it will be flushed. You are not flushing only the dog.

Comment by Mathieu De Zutter [ 08/Nov/14 ]

OK, makes sense.





[DDC-2552] [GH-722] Support for order by association (for 2.3 branch) Created: 15/Jul/13  Updated: 08/Nov/14  Resolved: 15/Jul/13

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: collection, orm
Environment:

Symfony 2.3



 Description   

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

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

Message:

I need to `@OrderBy` an association, which does not work in `2.3` but I found the pull request https://github.com/doctrine/doctrine2/pull/549 by @FabioBatSilva who has implemented this in branch `2.4`.

I have copied the code, adjusted it for `2.3` and tested it in a real life application

The original pull request is related to Doctrine Issue #2241(http://www.doctrine-project.org/jira/browse/DDC-2241).
The ordering of associations has been implemented in Doctrine Issue #195(http://www.doctrine-project.org/jira/browse/DDC-195).

Please integrate this into `2.3` because `2.4` is not stable until now and thus it is not usable for many people.



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

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

Comment by Christian S. [ 15/Jul/13 ]

Can be closed (see https://github.com/doctrine/doctrine2/pull/722#issuecomment-20960237)

Comment by Doctrine Bot [ 08/Nov/14 ]

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

Comment by Doctrine Bot [ 08/Nov/14 ]

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





[DDC-3361] Doctrine error while trying to execute a DQL query on PostgreSQL 9.2.x Created: 23/Oct/14  Updated: 08/Nov/14

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

Type: Bug Priority: Major
Reporter: Reynier Perez Mira Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: postgresql, typecast
Environment:

CentOS 6.5, PostgreSQL 9.2, Symfony 2.5.5, Doctrine 2.4.6



 Description   

I have this DQL on a repository class:

    public function filterNorm($codigo = null, $anno = null, $term = null, $comite_tecnico = null)
    {
        $qb = $this->getEntityManager()->createQueryBuilder();
        $qb
                ->select('n')
                ->from("AppBundle:Norma", "n");

        if ($codigo != NULL) {
            $qb->where(
                    $qb->expr()->like('n.numero', $qb->expr()->literal('%'.$codigo.'%'))
            );
        }

        if ($anno != NULL) {
            $qb->orWhere(
                    $qb->expr()->like('n.anno', $qb->expr()->literal('%'.(int) $anno.'%'))
            );
        }

        if ($term != NULL) {
            $qb->orWhere(
                    $qb->expr()->like('n.nombre', $qb->expr()->literal('%'.$term.'%'))
            );
        }

        if ($comite_tecnico != NULL) {
            $qb->orWhere(
                    $qb->expr()->like('n.comite_tecnico', $qb->expr()->literal('%'.(int) $comite_tecnico.'%'))
            );
        }

        return $qb->getQuery()->getResult();
    }

And when I try to execute it, leaving the first paramter null, I got this error:

An exception occurred while executing 'SELECT n0_.numero AS numero0, n0_.anno AS anno1, n0_.id AS id2, n0_.nombre AS nombre3, n0_.activo AS activo4, n0_.comite_tecnico_id AS comite_tecnico_id5 FROM nomencladores.norma n0_ WHERE n0_.anno LIKE '%34%' OR n0_.nombre LIKE '%sad%'':

SQLSTATE[42883]: Undefined function: 7 ERROR: operator does not exist: integer ~~ unknown
LINE 1: ...o_id5 FROM nomencladores.norma n0_ WHERE n0_.anno LIKE '%34%...
^
HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. 

I think in somewhere Doctrine is failing or not, not so sure, if not what will be the solution around this issue I'm having?



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

First of all: do not hardcode parameters in your DQL, as that represents a possible DQL injection vector.

Is your schema in sync with the ORM mappings? Postresql seems to complain about a missing operator between incompatible types.

Comment by Reynier Perez Mira [ 23/Oct/14 ]

What you mean with "do not hardcode parameters in your DQL"? How should I do this? And yes schema and ORM mappings are good:

Symfony > doctrine:schema:validate
[Mapping] OK - The mapping files are correct.
[Database] OK - The database schema is in sync with the mapping files.

Comment by Marco Pivetta [ 23/Oct/14 ]

What you mean with "do not hardcode parameters in your DQL"? How should I do this?

You wrote:

$qb->where($qb->expr()->like('n.numero', $qb->expr()->literal('%'.$codigo.'%')));

Should be:

$qb->where($qb->expr()->like('n.numero', ':codigo'));
$qb->setParameter('codigo', '%' . $codigo . '%');
Comment by Reynier Perez Mira [ 08/Nov/14 ]

Hi there @ocramius any advice around this issue? Any tip to get ride of this? I have similar queries all over the application I'm working on and still don't know how to deal with this, thanks

Comment by Marco Pivetta [ 08/Nov/14 ]

Seems to be a db-side type mismatch in a comparison, not a D2 bug.

Comment by Reynier Perez Mira [ 08/Nov/14 ]

@ocramius and how I should deal with this? Any idea?





[DDC-2549] [GH-721] Updated batch-processing link extension Created: 11/Jul/13  Updated: 07/Nov/14  Resolved: 11/Jul/13

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

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


 Description   

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

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

Message:

I've changed the batch processing link adding .html else the link is broken



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

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

Comment by Marco Pivetta [ 11/Jul/13 ]

Merged: https://github.com/doctrine/doctrine2/commit/0aed9595c3ceec81dcf44a4eefc24bb49051868e

Comment by Doctrine Bot [ 07/Nov/14 ]

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





[DDC-3376] Only one row is returned Created: 06/Nov/14  Updated: 07/Nov/14

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

Type: Bug Priority: Major
Reporter: Patryyyck Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: inheritance, lazy-loading, n+1-queries, sti
Environment:

Linux Mint 17
PHP 5.5.9
Apache 2.4.7
Symfony 2.4.10
Doctrine ORM 2.4.6
Doctrine DBAL 2.4.3
Sql Server database



 Description   

Hi,

I don't know if you are the appropriate person.
I have an issue with Doctrine ORM or DBAL.
By the way, i'm not sure the issue is in one of these bundles.

I'm trying to get all the rows of on an entity A which is a SINGLE_TABLE with 3 discriminators.
This entity has a property "parent" which is a self referencing property (ManyToOne on entity A).

The getResult of my query only return the first row of my table.
When i replace getResult by getArrayResult, i have all my table.
But i want the objects

After hours of debugging, i saw that the Doctrine ORM ObjectHydrator.php loops on the result of my query (which have the good number of results):

while ($row = $this->_stmt->fetch(PDO::FETCH_ASSOC)) {
    $this->hydrateRowData($row, $cache, $result);
}

But, the hydrateRowData executes another query to get the parent of each row (Doctrine DBAL Connection.php function executeQuery).
This function prepares a query to get the parent with a param (parent id) and i think the prepare function return the same statement (stmt) as the first query (the list of all the entity A).
So, the prepared query is executed but when the Doctrine ORM ObjectHydrator.php want to fetch the second row, he considers that there's no more rows to fetch and return the first rows.

I don't know if i am clear enough. Tell me if you want more details.

Oh. I forgot. If i try the same request with the same datas but in a mySQL database (pdo_mysql), i have a good result. I don't know if that helps.

Thanks

Regards



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

The issue you described is very well known and it is a limitation of the ORM. What happens is following:

1. you have an inheritance A -> B | C | D (A being the root of the inheritance)
2. A has a self-referencing association to A (typically like a hierarchy of parent-child)
3. the ORM tries to load an A instance that has a reference to a parent of type A. In order to do so, the ORM has to resolve the actual type of the referenced parent, and therefore cannot lazily load it via a proxy (a query has to be executed in order to find out the value of the discriminator column)

This means that for performance reasons you should NEVER reference the root of an inheritance, but only leafs (where the ORM does not need to do this sort of resolution).

See also http://doctrine-orm.readthedocs.org/en/latest/reference/inheritance-mapping.html#id4 (Performance impact of inheritance mapping) for more details.

Comment by Patryyyck [ 07/Nov/14 ]

Thanks Marco for your quick answer.

I understand the ORM limitation.
But i still don't understand why this limitation doesn't exist when i use a MySQL database.





[DDC-3378] [GH-1176] Add test exposing UnitOfWork merge bug Created: 07/Nov/14  Updated: 07/Nov/14

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

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


 Description   

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

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

Message:

I hope that I'm doing something wrong and that this is not a bug ...






[DDC-3372] PersistentCollection clear function takes snapshot when the collection is cleared Created: 06/Nov/14  Updated: 07/Nov/14

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

Type: Bug Priority: Minor
Reporter: Ward Peeters Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: collection, orm
Environment:

Symfony 2.5.6



 Description   

I'm not sure if it's a bug or you guys have a reason why you do it. The problem occurs when you do a $coll->clear() he will clear the collection and whenever it's cleared the takeSnapshot is ran as well so our snapshot is empty so we lose the prevous state of the collection.

public function clear()
    {
        if ($this->initialized && $this->isEmpty()) {
            return;
        }

        $uow = $this->em->getUnitOfWork();

        if ($this->association['type'] & ClassMetadata::TO_MANY &&
            $this->association['orphanRemoval'] &&
            $this->owner) {
            // we need to initialize here, as orphan removal acts like implicit cascadeRemove,
            // hence for event listeners we need the objects in memory.
            $this->initialize();

            foreach ($this->coll as $element) {
                $uow->scheduleOrphanRemoval($element);
            }
        }

        $this->coll->clear();

        $this->initialized = true; // direct call, {@link initialize()} is too expensive

        if ($this->association['isOwningSide'] && $this->owner) {
            $this->changed();

            $uow->scheduleCollectionDeletion($this);

            $this->takeSnapshot();
        }
    }


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

Can you please abstract your problem into a test case?

Comment by Ward Peeters [ 07/Nov/14 ]

if that helps yes. The problem is that i'm not sure it's a bug. It might be the way you guys wanted it to be.
I'll create a test case might be better to understand.

Comment by Marco Pivetta [ 07/Nov/14 ]

It looks like a bug to me: the snapshot should be taken only when no snapshot was there upfront, as far as I know.





[DDC-3377] DateTime columns cannot be used with @Id Created: 06/Nov/14  Updated: 07/Nov/14  Resolved: 07/Nov/14

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

Type: Bug Priority: Major
Reporter: Chris Verges Assignee: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: None
Environment:

PHP 5.4.33
Symfony 2.5.6
Doctrine 2.4.x-dev


Issue Links:
Duplicate
duplicates DDC-2768 Doctrine could not work with date as ... Resolved
duplicates DDC-1471 Unable to read mySQL "DATE" field fro... Resolved
duplicates DDC-2487 UnitOfWork::getEntityIdentifier() con... Resolved
duplicates DDC-1780 Function createEntity does't support ... Closed

 Description   

DateTimeIdTest.php:

use Doctrine\ORM\Mapping as ORM;

/**
 * @ORM\Table(name="datetime_id_test")
 * @ORM\Entity
 */
class DateTimeIdTest
{
    /**
     * @ORM\Column(name="when", type="datetime")
     * @ORM\Id
     */
    public $when;

    public function __construct()
    {
        $this->when = new \DateTime();
    }
}

test.php:

require_once('DateTimeIdTest.php');

$entity = new DateTimeIdTest();
$entityManager->persist($entity);

Output:

Object of class DateTime could not be converted to string

/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1359
/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1172
/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:864
/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1635
/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1591
/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php:624
/app/cache/test/jms_diextra/doctrine/EntityManager_545bc3b10fd93.php:94
test.php:4

I was able to debug this down to where the implode() call in Doctrine\ORM\UnitOfWork::addToIdentityMap() is what is triggering this problem. It attempts to convert all contained entities in the Doctrine\ORM\UnitOfWork::entityIdentifiers array to strings. For a DateTime object, the DateTime::format() function should be used instead of relying on __toString().



 Comments   
Comment by Chris Verges [ 06/Nov/14 ]

There is a portable workaround where you create a string-based shadow key that gets updated by Doctrine events:

DateTimeIdTest.php:

use Doctrine\ORM\Mapping as ORM;
use Doctrine\ORM\Events as Events;

/**
 * @ORM\Table(name="datetime_id_test")
 * @ORM\Entity
 * @ORM\HasLifecycleCallbacks
 */
class DateTimeIdTest
{
    public $when;

    /**
     * @ORM\Column(name="when", type="string")
     * @ORM\Id
     */
    public $whenKey;

    public function __construct()
    {
        $this->when = new \DateTime();
    }

    /**
     * @Events\PrePersist
     * @Events\PreUpdate
     */
    public function syncWhenToWhenKey(LifecycleEventArgs $event)
    {
        $entityManager = $event->getEntityManager();
        $connection = $entityManager->getConnection();
        $platform = $connection->getDatabasePlatform();

        $this->whenKey = $when->format($platform->getDateTimeFormatString());
    }

    /**
     * @Events\PostLoad
     */
    public function syncWhenKeyToWhen(LifecycleEventArgs $event)
    {
        $entityManager = $event->getEntityManager();
        $connection = $entityManager->getConnection();
        $platform = $connection->getDatabasePlatform();

        $this->when = \DateTime::createFromFormat($platform->getDateTimeFormatString(), $this->whenKey);
    }
}




[DDC-2768] Doctrine could not work with date as primary key Created: 30/Oct/13  Updated: 07/Nov/14  Resolved: 14/Dec/13

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

Type: Bug Priority: Critical
Reporter: Nikita Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None

Issue Links:
Duplicate
is duplicated by DDC-2912 Date column could not be PK Resolved
is duplicated by DDC-3377 DateTime columns cannot be used with @Id Resolved

 Description   

Part of my mapping:

 
id:
    statDate:
        type: date
    phrase:
        type: string
    bannerId:
        type: integer

So I've got an exception:

Object of class DateTime could not be converted to string in /Users/hell0w0rd/dev/rsol/direct/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php line 13
45



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

DateTime instances must implement `__toString` in order to be used as identifiers. That is a known limitation.

See http://stackoverflow.com/questions/15080573/doctrine-2-orm-datetime-field-in-identifier/15085566#comment21225419_15085566





[DDC-1471] Unable to read mySQL "DATE" field from mysql db Created: 05/Nov/11  Updated: 07/Nov/14  Resolved: 19/Nov/11

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

Type: Bug Priority: Major
Reporter: Andreas Herz Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None
Environment:

OSX
mySQL 5.1.45


Issue Links:
Duplicate
is duplicated by DDC-3377 DateTime columns cannot be used with @Id Resolved

 Description   

Unable to retrieve an object with an "DATE" SQL type via the ORM mapper.
I retrieve als a convert exception like :Object of class DateTime could not be converted to string.

I add my SQL Tabel and the mapped class to the bug.

========================
CREATE TABLE SQL
========================

 
CREATE TABLE `suggestions_votes` (
  `suggestion_id` int(10) unsigned NOT NULL DEFAULT '0',
  `ip` int(10) unsigned NOT NULL DEFAULT '0',
  `day` date NOT NULL DEFAULT '0000-00-00',
  `vote` tinyint(1) NOT NULL DEFAULT '0',
  `dt` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`suggestion_id`,`ip`,`day`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

========================
Mapped PHP Class
========================

 
<?php
/**
* @Entity @HasLifecycleCallbacks
* @Table(name="suggestions_votes")
*/
class Model_votes_4eb50755dfdfe  {
 
   /**
    * @Id
    * @Column(name="`suggestion_id`", type="integer", nullable=false)
    */
    public $suggestion_id;

   /**
    * @Id
    * @Column(name="`ip`", type="integer", nullable=false)
    */
    public $ip;

   /**
    * @Id
    * @Column(name="`day`", type="date", nullable=false)
    */
    public $day;

   /**
    * @Column(name="`vote`", type="boolean", nullable=false)
    */
    public $vote;

   /**
    * @Column(name="`dt`", type="datetime", nullable=false)
    */
    public $dt;

    public function getIdFieldName(){ return 'day';}

    public function getRepresentativeFieldName(){ return 'day';}

    public function getTableName(){ return 'suggestions_votes';}

} //end class

?>

==================================================
Generated Error
==================================================
<p>Severity: 4096</p>
<p>Message: Object of class DateTime could not be converted to string</p>
<p>Filename: ORM/UnitOfWork.php</p>
<p>Line Number: 1900</p>

==================================================
Code of error message
==================================================

 
public function createEntity($className, array $data, &$hints = array())
    {
        $class = $this->em->getClassMetadata($className);
        //$isReadOnly = isset($hints[Query::HINT_READ_ONLY]);
        if ($class->isIdentifierComposite) {
            $id = array();
            foreach ($class->identifier as $fieldName) {
                if (isset($class->associationMappings[$fieldName])) {
                    $id[$fieldName] = $data[$class->associationMappings[$fieldName]['joinColumns'][0]['name']];
                } else {
                    $id[$fieldName] = $data[$fieldName];
                }
            }
            $idHash = implode(' ', $id);   <<<<<<<===== Produce the Error
        } else {
            if (isset($class->associationMappings[$class->identifier[0]])) {
                $idHash = $data[$class->associationMappings[$class->identifier[0]]['joinColumns'][0]['name']];
            } else {
                $idHash = $data[$class->identifier[0]];
            }
            $id = array($class->identifier[0] => $idHash);
        }


 Comments   
Comment by Andreas Herz [ 05/Nov/11 ]

I add some TRACE message to the code for more information

===============================================
Commented Code
===============================================

 
    public function createEntity($className, array $data, &$hints = array())
    {
        $class = $this->em->getClassMetadata($className);
        //$isReadOnly = isset($hints[Query::HINT_READ_ONLY]);
        if ($class->isIdentifierComposite) {
            $id = array();
            var_dump($class);
            foreach ($class->identifier as $fieldName) {
                echo $fieldName; 
                var_dump( $data[$fieldName]);
                echo "\n";
                if (isset($class->associationMappings[$fieldName])) {
                    echo "Try to convert with mapper....\n";
                    $id[$fieldName] = $data[$class->associationMappings[$fieldName]['joinColumns'][0]['name']];
                } else {
                    echo "no mapper found\n";
                    $id[$fieldName] = $data[$fieldName];
                }
            }
            $idHash = implode(' ', $id);
        } else {
            if (isset($class->associationMappings[$class->identifier[0]])) {
                $idHash = $data[$class->associationMappings[$class->identifier[0]]['joinColumns'][0]['name']];
            } else {
                $idHash = $data[$class->identifier[0]];
            }
            $id = array($class->identifier[0] => $idHash);
        }

===============================================
DUMP OUTPUT
===============================================

 
object(Doctrine\ORM\Mapping\ClassMetadata)#51 (32) {
  ["reflFields"]=>
  array(5) {
    ["suggestion_id"]=>
    object(ReflectionProperty)#61 (2) {
      ["name"]=>
      string(13) "suggestion_id"
      ["class"]=>
      string(27) "Model_ppppppp_4eb53138782ae"
    }
    ["ip"]=>
    object(ReflectionProperty)#62 (2) {
      ["name"]=>
      string(2) "ip"
      ["class"]=>
      string(27) "Model_ppppppp_4eb53138782ae"
    }
    ["day"]=>
    object(ReflectionProperty)#65 (2) {
      ["name"]=>
      string(3) "day"
      ["class"]=>
      string(27) "Model_ppppppp_4eb53138782ae"
    }
    ["vote"]=>
    object(ReflectionProperty)#68 (2) {
      ["name"]=>
      string(4) "vote"
      ["class"]=>
      string(27) "Model_ppppppp_4eb53138782ae"
    }
    ["dt"]=>
    object(ReflectionProperty)#71 (2) {
      ["name"]=>
      string(2) "dt"
      ["class"]=>
      string(27) "Model_ppppppp_4eb53138782ae"
    }
  }
  ["_prototype":"Doctrine\ORM\Mapping\ClassMetadata":private]=>
  NULL
  ["name"]=>
  string(27) "Model_ppppppp_4eb53138782ae"
  ["namespace"]=>
  string(0) ""
  ["rootEntityName"]=>
  string(27) "Model_ppppppp_4eb53138782ae"
  ["customRepositoryClassName"]=>
  NULL
  ["isMappedSuperclass"]=>
  bool(false)
  ["parentClasses"]=>
  array(0) {
  }
  ["subClasses"]=>
  array(0) {
  }
  ["namedQueries"]=>
  array(0) {
  }
  ["identifier"]=>
  array(3) {
    [0]=>
    string(13) "suggestion_id"
    [1]=>
    string(2) "ip"
    [2]=>
    string(3) "day"
  }
  ["inheritanceType"]=>
  int(1)
  ["generatorType"]=>
  int(5)
  ["fieldMappings"]=>
  array(5) {
    ["suggestion_id"]=>
    array(10) {
      ["fieldName"]=>
      string(13) "suggestion_id"
      ["type"]=>
      string(7) "integer"
      ["length"]=>
      NULL
      ["precision"]=>
      int(0)
      ["scale"]=>
      int(0)
      ["nullable"]=>
      bool(false)
      ["unique"]=>
      bool(false)
      ["columnName"]=>
      string(13) "suggestion_id"
      ["id"]=>
      bool(true)
      ["quoted"]=>
      bool(true)
    }
    ["ip"]=>
    array(10) {
      ["fieldName"]=>
      string(2) "ip"
      ["type"]=>
      string(7) "integer"
      ["length"]=>
      NULL
      ["precision"]=>
      int(0)
      ["scale"]=>
      int(0)
      ["nullable"]=>
      bool(false)
      ["unique"]=>
      bool(false)
      ["columnName"]=>
      string(2) "ip"
      ["id"]=>
      bool(true)
      ["quoted"]=>
      bool(true)
    }
    ["day"]=>
    array(10) {
      ["fieldName"]=>
      string(3) "day"
      ["type"]=>
      string(4) "date"
      ["length"]=>
      NULL
      ["precision"]=>
      int(0)
      ["scale"]=>
      int(0)
      ["nullable"]=>
      bool(false)
      ["unique"]=>
      bool(false)
      ["columnName"]=>
      string(3) "day"
      ["id"]=>
      bool(true)
      ["quoted"]=>
      bool(true)
    }
    ["vote"]=>
    array(9) {
      ["fieldName"]=>
      string(4) "vote"
      ["type"]=>
      string(7) "boolean"
      ["length"]=>
      NULL
      ["precision"]=>
      int(0)
      ["scale"]=>
      int(0)
      ["nullable"]=>
      bool(false)
      ["unique"]=>
      bool(false)
      ["columnName"]=>
      string(4) "vote"
      ["quoted"]=>
      bool(true)
    }
    ["dt"]=>
    array(9) {
      ["fieldName"]=>
      string(2) "dt"
      ["type"]=>
      string(8) "datetime"
      ["length"]=>
      NULL
      ["precision"]=>
      int(0)
      ["scale"]=>
      int(0)
      ["nullable"]=>
      bool(false)
      ["unique"]=>
      bool(false)
      ["columnName"]=>
      string(2) "dt"
      ["quoted"]=>
      bool(true)
    }
  }
  ["fieldNames"]=>
  array(5) {
    ["suggestion_id"]=>
    string(13) "suggestion_id"
    ["ip"]=>
    string(2) "ip"
    ["day"]=>
    string(3) "day"
    ["vote"]=>
    string(4) "vote"
    ["dt"]=>
    string(2) "dt"
  }
  ["columnNames"]=>
  array(5) {
    ["suggestion_id"]=>
    string(13) "suggestion_id"
    ["ip"]=>
    string(2) "ip"
    ["day"]=>
    string(3) "day"
    ["vote"]=>
    string(4) "vote"
    ["dt"]=>
    string(2) "dt"
  }
  ["discriminatorValue"]=>
  NULL
  ["discriminatorMap"]=>
  array(0) {
  }
  ["discriminatorColumn"]=>
  NULL
  ["table"]=>
  array(1) {
    ["name"]=>
    string(17) "suggestions_votes"
  }
  ["lifecycleCallbacks"]=>
  array(0) {
  }
  ["associationMappings"]=>
  array(0) {
  }
  ["isIdentifierComposite"]=>
  bool(true)
  ["containsForeignIdentifier"]=>
  bool(false)
  ["idGenerator"]=>
  object(Doctrine\ORM\Id\AssignedGenerator)#57 (0) {
  }
  ["sequenceGeneratorDefinition"]=>
  NULL
  ["tableGeneratorDefinition"]=>
  NULL
  ["changeTrackingPolicy"]=>
  int(1)
  ["isVersioned"]=>
  NULL
  ["versionField"]=>
  NULL
  ["reflClass"]=>
  object(ReflectionClass)#52 (1) {
    ["name"]=>
    string(27) "Model_ppppppp_4eb53138782ae"
  }
  ["isReadOnly"]=>
  bool(false)
}
suggestion_idint(0)

no mapper found
ipint(0)

no mapper found
dayobject(DateTime)#59 (3) {
  ["date"]=>
  string(20) "-0001-11-30 00:00:00"
  ["timezone_type"]=>
  int(3)
  ["timezone"]=>
  string(13) "Europe/Dublin"
}

no mapper found
<div style="border:1px solid #990000;padding-left:20px;margin:0 0 10px 0;">

<h4>A PHP Error was encountered</h4>

<p>Severity: 4096</p>
<p>Message: Object of class DateTime could not be converted to string</p>
<p>Filename: ORM/UnitOfWork.php</p>
<p>Line Number: 1905</p>

Comment by Andreas Herz [ 05/Nov/11 ]

After some codereading and debugging I think it is the problem that a "DATE" field is part
of the PKEY?

Is this possible?

Comment by Benjamin Eberlei [ 19/Nov/11 ]

Yes this is the reason.

2 workaround solutions:

1. Use a "string" instead
2. Add your own custom datetime type with a "MyDateTime extends DateTime" which implements __toString() and call new MyDateTime("...");

Comment by Andreas Palm [ 31/Jan/12 ]

Should be fixed with pull request #275





[DDC-1780] Function createEntity does't support DateTime identifier Created: 16/Apr/12  Updated: 07/Nov/14  Resolved: 07/Jul/12

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

Type: Bug Priority: Major
Reporter: Tereshchenko Maxim Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 0
Labels: None

Issue Links:
Duplicate
is duplicated by DDC-3377 DateTime columns cannot be used with @Id Resolved

 Description   

When I try to get data (as objects, function getResult()) from a table with two indexes (1.Integer, 2.DateTime), Doctrine returns duplicate objects to the first index.
This bug is present only in the function getResult(), getArrayResult work correctly.
The bug is in file UnitOfWork.php, line 2323-2329.

$idHash = implode(' ', $id);

This code does not take into account that identifer may be DateTime object.



 Comments   
Comment by Alexander [ 07/Jul/12 ]

Doctrine doesn't support DateTime objects as identifiers because the objects don't implement __toString().





[DDC-2487] UnitOfWork::getEntityIdentifier() contains objects when custom mapping types are part of an entity's identity Created: 04/Jun/13  Updated: 07/Nov/14  Resolved: 22/Dec/13

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

Type: Bug Priority: Major
Reporter: Benjamin Morel Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: identity

Issue Links:
Duplicate
is duplicated by DDC-3377 DateTime columns cannot be used with @Id Resolved

 Description   

I'm using a custom mapping type for a LocalDate class (mapped to a DATE field in the MySQL database).

Given the following entity:

/**
 * @Entity
 */
class Timeslot
{
    /**
     * @Id
     * @ManyToOne(targetEntity="Restaurant")
     */
    protected $restaurant;

    /**
     * @Id
     * @Column(type="localdate")
     */
    protected $date;
}

When var_export() -ing the result of UnitOfWork::getEntityIdentifier() on an instance of this class, the result is similar to:

array(
	'restaurant' => '5',
	'date' => LocalDate::__set_state(array('year' => 2013, 'month' => 6, 'day' => 26))
)

This is a bit weird, because as far as I understand it, it should return the identity as it maps to database fields:

array(
	'restaurant' => '5',
	'date' => '2013-06-26'
)

If we take the $restaurant example, it returns the restaurant ID, and not the Restaurant entity, so my opinion is that it should be the same for $date.

Shouldn't the UnitOfWork use Type::convertToDatabaseValue() on custom mapping types to infer their value, when computing the identity of an entity?



 Comments   
Comment by Marco Pivetta [ 04/Jun/13 ]

Benjamin Morel why would getEntityIdentifier convert types? The UoW doesn't worry about the DBAL representation of the objects - actually, the UoW doesn't know of the DBAL at all.

Comment by Benjamin Morel [ 04/Jun/13 ]

Your point is valid, but that's still annoying. Why would getEntityIdentifier() return objects?
By the way, UnitOfWork is aware of EntityManager, and thus the Connection, and thus the Platform!
It does use the Connection in commit().

Comment by Marco Pivetta [ 04/Jun/13 ]

Benjamin Morel that is because that is the identifier in your object. It's composed by the identifier of an associated entity and a datetime object (scalar)

Comment by Benjamin Morel [ 04/Jun/13 ]

Marco Pivetta Then why does it return the restaurant ID, and not the Restaurant object?

Comment by Benjamin Eberlei [ 22/Dec/13 ]

This is not a bug, it is just how it works, the docblock says nothing about how the fields have to look. The UnitOfWork API is mostly serving itself and optimized for that.





[DDC-3374] [GH-1175] removed "comments-as-vcs"-styled-comment Created: 06/Nov/14  Updated: 07/Nov/14  Resolved: 07/Nov/14

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: entitymanager, final


 Description   

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

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

Message:



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

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

Comment by Doctrine Bot [ 07/Nov/14 ]

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





[DDC-3358] [GH-1166] Fixing HHVM+XSD validation tests as of documented HHVM inconsistencies Created: 20/Oct/14  Updated: 07/Nov/14  Resolved: 07/Nov/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: ci, hhvm, travis, xml


 Description   

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

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

Message:

See https://github.com/facebook/hhvm/blob/3445a26e54faba5828eb6b8f6e74e52b472cf282/hphp/doc/inconsistencies#L131-L134 as a reference



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

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





[DDC-2548] [GH-720] Allow to have non-distinct queries Created: 09/Jul/13  Updated: 07/Nov/14  Resolved: 06/Aug/13

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

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


 Description   

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

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

Message:

The getHint method would return false if no hint was set for the given name. Therefore even if you set the CountWalker::HINT_DISTINCT to false, it would have been ignored and set to true by the paginator.



 Comments   
Comment by Doctrine Bot [ 06/Aug/13 ]

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

Comment by Marco Pivetta [ 06/Aug/13 ]

Merged: https://github.com/doctrine/doctrine2/commit/354d7050dc83cab7315c95c3511f5cf8c2b567c5

Comment by Doctrine Bot [ 07/Nov/14 ]

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





[DDC-3371] MultiTableUpdateExecutor does not handle input parameters correctly within arithmetic expression assignments to updated fields Created: 05/Nov/14  Updated: 05/Nov/14

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

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


 Description   

An update statement like

UPDATE MyEntity e SET e.value1 = e.value1 + :inParam1 WHERE e.value2 = :inParam2

will fail if MyEntity is part of a join table inheritance hierarchy and hence the update is handled by the MultiTableUpdateExecutor. The insert statement for the temporary ID table causes the following PDOException:

SQLSTATE[HY093]: Invalid parameter number: number of bound variables does not match number of tokens

The problem is in counting the number of input parameters in the update part of the statement. Lines 127-131 of the MultiTableUpdateExecutor:

if ($newValue instanceof AST\InputParameter) {
    $this->_sqlParameters[$i][] = $newValue->name;
    ++$this->_numParametersInUpdateClause;
}

fall short in detecting input parameters unless they are directly assigned as new values.






[DDC-3363] "The EntityManager is closed." after insert error. Created: 25/Oct/14  Updated: 05/Nov/14  Resolved: 05/Nov/14

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

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

Issue Links:
Duplicate
duplicates DDC-1037 The EntityManager is closed when an e... Resolved

 Description   
               try {
                    $em = $this->getContainer()->get('doctrine')->getManager();
                    $em->persist($article);
                    $em->flush();
                } catch (\Exception $e) {
                    $output->writeln($e->getMessage());
                }

If flush will generate error - all other flush operations will end with error: "The EntityManager is closed.".

Internet says that recreating EM is almost imposible without using own EM management code.

WHY i have to code EM management code to use EM? It's Doctrine's task to manage EM.

I just want to use try catch and process errors - Closing and opening connections it's Doctrine's task.

This task (reopen connection) should be done by Doctrine.






[DDC-2544] [GH-717] Allow query parameters starting with an underscore Created: 04/Jul/13  Updated: 05/Nov/14  Resolved: 30/Jul/13

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

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


 Description   

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

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

Message:

Using a query parameter of which the name starts with an underscore results in a QueryException. For example:

``` php
$q = $em->createQueryBuilder()
->select("u")
->from("User", "u")
->where("u.username = :_name")
->setParameter("_name", "bar")
->getQuery();
```

Results in:

Invalid parameter format, : given, but :<name> or ?<num> expected.

This happens because of a bug in the Lexer, which recognizes `:_name` as two tokens (the `:` as the start of a input parameter, `_name` as an identifier). The attached patch changes the regular expression for input parameters to allow identifiers starting with a letter or underscore.



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

A related Github Pull-Request [GH-717] was closed:
https://github.com/doctrine/doctrine2/pull/717

Comment by Fabio B. Silva [ 30/Jul/13 ]

Merged : https://github.com/doctrine/doctrine2/commit/a53fe14fa254618bc9a67296f845ec4923a13606

Comment by Doctrine Bot [ 05/Nov/14 ]

A related Github Pull-Request [GH-717] was assigned:
https://github.com/doctrine/dbal/pull/717

Comment by Doctrine Bot [ 05/Nov/14 ]

A related Github Pull-Request [GH-717] was closed:
https://github.com/doctrine/dbal/pull/717





[DDC-2535] [GH-712] Extra lazy get for inverse side of many-to-many Created: 01/Jul/13  Updated: 05/Nov/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of sandermarechal:

Url: https://github.com/doctrine/doctrine2/pull/712

Message:

This is the cange requested by @stof and @beberlei in PR #710. It implements an extra lazy get on the working side of the relationship. As mentioned in #710 the unit tests fails for reasons I don't quite understand. The error I get is:

```
1) Doctrine\Tests\ORM\Functional\ExtraLazyCollectionTest::testGetIndexByManyToMany
Exception: [PHPUnit_Framework_Error_Notice] Undefined index: joinColumns

Trace:
/home/sander/src/doctrine2/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php:1665
/home/sander/src/doctrine2/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php:1610
/home/sander/src/doctrine2/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php:1701
/home/sander/src/doctrine2/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php:1115
/home/sander/src/doctrine2/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php:746
/home/sander/src/doctrine2/lib/Doctrine/ORM/Persisters/ManyToManyPersister.php:55
/home/sander/src/doctrine2/lib/Doctrine/ORM/PersistentCollection.php:529
/home/sander/src/doctrine2/tests/Doctrine/Tests/ORM/Functional/ExtraLazyCollectionTest.php:578
```

If someone with a little more understanding of the Doctrine internals can help me fix this, then we could restore some of the functionality that PR #710 had to remove.



 Comments   
Comment by Doctrine Bot [ 05/Nov/14 ]

A related Github Pull-Request [GH-712] was assigned:
https://github.com/doctrine/dbal/pull/712





[DDC-2529] [GH-709] add getManager Created: 25/Jun/13  Updated: 05/Nov/14  Resolved: 25/Jun/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of tvlooy:

Url: https://github.com/doctrine/doctrine2/pull/709

Message:

getEntityManager is deprecated in Symfony2 (and gone in 2.3). It would be nice if Doctrine followed this (or at least added the getManager call) ot make it consistent. https://github.com/sensiolabs/SensioGeneratorBundle/pull/123



 Comments   
Comment by Doctrine Bot [ 25/Jun/13 ]

A related Github Pull-Request [GH-709] was closed:
https://github.com/doctrine/doctrine2/pull/709

Comment by Doctrine Bot [ 05/Nov/14 ]

A related Github Pull-Request [GH-709] was assigned:
https://github.com/doctrine/dbal/pull/709

Comment by Doctrine Bot [ 05/Nov/14 ]

A related Github Pull-Request [GH-709] was closed:
https://github.com/doctrine/dbal/pull/709





[DDC-2540] [GH-714] Cache results for extra lazy get Created: 03/Jul/13  Updated: 05/Nov/14  Resolved: 03/Jan/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of sandermarechal:

Url: https://github.com/doctrine/doctrine2/pull/714

Message:

Repeated getting of the same key on an extra lazy collection
should only issue a query for the first get, not for any
subsequent gets.



 Comments   
Comment by Sander Marechal [ 03/Jul/13 ]

It would be great if this can be included into 2.4 along with the extra lazy get from #DDC-1398

Comment by Doctrine Bot [ 03/Jan/14 ]

A related Github Pull-Request [GH-714] was closed:
https://github.com/doctrine/doctrine2/pull/714

Comment by Doctrine Bot [ 05/Nov/14 ]

A related Github Pull-Request [GH-714] was assigned:
https://github.com/doctrine/dbal/pull/714





[DDC-2533] [GH-710] Fix extra lazy get Created: 27/Jun/13  Updated: 05/Nov/14  Resolved: 30/Jun/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of sandermarechal:

Url: https://github.com/doctrine/doctrine2/pull/710

Message:

I made a big mistake in PR #706, my apologies. The get() function in the OneToManyPersister and ManyToManyPersister did not add the collection owner to the load query.

The first commit in this PR fixes this for the OneToMayPersister.

I could not find a way to fix this for the ManyToManyPersister. Problem is that you can only use conditions on the owning side of a ManyToMany relation, not on the inverse side. Code like `load(array($mapping['inversedBy'] => $coll->getOwner()), ...)` gave an ORMException.

Therefor, the second commit in this PR removes the extra-lazy-get for ManyToMany relations. If anyone has any ideas how to make this work for the ManyToMany side, please let me know.



 Comments   
Comment by Doctrine Bot [ 30/Jun/13 ]

A related Github Pull-Request [GH-710] was closed:
https://github.com/doctrine/doctrine2/pull/710

Comment by Doctrine Bot [ 05/Nov/14 ]

A related Github Pull-Request [GH-710] was assigned:
https://github.com/doctrine/dbal/pull/710

Comment by Doctrine Bot [ 05/Nov/14 ]

A related Github Pull-Request [GH-710] was closed:
https://github.com/doctrine/dbal/pull/710





[DDC-2520] [GH-705] [DDC-2519] Partial association identifier Created: 20/Jun/13  Updated: 05/Nov/14  Resolved: 23/Jun/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of FabioBatSilva:

Url: https://github.com/doctrine/doctrine2/pull/705

Message:

http://www.doctrine-project.org/jira/browse/DDC-2519



 Comments   
Comment by Doctrine Bot [ 23/Jun/13 ]

A related Github Pull-Request [GH-705] was closed:
https://github.com/doctrine/doctrine2/pull/705

Comment by Fabio B. Silva [ 23/Jun/13 ]

Merged : https://github.com/doctrine/doctrine2/commit/2ce72f38a2a13c665cd7e2ee5d79eb82d2c8003b

Comment by Doctrine Bot [ 05/Nov/14 ]

A related Github Pull-Request [GH-705] was assigned:
https://github.com/doctrine/dbal/pull/705

Comment by Doctrine Bot [ 05/Nov/14 ]

A related Github Pull-Request [GH-705] was closed:
https://github.com/doctrine/dbal/pull/705





[DDC-3369] Association Entity primary key composite with foreign keys Created: 04/Nov/14  Updated: 05/Nov/14  Resolved: 05/Nov/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4.6
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Major
Reporter: Saydev Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: mapping, orm
Environment:

Projet Symfony 2



 Description   

Impossible to make an association between two entities in the following cases:

Entity1 with a composite primary key :
key1 (PK)
key2 (PK)

Entity2 with a composite primary key (with foreign key) :
key1 (PK FK)
key2 (PK FK)
key3 (PK)

How to connect two entities with this scenario?



 Comments   
Comment by Marco Pivetta [ 05/Nov/14 ]

This actually works as long as key1, key2 and key3 are user-generated values (such as UUIDs). We cannot support the case when these values are db-side generated.

Comment by Saydev [ 05/Nov/14 ]

Can we get around this problem ?





[DDC-2518] [GH-704] added badges stable release and total downloads Created: 19/Jun/13  Updated: 05/Nov/14  Resolved: 19/Jun/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4
Security Level: All

Type: Documentation Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of liuggio:

Url: https://github.com/doctrine/doctrine2/pull/704

Message:

you can see the preview here: https://github.com/liuggio/doctrine2/tree/patch-1



 Comments   
Comment by Doctrine Bot [ 19/Jun/13 ]

A related Github Pull-Request [GH-704] was closed:
https://github.com/doctrine/doctrine2/pull/704

Comment by Marco Pivetta [ 19/Jun/13 ]

https://github.com/doctrine/doctrine2/commit/1382d766b09a04d504871bb50d519575ac553136

Comment by Doctrine Bot [ 05/Nov/14 ]

A related Github Pull-Request [GH-704] was assigned:
https://github.com/doctrine/dbal/pull/704





[DDC-2513] [GH-702] ANSI compliant quote strategy Created: 18/Jun/13  Updated: 05/Nov/14  Resolved: 23/Jun/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of FabioBatSilva:

Url: https://github.com/doctrine/doctrine2/pull/702

Message:



 Comments   
Comment by Doctrine Bot [ 23/Jun/13 ]

A related Github Pull-Request [GH-702] was closed:
https://github.com/doctrine/doctrine2/pull/702

Comment by Fabio B. Silva [ 23/Jun/13 ]

Merged : https://github.com/doctrine/doctrine2/commit/457036aacb660b21196d4fce7de215a943cc52e8

Comment by Doctrine Bot [ 05/Nov/14 ]

A related Github Pull-Request [GH-702] was closed:
https://github.com/doctrine/dbal/pull/702





[DDC-2511] [GH-701] list_bugs.php needs to call to getters for protected vars Created: 17/Jun/13  Updated: 05/Nov/14  Resolved: 17/Jun/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.5
Security Level: All

Type: Documentation Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of rbroen:

Url: https://github.com/doctrine/doctrine2/pull/701

Message:

list_bugs.php needs to call to getters for protected vars. This was changed in the "getting-started" code repository, but not in the "getting-started" tutorial.



 Comments   
Comment by Doctrine Bot [ 17/Jun/13 ]

A related Github Pull-Request [GH-701] was closed:
https://github.com/doctrine/doctrine2/pull/701

Comment by Marco Pivetta [ 17/Jun/13 ]

Merged at https://github.com/doctrine/doctrine2/commit/a39ceb3159d9716b528c422099c853224a1bc863

Comment by Doctrine Bot [ 22/Oct/14 ]

A related Github Pull-Request [GH-701] was assigned:
https://github.com/doctrine/dbal/pull/701

Comment by Doctrine Bot [ 05/Nov/14 ]

A related Github Pull-Request [GH-701] was closed:
https://github.com/doctrine/dbal/pull/701





[DDC-3117] [GH-1027] Support for Partial Indexes for PostgreSql and Sqlite Created: 07/May/14  Updated: 05/Nov/14  Resolved: 05/Nov/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers
Affects Version/s: None
Fix Version/s: 2.5
Security Level: All

Type: New Feature Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: mapping, postgresql, sqlite

Issue Links:
Dependency
depends on DBAL-900 [GH-600] Support for Partial Indexes ... Resolved
Reference
relates to DC-82 Conditional unique validator and index Closed

 Description   

This issue is created automatically through a Github pull request on behalf of PowerKiKi:

Url: https://github.com/doctrine/doctrine2/pull/1027

Message:

Support for Partial Indexes was available in Doctrine 1 following
http://www.doctrine-project.org/jira/browse/DC-82. This commit
reintroduce support for Doctrine 2. We use the same syntax with an
optionnal "where" attribute for Index and UniqueConstraint.

It is unit-tests covered and documented in manual. This Pull Request depends on https://github.com/doctrine/dbal/pull/600. So they should both be merged or rejected together.

Thanks for your time !



 Comments   
Comment by Adrien Crivelli [ 07/May/14 ]

This patch depends on DBAL-900. So they should both be merged or rejected together.

Comment by Doctrine Bot [ 16/May/14 ]

A related Github Pull-Request [GH-600] was closed:
https://github.com/doctrine/dbal/pull/600

Comment by Doctrine Bot [ 02/Aug/14 ]

A related Github Pull-Request [GH-600] was assigned:
https://github.com/doctrine/dbal/pull/600

Comment by Doctrine Bot [ 19/Aug/14 ]

A related Github Pull-Request [GH-600] was closed:
https://github.com/doctrine/dbal/pull/600

Comment by Doctrine Bot [ 05/Nov/14 ]

A related Github Pull-Request [GH-1027] was assigned:
https://github.com/doctrine/doctrine2/pull/1027

Comment by Doctrine Bot [ 05/Nov/14 ]

A related Github Pull-Request [GH-1027] was closed:
https://github.com/doctrine/doctrine2/pull/1027





[DDC-2541] [GH-715] Changed the paginator to allow using aditional tree walkers. Created: 03/Jul/13  Updated: 04/Nov/14  Resolved: 03/Jul/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Incomplete Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of Lumbendil:

Url: https://github.com/doctrine/doctrine2/pull/715

Message:

The paginator currently ignores additional tree walkers if it can't use an output walker. This patch appends the tree walker instead of replacing any existing tree walkers.



 Comments   
Comment by Doctrine Bot [ 03/Jul/13 ]

A related Github Pull-Request [GH-715] was closed:
https://github.com/doctrine/doctrine2/pull/715

Comment by Doctrine Bot [ 04/Nov/14 ]

A related Github Pull-Request [GH-715] was assigned:
https://github.com/doctrine/dbal/pull/715

Comment by Doctrine Bot [ 04/Nov/14 ]

A related Github Pull-Request [GH-715] was closed:
https://github.com/doctrine/dbal/pull/715





[DDC-2534] [GH-711] Coveralls code coverage Created: 28/Jun/13  Updated: 31/Oct/14  Resolved: 28/Jun/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4, 2.5
Security Level: All

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of FabioBatSilva:

Url: https://github.com/doctrine/doctrine2/pull/711

Message:

This patch adds support for https://coveralls.io



 Comments   
Comment by Doctrine Bot [ 28/Jun/13 ]

A related Github Pull-Request [GH-711] was closed:
https://github.com/doctrine/doctrine2/pull/711

Comment by Marco Pivetta [ 28/Jun/13 ]

Merged at https://github.com/doctrine/doctrine2/commit/8e1111c8d3f0281990ab4533aa42a6020c43abd0

Comment by Doctrine Bot [ 31/Oct/14 ]

A related Github Pull-Request [GH-711] was closed:
https://github.com/doctrine/dbal/pull/711





[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-3367] [GH-1171] Improvements for complex select statements when using new object expression Created: 28/Oct/14  Updated: 28/Oct/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of jaimz22:

Url: https://github.com/doctrine/doctrine2/pull/1171

Message:

My update allows you to alias objects created with the ["new" object expression](http://doctrine-orm.readthedocs.org/en/latest/reference/dql-doctrine-query-language.html#new-operator-syntax), as well as the ability to create queries that allow you to have multiple "new" object expressions and mixed scalar results.

Suppose you create a query as such:

```dql
SELECT new UserDTO(u.id,u.name) as user,new AddressDTO(a.street,a.postalCode) as address, a.id as addressId FROM User u INNER JOIN u.addresses a WITH a.isPrimary = true
```

upon executing this query, you'll end up with a result set that looks like the following:

```php
array(
0=>array(
0=>

{UserDTO object},
1=>{AddressDTO object},
2=>{u.id scalar},
3=>{u.name scalar},
4=>{a.street scalar},
5=>{a.postalCode scalar},
'addressId'=>{a.id scalar},
),
...
)
```

My changes fix that so you'd end up with a more usable result set:

```php
array(
0=>array(
'user'=>{UserDTO object}

,
'address'=>

{AddressDTO object}

,
'addressId'=>

{a.id scalar}

)
...
)
```






[DDC-2525] [GH-707] [#DDC-2524] Wrong commit order with cascade remove and double association Created: 24/Jun/13  Updated: 27/Oct/14  Resolved: 08/Sep/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of mnapoli:

Url: https://github.com/doctrine/doctrine2/pull/707

Message:

This PR contains the failing test cas for DDC-2524(http://www.doctrine-project.org/jira/browse/DDC-2524).



 Comments   
Comment by Doctrine Bot [ 31/Jul/13 ]

A related Github Pull-Request [GH-707] was closed:
https://github.com/doctrine/doctrine2/pull/707

Comment by Fabio B. Silva [ 08/Aug/13 ]

Closed, For more details see https://github.com/doctrine/doctrine2/pull/707

Comment by Benjamin Eberlei [ 08/Sep/13 ]

Was not merged

Comment by Doctrine Bot [ 04/Nov/13 ]

A related Github Pull-Request [GH-707] was reopened:
https://github.com/doctrine/doctrine2/pull/707

Comment by Doctrine Bot [ 27/Oct/14 ]

A related Github Pull-Request [GH-707] was closed:
https://github.com/doctrine/dbal/pull/707





[DDC-2371] [GH-631] Fix typo in one of the orderBy examples. Created: 26/Mar/13  Updated: 26/Oct/14  Resolved: 08/Sep/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4
Security Level: All

Type: Documentation Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of aaronmu:

Url: https://github.com/doctrine/doctrine2/pull/631

Message:

Fix typo in one of the orderBy examples.



 Comments   
Comment by Benjamin Eberlei [ 26/Mar/13 ]

A related Github Pull-Request [GH-631] was closed
https://github.com/doctrine/doctrine2/pull/631

Comment by Doctrine Bot [ 26/Oct/14 ]

A related Github Pull-Request [GH-631] was closed:
https://github.com/doctrine/dbal/pull/631





[DDC-3365] Indexes and uniqueConstraints has been ignored Created: 26/Oct/12  Updated: 26/Oct/14

Status: Awaiting Feedback
Project: Doctrine 2 - ORM
Component/s: Tools
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Minor
Reporter: Diego Oliveira Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Ubuntu 12.04 with MySQL 5.5 and PHP 5.4


Attachments: Text File dbal-fixing-373.patch     Text File orm-fixing-373.patch    

 Description   

I using the Doctrine Migrations and when I declared my entity with the indexes section, the index name has been ignored. It's like this:

indexes:
IDX_ADDRESS_CITY:
columns: city_id

but, the diff tools ignore it and give me this code:
$this->addSql("CREATE INDEX IDX_7299B5238BAC62AF ON tb_address (city_id)");

and it should be:
$this->addSql("CREATE INDEX IDX_ADDRESS_CITY ON tb_address (city_id)");

Notice: I open the same bug on the migrations repository in github and @kimhemsoe told me to open here, since this is generated by DBAL component.



 Comments   
Comment by Padraig O'Sullivan [ 11/Dec/12 ]

Did you specify an index name in the indexes property for your entity in your PHP file? In this case, you should have something like:

indexes={@Index(name="IDX_ADDRESS_CITY", columns={"city_id"})}

That should result in the correct SQL being generated. If I modify the above to:

indexes={@Index(columns={"city_id"})}

I also get a migration that has SQL with an auto-generated index name.

Comment by Diego Oliveira [ 02/Feb/13 ]

Yes I did specify a name, as you can see:

uniqueConstraints:
    UNIQUE_STATE_SLUG:
        columns: slug
indexes:
    IDX_USER_ADDRESS:
        columns: address_id

I don't try do to it using annotations because I choose do use yaml to describe my entities. I will take a look on the source code to see if I can fix it and send a PR.

Comment by Diego Oliveira [ 02/Apr/13 ]

I already sent this patch to Guilherme Blanco, but I guess he doesn't have time to take a look on it.

I guess my solution it's not ideal, but it solve the problem and can be a base to make a better solution.

Comment by Benjamin Eberlei [ 20/Apr/13 ]

Diego Oliveira the fix doesn't seem too nice with the additional boolean flag.

I would rather like to fix the root cause instead of adding this solution.

Comment by Benjamin Eberlei [ 20/Apr/13 ]

The issue is tricky, because we cannot just move the index definitions above, they will need the columns, however that directly generates the index in the schema tool. Maybe if the gather join column methods would check if they can add an index already it would work.

Comment by Steve Müller [ 26/Oct/14 ]

Moving this to ORM as it is completely related to ORM's schema tool. The schema tool hast to declare the order and priority of indexes.





[DDC-3364] QueryBuilder fails when using alias in having with like expr Created: 21/May/14  Updated: 26/Oct/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: webDEVILopers Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: GROUP_CONCAT, dql, expression, having, like, mysql
Environment:

Debian, MySQL, PHP, Zend Framework 2, Doctrine Module, Doctrine Extensions



 Description   

In my select I create an alias. I use a like expr on this alias in the having clause.

Trying several variations I still get the following error:
Expected '.' or '(', got 'long_name'

My example including variations inside comments:

$having = $qb->expr()->like('long_name', $qb->expr()->literal('%' . $term . '%'));

$qb->select(array(
    'b.id', 'b.name AS branch_name',
    'c.name AS company_name',
    'GroupConcat(b.name, \', \', c.name) AS long_name' // same for 'c.name AS long_name'
))
->from('Application\Entity\Branch', 'b')
->join('b.company', 'c')
->where('b.compartment = 1')
->having('(' . $having . ')') // same for having($having)
->groupBy('c.id')
->orderBy('c.name')
->addOrderBy('b.name');

I use a Doctrine Extension for the MySQL GROUP_CONCAT functionality:
https://github.com/beberlei/DoctrineExtensions/blob/master/lib/DoctrineExtensions/Query/Mysql/GroupConcat.php

This should have no effect on the result since I tried a simple alias - see comment - instead of it.

The problem seems to be using an alias inside the having clause when adding the like expr.
The following clause would work:

$having = $qb->expr()->like('c.name', $qb->expr()->literal('%' . $term . '%'));

I also tried this workaround using the GROUP_CONCAT method inside the where part:

->andWhere($qb->expr()->like('GroupConcat(b.name, \', \', c.name)', $qb->expr()->literal('%' . $term . '%')))

Allthough I used the groupBy part I got this error:
General error: 1111 Invalid use of group function



 Comments   
Comment by Marco Pivetta [ 26/Jun/14 ]

What is the actual failure/exception type? What about the generated SQL?

Comment by Steve Müller [ 26/Oct/14 ]

Moved to ORM, the error and use case is ORM related.





[DDC-3336] Undefined property: Doctrine\ORM\Query\AST\SimpleArithmeticExpression::$field Created: 04/Oct/14  Updated: 26/Oct/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: 2.4.4
Fix Version/s: None
Security Level: All

Type: Bug Priority: Critical
Reporter: Glen Ainscow Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Reference
relates to DDC-1958 pager produces wrong results on postg... Resolved

 Description   

I upgraded from 2.4.1 to 2.4.4, and now I'm seeing this notice here & there: Undefined property: Doctrine\ORM\Query\AST\SimpleArithmeticExpression::$field in /*/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/Pagination/LimitSubqueryOutputWalker.php on line 200

This seems to be in a method with the description "Generates new SQL for Postgresql or Oracle if necessary." ... but we're on MySQL (Percona).



 Comments   
Comment by Glen Ainscow [ 05/Oct/14 ]

Changed this to critical. It's also screwing up ordering, for example:

SELECT tp, p, CASE WHEN tp.memberTo IS NULL THEN 1 ELSE 0 END AS HIDDEN ord FROM Tournaments_Model_TeamPlayer tp INNER JOIN tp.player p LEFT JOIN p.user u WHERE tp.team = ?1 ORDER BY ord DESC, tp.memberFrom ASC

The paginator doesn't order the data correctly unless I remove the 2nd order by (tp.memberFrom ASC). The generated SQL from the QB/DQL is correct, so the paginator must be messing something up.

See: http://www.doctrine-project.org/jira/browse/DDC-1958?focusedCommentId=24010&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-24010

Comment by Marco Pivetta [ 13/Oct/14 ]

Need a test case in order to verify the issue

Comment by Glen Ainscow [ 26/Oct/14 ]

Okay, try this:

        $qb->from('Team', 't')
              ->select('t')
              ->orderBy('(1-1000)*1', 'DESC')
              ->getQuery()
              ->getResult();

This is simplified, the actual query works with field values, like this:

        ->orderBy('(((t.eloRating-1000)*t.reliability) + 1000)', 'DESC')

This causes the first issue.

Comment by Glen Ainscow [ 26/Oct/14 ]

The second issue is explained by Guilherme Sant