[DDC-2946] [GH-926] Feature/console em helper interface Created: 01/Feb/14  Updated: 21/Apr/14  Resolved: 21/Apr/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


 Description   

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

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

Message:



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

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

Comment by Guilherme Blanco [ 21/Apr/14 ]

This was merged some time ago.

Reference commit: https://github.com/doctrine/doctrine2/commit/105d9e998baffb44cb44cf08d1c31c448ef6302a





[DDC-2197] [GH-534] [DDC-2196] Improved "extendability" of EntityManager Created: 14/Dec/12  Updated: 21/Apr/14  Resolved: 16/Dec/12

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: Benjamin Eberlei 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/534

Message:

[DDC-2196 EntityManager can't be extended easily](http://www.doctrine-project.org/jira/browse/DDC-2196)

EntityManager::create now uses "new static" instead of "new EntityManager"



 Comments   
Comment by Benjamin Eberlei [ 14/Dec/12 ]

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

Comment by Benjamin Eberlei [ 14/Dec/12 ]

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

Comment by Benjamin Eberlei [ 16/Dec/12 ]

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

Comment by Doctrine Bot [ 23/Feb/14 ]

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

Comment by Doctrine Bot [ 21/Apr/14 ]

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





[DDC-3058] [GH-993] Update JoinColumn.php Created: 28/Mar/14  Updated: 21/Apr/14  Resolved: 21/Apr/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: Guilherme Blanco
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

If $referencedColumnName = 'id' by default, it doesn't make sense to make checks like:
```php
if (empty($joinColumn['referencedColumnName'])) {
```
(ClassMetaDataInfo file)


Considering you map your column
```
@ORM\JoinColumn(onDelete="CASCADE")
```
You'll get JoinColumn with 'id' value, which doesn't let doctrine use naming strategies for referenced column names



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

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

Comment by Guilherme Blanco [ 21/Apr/14 ]

Unfortunately, while this is true for Annotations (it can never be empty), it is not for XML, YAML and PHP itself.
When using Annotations, we keep convention over configuration as the standard, providing the default id, while we require further configuration on other drivers.

Closing as invalid.





[DDC-3063] Unexpected behavior with 'WHERE NOT IN' and empty array Created: 01/Apr/14  Updated: 21/Apr/14

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

Type: Bug Priority: Major
Reporter: Tim Stamp Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: None
Environment:

CentOS, PHP 5.4, mysql



 Description   

I tried to set version to 2.4.0 but was prevented.

Assume the set 'n' contains 10 records, all with id > 0.

->andWhere('n.id NOT IN (:ids)')->setParameter('ids', [])
returns 0 records.

->andWhere('n.id NOT IN (:ids)')->setParameter('ids', [0])
returns 10 records.


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

This is a simple misunderstanding of how SQL IN() works

Comment by Tim Stamp [ 01/Apr/14 ]

You're right that its invalid SQL, but this is DQL. In SQL this would raise an error, in DQL it says nothing and returns nothing.

Isnt there a way to check if a statement has caused this error?

Comment by Marco Pivetta [ 01/Apr/14 ]

Tim Stamp yeah, when using IN() and NOT IN() you should actually check if the parameters are empty or not before adding the clause.

Comment by Steve Müller [ 01/Apr/14 ]

It's still weird that no error is raised by that. Tim Stamp can you check what SQL is generated by your query?

Comment by Steve Müller [ 01/Apr/14 ]

Hehe I think I got the problem. It might be DBAL related. See:

https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/SQLParserUtils.php#L140
https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/SQLParserUtils.php#L169

Looks like the implementing person did that by intention but don't ask me why.

Comment by Marco Pivetta [ 01/Apr/14 ]

Thats to avoid having an SQL statement like

SELECT * FROM foo WHERE bar IN()

, which is invalid.

Indeed, the NOT IN() case is not contemplated by that.

Comment by Steve Müller [ 01/Apr/14 ]

Just wondering if that kind of implementation isn't changing expectations because it looks like IN(NULL) will select all NULL rows then, even though this is not explicitly requested by the user. I don't care really TBH but this behaviour is not very transparent to the user. Personally I would like to see an error instead... Then at least I know what's going on and can fix that by additional checks instead.

Comment by Marco Pivetta [ 01/Apr/14 ]

Makes sense. Re-opening.

Comment by Steve Müller [ 01/Apr/14 ]

The question is if we can change this behaviour without breaking applications that rely on the current one. Because changing the code to throw an error breaks applications that insist on returning 0 rows for an empty array. I don't know what rules apply here concerning BC. What do you think Marco Pivetta?

Comment by Marco Pivetta [ 01/Apr/14 ]

Steve Müller existing apps should do following anyway:

if ($productIds) {
    $qb->andWhere('p.id IN (:productIds)')->setParameter('productIds', $productIds);
}

If they are not, that's most likely a bug in their codebase.

Comment by Steve Müller [ 01/Apr/14 ]

Agree. Was just wondering about what we can expect and what we can't expect.

Comment by Guilherme Blanco [ 21/Apr/14 ]

Steve Müller feel free to patch DBAL.
It's a bug, not a supported feature. If we have 2 tickets:
1- If I pass an empty array, I get nullable rows and I can't fix this
2- If I pass an empty array, it used to return nullable rows, now it returns nothing
Which one would you fix?





[DDC-3085] NULL comparison are not supported for result variables in the HAVING clause Created: 15/Apr/14  Updated: 21/Apr/14  Resolved: 21/Apr/14

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

Type: Bug Priority: Major
Reporter: Christophe Coevoet Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

the following DQL query fails saying that score does not point to a class:

SELECT u AS user, SUM(r.value) AS score
FROM User u
LEFT JOIN ResultEntry r WITH r.user = u
GROUP BY u
HAVING score IS NOT NULL AND score >= 5

When removing the condition score IS NOT NULL, the query is working fine. The score result variable can be used in other comparisons:

SELECT u AS user, SUM(r.value) AS score
FROM User u
LEFT JOIN ResultEntry r WITH r.user = u
GROUP BY u
HAVING score >= 5


 Comments   
Comment by Guilherme Blanco [ 21/Apr/14 ]

Added coverage for this issue on master as of https://github.com/doctrine/doctrine2/commit/63d21ca4b28cb0e9192dadf6ff9d9dd17f0c2e4c
I'm unable to "fix" this because it's an enhancement to DQL (support ResultVariable in NullComparisonExpression) that cannot be done in 2.4 series. Please use 2.5 (currently dev-master) instead.





[DDC-3095] [GH-1014] Update second level cache doc Created: 20/Apr/14  Updated: 21/Apr/14  Resolved: 21/Apr/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


 Description   

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

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

Message:

Hi,

While testing the second level cache (side note: this is truly awesome and flexible, I love the fact it works with Criteria too), I realized that if you add the "Cache" annotation to an association, it won't put in cache the associated entities, until you also mark the target entity as cacheable. This is not obvious from reading the doc (and I don't know if that's expected behavior neither).



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

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

Comment by Guilherme Blanco [ 21/Apr/14 ]

This issue got merged into master.





[DDC-3065] Generated 'IN' clause doesn't handle 'null' values (needs to add 'IS NULL' check) Created: 03/Apr/14  Updated: 21/Apr/14  Resolved: 21/Apr/14

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

Type: Bug Priority: Critical
Reporter: Sam Adams Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: IN, null, orm

Issue Links:
Dependency
depends on DDC-3067 [GH-999] DDC-3065 null value in in cr... Resolved
Reference
is referenced by DDC-3066 [GH-998] DDC-3065 null value in in cr... Resolved

 Description   

BasicEntityPersister::getSelectSQL($criteria) first argument can take an array.
However, if that array contains an 'or' structure like so:

array(
  'mycol'=>array(
    'couldbethis','orthis',null
  )
);

it is converted into:

mycol IN (?)

With the final query looking like:

WHERE mycol IN ('couldbethis','orthis',null)

The problem is, mysql will never be able to match the null.

Possible change to getSelectConditionStatementSQL method:

        if (is_array($value)) {
            $in = sprintf('%s IN (%s)' , $condition, $placeholder);
            $nullKey = array_search(null, $value, true);

            if ($nullKey) {
                return sprintf('(%s OR %s IS NULL)' , $in, $condition);
            } else {
                return $in;
            }
        }

resulting in a final query like:

WHERE (mycol IN ('couldbethis','orthis',null) OR mycol IS NULL)


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

Please see https://github.com/doctrine/doctrine2/pull/998 - I applied your suggested fix and tested it carefully

Comment by Doctrine Bot [ 03/Apr/14 ]

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

Comment by Guilherme Blanco [ 21/Apr/14 ]

As of https://github.com/doctrine/doctrine2/commit/4185a9ce4b205e683097842916c8a8929659c6d1 this issue is fixed.





[DDC-3066] [GH-998] DDC-3065 null value in in criteria support Created: 03/Apr/14  Updated: 21/Apr/14  Resolved: 03/Apr/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: Invalid Votes: 0
Labels: None

Issue Links:
Reference
relates to DDC-3065 Generated 'IN' clause doesn't handle ... Resolved

 Description   

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

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

Message:

See DDC-3065 (http://www.doctrine-project.org/jira/browse/DDC-3065)

This MAY be a breakage, since the following API now works as expected:

```php
$repository->findBy(['fieldName' => [null]);
$repository->findBy(['fieldName' => [123, null]);
```

Where before, `null` was just ignored



 Comments   
Comment by Doctrine Bot [ 03/Apr/14 ]

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

Comment by Marco Pivetta [ 03/Apr/14 ]

Wrong branch name.

Comment by Doctrine Bot [ 21/Apr/14 ]

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





[DDC-3067] [GH-999] DDC-3065 null value in in criteria support Created: 03/Apr/14  Updated: 21/Apr/14  Resolved: 17/Apr/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: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Dependency
is required for DDC-3065 Generated 'IN' clause doesn't handle ... Resolved

 Description   

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

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

Message:

See DDC-3065 (http://www.doctrine-project.org/jira/browse/DDC-3065)

This MAY be a breakage, since the following API now works as expected:

```php
$repository->findBy(['fieldName' => [null]]);
$repository->findBy(['fieldName' => [123, null]]);
```

Where before, `null` was just ignored



 Comments   
Comment by Doctrine Bot [ 03/Apr/14 ]

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

Comment by Fabio B. Silva [ 17/Apr/14 ]

Closed, see : https://github.com/doctrine/doctrine2/pull/998

Comment by Doctrine Bot [ 21/Apr/14 ]

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





[DDC-3075] [GH-1005] Added support of the subselect expressions into NEW expressions Created: 08/Apr/14  Updated: 20/Apr/14  Resolved: 20/Apr/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


 Description   

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

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

Message:

Added support for the subselects into the ���NEW��� Operator Syntax



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

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

Comment by Guilherme Blanco [ 20/Apr/14 ]

As of https://github.com/doctrine/doctrine2/commit/a3f95d919bfa52550b271486cd6e256e6c91d356 this issue is closed





[DDC-3094] dbal and orm versions not compatible Created: 20/Apr/14  Updated: 20/Apr/14  Resolved: 20/Apr/14

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

Type: Bug Priority: Blocker
Reporter: Luis Cordova Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: dbal, orm


 Description   

( ! ) Fatal error: Call to undefined method Doctrine\ORM\Event\LifecycleEventArgs::format() in /Users/cordoval/Sites/x/vendor/doctrine/dbal/lib/Doctrine/DBAL/Types/DateTimeType.php on line 53

This is happening on sf2.4 default project

"require":

{ "php": ">=5.3.3", "symfony/symfony": "~2.4", "doctrine/orm": "~2.2,>=2.2.3", "doctrine/doctrine-bundle": "~1.2", "twig/extensions": "~1.0", "symfony/assetic-bundle": "~2.3", "symfony/swiftmailer-bundle": "~2.3", "symfony/monolog-bundle": "~2.4", "sensio/distribution-bundle": "~2.3", "sensio/framework-extra-bundle": "~3.0", "incenteev/composer-parameter-handler": "~2.0", "jms/security-extra-bundle": "1.5.*", "jms/di-extra-bundle": "1.4.*", "friendsofsymfony/user-bundle": "dev-master@dev", "doctrine/doctrine-migrations-bundle": "dev-master@dev", "doctrine/migrations": "dev-master@dev", "doctrine/doctrine-fixtures-bundle": "dev-master@dev", "doctrine/data-fixtures": "dev-master@dev", "symfony/icu": "~1.1", "colourstream/cron-bundle": "dev-update23@dev", "nelmio/alice": "dev-master@dev", "raulfraile/ladybug-bundle": "0.7", "guzzle/guzzle": "~3.7", "jms/serializer-bundle": "0.12.0", "beberlei/DoctrineExtensions": "dev-master@dev" }

,
"require-dev":

{ "behat/behat": "~3.0@dev", "phpspec/phpspec": "dev-master@dev", "phpspec/symfony2-extension": "dev-master@dev", "behat/mink-bundle": "~1.4", "phpunit/phpunit": "~3.7", "behat/mink-selenium2-driver": "~1.1" }

,



 Comments   
Comment by Luis Cordova [ 20/Apr/14 ]

closing but you guys broke backward compatibility here, i had to figure it out thanks though

Comment by Luis Cordova [ 20/Apr/14 ]





[DDC-2575] Hydration bug Created: 27/Jul/13  Updated: 18/Apr/14  Resolved: 18/Apr/14

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

Type: Bug Priority: Major
Reporter: Nicolas Bottarini Assignee: Guilherme Blanco
Resolution: Fixed Votes: 1
Labels: dql, orm


 Description   

I have the following class mappings:

class A
{
    /**
     * @Id
     * @Column(type="integer")
     * @GeneratedValue(strategy="AUTO")
     */
    protected $id;
    
    /**
     * @Column(type="string", length=100, nullable=FALSE)
     */    
    protected $sampleField;
    
    /**
     * @OneToOne(targetEntity="B", mappedBy="aRelation")
     **/     
    protected $bRelation;
}
class B
{
    /**
     * @Id
     * @OneToOne(targetEntity="A", inversedBy="bRelation")
     * @JoinColumn(name="a_id", referencedColumnName="id", nullable=FALSE, onDelete="CASCADE")
     */
    protected $aRelation;

    /**
     * @ManyToOne(targetEntity="C")
     * @JoinColumn(name="c_id", referencedColumnName="id", nullable=FALSE, onDelete="CASCADE")
     */
    protected $cRelation;

}
class C
{
    /**
     * @Id
     * @Column(type="integer")
     * @GeneratedValue(strategy="AUTO")
     */
    protected $id;
    
    /**
     * @Column(type="string", length=100, nullable=FALSE)
     */    
    protected $sampleField;
}

Then I make the following query:

$qb = $em->createQueryBuilder();
$qb = $qb->select('a, b, c')
      ->from('A','a')
      ->leftJoin('a.bRelation', 'b')
      ->leftJoin('b.cRelation', 'c');
      
$result = $qb->getQuery()->getResult();

The result contains a collection of instances of class A with the a.bRelation field populated and the a.bRelation.cRelation field populated in all rows except the last one.

The problem is an hydration problem. The Parser constructs the select statement with the fields of class A, then the fields of class C and last the fields of class B. The hydrator don't work correctly because when it's hydrating class C it doesn't find the class B (because it appears last in the select statement).
I think the problem is because class B only contains associations. If i put an extra field (an string for example) in class B it works as expected.



 Comments   
Comment by Popy [ 28/Oct/13 ]

I have the same kind of bug : i have a OneToMany relations which stays to null if I request both entities in one query, and miss an entity if I preload the related entities in a second query. It seems to occur on the last entity of the list.

If I remember well the hydrator code, there's (in the hydratation loop) something like "If we find a new root entity (or maybe on each row, i'm not sure), link the entities we didn't link". Maybe this thing is not done AFTER the loop for remaining entities.

I'll try to dig again into the hydrator code tomorrow to check this hypothesis.

Comment by Popy [ 29/Oct/13 ]

This bug seems more severe :

I made a test on a query with 3 entities (root, root->a, root->b, a and b relations are OneToMany, so no connections on this side), and there's the process I witness :

  • First result row
  • The hydrator finds the linked entities before the root... and just does nothing (line 359)
  • The hydrator finds the root entity, and hydrate it
  • Other result rows
  • The hydrator finds the linked entities before the root... and associate them with the previously found root entity, which is the root entity fetched on the first row
  • The hydrator finds the root entity, so trash the previous, and hydrate (without related entities, as they were linked to previous root entity)

To finish, the last row has no related entities, as its related entities were given to the previous row.

Comment by Popy [ 29/Oct/13 ]

Bug confirmed in a small Symfony app and Doctrine 2.3. I managed to reproduce the bug with 3 entities :

  • A (id autoincrement)
  • B (id autoincrement)
  • Root (composite id a,b which are ManyToOne relations to A and B entities)

Can provide the app to ease things.

Comment by Popy [ 29/Oct/13 ]

Possible workaround : declaring integer fields as ID (with the same field name as relation fields) makes the thing working again (at the price of thoose two useless properties and a prePersist method to fill them with related entity ids)

Comment by Benjamin Eberlei [ 14/Dec/13 ]

First step here: Try to reproduce this issue with the given entities above in a Testcase

Comment by Karol Horowski [ 14/Dec/13 ]

I created test for this issue, but I can't reproduce id. My pull request is here https://github.com/doctrine/doctrine2/pull/878

Comment by Popy [ 15/Dec/13 ]

You should maybe call $this->_em->clear() at the end of your setUp method.

I still have a Symfony Bundle reproducing the bug, how can i hand it to you ?

Comment by Benjamin Eberlei [ 15/Dec/13 ]

Popy you can create a branch of that symfony standard edition, and push it to a fork of symfony-standard on your Github account. Then you can comment a link to your branch on Github.

Comment by Karol Horowski [ 17/Dec/13 ]

After Popy's suggestion I added $this->_em->clear() and now I have failing test. My fault with this quick "everything is ok".

I tried to search what's happening in ObjectHydrator but something strange is going on in hydrateRowData method.

Comment by Popy [ 17/Dec/13 ]

Be carefull, headache come fast while reading this method

As far as I know, the problem could be solved if the hydrator started by hydrating the root entity first. Maybe.

Comment by Karol Horowski [ 19/Dec/13 ]

In select statement fields are in this order Root, B, A. Relations in my test are Root 1:1 A *:1 B.
Hydrator first gets Root data and next B. But here (line 407 in ObjectHydrator) it doesn't find A parent in resultPointers.

For now I don't have any idea how to add new logic for this.

Comment by Doctrine Bot [ 18/Apr/14 ]

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

Comment by Guilherme Blanco [ 18/Apr/14 ]

As of https://github.com/doctrine/doctrine2/commit/38b683838648b549aad0e38ce88c70b6393755b3 this issue is now fixed.





[DDC-2858] [GH-878] [DDC-2575] test for hydration problem issue Created: 14/Dec/13  Updated: 18/Apr/14  Resolved: 14/Dec/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 karolhor:

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

Message:

I made test for DDC-2575 issue but I couldn't reproduced it. All fields are populated correctly.



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

Duplicate of DDC-2575

Comment by Doctrine Bot [ 18/Apr/14 ]

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





[DDC-3093] [GH-1013] Remove SimpleXmlElement hack Created: 18/Apr/14  Updated: 18/Apr/14  Resolved: 18/Apr/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: Guilherme Blanco
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/1013

Message:

The functionality it self its already tested by : https://github.com/doctrine/doctrine2/blob/master/tests/Doctrine/Tests/ORM/Tools/Export/AbstractClassMetadataExporterTest.php#L155



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

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

Comment by Guilherme Blanco [ 18/Apr/14 ]

Fixed already.





[DDC-2783] EntityManager::transactional empty values as true Created: 07/Nov/13  Updated: 18/Apr/14

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

Type: Improvement Priority: Major
Reporter: Kirill chEbba Chebunin Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: entitymanager, transactional


 Description   

The problem:
Any response from transactional callback which is evaluated to false (empty array, empty string, 0, null, etc) becomes true

$return = call_user_func($func, $this);

$this->flush();
$this->conn->commit();

return $return ?: true;

There is the old resolved issue DDC-1336, which describes this behavior.
@return tag is clear now.

@return mixed Returns the non-empty value returned from the closure or true instead

But this logic is blowing mind and leading to unexpectable results. The expected behavior is just return callback result, i don't see any good use cases for current implementation.

It requires a BC break. Can the deprecation process be started to change this behaviour in few major releases?



 Comments   
Comment by Christophe Coevoet [ 07/Nov/13 ]

I agree that this makes the method hard to use. And I don't undertstand why it would replace the return value.

What was the intention for this Benjamin ?

Comment by Guilherme Blanco [ 18/Apr/14 ]

Christophe Coevoet Benjamin Eberlei I'm considering to remove the ternary and always return the callback result.
What do you think? It seems like a minor BC break, but would like to get more feedback around this.

Comment by Marco Pivetta [ 18/Apr/14 ]

Guilherme Blanco this was already refused before because of the BC break.





[DDC-3069] [GH-1000] [DDC-3068] EntityManager::find accept array of object as id Created: 04/Apr/14  Updated: 18/Apr/14  Resolved: 18/Apr/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: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

Pull Request for ticket http://www.doctrine-project.org/jira/browse/DDC-3068
Here follow the ticket description for you convenience.

According to the documentation, ``EntityManager::find`` should return one entity given it's primary key. When a primary key of an entity is composed of multiple associations, one (me ) would expect that the following works, but it doesn't:
```php
$entity = $_em->find('My\EntityClass', array(
'assoc1' => $instance1,
'assoc2' => $instance2
));
PHP Fatal error: Object of class My\EntityClass could not be converted to string
```
The only working way I've found is the following:
```php
$entity = $_em->find('My\EntityClass', array(
'assoc1' => $instance1->getId(),
'assoc2' => $instance2->getId()
));
```
I think that this second scenario is not correct, since expose implementation details.



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

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

Comment by Guilherme Blanco [ 18/Apr/14 ]

As of https://github.com/doctrine/doctrine2/commit/10a0daf6203b6d2ea0c92e30edb07ca7e83058b3 this issue was fixed.





[DDC-3068] EntityManager::find does not accept an array of object as a primary key Created: 03/Apr/14  Updated: 18/Apr/14  Resolved: 18/Apr/14

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

Type: Improvement Priority: Minor
Reporter: Giorgio Premi Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

According to the documentation, EntityManager::find should return one entity given it's primary key. When a primary key of an entity is composed of multiple associations, one (me ) would expect that the following works, but it doesn't:

$entity = $_em->find('My\EntityClass', array(
    'assoc1' => $instance1,
    'assoc2' => $instance2
));
PHP Fatal error:  Object of class My\EntityClass could not be converted to string

The only working way I've found is the following:

$entity = $_em->find('My\EntityClass', array(
    'assoc1' => $instance1->getId(),
    'assoc2' => $instance2->getId()
));

I think that this second scenario is not correct, since expose implementation details.

I've created a patch on my github fork, I'll create a pull request ASAP.



 Comments   
Comment by Guilherme Blanco [ 18/Apr/14 ]

As of https://github.com/doctrine/doctrine2/commit/10a0daf6203b6d2ea0c92e30edb07ca7e83058b3 issue was fixed.





[DDC-823] Errors in 2.0 Cookbook Documentation Created: 01/Oct/10  Updated: 18/Apr/14  Resolved: 18/Apr/14

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

Type: Task Priority: Trivial
Reporter: Ralfas Jegorovas Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

http://www.doctrine-project.org/projects/orm/2.0/docs/cookbook/getting-started-xml-edition/en#getting-started-xml-edition

Paragraph 1:
The benefit of Doctrine for the programmer is the possibility can to focus soley solely on the business and worry about persistence only as a secondary task. This doesn't mean persistence is not important to Doctrine 2, however it is our belief that there are considerable benefits for object-oriented programming, if persistence and entities are kept perfectly seperated separated.

Paragraph 2:
Entities are leightweight lightweight PHP Objects that don't need to extend any abstract base class or interface. An entity class must not be final or contain final methods. Additionally it must not implement __clone nor __wakeup or it should do so safely.

What would be the best way to note other errors?



 Comments   
Comment by Benjamin Eberlei [ 04/Oct/10 ]

The best way for us would be if you fork the docs on github, change the stuff and commit it. Then issue a pull request. It sounds complicated, but should be minimal overhead of ~5 minutesn on your end, but then we can merge it with a mouse-click, so we dont need to duplicate the whole correction effort on our end.

Comment by Joel Clermont [ 27/Jan/11 ]

I have fixed the typos from this ticket that were still present in the docs and issued a pull request on Github.

Comment by Michael Ridgway [ 11/Jul/11 ]

This issue should be closed: https://github.com/doctrine/orm-documentation/pull/17

Comment by Guilherme Blanco [ 18/Apr/14 ]

Issue got fixed somehow in the past





[DDC-2276] [GH-569] Hotfix/pre flush event args params Created: 04/Feb/13  Updated: 18/Apr/14  Resolved: 12/Feb/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: Benjamin Eberlei Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

As reported by a user on IRC, the `PreFlushEventArgs` object was built with incorrect parameters. this fix solves the problem by typehinting the constructor.

Tests aren't really necessary since a lot of functional tests were simply broken because of this additional typehint.



 Comments   
Comment by Benjamin Eberlei [ 12/Feb/13 ]

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

Comment by Fabio B. Silva [ 12/Feb/13 ]

Merged : https://github.com/doctrine/doctrine2/commit/719031f2effd2074d94c709b6b7311fb0773fb7f

Comment by Doctrine Bot [ 18/Apr/14 ]

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





[DDC-3021] [GH-976] Add cache invalidation strategy to AbstractQuery Created: 11/Mar/14  Updated: 17/Apr/14  Resolved: 17/Apr/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


 Description   

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

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

Message:

By adding the cached timestamps of the involved entity tables to the query hash, we will invalidate the cache when any of those tables have changed.



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

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

Comment by Fabio B. Silva [ 17/Apr/14 ]

Closed, see : https://github.com/doctrine/doctrine2/pull/976





[DDC-3074] [GH-1004] Removed all useless occurrence of require_once TestInit.php Created: 07/Apr/14  Updated: 17/Apr/14  Resolved: 17/Apr/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


 Description   

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

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

Message:

As @Ocramius pointed out when discussing about PR #1000, the statement ``require_once [...]TestInit.php`` is no longer useful.

I've removed all occurrence from the test cases.



 Comments   
Comment by Doctrine Bot [ 07/Apr/14 ]

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

Comment by Fabio B. Silva [ 17/Apr/14 ]

Fixed by : https://github.com/doctrine/doctrine2/commit/73e5bbecbef311194085e30d8b7fd6516bc50425





[DDC-2975] [GH-951] More informational entity not found exception Created: 11/Feb/14  Updated: 17/Apr/14  Resolved: 17/Apr/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


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 16/Apr/14 ]

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

Comment by Fabio B. Silva [ 17/Apr/14 ]

Fixed by : https://github.com/doctrine/doctrine2/commit/6e9b15a48fa9db4db6ba3cbb8c4fa5d40306a07c





[DDC-3081] [GH-1009] HHVM compatibility Created: 10/Apr/14  Updated: 17/Apr/14  Resolved: 17/Apr/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


 Description   

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

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

Message:

With this PR (based on DDC-3078, see #1008) we finally get 100% compatibility with HHVM as we described on http://www.doctrine-project.org/2013/12/23/our-hhvm-roadmap.html

This PR needs to be rebased on master once #1008 is merged.



 Comments   
Comment by Doctrine Bot [ 17/Apr/14 ]

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

Comment by Doctrine Bot [ 17/Apr/14 ]

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

Comment by Fabio B. Silva [ 17/Apr/14 ]

Fixed by : https://github.com/doctrine/doctrine2/commit/54d9f05e39bc6c0943a48dfb523675c931a1435b





[DDC-3080] [GH-1008] DDC-3078 SLC Cache interface ctor removal Created: 10/Apr/14  Updated: 17/Apr/14  Resolved: 17/Apr/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: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Dependency
is required for DDC-3078 Doctrine\ORM\Cache::__construct is in... Resolved

 Description   

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

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

Message:

See DDC-3078 ( http://www.doctrine-project.org/jira/browse/DDC-3078 ) - the cache interface should NOT cover a constructor.



 Comments   
Comment by Doctrine Bot [ 17/Apr/14 ]

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

Comment by Doctrine Bot [ 17/Apr/14 ]

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

Comment by Fabio B. Silva [ 17/Apr/14 ]

Fixed by https://github.com/doctrine/doctrine2/commit/6af3236ba6f285fe14763866b20ddc1085e6ea39





[DDC-3078] Doctrine\ORM\Cache::__construct is in an interface Created: 10/Apr/14  Updated: 17/Apr/14  Resolved: 17/Apr/14

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

Type: Bug Priority: Blocker
Reporter: Marco Pivetta Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: cache, config, second-level-cache

Issue Links:
Dependency
depends on DDC-3080 [GH-1008] DDC-3078 SLC Cache interfac... Resolved

 Description   

CTOR in the interface is a huge problem. This absolutely needs to be fixed before 2.5 is released, or we will have trouble in future.

I'm writing a PoC patch right now.



 Comments   
Comment by Fabio B. Silva [ 17/Apr/14 ]

Fixed by https://github.com/doctrine/doctrine2/commit/6af3236ba6f285fe14763866b20ddc1085e6ea39





[DDC-3092] [GH-1012] Ddc 3078 slc cache interface ctor removal Created: 17/Apr/14  Updated: 17/Apr/14  Resolved: 17/Apr/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: Guilherme Blanco
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/1012

Message:



 Comments   
Comment by Doctrine Bot [ 17/Apr/14 ]

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

Comment by Guilherme Blanco [ 17/Apr/14 ]

Issue now merged! \o/





[DDC-2890] Paginator generates invalid sql for some dql with setUseOutputWalkers(false) and $fetchJoinCollection = true Created: 07/Jan/14  Updated: 17/Apr/14  Resolved: 17/Apr/14

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

Type: Bug Priority: Major
Reporter: Jiri Kavalik Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: paginator
Environment:

ubuntu 12.04, ZF2 2.2.5, mysql 5.5.34



 Description   

We use doctrine paginator in zf2 for list pagination.

We tried to disable UseOutputWalkers because of performance gain - for some entities expected table size is in millions and we are paginating simple lists with some inner joins - but with UseOutputWalkers(false) and fetchJoinCollection=true (default) we get exception for queries ordering by referenced entity id.

Examples:

  • OK - DQL:
    SELECT Transaction FROM Transaction\Entity\Transaction Transaction ORDER BY Transaction.balance asc
    

    SQL:

    SELECT t0_.id AS id0, t0_.value AS value1, t0_.balance AS balance2, t0_.created_on AS created_on3, t0_.type_id AS type_id4, t0_.canceled_id AS canceled_id5, t0_.canceling_id AS canceling_id6, t0_.wallet_id AS wallet_id7 FROM transaction t0_ ORDER BY t0_.balance ASC
    

    Paginator SQL:

    SELECT count(DISTINCT t0_.id) AS sclr0 FROM transaction t0_
    SELECT DISTINCT t0_.id AS id0, t0_.balance AS balance1 FROM transaction t0_ ORDER BY t0_.balance ASC LIMIT 10 OFFSET 0
    SELECT t0_.id AS id0, t0_.value AS value1, t0_.balance AS balance2, t0_.created_on AS created_on3, t0_.type_id AS type_id4, t0_.canceled_id AS canceled_id5, t0_.canceling_id AS canceling_id6, t0_.wallet_id AS wallet_id7 FROM transaction t0_ WHERE t0_.id IN (?) ORDER BY t0_.balance ASC
    
  • Exception - Error producing an iterator - DQL:
    SELECT Transaction FROM Transaction\Entity\Transaction Transaction ORDER BY Transaction.type asc
    

    SQL:

    SELECT t0_.id AS id0, t0_.value AS value1, t0_.balance AS balance2, t0_.created_on AS created_on3, t0_.type_id AS type_id4, t0_.canceled_id AS canceled_id5, t0_.canceling_id AS canceling_id6, t0_.wallet_id AS wallet_id7 FROM transaction t0_ ORDER BY t0_.type_id ASC
    

    Paginator SQL with error:

    SELECT count(DISTINCT t0_.id) AS sclr0 FROM transaction t0_
    SELECT DISTINCT t0_.id AS id0, t0_. AS _1 FROM transaction t0_ ORDER BY t0_.type_id ASC LIMIT 10 OFFSET 0
    SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'AS _1 FROM transaction t0_ ORDER BY t0_.type_id ASC LIMIT 10 OFFSET 0' at line 1
    

    Same query with $fetchJoinCollection = false - OK - paginator SQL:

    SELECT count(DISTINCT t0_.id) AS sclr0 FROM transaction t0_
    SELECT t0_.id AS id0, t0_.value AS value1, t0_.balance AS balance2, t0_.created_on AS created_on3, t0_.type_id AS type_id4, t0_.canceled_id AS canceled_id5, t0_.canceling_id AS canceling_id6, t0_.wallet_id AS wallet_id7 FROM transaction t0_ ORDER BY t0_.type_id ASC LIMIT 10 OFFSET 0
    
  • using setUseOutputWalkers(true) generates most robust queries but count is really slow for 200k+ tables


 Comments   
Comment by Guilherme Blanco [ 17/Apr/14 ]

As of https://github.com/doctrine/doctrine2/commit/be1cc14a9c8641774d614f788103cef4a5373bb1 issue is now fixed.





[DDC-2935] [GH-919] tests for DDC-2890 Created: 24/Jan/14  Updated: 17/Apr/14  Resolved: 17/Apr/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: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

First error is notice level so I added second test with notices ignored to show actual malformed SQL which will be executed on server ignoring notices.



 Comments   
Comment by Doctrine Bot [ 17/Apr/14 ]

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

Comment by Guilherme Blanco [ 17/Apr/14 ]

As of https://github.com/doctrine/doctrine2/commit/be1cc14a9c8641774d614f788103cef4a5373bb1 this issue is fixed.





[DDC-3090] Cannot use single table inheritance in entities deriving from classes using class table inheritance Created: 17/Apr/14  Updated: 17/Apr/14  Resolved: 17/Apr/14

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

Type: Bug Priority: Major
Reporter: Przemyslaw Wrobel Assignee: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: None


 Description   

I have the following classes:

/**
 * @ORM\Table(name="diet_entries")
 * @ORM\Entity
 * @ORM\InheritanceType("JOINED")
 * @ORM\DiscriminatorColumn(name="discriminator", type="string")
 * @ORM\DiscriminatorMap({"recipe" = "Recipe", "ingredient" = "Ingredient" })
 */
abstract class DietEntry {}
/**
 * @ORM\Table(name="recipes")
 */
class Recipe extends DietEntry {}
/**
 * @ORM\Table(name="ingredients")
 * @ORM\InheritanceType("SINGLE_TABLE")
 * @ORM\DiscriminatorColumn(name="discriminator", type="string")
 * @ORM\DiscriminatorMap({ "ingredient" = "Ingredient", "supplement" = "Supplement" })
 */
class Ingredient extends DietEntry {}
/**
 * @ORM\Entity
 */
class Supplement extends Ingredient {}

and these tables: diet_entries, recipes, ingredients.

The idea was not to create the table for supplements since a supplement needs no extra attributes other then those derived from an ingredient, otherwise I would have added Supplement to discriminator map of DietEntry and provided a table for it which is mandatory in JOINED inheritance.
But the problem now is that when a query is build it looks like this:

An exception occurred while executing

SELECT i0_.id AS id0, i0_.name AS name1, i0_.energy AS energy2, d1_.name AS name3, d2_.name AS name4 FROM ingredients i0_ INNER JOIN diet_databases d1_ ON d3_.database_id = d1_.id LEFT JOIN dictionary d2_ ON i0_.group_id = d2_.id WHERE i0_.discriminator IN ('ingredient', 'supplement')

SQLSTATE[42S22]: Column not found: 1054 Unknown column 'i0_.name' in 'field list

The query for Ingredient is missing a join with the diet_entries table from which the ingredient derives. ORM only sees entities/tables down the inheritance path from the Ingredient class but not up from Ingredient to DietEntry



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

Duplicate of DDC-138





[DDC-2275] [GH-568] Fixed plural variable names to singular when generating add or remove methods for entities Created: 04/Feb/13  Updated: 17/Apr/14  Resolved: 02/Jan/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: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

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

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

Message:

Changed generateEntityStubMethod so that variable names in add or remove methods are singular too

Edited tests for EntityGenerator so that variable names are checked too



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

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

Comment by Doctrine Bot [ 17/Apr/14 ]

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





[DDC-3089] Doctrine1 to Doctrine2 Oracle type float Created: 17/Apr/14  Updated: 17/Apr/14  Resolved: 17/Apr/14

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

Type: Bug Priority: Major
Reporter: Antoine Dr Assignee: Steve Müller
Resolution: Invalid Votes: 0
Labels: None
Environment:

Linux - Oracle 10g



 Description   

I have a big problem migrating an application from Doctrine1 to Doctrine2.

The variable ROUNDNUMBER was set with Doctrine1 in the Oracle 10G database with the following schema :
ApprenticeYeartype:
columns:
id:

{type: integer, notnull: true, primary: true, autoincrement: true}

name:

{type: string(255), notnull: true}

roundNumber:

{type: float, notnull: true}

The values stored in this variable are: 0.1 or 0.5 or 1.0

In Oracle, the data type was set as "NUMBER" with no precision or scale set. I found this "If
a precision is not specified, the column stores values as given. If no scale is
specified, the scale is zero. ".
So there should be no scale which is weird because it worked with the values 0.1, 0.5...
It worked nicely on Symfony1 and Doctrine1, but for the migration to Symfony2 and Doctrine2, I used the command to import the schema from the database "php app/console doctrine:mapping:convert"

The created schema's ROUNDNUMBER variable was set with the Doctrine2 type "Integer". So now I get the variable as an int and not float and so I can't use it.

I tried changing the type to decimal, float etc...
/**

  • @var integer
    *
  • @ORM\Column(name="ROUNDNUMBER", type="integer", nullable=false)
    */
    private $roundnumber;

But I keep getting this error :
[Doctrine\DBAL\DBALException]
An exception occurred while executing 'ALTER TABLE APPRENTICE_YEARTYPE MODI
FY (ROUNDNUMBER DOUBLE PRECISION DEFAULT NULL)':

ORA-01440: column to be modified must be empty to decrease precision or sca
le

If anyone know a solution, please help me !



 Comments   
Comment by Steve Müller [ 17/Apr/14 ]

Looks like you create the column ROUNDNUMBER with an integer type mapping. Use "float" or "decimal" instead. When updating the schema please ensure that your ROUNDNUMBER column contains no data or at least all values in the column have to be NULL. See http://www.techonthenet.com/oracle/errors/ora01440.php
Please note that Doctrine's "float" maps to "DOUBLE PRECISION" and "decimal" to "NUMERIC(p,s)" on Oracle. See the DBAL types documentation for further information: http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/types.html#mapping-matrix

If you need further help, just drop me a line.

Comment by Steve Müller [ 17/Apr/14 ]

Not a Doctrine bug.





[DDC-3091] Not set entity to results if use query with JOIN Created: 17/Apr/14  Updated: 17/Apr/14

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

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


 Description   

Hi.
I have a problem, if i can use query with JOIN without grouping (DISTINCT) by identifier entity. Problem: not set entities to result, if entity has cached in ObjectHydration.

For example:

SQL query:

SELECT 
  b0_.id AS id0,
  b0_.hash AS hash1, 
  b0_.mii AS mii2, 
  b0_.iin AS iin3, 
  b0_.last_digits AS last_digits4, 
  b0_.number AS number5, 
  b0_.holder AS holder6, 
  p1_.keyword AS keyword7, 
  t2_.client AS client8, 
  CONCAT(b0_.hash, CONCAT(p1_.keyword, t2_.client)) AS sclr9 

FROM bank_card b0_ 
  INNER JOIN transaction_bank_card t2_ ON (t2_.bank_card_id = b0_.id) 
  INNER JOIN projects p1_ ON (t2_.project_key = p1_.keyword) 

WHERE (p1_.keyword = 'project1' AND t2_.client = '123') OR (p1_.keyword = 'project2' AND t2_.client = '321') /* ... Other where */

GROUP BY sclr9

Mysql result:

id0 hash1 mii2 iin3 last_digits4 number5 holder6 keyword7 client8 sclr9
28 1d741fd06f3315dad28039926effc5d7 5 533330 2763 533330******2763 John Doe p6 78165 1d741fd06f3315dad28039926effc5d7p678165
34 58b021876f625e3000137cd835f5fe40 5 555456 5047 555456******5047 OLOLO OLOLO p6 78165 58b021876f625e3000137cd835f5fe40p678165
2 887d30e9b4d18676c6e0dc8e21e36d28 5 556458 4251 556458******4251 Monkey Testing p6 78165 887d30e9b4d18676c6e0dc8e21e36d28p678165
1 bb14a77f2e363cd144b669f0b594d304 4 432114 1118 432114******1118 Monkey Testing p6 100673 bb14a77f2e363cd144b669f0b594d304p6100673
1 bb14a77f2e363cd144b669f0b594d304 4 432114 1118 432114******1118 Monkey Testing p6 100922 bb14a77f2e363cd144b669f0b594d304p6100922
1 bb14a77f2e363cd144b669f0b594d304 4 432114 1118 432114******1118 Monkey Testing p6 101441 bb14a77f2e363cd144b669f0b594d304p6101441
1 bb14a77f2e363cd144b669f0b594d304 4 432114 1118 432114******1118 Monkey Testing p6 78165 bb14a77f2e363cd144b669f0b594d304p678165
1 bb14a77f2e363cd144b669f0b594d304 4 432114 1118 432114******1118 Monkey Testing p6 85550 bb14a77f2e363cd144b669f0b594d304p685550
1 bb14a77f2e363cd144b669f0b594d304 4 432114 1118 432114******1118 Monkey Testing p6 85566 bb14a77f2e363cd144b669f0b594d304p685566
1 bb14a77f2e363cd144b669f0b594d304 4 432114 1118 432114******1118 Monkey Testing p6 85768 bb14a77f2e363cd144b669f0b594d304p685768

And the PHP code (from custom entity repository):

$qb
            ->select('bc')
            ->addSelect('p.key AS project_key')
            ->addSelect('tbc.client AS client')
            ->addSelect('CONCAT(bc.hash, CONCAT(p.key, tbc.client)) AS unique_key')
            ->innerJoin('FooBundle:TransactionBankCard', 'tbc', 'WITH', 'tbc.bankCard = bc.id')
            ->innerJoin('BarBundle:Project', 'p', 'WITH', 'tbc.project = p.key')
            ->where($orX)
            ->groupBy('unique_key');

        $result = $qb->getQuery()->getResult();

And this code returned only unique entities by identifier (Identifier: id field), but must returned the all entities from query.

The Object Hyndration has cached created entities, and if the next row is entity (indicate as identifier and dql alias), then hydration not set this entity to result.
Problem code: https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php#L569-L572

Thank.






[DDC-585] Create a coding standards document Created: 13/May/10  Updated: 17/Apr/14

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

Type: Documentation Priority: Major
Reporter: Roman S. Borschel Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None


 Description   

We need a new coding standards document for Doctrine 2.



 Comments   
Comment by Benjamin Morel [ 29/Jan/13 ]

Has there been any work on a coding standards document yet?
I'm currently working on fixing documentation on this project, and it might be a good time to define a standard.
I've started compiling a few recommendations based on various feedbacks I've got in my pull requests, and I can post them here.
Please let me know if there have been previous attempts so far!

Comment by Marco Pivetta [ 29/Jan/13 ]

Benjamin Morel Guilherme Blanco may have a CS ruleset, but it's not ready yet. Perfect timing btw, we really need to automate this to avoid having all these useless CS fix comments in pull requests

Comment by Benjamin Morel [ 29/Jan/13 ]

Ok, I'll post my document here once ready, and Guilherme Blanco will be able to compare it with his ruleset!

Comment by Benjamin Morel [ 30/Jan/13 ]

Here is a first draft: https://gist.github.com/4676670

Please comment!

Comment by Benjamin Morel [ 11/Feb/13 ]

Guilherme Blanco, if you don't have time to compare your ruleset with my draft, maybe you could publish your current ruleset so that others can have a look?

Comment by Benjamin Morel [ 02/Aug/13 ]

Any update guys? I'm willing to spend some time on this work, but if no one answers, we won't be going forward

Comment by Marco Pivetta [ 02/Aug/13 ]

Benjamin Morel I think a pull request against the doctrine website (https://github.com/doctrine/doctrine-website-sphinx) would be fine...

Comment by Steve Müller [ 17/Apr/14 ]

This should go into https://github.com/doctrine/coding-standard repo (long term).





[DDC-2274] [GH-567] Removed outdated methods in DatabasePlatformMock Created: 03/Feb/13  Updated: 17/Apr/14  Resolved: 05/Feb/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: 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 BenMorel:

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

Message:

`DatabasePlatformMock::getNativeDeclaration()` and `getPortableDeclaration()` do not override an existing method in `AbstractPlatform`.
I guess they are leftovers of a previous version, and should be removed.



 Comments   
Comment by Benjamin Eberlei [ 03/Feb/13 ]

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

Comment by Fabio B. Silva [ 05/Feb/13 ]

merged : https://github.com/doctrine/doctrine2/commit/ef1ed588b5db6f87399772f953bf8b6dc4d2556d

Comment by Doctrine Bot [ 17/Apr/14 ]

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





[DDC-1800] Paginator results is wrong if your query use order by clause Created: 27/Apr/12  Updated: 17/Apr/14  Resolved: 29/Aug/12

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.2.2
Fix Version/s: 2.3, 2.3.1
Security Level: All

Type: Bug Priority: Major
Reporter: Marc Drolet Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

linux oracle



 Description   

NOTE: I didn't try this on other database, I'm using Oracle.

if my original fetchJoin query use an order by clause, the results is not keeping the provided order by clause and re-order them by id.

here is my generated query to get the distinct records that get generated:

SELECT distinct ID0
FROM
(
SELECT f0_.id AS ID0, f0_.deal_type_id AS DEAL_TYPE_ID1, f0_.title AS TITLE2, f0_.deal_date AS DEAL_DATE3, f0_.amount AS AMOUNT4,
f0_.abstract AS ABSTRACT5, f0_.created_date AS CREATED_DATE6, f0_.last_updated_date AS LAST_UPDATED_DATE7,
f0_.object_status_id AS OBJECT_STATUS_ID8, f0_.published_date AS PUBLISHED_DATE9, f0_.publishing_status_id AS PUBLISHING_STATUS_ID10,
f1_.id AS ID11, f1_.role_id AS ROLE_ID12, f1_.role_type_id AS ROLE_TYPE_ID13, f2_.id AS ID14, f3_.id AS ID15, f4_.id AS ID16, f5_.id AS ID17,
c6_.id AS ID18, d7_.id AS ID19
FROM fo_deal f0_
INNER JOIN fo_deal_role f1_ ON f0_.id = f1_.deal_id
INNER JOIN fo_people f2_ ON f1_.people_id = f2_.id
INNER JOIN fo_property_deal f3_ ON f0_.id = f3_.deal_id
INNER JOIN fo_property f4_ ON f3_.property_id = f4_.id
LEFT JOIN fo_property_asset f5_ ON f4_.id = f5_.property_id
LEFT JOIN co_asset c6_ ON f5_.asset_id = c6_.id
LEFT JOIN ds_record d7_ ON c6_.ds_id = d7_.id
WHERE f1_.people_id = 2
AND f0_.object_status_id <> 3
AND f0_.publishing_status_id = 2
ORDER BY f0_.deal_date DESC, f0_.published_date DESC
)

running this query I get the id 30, 44 when the inner query return 44, 30

here is the query that should get generated to take care of the order by clause:
SELECT distinct ID0, rownum+
FROM
(
SELECT f0_.id AS ID0, f0_.deal_type_id AS DEAL_TYPE_ID1, f0_.title AS TITLE2, f0_.deal_date AS DEAL_DATE3, f0_.amount AS AMOUNT4,
f0_.abstract AS ABSTRACT5, f0_.created_date AS CREATED_DATE6, f0_.last_updated_date AS LAST_UPDATED_DATE7,
f0_.object_status_id AS OBJECT_STATUS_ID8, f0_.published_date AS PUBLISHED_DATE9, f0_.publishing_status_id AS PUBLISHING_STATUS_ID10,
f1_.id AS ID11, f1_.role_id AS ROLE_ID12, f1_.role_type_id AS ROLE_TYPE_ID13, f2_.id AS ID14, f3_.id AS ID15, f4_.id AS ID16, f5_.id AS ID17,
c6_.id AS ID18, d7_.id AS ID19
FROM fo_deal f0_
INNER JOIN fo_deal_role f1_ ON f0_.id = f1_.deal_id
INNER JOIN fo_people f2_ ON f1_.people_id = f2_.id
INNER JOIN fo_property_deal f3_ ON f0_.id = f3_.deal_id
INNER JOIN fo_property f4_ ON f3_.property_id = f4_.id
LEFT JOIN fo_property_asset f5_ ON f4_.id = f5_.property_id
LEFT JOIN co_asset c6_ ON f5_.asset_id = c6_.id
LEFT JOIN ds_record d7_ ON c6_.ds_id = d7_.id
WHERE f1_.people_id = 2
AND f0_.object_status_id <> 3
AND f0_.publishing_status_id = 2
ORDER BY f0_.deal_date DESC, f0_.published_date DESC
) ORDER BY rownum ASC

To fix this on the Paginator code:

file: ORM/Tools/Pagination/LimitSubqueryOutputWalker.php
method: walkSelectStatement

change:
$sql = sprintf('SELECT b.*, rownum as rn FROM (SELECT DISTINCT %s FROM (%s)) b', // AS _dctrn_result',
implode(', ', $sqlIdentifier), $sql);

for:
$sql = sprintf('SELECT b.*, rownum as rn FROM (SELECT DISTINCT %s, numrow FROM (%s) ORDER BY numrow ASC) b', // AS _dctrn_result',
implode(', ', $sqlIdentifier), $sql);



 Comments   
Comment by Marc Drolet [ 14/May/12 ]

rownum instead of numrow. sorry.

$sql = sprintf('SELECT b.*, rownum as rn FROM (SELECT DISTINCT %s, rownum FROM (%s) ORDER BY rownum ASC) b',
implode(', ', $sqlIdentifier), $sql);

Comment by Benjamin Eberlei [ 07/Jul/12 ]

Doctrine 2.2.2 doesnt have the LimitSubqueryoutputWalker and Doctrine 2.3-dev does not have the line in the code. Can you make a more explicit statement of where the change is necessary?

Comment by Marc Drolet [ 09/Jul/12 ]

It's in the Pagination of version 2.2.2. ORM/Tools/Pagination/LimitSubqueryOutputWalker.php

Comment by Benjamin Eberlei [ 09/Jul/12 ]

This is the 2.2 branch, https://github.com/doctrine/doctrine2/tree/2.2/lib/Doctrine/ORM/Tools/Pagination and https://github.com/doctrine/doctrine2/tree/2.2.2/lib/Doctrine/ORM/Tools/Pagination is the 2.2.2 tag.

no LimitSubqueryOutputWalker.php in there.

Comment by Benjamin Eberlei [ 29/Aug/12 ]

Fixed

Comment by Raymond Kolbe [ 09/Apr/13 ]

This issue is popping it's head up again!

Benjamin, your tests don't test for the ordering problem unless those tests are happening somewhere else?

https://github.com/doctrine/doctrine2/commit/f55b5411c8b1f75bf2b5cf5ffe4bc50034fb91cb

I am performing a query as complex as Marc's and I experience the same exact issue. I have checked out today's latest master branch as well as the 2.3 tag with no change.

Please advise.

Comment by Raymond Kolbe [ 09/Apr/13 ]

I have a PR in https://github.com/doctrine/doctrine2/pull/645





[DDC-2068] [GH-474] Fixed bug with comment option not being added to column. Created: 11/Oct/12  Updated: 17/Apr/14  Resolved: 12/Oct/12

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

Type: Bug 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 okovalov:

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

Message:

Title explains everything... =)



 Comments   
Comment by Benjamin Eberlei [ 12/Oct/12 ]

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

Comment by Doctrine Bot [ 29/Dec/13 ]

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





[DDC-2059] Property perceived as dumplicate in composite foreign key Created: 04/Oct/12  Updated: 17/Apr/14  Resolved: 05/Oct/12

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

Type: Bug Priority: Major
Reporter: Dimitris Bozelos Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

I have the following schema:

CREATE TABLE `user` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  PRIMARY KEY (`id`)
);

CREATE TABLE `project` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `user_id` int(10) unsigned NOT NULL,
  PRIMARY KEY (`id`),
);

CREATE TABLE `project_conversation` (
  `project_id` int(10) unsigned NOT NULL,
  `user_id` int(10) unsigned NOT NULL,
  PRIMARY KEY (`project_id`,`user_id`)
)

I have ommitted the foreign key definitions for better readability. When I execute doctrine:mapping:convert (in Symfony2, but it seems it's a Doctrine2 issue), I get the following error:

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

I have tracked down the issue to be caused by the existence of `user_id` in the project table. So basically, because `project_conversation` references `project` which in turn references `user`, `project_conversation` reference to `user` is perceived as duplicate.

I don't think that this should be the expected behavior though. user_id in `project` references the creator of the project while user_id in `project_conversation` references the creator of the conversation and thus I think the schema is valid.



 Comments   
Comment by Benjamin Eberlei [ 05/Oct/12 ]

Will be fixed in 2.2.4 and 2.3.1





[DDC-2050] [GH-459] Fix DDC-2012 Created: 30/Sep/12  Updated: 17/Apr/14  Resolved: 03/Oct/12

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

Type: Bug 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 FabioBatSilva:

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

Message:

http://www.doctrine-project.org/jira/browse/DDC-2012



 Comments   
Comment by Benjamin Eberlei [ 03/Oct/12 ]

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

Comment by Doctrine Bot [ 22/Dec/13 ]

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





[DDC-2012] Inserting a new entity with a custom mapping type does not call convertToDatabaseValueSQL() when using InheritanceType("JOINED") Created: 04/Sep/12  Updated: 17/Apr/14  Resolved: 03/Oct/12

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

Type: Bug Priority: Critical
Reporter: Kaspars Sproģis Assignee: Fabio B. Silva
Resolution: Fixed Votes: 0
Labels: None
Environment:

PHP


Attachments: Text File DDC2012Test.php     File DDC2012Test.php    

 Description   

When using class type inheritance - @InheritanceType("JOINED") and inserting new entity with a custom mapping type, custom type method convertToDatabaseValueSQL() is never called.

Here is sample class mapping:

Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
 
/**
 * @Table(name="item")
 * @Entity
 * @InheritanceType("JOINED")
 * @DiscriminatorColumn(name="type_id", type="smallint")
 * @DiscriminatorMap({1 = "ItemPerson"})
 */
class Item {

	/**
	 * @Column(name="tsv", type="tsvector", nullable=true)
	 */
	protected $tsv;
}

/**
 * @Table(name="item_person")
 * @Entity
 */
class ItemPerson extends Item
{
}

I am using the same custom TsvectorType with simple entities and even Mapped Superclasses and it works perfectly, however on InheritanceType("JOINED") method convertToDatabaseValueSQL() is never called :/
Hope someone knows how to fix this.
Thank you.



 Comments   
Comment by Fabio B. Silva [ 24/Sep/12 ]

Hi Kaspars,

I can't reproduce,
Could you change the added testcase and try to make it fails ?

Thanks

Comment by Kaspars Sproģis [ 26/Sep/12 ]

@Fabio thanks for looking into my problem
I attached test where you can detect the problem.

It was quite strange, all i did was changed column that uses custom type to array and some minimal convertToDatabaseValue and convertToDatabaseValueSQL logic and convertToDatabaseValueSQL was never called.

One more thing i noticed, this bug only appears on persist and not on merge.

Thanks

Comment by Fabio B. Silva [ 29/Sep/12 ]

Thanks Kaspars

But sorry, I dont get your use case.

Notice that convertToDatabaseValueSQL is called just when using queries to find a object by a especific columns which is your mapping type.

http://docs.doctrine-project.org/en/2.1/cookbook/advanced-field-value-conversion-using-custom-mapping-types.html#the-mapping-type

Comment by Kaspars Sproģis [ 29/Sep/12 ]

I am using PostgreSQL tsvector data type for full text search.

Here is my tsvector custom data type class:
https://gist.github.com/3129096

The only way to update this field in postgresql is to use postgresql function to_tsvector('some text').
And everything works fine, if i persist simple entity, this method transforms insert query as needed:

public function convertToDatabaseValueSQL($sqlExpr, AbstractPlatform $platform)
{
	return sprintf('to_tsvector(%s)', $sqlExpr);
}

But when i use inheritance, then by some reason convertToDatabaseValueSQL method is not called and tsv field is updated with simple text as returned by convertToDatabaseValue() method.
I modified the Ticket Test so that you can see exact moment of when it is not called, which is exactly my problem.

Here is the result after persisting (for persist it failed)

$person = new ItemPerson();
$person->setName('some words for test');
$em->persist($person);
$em->flush();

DB Result:
Name                | Tsv
--------------------|------------------------------------
some words for test | 'for' 'some' 'test' 'words'

Here is the result after second time update (now by tsv format you can see it worked):

$person->setName('some more words for test');
$em->flush();

DB Result:
Name                | Tsv
--------------------|------------------------------------
some words for test | 'test':5 'word':3
Comment by Fabio B. Silva [ 30/Sep/12 ]

Thanks Kaspars

Now i saw the problem

Writing a patch ...

Comment by Kaspars Sproģis [ 03/Oct/12 ]

Just tested fixed version and everything works perfectly now.
Thank you!

Comment by Fabio B. Silva [ 03/Oct/12 ]

Fixed by : https://github.com/doctrine/doctrine2/commit/91caff1d8965c20b72d5fdd04ffadf3ab063c1ba





[DDC-1977] Undefined index in ParameterTypeInferer Created: 10/Aug/12  Updated: 17/Apr/14  Resolved: 25/Aug/12

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.2.3
Fix Version/s: 2.3, 2.3.1
Security Level: All

Type: Bug Priority: Minor
Reporter: Matt Button Assignee: Fabio B. Silva
Resolution: Fixed Votes: 0
Labels: None
Environment:

PHP 5.3.6-13ubuntu3.8 with Suhosin-Patch (cli) (built: Jun 13 2012 17:19:54)

{ "package": "doctrine/common", "version": "2.2.2" }

,

{ "package": "doctrine/dbal", "version": "2.2.x-dev", "source-reference": "b961a3fce6bf220f1dca47d7d747b9074bea4730", "commit-date": "1341779435" }

,

{ "package": "doctrine/doctrine-bundle", "version": "dev-master", "source-reference": "62134e6a8dd3f330131ee6a970f0cee1d7760c1d", "commit-date": "1343203511" }

,

{ "package": "doctrine/orm", "version": "2.2.x-dev", "source-reference": "5d2a3bcb3b467f41ee58575764f3ba84937f76e4", "commit-date": "1341676080" }

,



 Description   

Trying to bind an empty array as a parameter to a raw SQL query results in an undefined index error on line 59.

https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Query/ParameterTypeInferer.php#L59



 Comments   
Comment by Matt Button [ 10/Aug/12 ]

One way to work around this is to specify the type of the array as the third parameter to addParameter

Comment by Fabio B. Silva [ 25/Aug/12 ]

Fixed by : https://github.com/doctrine/doctrine2/commit/ece6a005bcecc4a9e4a154d9379cfbe141370415





[DDC-2827] [GH-864] Updated parser to support aggegrate functions in null comparisons Created: 29/Nov/13  Updated: 17/Apr/14  Resolved: 17/Apr/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: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

Parser didn't support syntax like "SELECT i FROM entity i JOIN i.second s GROUP BY i HAVING max(s.something) IS NULL" which should be perfectly valid. Changed isAggregateFunction to support parameterless call which makes it consistent with isFunction.



 Comments   
Comment by Guilherme Blanco [ 17/Apr/14 ]

As of https://github.com/doctrine/doctrine2/commit/841bdd5ca52d2849b8091c56f99e201d169e1639 this issue is fixed

Comment by Doctrine Bot [ 17/Apr/14 ]

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





[DDC-3009] [GH-968] Test: Add failing test Created: 04/Mar/14  Updated: 17/Apr/14  Resolved: 17/Apr/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: Guilherme Blanco
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

It says in http://www.doctrine-project.org/jira/browse/DBAL-446 that this issue has been fixed, but apparently, it hasn't.



 Comments   
Comment by Doctrine Bot [ 17/Apr/14 ]

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

Comment by Guilherme Blanco [ 17/Apr/14 ]

This issue is DBAL related, not ORM.





[DDC-2934] [GH-918] Fix use of function in OrderBy Created: 24/Jan/14  Updated: 17/Apr/14  Resolved: 17/Apr/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: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

This commit adds support for functions (like CONCAT()) in OrderBy.



 Comments   
Comment by Doctrine Bot [ 17/Apr/14 ]

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

Comment by Guilherme Blanco [ 17/Apr/14 ]

As of https://github.com/doctrine/doctrine2/commit/ceada41b83c9b71d4831d9e50d4c43a75b1ee531 this issue is fixed





[DDC-3076] [GH-1006] Handling invalid discriminator values Created: 09/Apr/14  Updated: 16/Apr/14  Resolved: 15/Apr/14

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

Type: Improvement 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 Trainmaster:

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

Message:

Two scenarios:

  • *The DiscriminatorMap is specified via metadata*. In case the entity's discriminator value is not matching with a value of the DiscriminatorMap it will result in a ``Notice: Undefined index ... on line 102`` and ``exception 'Doctrine\Common\Persistence\Mapping\MappingException' with message 'Class '' does not exist' in``. The proposed changes deal with this.
  • *The DiscriminatorMap is automatically generated*. The discriminator value may no longer be invalid if there's just metadata missing for the automatically generated class names. I'm not sure how to deal with that properly.


 Comments   
Comment by Doctrine Bot [ 15/Apr/14 ]

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

Comment by Marco Pivetta [ 15/Apr/14 ]

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





[DDC-2984] Support Custom DBAL types to be used as identifiers Created: 15/Feb/14  Updated: 16/Apr/14  Resolved: 16/Apr/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4, 2.4.1
Fix Version/s: 2.5, 2.4.3
Security Level: All

Type: Improvement Priority: Minor
Reporter: Alexander Miertsch Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

I've tried to use a Value Object that extends the DBAL\Types\StringType as identifier of an Aggregate Root. This is common practice in DDD, f.e. defining a TrackingId as identifier of a Cargo Aggregate. I've written a unit test for my repository and everything seemed to work well until clearing the UnitOfWork and trying to fetch a fresh entity. The error is similar to the one described in DDC-2176. The issue is closed and I don't understand why?

I think the support of Value Objects is a must have in Doctrine. I've checked out the new feature of defining embedded Value Objects and it works as a charm. But without the option to use Value Objects as identifiers Doctrine is missing an important feature!



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

DDC-2176 duplicates DDC-1998

Some clarifications:

  • custom types work as identifiers with the ORM as long as object types implement a __toString method that emulates the unique identifier
  • value objects as identifiers are not yet supported and will likely not be supported for another while because of technical limitations

What you can do to help out is writing a test case showing how you would want to use VOs on associations and identifiers.

Comment by Alexander Miertsch [ 16/Feb/14 ]

thank you for your reply. I have to check with my client if I can spend time to provide a test case. For now, we use the workaround that Yves Berkholz mentioned in his issue DDC-2176 to work with a string represantation of the VO inside the Entity.

The problem is, that the UnitOfWork uses the $idHash as key in the identityMap. If you use a Custom DBAL type as Identifier, the $idHash will be an Object and PHPUnit fails with the error: PHPUnit_Framework_Error_Warning : Illegal offset type in Doctrine\ORM\UnitOfWork.php(2578): ...
Even if the custom type implements a __toString() method.
The error/warning occurs in the same line as of the provided code block of Yves Berkholz:

$this->identityMap[$class->rootEntityName][$idHash] = $entity; // <- 2466 -> now it is line 2578

Comment by Alexander Miertsch [ 24/Feb/14 ]

I send a pull request that reproduces the bug in a TestCase, but DoctrineBot has opened a new issue: DDC-2998.

Comment by Guilherme Blanco [ 16/Apr/14 ]

As of https://github.com/doctrine/doctrine2/commit/5ce6dabe9bb9e81eac6fd261db9bd29f7b7f290c this issue was fixed.





[DDC-2998] [GH-961] [DDC-2984] Provide TestCase to reproduce bug Created: 24/Feb/14  Updated: 16/Apr/14  Resolved: 16/Apr/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.5, 2.4.3
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 codeliner:

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

Message:



 Comments   
Comment by Guilherme Blanco [ 16/Apr/14 ]

As of https://github.com/doctrine/doctrine2/commit/5ce6dabe9bb9e81eac6fd261db9bd29f7b7f290c this issue was fixed.

Comment by Doctrine Bot [ 16/Apr/14 ]

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





[DDC-1925] Bug in UnitOfWork and ManyToMany relations Created: 14/Jul/12  Updated: 16/Apr/14  Resolved: 29/Jul/12

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

Type: Bug Priority: Major
Reporter: Andrew Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None
Environment:

symfony2



 Description   

Lets say, I have entity Forum with ManyToMany relations with User.
I need to validate user changes and I use code like

$uow = $this->getDoctrine()>getEntityManager()>getUnitOfWork();
$uow->computeChangeSets();
$changeSet = $uow->getEntityChangeSet($forum);
if (.... bla-bla-bla....)

{ $em = $this->getDoctrine()->getEntityManager(); $em->persist($forum); $em->flush(); }

Unfortunately, whenever I try to change manyToMany relations - I got error
SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '4-4' for key 'PRIMARY'

If I comment uow code - everything works just great.

It looks like bug in UnitOfWork implementation.

Let me know if you need more details from me.



 Comments   
Comment by Marco Pivetta [ 16/Jul/12 ]

What is the part you commented out? Also, in what context is your code executed?

Comment by Andrew [ 16/Jul/12 ]

I got error when $em->persist($forum); $em->flush(); executed.

I can create github repository with code, which reproduce this error, if you want.

Comment by Marco Pivetta [ 16/Jul/12 ]

Please do

Comment by Andrew [ 16/Jul/12 ]

that would be simple symfony2 application - will it work for you?

Comment by Marco Pivetta [ 16/Jul/12 ]

As long as the code is related to doctrine. Otherwise this issue is quite incomplete

Comment by Andrew [ 16/Jul/12 ]

Done, please check https://github.com/zhil/testDoctrine

In few words, when I add code like
$uow = $this->getDoctrine()>getEntityManager()>getUnitOfWork();
$uow->computeChangeSets();
$changeSet = $uow->getEntityChangeSet($product);

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

I got fake MYSQL error

Thank in advance for your help

Comment by Andrew [ 19/Jul/12 ]

Just wonder - is it bug in doctrine2 or its problems somewhere else? (symfony2/my code/ etc.)

This is part of the live project - I need to fix it

Comment by Marco Pivetta [ 19/Jul/12 ]

I think it is related with the fact that you're using the `UnitOfWork` manually. You can probably try to fix the problem by moving your code to an event subscriber until this is fixed.

Comment by Andrew [ 19/Jul/12 ]

Well, I used UnitOfWork, because I need to know what was changed during object validation (for example, property status can be changed only in predefined cases etc.).

Ok, thanks for the suggestion - I will implement some temporary solution for this problem

Comment by Marco Pivetta [ 19/Jul/12 ]

I think I spotted where this happens, but I don't have a clear overview on the situation. Will try to work on this...

Comment by Andrew [ 19/Jul/12 ]

Thanks for the checking this issue.
I have already patched my application with ugly patch. Just in case solution will take some time and somebody else will need similar patch. I patched entity like

entity {
public $previousStatusBugfix = -1;
public function setStatus($status)

{ // check http://www.doctrine-project.org/jira/browse/DDC-1925?focusedCommentId=18344#comment-18344 // Ticket #651 $this->previousStatusBugfix = $this->status; $this->status = $status; }

}

and validator

if(($object->previousStatusBugfix != 1) && ($object>previousStatusBugfix != $object->getStatus()))

{ $changeSet = array("status"=>array(0=>$object->previousStatusBugfix, 1=>$object->getStatus())); }

Comment by Marco Pivetta [ 19/Jul/12 ]

I just wrote a couple of tests (attaching them to the issue shortly) and found out that on `>=2.2.x` your code runs perfectly.
The problem is on the `2.1.x` branch, and the commit that fixed the issue is https://github.com/doctrine/doctrine2/commit/4474d30 for DDC-1210

Now looking if it can be merged into `2.1.x` since it doesn't seem to cause any BC break.

Comment by Benjamin Eberlei [ 19/Jul/12 ]

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

Comment by Benjamin Eberlei [ 19/Jul/12 ]

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

Comment by Marco Pivetta [ 19/Jul/12 ]

Duplicate of DDC-1210

Comment by Benjamin Eberlei [ 23/Jul/12 ]

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

Comment by Benjamin Eberlei [ 29/Jul/12 ]

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

Comment by Doctrine Bot [ 12/Nov/13 ]

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

Comment by Doctrine Bot [ 13/Nov/13 ]

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





[DDC-2249] Default value sequence Created: 19/Jan/13  Updated: 16/Apr/14  Resolved: 16/Apr/14

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

Type: Task Priority: Major
Reporter: Maria Assignee: Guilherme Blanco
Resolution: Can't Fix Votes: 1
Labels: None
Environment:

Symfony 2, linux



 Description   

I want to have a column on a table that by default it takes the value from a sequence.

I've tried to do something like this:
/**

  • @ORM\Column(type="integer", unique="true")
  • @ORM\GeneratedValue(strategy="SEQUENCE")
  • @ORM\SequenceGenerator(sequenceName="seq_categorias", initialValue=1, allocationSize=100)
    */
    protected $id_categoria;

But this doesn't work, it creates de sequence but not the link between the table column and the sequence. Is there any possibility to do something like this? Or any autoincrement default value instead?

Thanks!



 Comments   
Comment by Guilherme Blanco [ 16/Apr/14 ]

We cannot fix this as sequences only work internally in Doctrine for ID fields.





[DDC-536] Remove the _ prefix from private and protected members Created: 23/Apr/10  Updated: 16/Apr/14

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

Type: Improvement Priority: Major
Reporter: Roman S. Borschel Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 1
Labels: None


 Description   

The reasoning is simple: The prefix "_" is usually either used for easier distinction of instance variables from other, i.e. local variables, instead of always using "this." (often seen in C#), or it is used to signal that a member is not meant to be accessed from outside of the class when the language does not have visibility modifiers (PHP4).

Since you always have to use "$this->" in PHP5+ when accessing instance members and there are visibility modifiers, the "_" is largely superfluous and just makes the verbose OO code even more verbose.

Maybe the following find/replace steps will do the job almost completely:

"private $_" => "private $"
"protected $_" => "protected $"
"$this->_" => "$this->"


 Comments   
Comment by Benjamin Eberlei [ 27/Apr/10 ]

i just found a possible BC issue with this.

EntityRepository is allowed to be extended by us, it has several variables that are underscore prefixed. How to proceed in this case?

Comment by Roman S. Borschel [ 27/Apr/10 ]

I know but its not really a problem I think. We should just decide whether we make them private in the first place and provide getters instead (which would have avoided this problem in the first place).

Comment by Roman S. Borschel [ 27/Apr/10 ]

Leaving the prefixes on the repository class only is also an option... but I dont think thats necessary.

Comment by Benjamin Eberlei [ 27/Apr/10 ]

can we commit getters for Beta 1 then? We could give everyone a period until Beta 2 to fix their code and then make the change.

EntityRepository is the only class that is meant to be userland extendable to my knowledge, so this should be the only problem to adress

Comment by Roman S. Borschel [ 27/Apr/10 ]

Yes, you can add getters and commit right away if you want. Plus adding a note on the upgrade document that direct access of these properties is deprecated.

Comment by Roman S. Borschel [ 27/Apr/10 ]

Persisters will be also extensible some day in userland but they need more polish for that, I've already started with it

Comment by Johnny Peck [ 19/Nov/10 ]

Is this still planned? Searching the code base finds this is not being implemented. It would be a good idea to implement the change sooner than later if it will be done at all. Also, +1 for the change. It makes complete sense.

Comment by Guilherme Blanco [ 16/Apr/14 ]

Moving to 3.0 as this can potentially create BC breaks





[DDC-1038] there are tabs in the code base Created: 16/Feb/11  Updated: 16/Apr/14  Resolved: 16/Apr/14

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

Type: Task Priority: Major
Reporter: Lukas Kahwe Assignee: Guilherme Blanco
Resolution: Invalid Votes: 0
Labels: None


 Description   

a quick search through the ORM code base finds quite a few tabs. other doctrine projects there might also be some, though in common i only found some inside the LGPL license file.



 Comments   
Comment by Guilherme Blanco [ 16/Apr/14 ]

Invaliding the issue since it's already over 3 years.
If issue still persists, reopen it with more information.





[DDC-2736] Error generating annotations of index in Entities Created: 11/Oct/13  Updated: 16/Apr/14  Resolved: 16/Apr/14

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

Type: Bug Priority: Minor
Reporter: Cesar Gutierrez Tineo Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None
Environment:

Ubuntu 12.04, PHP 5.3.10


Attachments: File bootstrap.php     File Opportunities.php    

 Description   

<?php
//
/**

@ORM\Entity
@ORM\Table(name="opportunities",indexes={@ORM\index(name="idx_opp_name", columns=

{"name"}

),@ORM\index(name="idx_opp_assigned", columns=

{"assigned_user_id"}

)}) **/ //

@ORM\index instead of @ORM\Index

//
?>

throw this error

[Doctrine\Common\Annotations\AnnotationException]

[Semantical Error] The annotation "@Doctrine\ORM\Mapping\index" in class CRM\Entity\Opportunities does not exist, or could not be auto-loaded.



 Comments   
Comment by Marco Pivetta [ 17/Oct/13 ]

Can you provide the entire generated file as an attachment?

Comment by Cesar Gutierrez Tineo [ 17/Oct/13 ]

Generated class.

Comment by Cesar Gutierrez Tineo [ 17/Oct/13 ]

Hi, Marco. Do I have to provide more files?

Comment by Marco Pivetta [ 17/Oct/13 ]

Cesar Gutierrez Tineo looks like the annotations for `Index` are lowercase (`index`) - what command did you issue to generate them?

Comment by Cesar Gutierrez Tineo [ 17/Oct/13 ]

i configured my bootstrap, and used " orm:generate-entities " in php bin/doctrine

Comment by Marco Pivetta [ 17/Oct/13 ]

Can you try using 2.4 for this? It looks OK in the EntityGenerator...

Comment by Cesar Gutierrez Tineo [ 17/Oct/13 ]

Ok, I'll try. I use 2.2.1.

Comment by Guilherme Blanco [ 16/Apr/14 ]

Assuming issue got resolved by 2.4 upgrade.
Got no feedback from user.





[DDC-1963] Remove by-ref access to changeset in lifecycle event args Created: 31/Jul/12  Updated: 16/Apr/14

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

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


 Description   

UoW currently passes computed changesets to lifecycle event args byref. This has to be changed to force users to use UoW public API to modify changesets instead.






[DDC-1852] Doctrine\ORM\Tools\SchemaValidator should check validity of lifecycle callbacks Created: 04/Jun/12  Updated: 16/Apr/14

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

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


 Description   

The schema validator should analyze mapped lifecycle callbacks and:

a) if some lifecycle callbacks were defined, but no @HasLifecycleCallbacks annotation/mapping was set, warn the user
b) if some lifecycle callbacks were defined, but methods are not public, warn the user



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

Existing PR at https://github.com/doctrine/doctrine2/pull/361





[DDC-2061] Matching Criteria on a PersistentCollection only works on OneToMany associations Created: 08/Oct/12  Updated: 16/Apr/14  Resolved: 16/Apr/14

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

Type: Improvement Priority: Major
Reporter: Terje Bråten Assignee: Guilherme Blanco
Resolution: Fixed Votes: 4
Labels: criteria, matching


 Description   

What is needed to make it also work for ManyToMany associations?

May be a better fallback would be do an ArrayCollection->matching() instead of just giving a runtime exception?

Is this something that is difficult to implement?



 Comments   
Comment by Guilherme Blanco [ 16/Apr/14 ]

This is already possible on 2.5 branch (dev-master for now).
Tracked commit history and found this commit hash as the one that allowed this:

https://github.com/doctrine/doctrine2/commit/160b07d1e3107b9a8210fc73d456305b03146c39





[DDC-3088] EntityManager::clear doesn't working with inserting Created: 16/Apr/14  Updated: 16/Apr/14

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

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

PHP 5.4.25-1+sury.org~precise+2 (cli) (built: Feb 12 2014 10:45:30)
Symfony version 2.4.2 - app/dev/debug



 Description   

It looks like EntityManager's clear() method doesn't remove objects that was persisted during script execution.

Bellows are two functions. First one insert 10.000 records and use clear after each flush that should remove objects from memory, but instead of that memory usage growths in each iteration. There isn't any other reference for this objects.

I've checked how it works for reading and with clearing it works perfectly - script uses only constant memory.

 
    private function testInserting($em, $entityClass, $batchSize, $startMemoryUsage)
    {
        for ($i = 1; $i <= 10000; ++$i) {

            $item = new $entityClass();
            $item->setName($i);
            $item->setPresentation($i);
            $em->persist($item);

            if ($i % $batchSize == 0) {
                $em->flush();
                $em->clear();

                $currentMemoryUsage = memory_get_usage();
                printf("%d:\n\t%.2f MB (%.2f MB)\n", $i, $currentMemoryUsage /1024 / 1024, ($currentMemoryUsage - $startMemoryUsage) / 1024 / 1024);
            }
        }
    }
    
    
private function testReading($em, $entityClass, $batchSize, $startMemoryUsage)
    {
        $q = $em->createQuery("select i from $entityClass i");
        $iterableResult = $q->iterate();

        $i = 0;
        while (($row = $iterableResult->next()) !== false) {
            $em->clear();
            if ($i % $batchSize == 0) {
                $currentMemoryUsage = memory_get_usage();
                printf("%d:\n\t%.2f MB (%.2f MB)\n", $i, $currentMemoryUsage /1024 / 1024, ($currentMemoryUsage - $startMemoryUsage) / 1024 / 1024);
            }

            $i++;
        }
    }
    

My results:

1) Reading without clearing ($em->clear(); removed)

0:
22.89 MB (2.63 MB)
1000:
33.41 MB (13.15 MB)
2000:
44.04 MB (23.78 MB)
3000:
53.50 MB (33.24 MB)
4000:
65.13 MB (44.86 MB)
5000:
74.81 MB (54.55 MB)
6000:
84.27 MB (64.01 MB)
7000:
97.96 MB (77.69 MB)
8000:
107.40 MB (87.14 MB)
9000:
117.17 MB (96.91 MB)
10000:
126.61 MB (106.35 MB)

2) Reading with using clear

0:
22.89 MB (2.63 MB)
1000:
26.25 MB (5.99 MB)
2000:
24.74 MB (4.48 MB)
3000:
26.72 MB (6.46 MB)
4000:
24.79 MB (4.52 MB)
5000:
26.76 MB (6.50 MB)
6000:
24.81 MB (4.55 MB)
7000:
26.77 MB (6.51 MB)
8000:
24.83 MB (4.57 MB)
9000:
26.81 MB (6.54 MB)
10000:
24.86 MB (4.60 MB)

3) Inserting without clearing

1000:
29.50 MB (9.24 MB)
2000:
37.76 MB (17.50 MB)
3000:
45.12 MB (24.86 MB)
4000:
54.34 MB (34.07 MB)
5000:
61.79 MB (41.53 MB)
6000:
69.09 MB (48.82 MB)
7000:
76.40 MB (56.13 MB)
8000:
83.75 MB (63.48 MB)
9000:
95.64 MB (75.37 MB)
10000:
102.98 MB (82.71 MB)

4) Inserting with using clear

1000:
27.90 MB (7.63 MB)
2000:
34.64 MB (14.37 MB)
3000:
40.43 MB (20.17 MB)
4000:
48.20 MB (27.93 MB)
5000:
54.12 MB (33.85 MB)
6000:
59.89 MB (39.63 MB)
7000:
65.67 MB (45.40 MB)
8000:
71.43 MB (51.16 MB)
9000:
81.51 MB (61.25 MB)
10000:
87.29 MB (67.02 MB)



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

Would be useful to see what the entity class looks like.

Additionally, the ORM version being affected is also needed.





[DDC-274] Class and namespace naming inconsistency Created: 24/Jan/10  Updated: 16/Apr/14

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

Type: Improvement Priority: Critical
Reporter: Glen Ainscow Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 1
Labels: None


 Description   

There are inconsistencies with some class and namespace names that include acronyms.

Examples:

Classes with upper-casing:
ORMException, DBALException, OCI8Connection, etc.

Classes with proper-casing:
RunDqlTask, CliException, MySqlPlatform, etc.

Namespaces with upper-casing:
DBAL, ORM, Doctrine\DBAL\Driver\PDOMsSql, etc.

Namespaces with proper-casing:
Doctrine\Common\Cli, Doctrine\DBAL\Tools\Cli\, Doctrine\ORM\Id, etc.

There is more proper-casing than upper-casing. IMHO, proper-casing is better as it's easier to read "SqlException" than it is to read "SQLException" (the "E" looks like part of the acronym), and things like "CLITask" can be avoided.

I discussed this a bit with Benjamin and Guilherme, and they were unsure and said that the whole team needed to reach consensus.

I'm leaving the priority as "Major" because this should probably be fixed sooner rather than later to prevent compatibility breaks.



 Comments   
Comment by Guilherme Blanco [ 25/Jan/10 ]

Increasing the severity and adding a fix version since this MUST be fixed before next release.

Comment by Roman S. Borschel [ 25/Jan/10 ]

I find this to be of rather minor importance. You're talking of compatibility breaks, but thats only the case if we intend to start being very nitpicky about the naming in the future. We are currently not, and we wont be, so not much risk of later breakage.

We have a rule of thumb already: Acronyms up to 4 characters all uppercase, otherwise normal camelcase.

Now, it is often a matter of taste what is an acronym and what not and also not all acronyms have a clear casing, prime example mysql.

Being too nit-picky here is just a pain in the ass and we won't reach a common consensus anyway.

Comment by Roman S. Borschel [ 25/Jan/10 ]

Oh and we better dont start arguing about whats better to read because there is no chance of agreement. If you ask me I find SQLException better than SqlException. So here we go. Lets better not run down this path.

Comment by Glen Ainscow [ 25/Jan/10 ]

No need to get upset, I'm only trying to help.

I just thought that consistency is usually a good idea, either way.

I have to disagree in that an acronym is an acronym, it's not a matter of taste, the letters either stand for something, or they don't.

As for "mysql", only the SQL part is an acronym. So, MySQL or MySql.

Close if you disagree.

Comment by Roman S. Borschel [ 25/Jan/10 ]

I'm not upset. What made you think so? Maybe I should introduce a every now and then.

There's just no point in arguing about readability.

Like I said, we do have a naming standard even if its not adhered everywhere. The standard is also not something we've made up ourselves because we try to avoid that. When we introduced namespaces, we talked about adopting either the Java or .NET naming standards. We opted for the .NET standards. And there its recommended to write acronyms with up to 4 characters all uppercase.

I dont think there are too many violations of that in the code, probably Cli => CLI and some others but most of it looks ok to me.

UPDATE: Maybe we can gather a list here in this ticket of violations? Cli => CLI would be one. MySql => MySQL another. "Id" is rather an abbreviation of Identifier and not an acronym, to me at least.

Comment by Guilherme Blanco [ 25/Jan/10 ]

It's not a case of getting anyone upset...

But we should fix it and keep consistency of our codebase.

@romanb We should all talk and reach a common sense.
That's our last chance (last alpha) to get this consistency in.

Comment by Roman S. Borschel [ 25/Jan/10 ]

@Guilherme: We do have a naming standard since a year. You want to change the standard now?

Comment by Glen Ainscow [ 25/Jan/10 ]

@Roman,

Just a feeling I got.

This issue was more about consistency (indicated in the title) than moving to proper-case naming.

I think it might be up to 3 characters in .NET, HtmlElement, System.Linq, etc. Anyway, not important.

I agree that Id. is an abbreviation.

There are some more violations. If you decide you want to change them, let me know and I'll compile a list.

Comment by Roman S. Borschel [ 25/Jan/10 ]

@Glen: Yes, a list would be great. I find it hard to be 100% consistent sometimes though because my taste conflicts with the rule. For example, I would prefer "Id" over "ID", especially since it comes directly after ORM "Doctrine\ORM\ID\..." would be a bit too much. But I would not like "Orm" or "Dbal" either. But I think in most cases we can clearly fix the inconsistency. Like CLI or MySQL or MSSQL (or should it be MsSQL?).

Thanks for your help!

We should probably create updated coding standards for Doctrine 2 also, since they differ quite some from Doctrine 1 due to the introduction of namespaces and such. I'll create a ticket for that.

Comment by Glen Ainscow [ 25/Jan/10 ]

I'll do the list for you by tomorrow at the latest, just running out of time ATM.

Id is correct, as mentioned above, so that would be fine. MsSQL is correct (Ms = Microsoft = abbreviation).

Comment by Glen Ainscow [ 25/Jan/10 ]

Found some time ...

Doctrine\Common\Cache\ApcCache -> APCCache
Doctrine\Common\Cli -> CLI
Doctrine\Common\Cli\Printers\AnsiColorPrinter -> ANSIColorPrinter
Doctrine\Common\Cli\CliController -> CLIController
Doctrine\Common\Cli\CliException -> CLIException

Doctrine\DBAL\Driver\PDOMsSql -> PDOMsSQL
Doctrine\DBAL\Driver\PDOMySql -> PDOMySQL
Doctrine\DBAL\Driver\PDOPgSql -> PDOPgSQL
Doctrine\DBAL\Driver\PDOSqlite -> PDOSQLite
Doctrine\DBAL\Logging\EchoSqlLogger -> EchoSQLLogger
Doctrine\DBAL\Logging\SqlLogger -> SQLLogger
Doctrine\DBAL\Platforms\MsSqlPlatform -> MsSQLPlatform
Doctrine\DBAL\Platforms\MySqlPlatform -> MySQLPlatform
Doctrine\DBAL\Platforms\PostgreSqlPlatform -> PostgreSQLPlatform
Doctrine\DBAL\Platforms\SqlitePlatform -> SQLitePlatform
Doctrine\DBAL\Schema\Visitor\CreateSchemaSqlCollector -> CreateSchemaSQLCollector
Doctrine\DBAL\Schema\Visitor\DropSchemaSqlCollector -> DropSchemaSQLCollector
Doctrine\DBAL\Schema\MsSqlSchemaManager -> MsSQLSchemaManager
Doctrine\DBAL\Schema\MySqlSchemaManager -> MySQLSchemaManager
Doctrine\DBAL\Schema\PostgreSqlSchemaManager -> PostgreSQLSchemaManager
Doctrine\DBAL\Schema\SqliteSchemaManager -> SQLiteSchemaManager
Doctrine\DBAL\Tools\Cli -> CLI
Doctrine\DBAL\Tools\Cli\Tasks\RunSqlTask -> RunSQLTask

Doctrine\ORM\Mapping\Driver\PhpDriver -> PHPDriver
Doctrine\ORM\Mapping\Driver\XmlDriver -> XMLDriver
Doctrine\ORM\Mapping\Driver\YamlDriver -> YAMLDriver
Doctrine\ORM\Query\Exec\AbstractSqlExecutor -> AbstractSQLExecutor
(Should Doctrine\ORM\Query\Expr\Andx and Orx be AndX and OrX?)
Doctrine\ORM\Query\SqlWalker -> SQLWalker
Doctrine\ORM\Tools\Cli -> CLI
Doctrine\ORM\Tools\Cli\Tasks\RunDqlTask -> RunDQLTask
Doctrine\ORM\Tools\Export\Driver\PhpExporter -> PHPExporter
Doctrine\ORM\Tools\Export\Driver\XmlExporter -> XMLExporter
Doctrine\ORM\Tools\Export\Driver\YamlExporter -> YAMLExporter

... I think that's it. More than you expected? I did say: "There is more proper-casing than upper-casing."

Comment by Roman S. Borschel [ 25/Jan/10 ]

No, not more than I expected. It's mostly SQL and CLI basically. Thanks for the list!

We should try to go through that list before beta.

Comment by Roman S. Borschel [ 05/Mar/10 ]

Methods should be adjusted accordingly also (even though they're case insensitive). I already started with that. More to come.

Comment by Roman S. Borschel [ 28/Mar/10 ]

Most of the Cli => CLI changes seem to be complete now.

Comment by Roman S. Borschel [ 26/Apr/10 ]

Pushing the rest of the name changes towards beta2.

Comment by Roman S. Borschel [ 19/May/10 ]

More renamings have been done but still more to do. Pushing remaining work to beta3.

Comment by Roman S. Borschel [ 30/Aug/10 ]

Final name changes should be done prior to going into RC1.

Comment by Benjamin Eberlei [ 31/Oct/10 ]

there is much to be done yet, however most of it is also public API class names and might cause quite some BC breaks (i.e. DBAL Platforms and Schema Manager, Mapping Driver Names). I am not sure how to proceed here.

Comment by Roman S. Borschel [ 31/Oct/10 ]

Since PHP is mostly case-insensitive on class and method names it shouldn't be much of an issue.

Comment by Guilherme Blanco [ 16/Apr/14 ]

Scheduled to 3.0 as this may potentially create BC breaks





[DDC-222] Create unit tests for CLI components Created: 22/Dec/09  Updated: 16/Apr/14  Resolved: 16/Apr/14

Status: Closed
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.0-ALPHA3
Fix Version/s: 2.x
Security Level: All

Type: Task Priority: Critical
Reporter: Roman S. Borschel Assignee: Guilherme Blanco
Resolution: Invalid Votes: 0
Labels: None

Issue Links:
Reference
is referenced by DDC-359 Specified, but empty CLI Options --op... Resolved

 Comments   
Comment by Roman S. Borschel [ 19/May/10 ]

Whats the status here? Do we have any?

Comment by Guilherme Blanco [ 19/May/10 ]

Since we moved to Symfony Console I don't think this is needed anymore.
The purpose of this ticket was actually to test our own CLI support, which was dropped.

I'm closing the ticket due to this. Reopen if you have any other comment.

Comment by Benjamin Eberlei [ 20/May/10 ]

I think we do need some basic functional tests of our Commands, they have been subject to many bugs in the past becaues they are not tested.

Comment by Benjamin Eberlei [ 19/Jun/10 ]

Fixed another fatal error in the command due to missing namespace dependency. We need tests for all the commands, there have been dozens of issues on these things so far.

This commit shows a simple approach on how testing is easily possible for symfony commands:

http://github.com/doctrine/doctrine2/commit/51e6681934a7cf4448b85c5670c04045f66c6056

Comment by Roman S. Borschel [ 26/Aug/10 ]

Can we expect some more tests for beta4 or is it unlikely that you find the time? Should we move this further back or does someone else want to step in?

Comment by Guilherme Blanco [ 16/Apr/14 ]

This is not valid anymore as we use Symfony CLI component





[DDC-2668] DQL TRIM function is not converted into TRIM SQL correctly Created: 10/Sep/13  Updated: 16/Apr/14  Resolved: 26/Sep/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: DQL
Affects Version/s: 2.3.1, 2.3.4
Fix Version/s: 2.5, 2.4.1
Security Level: All

Type: Bug Priority: Major
Reporter: Slavik Derevyanko Assignee: Fabio B. Silva
Resolution: Fixed Votes: 0
Labels: None


 Description   

Hi!

Using DQL to generate SQL TRIM code won't trim '0'.
For ex., this expression doesn't work:

$queryBuilder->andWhere("TRIM (LEADING '0' FROM t.field) LIKE :field")

This is happening as whenever TRIM DQL is converted into SQL, trimming character is checked for being 'false' multiple times. In php, both 0 and '0' are equaled to false.

doctrine/orm/lib/Doctrine/ORM/Query/AST/Functions/TrimFunction.php:61
doctrine/dbal/lib/Doctrine/DBAL/Platforms/AbstractPlatform.php:640






[DDC-1954] Specialized Batch Insert Mode for the Entity Manager Created: 29/Jul/12  Updated: 16/Apr/14

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

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


 Description   

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

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






[DDC-2937] [GH-920] SingleScalarHydrator reports ambiguous error. Created: 27/Jan/14  Updated: 16/Apr/14  Resolved: 16/Apr/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: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

In the previous situation there is a combined test (A or B) which result in the same error message. However the error message does not fit with condition B (see code).

Looking at the function description the function should return a _a single scalar value_.

On a side note:
1. it's weird that this method call is used gatherScalarRowData() as it seems to fetch an entire row.
2. there is no function to fetch a single row.



 Comments   
Comment by Flip [ 27/Jan/14 ]

Should have paid more attention when i submit the previous PR 4 months ago

Comment by Doctrine Bot [ 16/Apr/14 ]

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

Comment by Guilherme Blanco [ 16/Apr/14 ]

Done as of https://github.com/doctrine/doctrine2/commit/1488a509b24c918e2321ca736895e6418c17e7ad





[DDC-1149] Optimize OneToMany and ManyToMany without join Created: 12/May/11  Updated: 16/Apr/14  Resolved: 16/Apr/14

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

Type: New Feature Priority: Major
Reporter: Andrey Kolyshkin Assignee: Guilherme Blanco
Resolution: Fixed Votes: 15
Labels: None

Attachments: File testDoctrine.php    

 Description   
 
/**
 * @Entity
 * @Table(name="users")
 */
class User {

    /**
     * @Column
     * @Id
     */
    public $user_id;

    /**
     * @Column
     */
    public $email;

    /**
     * @OneToMany(targetEntity="Language", mappedBy="user",fetch="EAGER")
     */
    public $languages;

}

/**
 * @Entity
 * @Table(name="user_languages")
 */
class Language {

    /**
     * @Column
     * @Id
     */
    public $user_language_id;

    /**
     * @ManyToOne(targetEntity="User", inversedBy="languages")
     * @JoinColumn(name="user_id", referencedColumnName="user_id")
     */
    public $user;

    /**
     * @Column
     */
    public $user_id;
}
$users = $em->getRepository('User')->findAll();

Result:

SELECT t0.user_id AS user_id1, t0.email AS email2 FROM users t0
SELECT t0.user_language_id AS user_language_id1, t0.user_id AS user_id2, t0.user_id AS user_id3 FROM user_languages t0 WHERE t0.user_id = ?
array(1) {
  [0]=>
  string(1) "1"
}
array(1) {
  [0]=>
  NULL
}
SELECT t0.user_language_id AS user_language_id1, t0.user_id AS user_id2, t0.user_id AS user_id3 FROM user_languages t0 WHERE t0.user_id = ?
array(1) {
  [0]=>
  string(1) "2"
}
array(1) {
  [0]=>
  NULL
}
SELECT t0.user_language_id AS user_language_id1, t0.user_id AS user_id2, t0.user_id AS user_id3 FROM user_languages t0 WHERE t0.user_id = ?
array(1) {
  [0]=>
  string(1) "3"
}
array(1) {
  [0]=>
  NULL
}

...

Need result:

SELECT t0.user_id AS user_id1, t0.email AS email2 FROM users t0
SELECT u0_.user_language_id AS user_language_id0, u0_.user_id AS user_id1, u0_.user_id AS user_id2 FROM user_languages u0_ WHERE u0_.user_id IN (1, 2, 3)


 Comments   
Comment by Benjamin Eberlei [ 12/May/11 ]

Sure you are on git master? this should be optimized already with fetch=EAGER

Comment by Andrey Kolyshkin [ 12/May/11 ]

Attach test file

I run

git clone git://github.com/doctrine/doctrine2.git
git clone git://github.com/doctrine/common.git
git clone git://github.com/doctrine/dbal.git

and run testDoctrine.php

Result


SELECT t0.user_id AS user_id1 FROM users t0

SELECT t0.post_id AS post_id1, t0.user_id AS user_id2 FROM posts t0 WHERE t0.user_id = ?

array(1) {
  [0]=>
  string(1) "1"
}
array(1) {
  [0]=>
  NULL
}
SELECT t0.post_id AS post_id1, t0.user_id AS user_id2 FROM posts t0 WHERE t0.user_id = ?

array(1) {
  [0]=>
  string(1) "2"
}
array(1) {
  [0]=>
  NULL
}
SELECT t0.post_id AS post_id1, t0.user_id AS user_id2 FROM posts t0 WHERE t0.user_id = ?

array(1) {
  [0]=>
  string(1) "3"
}
array(1) {
  [0]=>
  NULL
}
Comment by Guilherme Blanco [ 10/Oct/11 ]

Please instead of using fetch="EAGER", please use fetch="EXTRA_LAZY". It would fix your issue.
I have successfully tested this situation in 2.2-DEV and it works like a charm. =)

Comment by Vladimir [ 25/Mar/13 ]

Doctrine ORM 2.3.3 (Symfony2.2) - using LAZY or EXTRA_LAZY fetch mode there are only one query for:

$users = $em->getRepository('User')->findAll();

but additional users_count queries for

foreach($users as $user) $user->languages->toArray()

And if use fetch EAGER - for some reason there are 2 x users_count queries , ie each query

SELECT t0.post_id AS post_id1, t0.user_id AS user_id2 FROM posts t0 WHERE t0.user_id = ?

with unique user_id executed twice

Comment by Konstantin [ 04/Aug/13 ]

Please fix this issue

Comment by Madhav Krishna [ 14/Nov/13 ]

Is this likely to be resolved soon? Or is there a good workaround that we could implement?

Comment by CoL [ 28/Nov/13 ]

Any news on this issue?

Comment by Flip [ 17/Jan/14 ]

sounds very useful !

Comment by Guilherme Blanco [ 16/Apr/14 ]

As of https://github.com/doctrine/doctrine2/commit/b28fa9a05a868d42c9b161cda3c73a8c5822acb4 this issue is fixed





[DDC-2907] [GH-907] [DDC-1632] OneToMany Fetch eager Created: 11/Jan/14  Updated: 16/Apr/14  Resolved: 16/Apr/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: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

version for 2.3:
https://github.com/doctrine/doctrine2/pull/905



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

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

Comment by Doctrine Bot [ 16/Apr/14 ]

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

Comment by Guilherme Blanco [ 16/Apr/14 ]

As of https://github.com/doctrine/doctrine2/commit/b28fa9a05a868d42c9b161cda3c73a8c5822acb4 this issue is fixed.





[DDC-2902] [GH-905] [DDC-1632] OneToMany Fetch eager Created: 10/Jan/14  Updated: 16/Apr/14  Resolved: 23/Mar/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: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

Hi. Fetch eager would be helpfull for me and this seems it works (coundn't run tests for some reason...)



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

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

Comment by Doctrine Bot [ 16/Apr/14 ]

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





[DDC-3049] [GH-988] Exporter support for association fetch modes Created: 26/Mar/14  Updated: 16/Apr/14  Resolved: 16/Apr/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: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

As reported here: http://www.doctrine-project.org/jira/browse/DDC-3047

Also noticed the fetch modes were not supported for PHP and YAML exporters.



 Comments   
Comment by Doctrine Bot [ 16/Apr/14 ]

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

Comment by Guilherme Blanco [ 16/Apr/14 ]

Merged as of https://github.com/doctrine/doctrine2/commit/4029dc2ea807b1d2ac170b02f36838eb02464004





[DDC-3047] XML Exporter driver does not export association fetch-mode Created: 25/Mar/14  Updated: 16/Apr/14  Resolved: 16/Apr/14

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

Type: Bug Priority: Minor
Reporter: Menno Holtkamp Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

While exporting (annotations based) metadata to XML, the 'fetch-mode' of the associations seems to be skipped by the XML Exporter
https://github.com/doctrine/doctrine2/blob/927d69b61a520e939c2f2e4105329907850e61fa/lib/Doctrine/ORM/Tools/Export/Driver/XmlExporter.php#L234

This should result in an XML attribute named 'fetch' of type 'fetch-type': https://github.com/doctrine/doctrine2/blob/927d69b61a520e939c2f2e4105329907850e61fa/doctrine-mapping.xsd#L277

Will try to come up with a PR + test



 Comments   
Comment by Menno Holtkamp [ 26/Mar/14 ]

Auto-created issue with PR: http://www.doctrine-project.org/jira/browse/DDC-3049

Comment by Guilherme Blanco [ 16/Apr/14 ]

Merged as of https://github.com/doctrine/doctrine2/commit/4029dc2ea807b1d2ac170b02f36838eb02464004





[DDC-3060] [GH-995] Allow cascaded clearing of associated Entities Created: 30/Mar/14  Updated: 16/Apr/14  Resolved: 16/Apr/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: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 16/Apr/14 ]

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

Comment by Guilherme Blanco [ 16/Apr/14 ]

As of https://github.com/doctrine/doctrine2/commit/1cd0b26a40dc22b0d11b1860eb058ab9cdc29f36 this issue is fixed.





EntityManager::clear($entity) support (DDC-1278)

[DDC-2850] Allow cascaded clearing of Entities associated to the indicated Entity Created: 11/Dec/13  Updated: 16/Apr/14

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

Type: Sub-task Priority: Minor
Reporter: Menno Holtkamp Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

As described here, it would be nice to have associated Entities be cleared in case required and configured in such way. It seems the functionality is available already, but always disabled (noCascade => TRUE).
A secondary optional boolean parameter to the function would do:

https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/UnitOfWork.php#L2342

 
public function clean($entityName = null, $noCascade = true)

https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/UnitOfWork.php#L2369

$this->doDetach($entity, $visited, $noCascade);


 Comments   
Comment by Menno Holtkamp [ 30/Mar/14 ]

PR: https://github.com/doctrine/doctrine2/pull/995
Auto-created issue: http://www.doctrine-project.org/jira/browse/DDC-3060

Comment by Doctrine Bot [ 16/Apr/14 ]

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





[DDC-1197] Proxies should handle variable argument lists Created: 05/Jun/11  Updated: 15/Apr/14  Resolved: 15/Apr/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: Can't Fix Votes: 0
Labels: None


 Description   

This is a contingency issue for https://github.com/doctrine/doctrine2/pull/60

"Fix to allow for proxy generated classes to respect methods in parent which may use func_get_args internally. Previously they would be passed nothing and thus fail. Also reduces need to build up argumentString. "



 Comments   
Comment by Chris Richard [ 15/Apr/14 ]

Could we use an annotation to indicate when a function uses variable arguments and output call_user_func_array only in that case?

Comment by Marco Pivetta [ 15/Apr/14 ]

I won't fix this. There are some problems here that are not trivial:

1 - to make proxies always "safe", we would need to use func_get_args in every proxy call
2 - because of (1), performance will GREATLY degrade
3 - because of (1), byref parameter passing will be broken

What we could do is introspecting the contents of methods to look for func_get_args usages (requires introduction of a complex parser).

I am closing this - consider opening an issue at https://github.com/Ocramius/ProxyManager/issues instead, so we can analyze if this logic can be improved for 3.x with the replacement of the "simple" doctrine proxies with something more complete.

Also note that https://github.com/Ocramius/ProxyManager/issues/159 could also solve this without the need for complex logic.





[DDC-3087] Entity code generation skip setters Created: 15/Apr/14  Updated: 15/Apr/14

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

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


 Description   

When executing `orm:generate-entities` to generated methods, do not generate setters when entity is readOnly `@ORM\Entity(readOnly=true)`






[DDC-3086] [GH-1011] Single quotes can't nest Created: 15/Apr/14  Updated: 15/Apr/14  Resolved: 15/Apr/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: 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 md2perpe:

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

Message:

I decided to use "... '...' ...", but perhaps you prefer '... \'...\' ...'?



 Comments   
Comment by Doctrine Bot [ 15/Apr/14 ]

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

Comment by Marco Pivetta [ 15/Apr/14 ]

Merged: https://github.com/doctrine/doctrine2/commit/68d477a4c6d2dc2c201015a6fceb4e64e5ce744a





[DDC-3084] Native query removes duplicate root entities Created: 14/Apr/14  Updated: 15/Apr/14  Resolved: 14/Apr/14

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

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


 Description   

I have a query like that:

        $rsm = new ResultSetMappingBuilder($this->_em);
        $rsm->addScalarResult('rank', 'rank');
        $rsm->addRootEntityFromClassMetadata('Application\Entity', 'e');

		$query = $this->_em->createNativeQuery('
            SELECT
            	r.rank, ' . $rsm->generateSelectClause(array('e')) . '
            FROM ...
	    ', $rsm);

        return $query->getResult();

When I issue it at the mysql side it returns 3 rows but doctrine returns only 2 - I have tried getArrayResults() with the same results

The query could return the same entity multiple times for different values of the "rank" scalar value but it seems that doctrine removes those duplicates



 Comments   
Comment by Przemyslaw Wrobel [ 14/Apr/14 ]

the result should be like this: ("rank", "entity")
1, entity1
2, entity2
3, entity2

Comment by Marco Pivetta [ 14/Apr/14 ]

Doctrine ORM groups the values of the root of the selection by identifier during hydration: this is the expected result.

Comment by Przemyslaw Wrobel [ 15/Apr/14 ]

If it is really grouping than I shoud have something like that
entity1, 1
entity2, array(2,3)

Now the problem is that I am losing data - the row: 3, entity2 is missing and I have to resort to DBAL query or do not map to entities but than I cannot use my model logic





[DDC-2629] [GH-768] DDC-391: Add support to configure custom persister classes Created: 22/Aug/13  Updated: 15/Apr/14  Resolved: 02/Jan/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: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates DDC-2637 [GH-769] Add Custom Persisters Open

 Description   

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

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

Message:

Based on https://github.com/doctrine/doctrine2/commit/8c3ad50bb5ad51f9064543768745f3d85f4b7d64 (from the http://github.com/doctrine/doctrine2/tree/OverridePersisters branch)

Basis for feature: http://www.doctrine-project.org/jira/browse/DDC-391



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

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

Comment by Doctrine Bot [ 15/Apr/14 ]

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





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

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

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

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

 Description   

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

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

Message:

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



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

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

Comment by Doctrine Bot [ 15/Apr/14 ]

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





Generated at Mon Apr 21 12:35:41 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.