Fixed

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

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

Debian 5 dotdeb
PHP 5.3
MySQL 5.0
Apache 2.2

I have made some other search about it.

On the queryBuilder described above, I was using getSingleResult / getResult.
When I'm using getScalarResult I can see data of every options.

Here the scalar result :

array(3) {
  [0]=>
  array(21) {
    ["player_id"]=>
    int(2)
    ["options_id"]=>
    NULL
    ["options_enabled"]=>
    NULL
  }
  [1]=>
  array(21) {
    ["player_id"]=>
    int(2)
    ["options_id"]=>
    int(2)
    ["options_enabled"]=>
    bool(true)
  }
  [2]=>
  array(21) {
    ["player_id"]=>
    int(2)
    ["options_id"]=>
    int(4)
    ["options_enabled"]=>
    bool(true)
  }
}

Do you have any clue ?

I think I have find the problem.

See patch.
I have test the modification, it seem to be okay.

In the 2.1.2 version, If the first related object wasn't a "nonemptyComponents", the ObjectHydrator initialized the collection by a specific way.

It's a patch for Doctrine/ORM/Internal/Hydration/ObjectHydrator.php version 2.1.2.

I have add a correction on Github : https://github.com/armetiz/doctrine2/commit/42d507632fd27a23220c38bb867b611c3caaab8e

Thanks for digging into that, I will evaluate this issue

No problem, It was blocking for me.
But I don't understand why this bug doesn't appear to other users. Because of that, I'm wondering if it's a real bug or a miss configuration on my app.

To be sure, the best will be to create a new test, but I'm not really familiar to create ORM test case..

Thomas.

can you post your mappings?

PlayerEntity :

<?xml version="1.0" encoding="UTF-8"?>
<doctrine-mapping xmlns="http://doctrine-project.org/schemas/orm/doctrine-mapping"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://doctrine-project.org/schemas/orm/doctrine-mapping
                    http://doctrine-project.org/schemas/orm/doctrine-mapping.xsd">
	<entity name="PlayerEntity">
		<many-to-many field="options" target-entity="OptionEntity" mapped-by="players" />
	</entity>
</doctrine-mapping>
{/code}

<?xml version="1.0" encoding="UTF-8"?>
<doctrine-mapping xmlns="http://doctrine-project.org/schemas/orm/doctrine-mapping"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://doctrine-project.org/schemas/orm/doctrine-mapping
http://doctrine-project.org/schemas/orm/doctrine-mapping.xsd" >
<entity name="OptionEntity" table="options">
<many-to-many field="players" target-entity="PlayerEntity" inversed-by="options">
<cascade>
<cascade-merge />
</cascade>
<join-table name="compo_option_player" />
</many-to-many>
</entity>
</doctrine-mapping>

I have post all the mapping, but it's Doctrine compliant.
PlayerEntity extends PlayerBaseEntity, and Option is a standalone Entity.
All define an auto generated identifier.
The join table is correctly configured.

Do you need this mapping to create tests ?
To sum-up, this is a simply ManyToMany relation between an inheritance Entity & a simple Entity.

Do you need any else ?

Thomas.

Fixed.

This issue is referenced in Github Pull-Request GH-161
https://github.com/doctrine/doctrine2/pull/161

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

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

Verified:

    /**
     * @group DDC-1435
     */
    public function testForeignKeyAsPrimaryKeySubselect()
    {
        $this->assertSqlGeneration(
            "SELECT s FROM Doctrine\Tests\Models\DDC117\DDC117Article s WHERE EXISTS (SELECT r FROM Doctrine\Tests\Models\DDC117\DDC117Reference r WHERE r.source = s)",
            ""
        );
    }

This however is not possible anyways, since you cannot have "r" in a SimpleSelectExpression when it resolves to multiple columns. You can try to select just one arbitrary field, for example."SELECT r.foobar FROM .."

Would that just be a documentation issue then? I didn't see that restriction in the grammar, but I may have overlooked it. I issued a pull request for this issue assuming that an association mapped field is valid input for getQuotedColumnName.

Selecting a single field does work fine.

Did you touch this in your latest changes to SimpleSelectExpression guilherme?

Hi,

@beberlei No. Issue was totally unrelated.
Please merge my commit to 2.1.X.

The issue was caused by the identifier iteration was considering that @Id fields are always fields, never associations. You may see that in method getQuoteColumnName.

Solution was to create a new method called getQuotedIdenitiferColumnNames and consume it in SqlWalker.
This addresses the issue.

Committed patch and test case as of: https://github.com/doctrine/doctrine2/commit/0ec2cc557f51d6240396689e36101f62d84d2a38

Cheers,

Merged into 2.1.x

This issue is referenced in Github Pull-Request GH-159
https://github.com/doctrine/doctrine2/pull/159

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

I think your mapping is wrong. You cannot map an @Id + @ManyToOne and then remap the same column using @Column.

What exactly are the parameters to the query? How is it updating article_id ?

Is this even affected by "indexBy"? Can you remove them and try again?

I have to use @Id + $ManyToOne and @Column on the same database field because indexBy only supports normal @Columns as key. We have used this workaround numerous times in our system without any issues.

And it seems that this is not causing the updates. Here is another example:

 
/**
 * @Entity
 */
class Article
{

    /**
     * @Id
     * @Column(type="integer")
     */
    protected $id;

    /**
     * @OneToMany(targetEntity="ArticleText", mappedBy="article", indexBy="locale", fetch="EXTRA_LAZY")
     */
    protected $texts;

    .......

}

/**
 * @Entity
 */
class ArticleText
{

    /**
     * @Id
     * @ManyToOne(targetEntity="Article", inversedBy="texts")
     */
    protected $article;

    /**
     * @Id
     * @Column
     */
    protected $locale;

   /**
    * @Column
    */
   protected $title;

    .......

}

$q = $em->createQuery("SELECT a, t FROM Article a JOIN a.texts t WITH t.locale = :activeLocale");
$q->setParameter('activeLocale', 'en');

$em->flush(); // dummy flush, no queries made

$q->getResult();

$em->flush(); // this will trigger the updates

UPDATE article_text SET article_id = 1 WHERE locale = 'en' AND article_id = 1
UPDATE article_text SET article_id = 2 WHERE locale = 'en' AND article_id = 2
UPDATE article_text SET article_id = 3 WHERE locale = 'en' AND article_id = 3
UPDATE article_text SET article_id = 4 WHERE locale = 'en' AND article_id = 4
UPDATE article_text SET article_id = 5 WHERE locale = 'en' AND article_id = 5
.......

it does it one per article for all articles in result.

If i remove the indexBy annotation the updates disappear. Extra lazy loading has no effect on this bug.

Attached is a working testcase with your example code.

Can you please verify that it follows your example exactly and try to make it generate those UPDATEs?

This is fixed in 2.1.3, it was a bug until 2.1.2

fixed and merged into 2.1.x

Symfony2

Can you test against master again? I made a fix in context of DDC-1452 that i think could solve this issue.

I will do it

I cann't run master branch on current env (Symfony 2.0.2).

MappingException: The association mapping 'eventArea' misses the 'targetEntity' attribute, but targetEntity present. Can you merge fix into 2.1.x branch?

I am not sure this fix is mergable in 2.1, also it is a rather complex change that i don't want to merge back to the stable branch for stability reasons.

Let me try to reproduce this in a test and then go further from there.

DDC-1452 is indeed the same bug as this one and the fix works.

I cant merge this as with the latest refactorings it gives hundrets of conflicts, but will re-apply manually.

Backported and fixed in 2.1.x

Thank you very much, Benjamin!

Fixed.

Linux, php 5.3.8

Fixed

In my database, out of 56 tables, 17 will not be deleted. I tried to find something these tables have in common, but could not find a pattern. After repeating the drop-schema command, three tables remain, including the top-most base table in the inheritance hierarchy, and a table referenced by it. Repeating the drop-schema command again drops those tables, too.

I changed alot in the dropSchema command, can you try again? The problem here is with all the foreign keys.

Ok, thanks.

I tried again, now with Doctrine version 2.04.

I updated the Doctrine 2 installation to version 2.04, then recreated the complete database from scratch using doctrine orm:schema-tool:create --force.
Before recreating the database, I manually, dropped all tables in the database, and verified all tables were gone. I also regenerated the proxy classes, just in case it could have any effect.

The 86 tables have been created, as expected.

Then I tried to drop the database by calling doctrine orm:schema-tool:drop --force.

After using the command, there are still 17 tables remaining.

Overall, the result seems to be unaffected by the upgrade to the latest minor version.

One thing that works now, though, is that calling doctrine orm:schema-tool:drop --force repeatedly, will also delete the 17 tables remaining after the first call.

So it did get better, although it does not work the first time it gets called, and still wrongly reports success the first time.

This should be fixed now, SchemaTool didnt handle sequence removal correctly before. Can you verify?

Hey Ben,

I am currently travelling and do not have access to any development system. I will be back home by July, 1st and will have a look at this and let you know. Thanks for fixing it.

maybe it's related to this bug : http://www.doctrine-project.org/jira/browse/DDC-1266

I just found this piece of code that mutes exceptions...

    public function dropSchema(array $classes)
    {
        $dropSchemaSql = $this->getDropSchemaSQL($classes);
        $conn = $this->_em->getConnection();

        foreach ($dropSchemaSql as $sql) {
            try {
                $conn->executeQuery($sql);
            } catch(\Exception $e) {
                
            }
        }
    }

maybe I'm missing something but even after reading the function comment this seems like a bad idea.
if dropTable is called within a transaction, the transaction will be aborted and the function will still return as if sucessful

@Mathieu: Yes, that could very well be the root cause.

@Benjamin: I verified that the error is still there, now with Doctrine 2.1 and PostgreSQL 8.4. The command line tool (doctrine orm:schema-tool:drop --force) still wrongly reports success, in spite of several tables remaining in the schema.

Once I remove the try-catch-construct mentioned by Mathieu above (leaving the try block's content intact, of course), and reissue the command, there are exceptions. E.g.:

PDOException SQLSTATE[42P01]: Undefined table: 7 ERROR: sequence "some_random_sequence_seq" does not exist.

I believe that the intention of the try-catch-block above is to mute exactly that type of error, since it should not make any difference if something that is not there could not be deleted, because, after all, it is gone anyway. Unfortunately, it actually does make a difference in case several SQL-DDL commands are combined into a single call, because if any command in the call fails and raises an exception, all following commands in the same call will not be executed. I have not analyzed this further, but I think there is something smelly here.

Fixed

Fixed in DBAL now by using SplObjectStorage to have only one unique sequence to drop (same for tables and foreign keys)

Assigned to Guilherme

Fixed since commit https://github.com/doctrine/doctrine2/commit/6bbf2d9da35aa8ce500f26d671a135a00870e33a

Merged into 2.1

Merged into 2.1.x

Even if we fixed that it wouldn't work to have a DateTime as primary key. Since PK values need to be "stringable".

Changed to improvement and link to DDC-1320

Even though DateTime would be solved in a different way, I think the patch must be applied specially because the identifier can be anything else, including a user customized type.

I fixed this issue by commit: https://github.com/doctrine/doctrine2/commit/666691f84fd5a48d0eb6af7e93b83c2651555e61

Set to 2.2-DEV as one thing is unclear for me, see commit comment.

Merged into 2.1.x

Fixed.

Symfony 2.0.3 / LAMP

verified.

fixed

Ubuntu 11.10, PHP 5.3.6, MySQL 5.1.58

Test case.

Possible change diff for file Doctrine/ORM/Persisters/BasicEntityPersister.php from Doctrine ORM 2.1.2.

Idea is to use the main table (not inherited one) if the column is a part of ID. So, I guess, it will be in both tables.

@@ -1197,7 +1197,7 @@ class BasicEntityPersister
             $conditionSql .= $conditionSql ? ' AND ' : '';
 
             if (isset($this->_class->columnNames[$field])) {
-                if (isset($this->_class->fieldMappings[$field]['inherited'])) {
+                if (isset($this->_class->fieldMappings[$field]['inherited']) && empty($this->_class->fieldMappings[$field]['id'])) {
                     $conditionSql .= $this->_getSQLTableAlias($this->_class->fieldMappings[$field]['inherited']) . '.';
                 } else {
                     $conditionSql .= $this->_getSQLTableAlias($this->_class->name) . '.';

Fixed

Debian 6, Symfony 2, Doctrine 2

Doesnt he still hydrate an empty object for this row then? Why are you even using the object hydrator? I rather tend to go and throw an exception if for a query using the ObjectHydrator $id[$dqlAlias] is empty, because frankly this is just not supported.

He does hydrate one empty object for the first line with empty ID, but he does not hydrate further empty object.

Thus, instead of having an array with the following objects :

 
Entity(id=4)
Entity(id=1)
Entity(id=2)
Entity(id=3)
Entity(id=)
Entity(id=)
Entity(id=)
Entity(id=)
Entity(id=7)
Entity(id=6)
Entity(id=5)

I got :

 
Entity(id=4)
Entity(id=1)
Entity(id=2)
Entity(id=3)
Entity(id=)
Entity(id=7)
Entity(id=6)
Entity(id=5)

Yes, but can you show me your DQL statement?

I'm using Native Query, so I guess it's not DQL, but here's the query (Oracle SQL)

SELECT *
FROM (
    SELECT to_date(:date_start,\'dd-mm-yyyy\') + rownum -1 as period_date
    FROM all_objects
    WHERE rownum <= to_date(:date_end,\'dd-mm-yyyy\') - to_date(:date_start,\'dd-mm-yyyy\')+1
)
LEFT JOIN entity ON period_date = entity_date',

For the Array- and ObjectHydrator the ID is a required result.

I am not sure how to proceed with this, i think the right behavior is to return null as the object when no id is found. What do you think?

Is the Date a scalar value of the result?

The expected results would be, in order of preference :

• Entity without id set (like in my example above)
• null value

And yes, the Date was an additional scalar value for which I needed the Native Query

Your example lacks details but, for case one. Did the queries return values for the non-id columns of this entity?

Sorry for the concision, I didn't wanted to flood my comment with unrelated data.

The fact is the queries returned values for the non-id columns when the ID was set, and null values when not. I will update my comment.

I will go with adding NULL values there. This is more consistent, since null represents a non-existent entity.

Fixed and merged back into 2.1.x

Ubuntu 11.04, MySQL 5.1.54-1ubuntu4, PHP 5.3.5-1ubuntu7.2

Attached standardized test case.

Fixed.

Unix/Apache/PHP 5.3/MySQL

Fixed

Verified, have a fix for this already but its rather tricky with how far i want to push this.

I committed a fix into master and 2.1.x https://github.com/doctrine/doctrine2/commit/3801e0c230b5bf4060ee72800a270340ffee2355

This could somewhat be considered a BC. But i doubt people use partial objects to update the fields they omitted.

All

Fixed.

ubuntu

Fixed in https://github.com/doctrine/doctrine2/commit/24042863acbabdcd0fa1432135a9836467f3bce7

It should be available in next release.

good catch, thank you very much!

fixed and merged back into 2.1.x

I too would like to see this. I thought this issue was fixed with DDC-1145 but that only solves it for joins. It does not allow indexing on the result itself. I would like to see something like this:

$builder->select('u')->from('User')->indexBy('u.id');
$builder->getQuery()->getResult();

Or it may be better to implement it on the query (since it affects hydration rather than the query itself):

$builder->select('u')->from('User');
$builder->getQuery()->setIndex('u.id')->getResult();

Fixed in https://github.com/doctrine/doctrine2/commit/80284a273ded303c059b013808d1199d8546d359