composer.json require :

"php": ">=5.3.3",
"symfony/symfony": "2.1.*",
"doctrine/orm": ">=2.2.3,<2.4-dev",
"doctrine/doctrine-bundle": "dev-master",
"twig/extensions": "dev-master",
"symfony/assetic-bundle": "dev-master",
"symfony/swiftmailer-bundle": "dev-master",
"symfony/monolog-bundle": "dev-master",
"sensio/distribution-bundle": "dev-master",
"sensio/framework-extra-bundle": "dev-master",
"sensio/generator-bundle": "dev-master",
"jms/security-extra-bundle": "1.2.*",
"jms/di-extra-bundle": "1.1.*",
"twitter/bootstrap": "master",
"friendsofsymfony/rest-bundle": "dev-master",
"doctrine/doctrine-fixtures-bundle": "dev-master"

I implemented it in my forks :

https://github.com/benja-M-1/doctrine2/commit/c8d899b14446accf869ddc0043f4235284375755
https://github.com/benja-M-1/dbal/commit/b9423c8d46a2bcdaa5a1f0b26a9a28259b1e44a2

It works for me, but I didn't write unit tests.

Hi,

Did you have time to have a look at this issue?

Thanks

Please send a pull request when you submit a fix. It is the proper way to submit them for review. When we want to see things waiting for review, we look at the list of pending PRs, not at all comments of the issue tracker to find links in them.

And I can tell you that this change has a big issue: it introduces a state in the database platform whereas it is currently stateless. This is likely to cause some issues when using more than 1 query (which is a common use case).

Hi Christophe thank you for your feedback.

I didn't send a PR because I wanted someone sharing his thoughts about what I suggested in this current issue. However I don't really understand the stateless argument, can you explain a bit more?

Otherwise how would do you proceed to tell Doctrine not to hydrate platform-specific columns?

If you run several queries, they will be affected by the extra columns of previous requests, which is wrong

I think the ObjectHydrator catches this by skipping undefined columns, i think we might just have overoptimized the SimpleObjectHydrator a little bit.

Doctrine 2.2.2
PHP 5.3.10 with Suhosin-Patch
mysql Ver 14.14 Distrib 5.5.15, for osx10.7
Mac OS X 10.7 Lion

I don't think this is valid. Orphan removal scheduling is handled only when an unit of work is available.

What's the state of `$dinner` before your example? Can you `var_dump` it?

linux, oracle

This seems to be quite old. Marc Drolet is it still valid with the latest ORM?

I'll try to test this problem on an updated version and I'll let you know.
The bug entry is also quite old and I've a local modified version of the paginator here to make it work with oracle, so it can take some time before I can test this out on the current doctrine version.

Ok, marking as awaiting feedback

Hi

Doctrine does not change the native query at all
The problem seems related with database connection.

Could you provide more details please?

Cheers

Doctrine\Common\Lexer.php

Hello, after checking， I found the problem should be here. As long as SQL wrap, or fill in alias, it will be error. It seems to be the preg_split problem?

        $flags = PREG_SPLIT_NO_EMPTY | PREG_SPLIT_DELIM_CAPTURE | PREG_SPLIT_OFFSET_CAPTURE;
        $matches = preg_split($regex, $input, -1, $flags);

        foreach ($matches as $match) {
            // Must remain before 'value' assignment since it can change content
            $type = $this->getType($match[0]);

            $this->tokens[] = array(
                'value' => $match[0],
                'type'  => $type,
                'position' => $match[1],
            );

Hi

Could you try to add a failing test case please ?

Cheers

xp php5.3.8 Apache

<?php

namespace Models\Entities;

/**
 * @Entity
 * @Table
 *
 * @NamedNativeQueries({
 *      @NamedNativeQuery(
 *          name             = "find-hotel-item",
 *          resultSetMapping = "mapping-find-item",
 *          query            = "SELECT Top 1 VEI_SN AS SN 
            FROM tourmanager.dbo.VEndorInfo vi 
INNER JOIN tourmanager.dbo.VEndorInfo2 vi2 ON 
vi.VEI_SN = vi2.VEI2_VEI_SN LEFT OUTER JOIN tourmanager.dbo.HotelInfo hi 
ON hi.hotelid = vi2.VEI2_VEI_SN INNER JOIN tourmanager.dbo.HotelInfo2 
hi2 ON hi2.hotelid = vi2.VEI2_VEI_SN AND hi2.LGC = 1 "
 *      )
 * })
 *
 * @SqlResultSetMappings({
 *      @SqlResultSetMapping(
 *          name    = "mapping-find-item",
 *          entities= {
 *              @EntityResult(
 *                  entityClass = "HTHotelItem",
 *                  fields = {
 *                      @FieldResult(name = "id",   column="SN")
 *                  }
 *              )
 *          }
 *      )
 * })
 *
 */

class HTHotelItem{
    /** @Id @Column(type="integer") @GeneratedValue */
    protected $id;
        
    /** @name */
    protected $name;
    
    /** @city */
    protected $city;
    
    /** @url */
    protected $url;
    
    public static function loadMetadata(\Doctrine\ORM\Mapping\ClassMetadataInfo $metadata){
        $metadata->addNamedNativeQuery(array(
            'name'              => 'find-hotel-item',
            'query'             => 'SELECT h FROM HTHotelItem h',
            'resultSetMapping'  => '\\Models\\Entities\\HTHotelItem'
        ));
    }
    
    function getId(){
        return $this->id;
    }
    
    function getName(){
        return $this->name;
    }
    
    function getCity(){
        return $this->city;
    }
    
    function getUrl(){
        return $this->url;
    }
}

@NamedNativeQueries query

If we write the long SQL, it will be fault. NO error massage.
1251 charecter must be wrong.
I still insist it is the problem of preg_split in
Doctrine\Common\Lexer.php

Can't reproduce,

Could you try to change the attached test case and make it fail.

Cheers

The Doctrine\Common\Lexer is never used in combination with native queries, only with the Annotation Parser, so i cannot be the preg_split that causes your SQL to be broken. Or do you get annotation errors?

Also what database are you using? maybe its related to the DBAL sql parsing?

I'm sorry my English is too bad.

I think it's Doctrine \ is \ Lexer. PHP preg_split the function of the problem in this file.
My system environment is xp/apache 5.3 + / php_pdo_sqlsrv_53 / mssql2000

Mysql 5.1.66 / Symfony 2.2.1

Can you show the CREATE TABLE and FOREIGN KEY statements of all the tables involved? It seems the cascade of the foreign keys is not propagated between multiple tables?

CREATE TABLE Base (id INT AUTO_INCREMENT NOT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB;
CREATE TABLE Child1 (id INT NOT NULL, foreignKey INT NOT NULL, UNIQUE INDEX UNIQ_179B6E88E992F5A (foreignKey), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB;

ALTER TABLE Child1 ADD CONSTRAINT FK_179B6E88E992F5A FOREIGN KEY (foreignKey) REFERENCES ExternalEntity (id) ON DELETE CASCADE;
ALTER TABLE Child1 ADD CONSTRAINT FK_179B6E8BF396750 FOREIGN KEY (id) REFERENCES Base (id) ON DELETE CASCADE;

The problem is that, the SQL model never explicitely tells the DB to delete the corresponding Base when Child1 gets removed. It looks like it is handled by the doctrine entity manager layer and not the actual DB engine (Base has no on delete cascade nor foreign key to its children).
So only doctrine can add the logic here because it knows the entity schema. But in this case, when it is deleted from another table, it looks like the special treatment is not triggered.

Maybe using

cascade={"remove"}

, instead of

onDelete="CASCADE"

to force the cascading process to be handled by doctrine would workaround the bug... But I prefer to have my DB do the logic work as much as possible.

Linux 3.6.6-1.fc17.x86_64

error log from orm:validate-schema

Copying from pastebin:

use \Doctrine\ORM\Mapping as ORM;
use \xxx\Doctrine\Annotation\Entity as re;
use \xxx\Doctrine\Annotation\Forms as rf;
use \Doctrine\Common\Collections;
 
/**
 * @ORM\Entity
 */
class EventPicture extends \Picture
{
 
    /**
     * @ORM\ManyToOne(targetEntity="Event", inversedBy="eventPicture")
     * @ORM\JoinColumn(name="FK_Event", referencedColumnName="id")
     */
    protected $event;
 
}

use \Doctrine\ORM\Mapping as ORM;
use \xxx\Doctrine\Annotation\Entity as re;
use \xxx\Doctrine\Annotation\Forms as rf;
use \Doctrine\Common\Collections;
 
/** @ORM\MappedSuperclass */
class Picture extends \xxx\Doctrine\Entity\BaseEntity
{
 
    /**
     * @ORM\Id
     * @ORM\Column(type="integer")
     * @ORM\GeneratedValue(strategy="IDENTITY")
     * @var type
     */
    protected $id;
 
    /**
     * @ORM\Column(type="string",unique=true, nullable=false)
     *  @rf\FileUpload(fileSize="php",uploadType="local",fieldName="link",formControl="FileUploadField",image=true)
     *
     */
    protected $link;
 
}

kluk does this happen also with any other simple custom annotation? For example following:

/**
 * @Annotation 
 * @Target({"PROPERTY","ANNOTATION"})
 */
final class Entity implements Annotation
{
    /**
     * @var string
     */
    public $value;
}

the same error when using simple annotation.

 
<?php

use \Doctrine\ORM\Mapping as ORM;
use \xxx\Doctrine\Annotation\Entity as re;
use \xxx\Doctrine\Annotation\Forms as rf;
use \Doctrine\Common\Collections;

/** @ORM\MappedSuperclass */
class Picture extends \xxx\Doctrine\Entity\BaseEntity {

    /**
     * @ORM\Id
     * @ORM\Column(type="integer")
     * @ORM\GeneratedValue(strategy="IDENTITY")
     * @var type
     */
    protected $id;

   
    /**
     * @ORM\Column(type="integer")
     * @rf\SetClass({"class","hide"})
     */
    public $value;

    /**
     * @ORM\Column(type="string",unique=true, nullable=true)
     * @rf\FileUpload(fileSize="php",uploadType="local",fieldName="link",formControl="FileUploadField",image=true)
     *
     */
    protected $link;

}

When i remove $value , $picture from class everything goes ok.
Easy fix for me is change ClassMetadataInfo.

    /**
     * INTERNAL:
     * Adds a field mapping without completing/validating it.
     * This is mainly used to add inherited field mappings to derived classes.
     *
     * @param array $fieldMapping
     *
     * @return void
     */
    public function addInheritedFieldMapping(array $fieldMapping)
    {
        if(isset($fieldMapping['fieldName'])){
        $this->fieldMappings[$fieldMapping['fieldName']] = $fieldMapping;
        $this->columnNames[$fieldMapping['fieldName']] = $fieldMapping['columnName'];
        $this->fieldNames[$fieldMapping['columnName']] = $fieldMapping['fieldName'];
        }
    }

But i dont know if this fix can break another part of doctrine.

Can you put the code of your annotations online? I can't seem to understand why this happens.

Amazon Redshift

Linux, Doctrine ORM 2.3.0, MySQL

Hi Erik,

The atribute "id" arealdy support "length" in the current doctrine version
: https://github.com/doctrine/doctrine2/blob/2.3/lib/Doctrine/ORM/Mapping/Driver/XmlDriver.php#L259

Which version are you using ?

Symfony2

Same problem here. I wanted to write some unit tests, checking the entity relations and ran into exactly the same problem. Maybe my code can provide some more information (Group entity is the owning side, role entity is the inverse side):

WHAT DOES NOT WORK:

        /**
         * Test ArrayCollection
         */
        $group = new Group('Group Test');
        $em->persist($group);
        $em->flush();

        $groups = new ArrayCollection();
        $groups->add($group);

        $this->role->setGroups($groups);

        $this->assertEquals($groups, $this->role->getGroups());

        /**
         * Test PersistentCollection
         */
        $em->persist($this->role);
        $em->flush();

        $groups = $this->role->getGroups();
        $groups->removeElement($group); // first remove element before adding a new one

        $group = new Group('Group Test 2');
        $em->persist($group);
        $em->flush();
        $groups->add($group);        

        $this->role->setGroups($groups);

        $this->assertEquals($groups, $this->role->getGroups());

WHAT WORKS:

        /**
         * Test ArrayCollection
         */
        $group = new Group('Group Test');
        $em->persist($group);
        $em->flush();

        $groups = new ArrayCollection();
        $groups->add($group);

        $this->role->setGroups($groups);

        $this->assertEquals($groups, $this->role->getGroups());

        /**
         * Test PersistentCollection
         */
        $em->persist($this->role);
        $em->flush();

        $groups = $this->role->getGroups();

        $group2 = new Group('Group Test 2');
        $em->persist($group2);
        $em->flush();
        $groups->add($group2);  // first adding a new element before removing one

        $groups->removeElement($group);

        $this->role->setGroups($groups);

        $this->assertEquals($groups, $this->role->getGroups());

Hope this helps in any way... I tried figuring it out on my own but I am too drunk right now xD

Thanks for the report, formatted it

Which version is that btw?

Occurs in version 2.1.6

If group is the owning side, why do you only set Role::$groups? This has to be the other way around or not?

@Steve

I cannot reproduce your issue.

Attached is a test script.

Your code is very weird btw, why are you getting and setting groups collection? It is passed by reference so you can just have something like $role->addGroup() and $role->removeGroup() and encapsulate the logic?

Also your tests are pretty useless, you check if two variables which are the same reference to the same collection are the same. Which should always be true.

@Lee

Can you provide more details? I cant verify this without more details.

Can anyone provide us with more feedback?

PHP 5.3 + MySQL 5.5

Fixed formatting

are you using result caching?

This is part of my bootstrap
,
,

		
$config = new \Doctrine\ORM\Configuration();
		
$cache = new \Doctrine\Common\Cache\ArrayCache;
$config->setMetadataCacheImpl($cache);
$config->setQueryCacheImpl($cache);
		
// driver: schema
$driver = $config->newDefaultAnnotationDriver(
	APPLICATION_PATH . '/models'
);
$config->setMetadataDriverImpl($driver);

Cannot reproduce it with the script attached. Can you try to modify this to fail or write your own testcase?

Downgraded

Please provide extra feedback.

Is the composite key a mix of association and field types?

I'm trying to remember the usage as it was a short term project but I believe it is.

For example a user has a userid.

The table in question might have a primary key consisting of the userid and an int representing a year..

Xubuntu 11.04 Linux 2.6.38 i386

Doctrine implements strict OO inheritance, what you want does not work as no casting is currently possible.

Reopening

Duplicate to DDC-16

« Hide
PHP 5.3.0 (cli) (built: Jul 21 2009 08:22:07)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies

Server Version: Apache/2.2.11 (Ubuntu) mod_jk/1.2.26 PHP/5.2.6-3ubuntu4.2 with Suhosin-Patch
Server Built: Aug 18 2009 14:26:31

mysql Ver 14.14 Distrib 5.1.31, for debian-linux-gnu (i486) using EditLine wrapper

Can you please show the code that you're using. I dont mean the models but the code that causes this problem.

Thanks.

$definitions = $phrase->getDefinitions();
var_dump($definitions[0] instanceof kateglo\application\models\Definition);

hope this help you.

regards,
arthur

Okay, thanks, I can reproduce this and will work on this. When I'm done I will add all these new tests to the test suite.

By the way, eager loading works fine for me. See this snippet:

        $query = $this->_em->createQuery("SELECT p,d FROM Doctrine\Tests\ORM\Functional\Phrase p JOIN p.definitions d");
        $res = $query->getResult();
        $definitions = $res[0]->getDefinitions();
        
        $this->assertEquals(1, count($res));
        $this->assertTrue($definitions[0] instanceof Definition);

This works for me. But lazy-loading results in the error you mentioned and which I will fix.

ok thank you very much it works like charm.

du bist Gold Wert Roman

please close the ticket.

Regards,
Arthur

PHP 5.3.0 (cli) (built: Jul 21 2009 08:22:07)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies

Server Version: Apache/2.2.11 (Ubuntu) mod_jk/1.2.26 PHP/5.2.6-3ubuntu4.2 with Suhosin-Patch
Server Built: Aug 18 2009 14:26:31

mysql Ver 14.14 Distrib 5.1.31, for debian-linux-gnu (i486) using EditLine wrapper

Should be fixed now in HEAD.

PHP 5.3.0 (cli) (built: Jul 21 2009 08:22:07)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies

Server Version: Apache/2.2.11 (Ubuntu) mod_jk/1.2.26 PHP/5.2.6-3ubuntu4.2 with
Suhosin-Patch
Server Built: Aug 18 2009 14:26:31

mysql Ver 14.14 Distrib 5.1.31, for debian-linux-gnu (i486) using EditLine wrapper

Should be fixed now in HEAD.

Thanks. We will try to address this as soon as possible. This is just an oversight in the implementation. The text type can definitely be made portable across all platforms.

In http://github.com/doctrine/doctrine2/commit/56a8f5cd5353908b815607a6e089201c95e01e6c this issue was fixed.

Thanks for the report and unit test. It saved me a LOT of time!

This test case is slightly different from example i wrote in description but shows same issue

Your report exposes exactly the issue pointed on DDC-349.

We should take a look how to fix this without having to update ALL unit tests that takes advantage of inheritance.

Also, the SQL spec requires that all joins need to be specified before write the ON keyword.
Example:

Exception: [PDOException] SQLSTATE[HY000]: General error: 1 a JOIN clause is required before ON
SELECT d0_.id AS id0, d0_.item AS item1 FROM DDC512Customer d0_ LEFT JOIN (DDC512OfferItem d1_ ON d0_.item = d1_.id INNER JOIN DDC512Item d2_ ON d1_.id = d2_.id)

And in the situation of a inheritance:

Exception: [PDOException] SQLSTATE[HY000]: General error: 1 a JOIN clause is required before ON             
SELECT o0_.id AS id0, o0_.name AS name1, o3_.id AS id2, o3_.name AS name3, o0_.discr AS discr4, o0_.mother_id AS mother_id5, o3_.discr AS discr6, o3_.mother_id AS mother_id7 FROM OJTIC_Pet o0_ LEFT JOIN OJTIC_Cat o1_ ON o0_.id = o1_.id LEFT JOIN OJTIC_Dog o2_ ON o0_.id = o2_.id INNER JOIN (OJTIC_Pet o3_ ON o0_.id = o3_.mother_id LEFT JOIN OJTIC_Cat o4_ ON o3_.id = o4_.id LEFT JOIN OJTIC_Dog o5_ ON o3_.id = o5_.id) WHERE o0_.name = 'Poofy' ORDER BY o3_.name ASC

I am aware of the problem and yes, nested joins for CTI can be a solution but its just 1 solution. The other one is to simply turn these CTI joins into left joins when they appear in the middle of a query (that is, not in the FROM clause).

So, given a Class hierarchy like this:

class Item
class StockItem extends Item
class OfferItem extends Item
class OrderItem extends OfferItem

StockItem <-onetoone-> OrderItem

and a DQL like this:

DQL: select s from StockItem s left join s.orderItem o ...

We have 2 possible solutions.

Nr. 1: Nested inner join

SELECT ... FROM stockitem s1_
INNER JOIN item s0_ ON s1_.id = s0_.id
LEFT JOIN
    (orderitem s2_ INNER JOIN offeritem s3_ ON s2_.id = s3_.id
     INNER JOIN item s4_ ON s2_.id = s4_.id)
ON s1_.id = s2_.stockItem_id

Nr. 2: Just use left joins for parent tables for all CTI joins that are the result of a DQL join (This is what Hibernate does):

SELECT ... FROM stockitem s1_
INNER JOIN item s0_ ON s1_.id = s0_.id
LEFT JOIN orderitem s2_ ON s1_.id = s2_.stockItem_id
LEFT JOIN offeritem s3_ ON s2_.id = s3_.id
LEFT JOIN item s4_ ON s2_.id = s4_.id

According to DDC-349, most databases seem to support nested inner joins (Nr. 1) but nevertheless its not in the ANSI standard I think, so I am not sure we can rely on it.

The Hibernate solution seems simpler but I still wonder whether they perform differently (Usually, inner joins are more performant than outer joins),

Fixed in http://github.com/doctrine/doctrine2/commit/01c2c06bbf529d89c9741ea97702359509ea230a using the "hibernate-way".

Please note that you currently should not name join columns the same as entity fields. See DDC-522. Better use @JoinColumn(name="item_id", ...)

PHP 5.3.2

I tried to debug by myself and i found that on line 411 in UnitOfWork.php is on flush in first example $class->associationMappings == null. When i change Shop_Data_Entity_Guest to /** @MappedSuperclass */ i can find $class->associationMappings on same line with some elements.

Hope it help to fix it

Andy

I tried to made patch by myself and it looks it start working. I'm not sure if this solution is proper. Andy

from line 1731 of UnitOfWork.php

 if (isset($this->_identityMap[$class->name][$idHash])) {  // $$class->rootEntityName to $class->name
            $entity = $this->_identityMap[$class->name][$idHash]; // $class->rootEntityName to $class->name
            $oid = spl_object_hash($entity);
            if ($entity instanceof Proxy && ! $entity->__isInitialized__) {
                $entity->__isInitialized__ = true;
                $overrideLocalValues = true;
            } else {
                $overrideLocalValues = isset($hints[Query::HINT_REFRESH]);
            }
        } else {
            //$entity = clone $class->prototype;
            $entity = new $className;
            $oid = spl_object_hash($entity);
            $this->_entityIdentifiers[$oid] = $id;
            $this->_entityStates[$oid] = self::STATE_MANAGED;
            $this->_originalEntityData[$oid] = $data;
            $this->_identityMap[$class->name][$idHash] = $entity; // $class->rootEntityName to $class->name

To ensure i checkouted trunk version but it doesn't solve this problem.

Andy

After using my patch i can't do $em->remove properly any other patch?

This is fixed now in trunk.

Thank you very much Hope this report was better than my first one.

Please open the ticket on the Doctrine ORM Module, this is the ORM bug tracker.

Sorry my mistake! I have opened an issue on github here: https://github.com/doctrine/DoctrineORMModule/issues/219 in case anyone ends up here.

Cheers.

DoctrineModule has a 0.8.x branch. Closing

On http://github.com/doctrine/doctrine2/commit/4845745337dbbed5eead25c3062a07103b38649f I fixed this issue.

Thanks for the report.

Windows 7, PHP 5.3.3

Your mapping information is wrong.
The mappedBy value must reference the field name of the owning side, and not the class name.

Marking ticket as invalid.

Ubuntu 12.04, PHP 5.3, 64 Bit, Symfony 2

Hi James

Do you have a failing test case ?
Could you attach/paste your entity please ?

Thanks

Entity exhibiting the behavior.

Hi James,
I can't reproduce,

Are you sure that you dont have more than one LocationData whith the same name ?

When working with indexBy the index columns must be unique into the collection.
I recommend that you add a unique constrain in the columns name.

If i'm wrong about it, please
Could you change the added test case and try to make it fails ?

Thanks

Hi Fabio,

The test case uses a SQLite DB without any foreign keys so the issue wouldn't be apparent.

How would I run the test against a MySQL db?

I've also attached the SQL log for the script I'm running, it looks the same as the output from the testcase.

Cheers,JB

SQL Log from script causing errors.

Hi James,

You must copy phpunit.xml.dist to phpunit.xml and change the database configurations.

I have attached the mysql log, the test case works fine.

It appears that it only attempts to delete 68 LocationData rows but in the database there are 76.

Okay, I've found the reason for this; the name isn't unique, some are duplicated.
Once the duplicates are removed there are 68 rows.
I'll add a unique index to the name column and hopefully this problem will go away.

Not sure whether you would consider this a bug.

Thanks for your help.

No problem, you are welcome

Actually isn't a bug, it is a documented behavior.

"Fields that are used for the index by feature HAVE to be unique in the database."

http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/tutorials/working-with-indexed-associations.html#working-with-indexed-assocations

Fields that are used for the index by feature HAVE to be unique in the database.

http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/tutorials/working-with-indexed-associations.html#working-with-indexed-assocations

Ubuntu 12.10, Zend Server CE

You are hydrating joined and filtered resultsets. You should never do this, as this will hydrate an invalid association into your objects.

MySQL 5.5 / Percona

Invalid IMO. This is an over-complication that (in such high load scenarios) is handled by clustering/load balancing. Not a problem of the ORM, since smashing all statements together will just make it impossible to trap any problems.

This performance improvement has been discussed directly on IRC.

The original problem is related to deadlocks and small transactions, which is not anyway solved by this issue.

Otherwise, this improvement requires a PoC that shows that it is possible to have exceptions still showing the query that caused the failure.

Sorry, was unclear. I basically mean that any approach squashing the queries into a single chunk sent to the DB should also allow us to get computed insert IDs and eventual exceptions should bubble up with the query that caused them.

• YAML Driver fixed.
• XML Driver fixed (supports now both cascade-persist and (because the other drivers do not use the prefixed cascade-) single "persist")

• I've modified the UnitTests to cover cascade="all" for XML & YAML

That patch looks good but there seem to be tabs in your patches. Please make sure that you use "soft tabs" (4 spaces) in your editor.

Resolved tab issue.

Patch applied. Thanks! So this will be included in todays ALPHA4 release.

Patch is ready and will be committed within the next week.

It seems like ObjectHydrator::_hydrateRow tries to find a _ce entry for AbstractUser (but _ce only holds entries for Person)...

Does Setting use inheritance also? TopnewsSetting extends Setting? If so which inheritance type?

Can we see the classes and their mappings? AbstractUser, User, Setting and TopnewsSetting. Then I can set up a test to reproduce it. Thanks!

Oh no I forgot to change TopnewsSetting to Setting in this report, there is no inheritance, just copy & paste bug.

Here are the classes and example code:

http://pastie.org/private/ljkiowarvm9trhdyug903q

Successfully reproduced in our test suite and working on it.

Should be fixed now. Thanks for reporting.

Can we see the query? I mean the DQL query! Thanks.

Nevermind. Got it reproduced.

I tried with revision 6913 and I still reproduce the problem.

Is there anyway I can use your UniTest framework, that way, I could check your test case and maybe suggest improvement.

I managed to run the UnitTests.

Do you have a test for this specific issue ?

Here is my result for Doctrine/Tests/ORM/AllTests.php

1) testOptimisticTimestampSetsDefaultValue(Doctrine\Tests\ORM\Functional\Locking\OptimisticTest)
strtotime(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/New_York' for 'EST/-5.0/no DST' instead
/home/eric/doctrine_trunk/tests/Doctrine/Tests/ORM/Functional/Locking/OptimisticTest.php:126

2) testOptimisticTimestampFailureThrowsException(Doctrine\Tests\ORM\Functional\Locking\OptimisticTest)
DateTime::createFromFormat(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/New_York' for 'EST/-5.0/no DST' instead
/home/eric/doctrine_trunk/lib/Doctrine/DBAL/Types/DateTimeType.php:33
/home/eric/doctrine_trunk/lib/Doctrine/ORM/Internal/Hydration/AbstractHydrator.php:225
/home/eric/doctrine_trunk/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php:239
/home/eric/doctrine_trunk/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php:112
/home/eric/doctrine_trunk/lib/Doctrine/ORM/Internal/Hydration/AbstractHydrator.php:102
/home/eric/doctrine_trunk/lib/Doctrine/ORM/AbstractQuery.php:511
/home/eric/doctrine_trunk/lib/Doctrine/ORM/AbstractQuery.php:387
/home/eric/doctrine_trunk/tests/Doctrine/Tests/ORM/Functional/Locking/OptimisticTest.php:136

3) testJoinedSubclassPersisterRequiresSpecificOrderOfMetadataReflFieldsArray(Doctrine\Tests\ORM\Functional\Ticket\DDC168Test)
PDOException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'salary' cannot be null
/home/eric/doctrine_trunk/lib/Doctrine/ORM/Persisters/JoinedSubclassPersister.php:190
/home/eric/doctrine_trunk/lib/Doctrine/ORM/UnitOfWork.php:698
/home/eric/doctrine_trunk/lib/Doctrine/ORM/UnitOfWork.php:283
/home/eric/doctrine_trunk/lib/Doctrine/ORM/EntityManager.php:288
/home/eric/doctrine_trunk/tests/Doctrine/Tests/ORM/Functional/Ticket/DDC168Test.php:34

You need to fix your timezone settings but that is unrelated to this problem.

To reproduce it, I added the following test temporarily to Doctrine\Tests\ORM\Functional\BasicFunctionalTest.php:

    public function testFlushDoesNotIssueUnnecessaryUpdates()
    {
        
        $user = new CmsUser;
        $user->name = 'Guilherme';
        $user->username = 'gblanco';
        $user->status = 'developer';
        
        $address = new CmsAddress;
        $address->country = 'Germany';
        $address->city = 'Berlin';
        $address->zip = '12345';
        
        $address->user = $user;
        $user->address = $address;
        
        $this->_em->persist($user);
        
        $this->_em->flush();
        $this->_em->clear();
        
        // show SQL from here on...
        $this->_em->getConnection()->getConfiguration()->setSqlLogger(new \Doctrine\DBAL\Logging\EchoSqlLogger);
        
        
        $query = $this->_em->createQuery('select u, a from Doctrine\Tests\Models\CMS\CmsUser u join u.address a');
        echo "QUERY!".PHP_EOL;
        $user2 = $query->getSingleResult();
        
        echo "FLUSH!".PHP_EOL;
        $this->_em->flush();
        
    }

However, since I did not really know how to check that, keeping this test in didnt make much sense.

Can you try this test? Before my patch it issued an UPDATE query but not after my changes.

It is pretty difficult to test this in an isolated manner.

First two failures are your fault, you havent set the default timezone in php.ini

The last failure is unrelated, its a benchmark for another bug.

OK. Latest trunk contains a test now that verifies that no SQL is executed on the flush.

Can you please tell us how to modify it to reproduce the problem?

Look into: Doctrine/Tests/ORM/Functional/BasicFunctionalTest.php

Last test method.

Got it! Your fix worked on OneToOne relation but not OneToMany

I did the same test using the CmsArticles entity and here is the result :

SELECT c0_.id AS id0, c0_.status AS status1, c0_.username AS username2, c0_.name AS name3, c1_.id AS id4, c1_.topic AS topic5, c1_.text AS text6, c1_.user_id AS user_id7 FROM cms_users c0_ INNER JOIN cms_articles c1_ ON c0_.id = c1_.user_id
FLUSH!
UPDATE cms_users SET name = ? WHERE id = ?
array(2) {
  [0]=>
  string(6) "FooBar"
  [1]=>
  int(17)
}
UPDATE cms_articles SET user_id = ? WHERE id = ?
array(2) {
  [0]=>
  int(17)
  [1]=>
  int(2)
}
DONE!
DELETE FROM cms_users_groups
DELETE FROM cms_groups
DELETE FROM cms_addresses
DELETE FROM cms_phonenumbers
DELETE FROM cms_articles
DELETE FROM cms_users

Dont forget to add the cascade persist for the articles relation

public function testFlushDoesNotIssueUnnecessaryUpdates()
    {

        $user = new CmsUser;
        $user->name = 'Guilherme';
        $user->username = 'gblanco';
        $user->status = 'developer';

        $address = new CmsAddress;
        $address->country = 'Germany';
        $address->city = 'Berlin';
        $address->zip = '12345';

        $article = new \Doctrine\Tests\Models\CMS\CmsArticle();
        $article->text = "Lorem ipsum dolor sunt.";
        $article->topic = "A Test Article!";
        $article->setAuthor($user);
        $user->articles[] = $article;


        $address->user = $user;
        $user->address = $address;

        $this->_em->persist($user);

        $this->_em->flush();
        $this->_em->clear();

        // show SQL from here on...
        $this->_em->getConnection()->getConfiguration()->setSqlLogger(new \Doctrine\DBAL\Logging\EchoSqlLogger);


        //$query = $this->_em->createQuery('select u, a from Doctrine\Tests\Models\CMS\CmsUser u join u.address a');
        $query = $this->_em->createQuery('select u, a from Doctrine\Tests\Models\CMS\CmsUser u join u.articles a');
        echo "QUERY!".PHP_EOL;
        $user2 = $query->getSingleResult();

        $user2->name = "FooBar";

        echo "FLUSH!".PHP_EOL;
        $this->_em->flush();

        echo "DONE!".PHP_EOL;

    }

OK. I will look into this later or tomorrow.

Thanks for your help.

Should be fixed now (second attempt)

Can you check whether DDC-140 can be closed also?

Yes, this is now fixed for me.
I confirm you this also close DDC-140

Thank you for your great work !!

This is indeed strange. My first guess was that the resultColumnNames get lost during serialization but the ClassMetadata#__sleep implementation seems to be correct in so far as it returns the resultColumnNames field as part of the fields to serialize.

Let me know as soon as you have more information.

Btw. Which metadata driver are you using? Annotations?

> My first guess was that the resultColumnNames get lost during serialization
This would be really strange, as the columns of the parent class Customer are still there after unserialization, so only a part is lost during serialization. My first guess was that the metadata is cached before the metadata loading is finished.

> Which metadata driver are you using? Annotations?
I'm using a custom metadata driver. Caching is separated from the driver, so the driver couldn't have anything to do with this, right?

I'll try to find where it goes wrong and let you know.

First request:

• Customer metadata is loaded and cached to Customer$CLASSMETADATA. $resultColumnNames contains Customer's fields.
• SuperCustomer metadata is loaded and cached to SuperCustomer$CLASSMETADATA. $resultColumnNames contains Customer's and SuperCustomer's fields.
• I request an object of class Customer be loaded from the database, which is an instance of SuperCustomer.
• StandardEntityPersister::_createEntity() is called to create the entity, and uses Customer metadata ALSO CONTAINING SuperCustomer's $resultColumnNames.

Second request:

• Customer metadata is loaded from Customer$CLASSMETADATA. $resultColumnNames contains Customer's fields.
• SuperCustomer metadata is loaded from SuperCustomer$CLASSMETADATA. $resultColumnNames contains Customer's and SuperCustomer's fields.
• I request an object of class Customer be loaded from the database, which is an instance of SuperCustomer.
• StandardEntityPersister::_createEntity() is called to create the entity, and uses Customer metadata NOT CONTAINING SuperCustomer's $resultColumnNames.

Thought: the Customer's metadata is somehow changed after caching to cope with Customer's subclasses as well, but these changes are not in the cache. I don't have enough knowledge of Doctrine's internals, but you probably have a pretty good idea where this could happen.

Thanks for your detailed information. I think I know what the issue is now. May be non-trivial to fix. I will try to look into it as soon as I got some free time.

Here is a patch which fixes the issue but through doing this roman and I realized another issue.

Scheduled for ALPHA4 as this may need some restructuring.

This should be fixed now in trunk.

Not sure if the issue is identical but seems at least related. Using NOTIFY change tracking with many-to-many bidirectional associations does not work. Objects added to the associations do not get persisted when calling EntityManager#flush.

Tested on r7404.

Dear Roman,

the line # 456 in UnitOfWork.php seems wrong to me:

            $isChangeTrackingNotify = isset($this->entityChangeSets[$oid]);

Shouldn't this only be set if the entity has

 @ChangeTrackingPolicy("NOTIFY") *

set in his class docBlock? The current behaviour now is to assign $changeset if changes exists, leaving the NOTIFY tracking policy out:

             $changeSet = $isChangeTrackingNotify ? $this->entityChangeSets[$oid] : array();

Because of this change, all our unit tests involving saving of entites break (basically, the whole application), which implement @postUpdate for logging purposes logging an own computed changeset.

Hi,

you're right, I did that naivly because I thought the only case where an entity would already have a changeset on flush is with the NOTIFY policy. I did not think of custom use cases like yours. It is fixed now in master. My apologies. However, this still means your approach would be broken if you would use the NOTIFY policy right? That sounds like maybe there is potential to improve the approach you're currently using. If you're missing anything in the API or implementation that forbids a different approach feel free to raise some new JIRA issues so we can possibly improve the situation.

Thank you for fixing this real quick! Our current approach is to compute the changeset on @preUpdate and after a successful save write the changeset to the database in @postUpdate. This conflicted with the changes made, I will however look into it and see if it's feasible for us to implement another approach.

Once again, thanks for your reply and fix.

I attached a patch for Doctrine\Orm\Id\Assigned, there seems to be a runaway line which makes the class add each element twice...

Whoops. Thanks for finding this! Does it fix this issue? I will need to add a testcase to the suite.

Does not entirely fix it: if the $value is empty, too few elements are added again.
Need to remove the "if (isset($value)) {" clause. I'll attach the fixed Assigned.php.

I think the isset() is correct. That way the $identifier array remains empty if the PK is null and later if ( ! $identifier) evaluates to false on the empty array and raises the exception. If we remove the isset() we would "accept" PKs with null values. But it might be better to do:

 if (!isset($value)) {
        throw ORMException::entityMissingAssignedId($entity);
  } else {
         $identifier[] = $value;
 }

I will fix this and add some new tests for it.

Should be fixed now.

Works for me on trunk, added test-case that proves it (Doctrine\Tests\ORM\Functional\LifecycleCallbackTest::testCascadedEntitiesCallsPrePersist())

There is still an issue. You can reproduce it if you change the test case slightly to this:

    /**
     * @group DDC-113
     */
    public function testCascadedEntitiesCallsPrePersist()
    {
        $e1 = new LifecycleCallbackTestEntity;
        $e2 = new LifecycleCallbackTestEntity;

        $c = new LifecycleCallbackCascader();
        
        $this->_em->persist($c);
        
        $c->entities[] = $e1;
        $c->entities[] = $e2;

        //$this->_em->persist($c);
        $this->_em->flush();

        $this->assertTrue($e1->prePersistCallbackInvoked);
        $this->assertTrue($e2->prePersistCallbackInvoked);
    }

The difference to the existing (and indeed working) test case is that the Cascader entity is persisted before the collection entries are added.

That is valid behaviour according to the lifecycle of an entity, persist gets cascaded right and only when ->persist() is called.

In the case you show, the two entities are also not persisted, because the cascade was already executed.

From a technical point of view this is ok - but from an intuitive point of view I would think I can use persist whereever I want. So I can create an entity, persist it (so it gets written to the DB), make changes to it (like adding entities to its collection) and getting its saved (and the collection entities persisted) when I call flush().

So I suspect lifecycle events to be called whenever an entity is persisted. And in this case LifecycleCallbackTestEntity's are persisted automatically by flush() (and this is after the Cascader is persisted!), so lifecycle events should fire here.

I have a fix for this ready, however, I want to look into something else before committing. I'll address this over the weekend.

Should be fixed now.

I think this might be a hen-egg problem.

@PreUpdate is only invoked after it is calculated that a change occured on all those entities that have updates. After a change in @PreUpdate events there would have to be another calculation of changes on all those entities, which would probably mean a significant performance hit.

I may not know all the consequences of this, but I think I have a fix for this bug.

In the class ORM\UnitOfWork

As I understand it, computeSingleEntityChangeSet() is called to update the changeset and _originalEntityData is set to the current values.

But, I see that the old changes are lost.

If i modify the function computeSingleEntityChangeSet to merge the changeset, it works.

At line 656 replace

$this->_entityChangeSets[$oid] = $changeSet;

By :

if($this->_entityChangeSets[$oid]){
    $this->_entityChangeSets[$oid] += $changeSet;
}
else {
    $this->_entityChangeSets[$oid] = $changeSet;
}

Here is my test case :

$qb = new \Doctrine\ORM\QueryBuilder($em);
$qb->select('fna')
			->from('Entity\FNA', 'fna')
			->andwhere($qb->expr()->eq('fna.id', ':fna_id'));
$qb->setParameter('fna_id', 1);
$query = $qb->getQuery();

$fna = $query->getSingleResult();
		
$fna->setStatus('COMPLETED');
$em->persist($fna);
$em->flush();

AND The preUdate :

/** 
 * @PreUpdate
*/
public function onPreUpdate($args=false)
 {
        $this->modified_at = new \DateTime();
}

Indeed this looks like a good fix except that the addition has to be the other way around so that when the same field is changed twice, first before the flush and then in a lifecycle callback/event the change from the callback prevails.

I will work on this and write a test for it.

Thanks Eric.

Fixed now.

Thanks Nico for reporting and thanks Eric for the suggestion!

The situation is actually worse if the relation is eager. In that case not only is the classname incorrectly resolved, but if the root-entity is an abstract class, the execution ends up in a fatal error.

It would seem to me that there are two ways to deal with the described problem:

1. join all the tables that contain the discriminator-fields, so that the correct subclasses can be inferred
OR
2. change the proxy pattern to a variant which is used in the FLOW3 framework, where there's only one proxy-class

A fix to the patch. Use the newer attachment.

I have patches for both of the options above. Should this be a configuration option? As it stands now, OneToMany and ManyToMany relationships enjoy the advantage of having the Collection in between the target and source entities. We could even use a hybrid approach, where a general proxy-object is created only when the object type cannot be inferred without joins.

It should of course be Nr. 1. The discriminator column is always stored in the topmost (root) table and tables of base classes must be joined, always. If this is not the case this is a bug. Can you show your patch?

It would seem to me that this would cause an inconsistency in how similar associations with different kinds of entities are treated.

From DDC-38: But inverse sides of one-one associations can never be lazy. Now going with option 1 would mean that in case the association is with an entity using class-table inheritance, these lazy associations would be allowed (because if we're joining the base-table anyway, there's no reason to forbid this) . This begs the question that if we're ready to do the joins in this case, should we reconsider doing them also to find out about target-existency when dealing with other types of entities?

Describing the changes StandardEntityPersister.php.diff:

• _getSelectEntitiesSql
  • For every inverse OneToOne relation join the target-table/base-table and find out the existence of the target-entity and the value of the discriminator column if one should exist. These values are given the names of the sourceFieldNames in the result array
• _createEntity
  • Pass the existence and discrimnator column values to unitOfWork->createEntity in the hints['associations'] array. This part is only speculative.

This selects the existence/discrimator-column information when an entity is queried using EntityManager->find, it's doesn't help if one is using a DQL query.

I understand now what the problem is. Its tricky. Your testcase however has a wrong mapping. The way you mapped it, any event that is fetched of a company will automatically be the main event In this case it would be correct to put a join column on the organization (main_event_id). But I understand the problem and will create a separate new test for it.

It will probably be treated similar to inverse sides of one-one. That means, when a one-one associations references a target entity that is a base type (not an outermost type, that means there are still possible subtypes), whether the association is the owning side or not it must be eagerly fetched.

Okay, so not allowing lazy-loading in this case at all. Why is this? As I stated earlier there are at least to ways to solve this without resorting to eager-loading. If using class-table inheritance means forgetting about lazy-load, to me at least it's a huge disadvantage and would be a deal breaker in using this inheritance-type. The problem with eager-load is not the first fetch that follows, but the uncertainty of how many fetches are going to follow in total. If the target-entity is the tip of a huge object-hierarchy full of entities using class-table inheritance, the current strategy is unusable. Having a couple of extra tables joined is nothing compared to the snowball that eager-fetching might get rolling.

Well, option Nr.1 is too complicated and can lead to lots of new issues. You can not always join arbitrary tables, not when it comes to DQL where it alters the overall result. The situation is much more complex than it might look to you right now.

Nr.2 is no option at all because such a proxy approach does not even hold for instanceof checks. An absolute no-go.

What it does now is the best thing from my point of view. If performance becomes an issue you can always improve upon that by eager fetching with DQL. Also, you did not yet understand how it works. The eager load does not happen always with class table inheritance, only when the target entity is a base type. If it is a subtype that does not have any further subtypes, then a proxy can be used without fear. Same goes for single table inheritance.

If you still feel this is too bad open a new issue as "improvement" and move any old/new patches you have there. There would need to be much more tests for such a change. Also you did not mention whether your patch actually passes all existing unit tests.

Sure I understood how it works. But to me one of the biggest advantages of class-table inheritance is exactly that the parent doesn't have to know the final type., and so in the configuration the association is pointed to the base-type. Yes, I accept that the issue might be way too complicated in the DQL case.

Option number two can be improved if the parent model that might have these general proxies invokes a load in it's getters. Exactly the way the generated proxies work now. Of course, this means that the models need to be aware of the possible proxies. It's not perfect, but maybe it could be an option?

Please open a new issue, I think this has potential as an improvement that can complement the current behavior.

What I mean is: for normal find/load ... operations that are not triggered by DQL we can probably do the join and in the case of DQL the current behavior is used, if you want to avoid the extra query in that case its as simple as adding the join to DQL.

So I think the approaches can be complementary.

Sure like the sound of that! I will be very happy to open this as an improvement. Thanks for your patience .

Doctrine2-trunk, Postgresql, Lazy loading

Strange, all the warnings and errors and the stack trace rather indicate that the associated value is NULL and not a (not initialized) proxy object. I'm working on this and already found an issue to address but I'm still unable to exactly reproduce this. Will keep you updated. If you have any further information, please let me know.

OK, managed to reproduce this. Working on it.

This should now be fixed but you need to manually delete your proxy classes so that they're regenerated. More improvements to the proxy classes and CLI tasks for (re)generating proxy classes will follow.

HEAD

Jon, I remember you mentioning this issue already. Did you fix it already?

No but I will fix it. The problem exists in Doctrine\ORM\Tools\Export\ClassMetadataExporter as well.

We should make is an option, not recursive all the time.... maybe include as an optional parameter --recursive

I'll check it out the issue and will come with a solution later today.

This behavior is already correct for single-valued associations but not for collections. Needs to be fixed in ObjectHydrator.

Brought Paul's changes over to doctrine/orm in branch DDC-604 http://github.com/doctrine/orm/tree/DDC-604

I've just added the fail case

By the way, this cannot be reproduced with the included testcases (no DB connection). So the problem may be between the ORM and the DBAL...

Do you get any error message? exception? stack trace?

PHP Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[23000]: Integrity constraint violation: 1451 Cannot delete or update a parent row: a foreign key constraint fails (`kaiser_sandbox`.`Child`, CONSTRAINT `Child_ibfk_1` FOREIGN KEY (`parentId`) REFERENCES `Item` (`id`))' in /home/kaiser/doctrine/doctrine/lib/Doctrine/DBAL/Connection.php:637
Stack trace:
#0 /home/kaiser/doctrine/doctrine/lib/Doctrine/DBAL/Connection.php(637): PDOStatement->execute(Array)
#1 /home/kaiser/doctrine/doctrine/lib/Doctrine/DBAL/Connection.php(385): Doctrine\DBAL\Connection->executeUpdate('DELETE FROM Ite...', Array)
#2 /home/kaiser/doctrine/doctrine/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php(353): Doctrine\DBAL\Connection->delete('Item', Array)
#3 /home/kaiser/doctrine/doctrine/lib/Doctrine/ORM/UnitOfWork.php(777): Doctrine\ORM\Persisters\BasicEntityPersister->delete(Object(Entities\SubItem))
#4 /home/kaiser/doctrine/doctrine/lib/Doctrine/ORM/UnitOfWork.php(316): Doctrine\ORM\UnitOfWork->_executeDeletions(Object(Doctri in /home/kaiser/doctrine/doctrine/lib/Doctrine/DBAL/Connection.php on line 637

Scheduled for beta2 but not sure we can make it, might end up on beta3. Increasing priority though as this seems to be a bug and these have priority.

Attached a test-case that verifies this bug exists.

Problem is the CommitOrderNodeCalculator not knowing about sub-class dependencies.

Double brackets in the DQL results in

"exception 'Doctrine\ORM\Query\QueryException' with message '[Syntax Error] line 0, col 62: Error: Expected Literal, got 'SELECT'' in /usr/share/php/lib/Doctrine/ORM/Query/QueryException.php:42

This might be caused by recent AST optimizations and thus I suspect this to be a regression.

Is there a workaround (other than not using a subquery)?

Well, a workaround for any DQL issues that is always available is a NativeQuery (createNativeQuery). In essence, a DQL query is just a high-level abstraction for a native SQL query + a ResultSetMapping. http://www.doctrine-project.org/projects/orm/2.0/docs/reference/native-sql/en#native-sql

The resulting objects from a native query are still fully managed and all, so its just a difference in query abstraction.

Nevertheless, this should be fixed soon.

Reproduced this successfully and already have a potential fix. Might not be a regression after all but a bug nevertheless.

Should be fixed now in HEAD (doctrine2/master).

PostgreSQL 8.4.3, Ubuntu 10.04

I think I reproduced this already. Seems to be related to PostgreSQL + IDENTITY only. The SequenceIdentityGenerator must be used but apparently it is not used.

Thanks for the report. Will keep you updated.

ps. The standalone reproduce scripts are good. Thanks for that! If you are interested it would be even better if the test code would be provided as a unit test or with some additional comments and/or assertions about what the desired behavior is or where the supposedly wrong behavior is (even if it is very obvious, like in this issue).

This patch fixes the issue for AssociationMapping and ClassMetadata. I'm not sure if there are more properties missing...

Ouch, bad oversight. Sorry for that. We do actually have tests for serializing and unserializing the metadata, obviously not enough... will fix it asap.

Fixed in http://github.com/doctrine/doctrine2/commit/db2be55e27c87fa513073b2bf44456f1d1423582 .

Thanks for your help.

Should we re-release Beta1? This is pretty serious and might annoy people

Hehe, no its fine. You can easily patch it manually if needed and beta2 is only a few weeks away.

And you can just use HEAD and not the tag, of course

If I clear the Entity Manager between lines 17 and 18, it works... Seems like the previously loaded Group is reused (which is perfectly fine), but its associations (or at least its self-referenced associations) are not loaded (neither proxies are generated)...

Thanks for reporting. I will take a look as soon as I find the time.

Test case for Doctrine\Tests\ORM\Functional\Ticket

It might be worth noting that, after renaming $parent to $parent2, the object is loaded but $item4->children remains empty.

If $item3 isn't being fetched beforehands, then everything seems to work fine.

After investigating, it came to my mind that the test submitted uses

$proxy->publicProperty

instead of

$proxy->getPublicProperty()

Therefore, the proxy is not initialized and thus we get unexpected behaviour. Adding a getter a la "getChildren()" and calling this method only, everything works fine.

Therefore, I mark this ticket as invalid.

Shouldn't these properties be automagically instantiated? In our project, we did use getChildren() and it did not work either (sorry, can't provide test case now, will do on monday).

I think collections are populated automatically everywhere (you can always use $this->children in entities), so this should work here as well.

The problem here is, that you're not really using an entity but a proxy object. A proxy object does not initialize its collections, see here: http://www.doctrine-project.org/documentation/manual/2_0/en/best-practices#don%27t-use-public-properties-on-entities

As long as you're using normal entities, the PersistentCollections will normally lazy load, thats true. But as soon as you're using proxies - like in this case - you're running into severe problems. I strongly recommend not using public properties.

You are right - if I use getChildren and a "protected $children", this example works.
However, if I use inheritance (e.g. SINGLE_TABLE), it breaks again, even if I don't use sub items. I'll update the test case.

Updated DDC531Test.php to use SINGLE_TABLE inheritance. Breaks again, even if I don't use public members for the collection...

Hi Nico,

thanks for your response. I will take a look at this issue shortly and will hopefully resolve it before beta2.

regards
christian

Thanks for your investigation. I tracked down the issue and have a fix pending.

Note though, that with such an example as in the provided testcase, the parents can never be lazy. That means all parents will be eagerly loaded. Of course you can work around that by eager-joining them in DQL or by using Query::HINT_FORCE_PARTIAL_LOAD and things like that.

The reason why the parents in the example can not be lazy is because a parent can potentially be of any subtype, so you would not know which proxy to put in. In general, a single-valued association that points to another entity that has mapped subclasses can not be lazy. This "problem" does not occur when the targeted entity has no mapped subclasses (this means it either does not participate in a mapped inheritance hierarchy or it is a leaf in the hierarchy).

See also: http://www.doctrine-project.org/jira/browse/DDC-357

Fixed in http://github.com/doctrine/doctrine2/commit/616f2eda0af1a15ba205cc5013b5f001c34dfc55

I think the order of operations in your example is not correct even though the error is misleading.

You are associating a "new doctor" to a "detached patient". That does not seem right, remember that merge() returns a managed copy, thus when merging the patient later, the "new doctor" is still associated with the "detached patient", not with the managed one.

The following should work:

// Merge detached patient
$managedPatient = $em->merge($patient);

// Associate new doctor with patient
$doctor->patients->add($managedPatient);
$managedPatient->doctor = $doctor;

// Persist new doctor and flush
$em->persist($doctor);
$em->flush();