[DDC-2953] ArrayHydrator: Not all items hydrated while orderBy Created: 05/Feb/14  Updated: 06/Feb/14

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

Type: Bug Priority: Critical
Reporter: Mariusz Jaskółka Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: array, hydration
Environment:

Linux and Windows, PHP5


Attachments: File ArrayHydrator.php     File Array_Hydrator_4.2.php     File Array_hydrator_4.2_bugfix.php    

 Description   

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

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

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

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

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

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



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

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

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

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

Comment by Marco Pivetta [ 06/Feb/14 ]

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

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

Version 2.4.2 oryginal file and bugfix

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

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

Comment by Marco Pivetta [ 06/Feb/14 ]

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

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

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

Comment by Marco Pivetta [ 06/Feb/14 ]

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

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

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

Comment by Marco Pivetta [ 06/Feb/14 ]

Mariusz Jaskółka fixed, thanks!





[DDC-2800] Something wrong with documentation generation Created: 18/Nov/13  Updated: 02/Apr/14

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

Type: Documentation Priority: Critical
Reporter: Flip Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

The ArrayCollection has a matching() function, but it does not show in the API docs. http://www.doctrine-project.org/api/common/2.4/class-Doctrine.Common.Collections.ArrayCollection.html



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

Flip The collection API has moved to its own repo anyways now and there currently is no API generation for this, aswell as other subprojects like annotations etc. But the matching() method exists in 2.3 branch, where the repos were not separated, yet.

http://www.doctrine-project.org/api/common/2.3/source-class-Doctrine.Common.Collections.ArrayCollection.html#463-498

Do we need to keep this ticket open?

Comment by Flip [ 02/Apr/14 ]

I think so because no new documentation is generated for subprojects.

Expected: http://www.doctrine-project.org/api/collections/2.4/ (or any other latest version if the subprojects have seperate versioning)





[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-3079] preUpdate in EntityListener not run in transaction Created: 10/Apr/14  Updated: 10/Apr/14

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


 Description   

I have entity:

class Article{
	/**
	 * @ORM\OneToMany(targetEntity = "ArticleModule\Model\Entities\ArticlePhoto", mappedBy = "article", cascade = {"persist", "remove"}, orphanRemoval = TRUE)
	 * @ORM\OrderBy({"sequence" = "ASC"})
	 */
	protected $articlePhotos;
}

And Entity Listener with preRemove.

I call

$article->articlePhotos->clear();
...some changes with entity...
$em->flush();

preRemove in Entity Listener is called, BUT before Begin transaction...

I can do
$em->transactional(function(){}); then it's full in transaction..






[DDC-3083] Persist/Flush silently fails when CTI is applied on an existing table Created: 12/Apr/14  Updated: 13/Apr/14

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

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


 Description   

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

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

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

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



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

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

Comment by Frank Liepert [ 13/Apr/14 ]

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

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

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

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

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

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

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

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


/** 
 * NEW REQUEST
 */

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

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

Comment by Marco Pivetta [ 13/Apr/14 ]

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

Comment by Frank Liepert [ 13/Apr/14 ]

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





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

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

Type: Bug Priority: Major
Reporter: Christophe Coevoet Assignee: Benjamin Eberlei
Resolution: Unresolved 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





[DDC-3070] [GH-1001] [DDC-3005] Defer invoking of postLoad event to the end of hydration cycle. Created: 04/Apr/14  Updated: 04/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: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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

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

Message:

This feature makes guarantee, that postLoad event fires after all associations are populated.
Test case also provided.






[DDC-3075] [GH-1005] Added support of the subselect expressions into NEW expressions Created: 08/Apr/14  Updated: 08/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: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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

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

Message:

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






[DDC-3073] @Column options Created: 07/Apr/14  Updated: 07/Apr/14

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

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


 Description   

The documentation seems to lack a reference to the ability to set options for columns. See:
http://stackoverflow.com/a/11776153/1833322
http://stackoverflow.com/a/14221973/1833322
http://stackoverflow.com/a/18050298/1833322






[DDC-3062] [GH-997] [FIX] Allow to use ManyToMany with all operators Created: 31/Mar/14  Updated: 31/Mar/14

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

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


 Description   

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

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

Message:

Hi,

ping @guillhermoblanco : I think this may be blocking for 2.5

I introduced not so long ago support for ManyToMany for Criteria. However, I realized my implementation was really incomplete, because I hard-coded the "=" operator (https://github.com/doctrine/doctrine2/pull/885/files#diff-982b7374bbe9d5f4b6b71f4869a446eaR575). This means that it fails in a lot of cases when you use something different than "eq" for Criteria.

This PR fixes that, however it's a bit hacky. The SqlExpressionVisitor was made by type hinting for a BasicEntityPersister, preventing us from using us for a collection persister. Therefore I added a new interface to keep BC.

There is also a lot of code duplication (the whole "getSelectConditionSQL" was copied from the BasicEntityPersister), but without trait or BC, I have no idea about how to solve it.

All tests pass, test were added for other operators.






[DDC-3055] table not escaped in orm:schema-tool:update if table already exists and needs to be altered Created: 27/Mar/14  Updated: 27/Mar/14

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

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


 Description   

the schema tool had to alter a table which name needs to be escaped (and was properly configured to do so). this didnt work because the table name wasnt escaped. completely deleting the table in the db let the schema tool generate the correct querys with escaped table names.



 Comments   
Comment by Marco Pivetta [ 27/Mar/14 ]

Hilz Simon did you try this with master as well?





[DDC-3054] [GH-991] Ability to define custom functions with callback instead of class name Created: 27/Mar/14  Updated: 27/Mar/14

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

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


 Description   

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

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

Message:

Right now the only way to define custom DQL functions is by giving the class name, and Doctrine will create the class:

```php
$config->addCustomNumericFunction('FOO', 'My\Custom\DqlFunction');
```

This is very limiting when the custom functions has dependencies, for example it can't be created by a DI container.

The approach I have taken here is very simple: it allows to define a callback instead of the class name: the callback will be called and it should return the instance:

```php
$config->addCustomNumericFunction('FOO', function($funcName)

{ return new My\Custom\DqlFunction($funcName); }

);
```

On a side note, I think it would be great to generalize that approach because currently there are a lot of places where the same constraints apply.






[DDC-3056] Return value mismatch between code under HHVM and Zend Created: 28/Mar/14  Updated: 28/Mar/14

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

Type: Bug Priority: Major
Reporter: Andy hunt Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: hhvm, orm, paginator
Environment:

Two environments:
LAMP stack with PHP 5.4.25 on Ubuntu 12.04
HHVM 3.0.0.-dev (rel) ob Ubuntu 12.04



 Description   

The following code produces differing results under Zend and HHVM runtimes.

// $all::build uses the query builder to select all entities of a type
/** @var \Doctrine\ORM\Query $query **/
$query = $all->build($qb);
$query->setMaxResults($pageSize)->setFirstResult($start);

$paginator = new Paginator($query);
$results = array_values((array)$paginator->getIterator());

Under Zend, $results is a 1-dimensional array containing N elements:
[1, 2, 3].

Under HHVM, $results is a 2-dimensional array containing a single array, containing N elements:
[ [1,3,3] ]



 Comments   
Comment by Christophe Coevoet [ 28/Mar/14 ]

I suggest reporting it to the HHVM team as a bug

Comment by Marco Pivetta [ 28/Mar/14 ]

Also: why are you using an array cast and not iterator_to_array?

Comment by Christophe Coevoet [ 28/Mar/14 ]

@Marco this should be equivalent. Casting a Traversable to array should traverse it. If HHVM does not do it, it is a bug.

Comment by Marco Pivetta [ 28/Mar/14 ]

Christophe Coevoet not really: http://3v4l.org/Z3t4t





[DDC-3058] [GH-993] Update JoinColumn.php Created: 28/Mar/14  Updated: 28/Mar/14

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

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


 Description   

This issue is created automatically through a Github pull request on behalf of 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






[DDC-3044] [GH-986] Add last modified time for metadata Created: 22/Mar/14  Updated: 22/Mar/14

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

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


 Description   

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

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

Message:

This patch improves performance during development and does not affect production performance.

Currently, enabling the metadata cache during development gives a remarkable performance boost, but it requires that you manually flush the metadata cache when the metadata has been changed. When running console commands such as ``console orm:schema-tool:update`` (see #979).

With this change, metadata entries fetched from cache are checked for freshness using a quick last modified check. This is much faster than loading the actual metadata using the metadata driver. This allows you to enable the metadata cache during development without the need for manually flushing the metadata cache.

This PR is part 1 of 2. Part 2 is for the doctrine/common repository.

If this PR is accepted, it allows us to optimize the auto-generate proxy classes feature by comparing the last modified time for the metadata with the modified timestamp of the generated file.






[DDC-3052] [GH-989] Fix the problem when the lifecycle event can be triggered more then once... Created: 26/Mar/14  Updated: 26/Mar/14

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

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


 Description   

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

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

Message:

We recently saw the postUpdate event get trigger multiple time incorrectly, it typically happens when flushing a set of entities persisted whose listener persist and flush another type of entity in it.

Php passes variables to foreach by value, for the function executeUpdates in the UnitOfWork, for example, entities in the $this->entityUpdates could be updated and unset in the listener of the first entity, while them will be updated and trigger listeners again when the process of first entity finishes (although they have already been unset from $this->entityUpdates). Similar for executeInsertion and executeDeletion.






[DDC-3046] The flushed data is not available immediately for querying Created: 25/Mar/14  Updated: 25/Mar/14

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

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

ubuntu 13.10, mysql 5.5.35



 Description   

Doctrine's persisted data is not accessible by other queries immediately, for details see http://stackoverflow.com/questions/22618689/doctrines-persisted-data-is-not-accessible-by-other-queries-immediately






[DDC-3029] DISTINCT , ORDER BY AND Limit in SQL Server Created: 14/Mar/14  Updated: 14/Mar/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: Michał Banaś Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Attachments: File SQLServerPlatform.php    

 Description   

I don't know if I should report it here , becouse error is in SQLServerPlatform.php file.
basicaly Distinct includes ROWNUM()
So if you add distinct in DQL it will be translated to "select distinct ...... , Rownum()" - which is always distinct offcource.

Here is original version
protected function doModifyLimitQuery($query, $limit, $offset = null)
{
if ($limit > 0) {
if ($offset == 0)

{ $query = preg_replace('/^(SELECT\s(DISTINCT\s)?)/i', '\1TOP ' . $limit . ' ', $query); }

else {
$orderby = stristr($query, 'ORDER BY');

if ( ! $orderby)

{ $over = 'ORDER BY (SELECT 0)'; }

else

{ $over = preg_replace('/\"[^,]*\".\"([^,]*)\"/i', '"inner_tbl"."$1"', $orderby); }

// Remove ORDER BY clause from $query
$query = preg_replace('/\s+ORDER BY(.*)/', '', $query);
$query = preg_replace('/^SELECT\s/', '', $query);

$start = $offset + 1;
$end = $offset + $limit;

$query = "SELECT * FROM (SELECT ROW_NUMBER() OVER ($over) AS doctrine_rownum, $query) AS doctrine_tbl WHERE doctrine_rownum BETWEEN $start AND $end";
}
}

return $query;
}
In Attachenment there is a fixed version of this file.






[DDC-3016] Criterias do not work with embeddables when matching in memory Created: 07/Mar/14  Updated: 12/Mar/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: Matthieu Napoli Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

When using criterias and doing the matching on a collection already loaded in memory, it will not work if filtering on embeddable objects.

Example:

    $criteria = new Criteria();
    $criteria->andWhere($criteria->expr()->eq('actions.view', true));

    $authorizations = $this->authorizations->matching($criteria);

Here the ClosureExpressionVisitor will try to get the property named >actions.view instead of >actions->view.

PHPUnit_Framework_Error_Notice : Undefined property: Tests\...\Model\ArticleAuthorization::$actions.view





[DDC-3025] Schema tool UPDATE or CREATE not generate decimal precision and scale for ID element Created: 12/Mar/14  Updated: 12/Mar/14

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

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


 Description   

FYI. I don't use doctrine but with symfony2, and only use .yml or .xml mapping. Not yet try with annotation.

These commands :

php app\console doctrine:schema:update
php app\console doctrine:schema:create

Will not generate id's precision and scale for this kind of mapping :

<doctrine-mapping .....>
  <entity name="Namespace\MyBundle\Entity\MyData" table="my_data">
    <id name="id" type="decimal" column="id" precision="x" scale="y">
      <generator strategy="IDENTITY"/>
    </id>
    <field ... />
  </entity>
</ ....>

Suggested changes :

  • Doctrine\ORM\Mapping\Driver\YamlDriver.php
  • Doctrine\ORM\Mapping\Driver\XmlDriver.php





[DDC-3007] ManyToMany does not respect all column attributes for the jointable Created: 03/Mar/14  Updated: 03/Mar/14

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

Type: Bug Priority: Major
Reporter: Michael Kühn Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Given following 2 entities:

<?php
class Role {
    /**
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="UUID")
     * @ORM\Column(name="id", type="guid", nullable=false, unique=true, length=36, options={"fixed"=true})
     */
    protected $id;

    /**
     * @ORM\ManyToMany(targetEntity="User", mappedBy="roleList")
     */
    private $userList;
}
<?php
class User {
    /**
     * @ORM\Column(name="id", type="guid", nullable=false, unique=true, length=36, options={"fixed"=true})
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="UUID")
     */
    protected $id;

    /**     *
     * @ORM\ManyToMany(targetEntity="Role", inversedBy="userList")
     * @ORM\JoinTable(name="user_role")
    protected $roleList;
}

It should create a table "user_role" with 2 columns which are CHAR(36).

But it ignores the Column-Attributes and creates a table "user_role" with 2 CHAR(255) columns.

This has various downsides:

  • It's unusable when using MyISAM, because of limited index size. (CREATE TABLE fails, see DBAL-423)
  • If using GUID-Type (see DBAL-423 with the changes from the linked ull request) and specify "length=36" and "fixed=true" on the Column-Annotation, no changes for the entity-tables itself are generated when running orm:schema-tool:update. However, there are still changes for the many-to-many-table generated (because internal "fixed" is false and length is unset) which represent the current state of the columns. These changes are always generated.





[DDC-2988] Notice: Undefined index: joinColumns in BasicEntityPersister.php Created: 19/Feb/14  Updated: 19/Feb/14

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

Type: Bug Priority: Major
Reporter: Dennis Væversted Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File undefined-joinColumn.patch    
Issue Links:
Duplicate
duplicates DDC-2808 Notice: Undefined index: joinColumns ... Resolved

 Description   

When trying to use findBy on a ManyToMany field i receive the error:

Notice: Undefined index: joinColumns in lib/Doctrine/ORM/Persisters/BasicEntityPersister.php

It seems to be caused internally by the code expecting 'joinColumns' to be directly on the association, however it is found under 'joinTable'.
I have attached a patch that atleast fixes my case, hopefully it can be used to pin-point what the error is.



 Comments   
Comment by Dennis Væversted [ 19/Feb/14 ]

Might be related to this one: http://www.doctrine-project.org/jira/browse/DDC-2808





[DDC-2990] [GH-956] Foreign association index names Created: 19/Feb/14  Updated: 23/Feb/14

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

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

Issue Links:
Reference
relates to DDC-2989 ORM should allow custom index names f... Open

 Description   

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

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

Message:

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






[DDC-2981] Multi get for second level cache (Doctrine Cache related) Created: 13/Feb/14  Updated: 13/Feb/14

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

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


 Description   

Hi every body!

I'm developing an application that is highly based on doctrine second-level cache feature.
Using memcache or redis as cache back-end, doctrine have to query thousand times for the cached values (especially on one-to-many and many-to-many associations).
This introduces a lot of latency (and network traffic)...

I'm thinking to add to Doctrine\Common\Cache\Cache interface a method fetchMulti(array $keys) that fetches multiple items in one call. In this way doctrine orm can ask for many items with just one call (for example, here https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Cache/DefaultCollectionHydrator.php#L84 this feature can be very useful).

I have made some real-world tests and it can reduce highly the number of total queries (my app runs 190 cache requests instead of 900 cache requests)

Many vendors (memcache, redis, apc ecc) already offer this functionality, but with doctrine-cache we can't use it...

I'm going to implement this feature. Can it be accepted as a pull request?

It may be BC breaking:

  • it can be implemented adding a method inside Doctrine\Common\Cache\Cache interface (more BC breaking but more clean and elegant)
  • it can be implemented adding an interface Doctrine\Common\Cache\MultiCache and later CacheProvider can implement it (less BC breaking)


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

Adding a method to Doctrine\Common\Cache\Cache is not viable because of BC - a new interface would be ok

Comment by Asmir Mustafic [ 13/Feb/14 ]

ok, i agree with you.
But this forces me to check always here https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Cache/Region/DefaultRegion.php#L95 if $this->cache is instance of MultiCache

Comment by Marco Pivetta [ 13/Feb/14 ]

Asmir Mustafic or you build a MultiCacheRegion

Comment by Asmir Mustafic [ 13/Feb/14 ]

It can be a good approach. I will try it.
I'm thinking to provide a default implementation of fetchMulti directly inside CacheProvider that internally loops over each key and call CacheProvider::fetch($id) to fetch its value.
Later i will overwrite this behavior inside vendor specific driver (ApcCache, RedisCache...)





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

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

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

MySQL, using DoctrineORMModule (zf2 integration)



 Description   

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

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

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

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

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

Doing this:

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

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

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

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

Leads to

integrity constraint violation, b_id can not be null

aka

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

I have no idea why this happens. This works:

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

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

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

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


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

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





[DDC-2982] [GH-954] Multi Get support for Second Level Cache Created: 14/Feb/14  Updated: 23/Mar/14

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

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


 Description   

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

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

Message:

Hi!
As discussed [here](http://www.doctrine-project.org/jira/browse/DDC-2981) i have implemented some kind of multi-get for second level cache implementation.

I have also created a PR to doctrine/cache component (see https://github.com/doctrine/cache/pull/29) that enables this feature at driver cache level.






[DDC-2973] [GH-949] Add a default lock mode to the EntityManager Created: 10/Feb/14  Updated: 10/Feb/14

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

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


 Description   

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

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

Message:

Following [this discussion](https://groups.google.com/forum/#!topic/doctrine-dev/xKGzQcDkilE) on the mailing list, this is a first draft of a proposal to introduce a default lock mode for all entities loaded through an EntityManager.

At the moment, there is no way to set a lock mode for the following use cases:

  • Proxies obtained through `getReference()` and then initialized
  • Entities lazy-loaded through traversal of associations

This proposal introduces the idea of a default lock mode, which can be set at runtime when all reads in a transaction should be locking.

It works this way:

$em->beginTransaction();
$em->getConfiguration()->setDefaultLockMode(LockMode::PESSIMISTIC_WRITE);

// load entities from EntityManager, Repositories or DQL, traverse associations, etc.
// all these entities will be loaded with the given lock mode

$em->commit();
$em->getConfiguration()->setDefaultLockMode(null);

I have successfully tested it with the following use cases:

  • `EntityManager::find()`
  • `EntityRepository::findBy()`
  • DQL queries
  • Proxies
  • Lazy-loaded collections through OneToMany and ManyToMany associations

Before moving forward and writing proper unit tests, I'm looking for your feedback on this proposal. Is this a concept you would be happy to integrate in Doctrine?

If yes, I have a doubt as regards to where the default lock mode should be set: @Ocramius suggested to set it on the `Configuration`; this looked reasonable at first glance, and I have implemented it this way for now. It feels a tiny bit wrong though now that I see it, as I feel like the contents of the Configuration should should only be set during bootstrapping, rather than being set and reset in the controllers as in the example above. I might be wrong obviously.

My suggestion would be to move the default lock mode to the EntityManager, so that the code would become:

$em->beginTransaction();
$em->setDefaultLockMode(LockMode::PESSIMISTIC_WRITE);

Happily waiting for your feedback!






[DDC-2955] [GH-933] [WIP] DDC-2953 Created: 05/Feb/14  Updated: 05/Feb/14

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

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


 Description   

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

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

Message:

This PR tries to fix DDC-2953 (http://www.doctrine-project.org/jira/browse/DDC-2953).

tl;dr: when the results are not sorted by root entity identifier, the array hydrator swallows some output.






[DDC-2940] [GH-922] Two hooks for DoctrineBundle to allow ContainerFilterCollection Created: 29/Jan/14  Updated: 29/Jan/14

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

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


 Description   

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

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

Message:

Allows the DoctrineBundle to inject a ```ContainerFilterCollection``` that creates filters through dependency injection. See doctrine/DoctrineBundle#245.

Would prefer to inject the ```FilterCollection``` into the constructor of the em, but since they have a cyclic dependency I chose setter injection.






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

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

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


 Description   

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

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

Message:

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






[DDC-2946] [GH-926] Feature/console em helper interface Created: 01/Feb/14  Updated: 01/Feb/14

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

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


 Description   

This issue is created automatically through a Github pull request on behalf of 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





[DDC-2929] Pessimistic lock on Query does not update the entity with the DB values if it's already cached Created: 22/Jan/14  Updated: 22/Jan/14

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

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

PHP 5.4.13-1~dotdeb.1


Issue Links:
Reference
is referenced by DDC-1846 Pessimistic lock does not retreive la... Resolved

 Description   

When asking for a pessimistic lock through a Query object, the entities already in the cache are not refreshed with the latest values from the database (unless you set the Query::HINT_REFRESH hint)

Example:

        $em->beginTransaction();
        try {
            $bar = $em->createQuery('SELECT b FROM Foo:Bar b WHERE b.id = :id')
                        ->setParameter('id', 150)
                        ->getSingleResult();
            var_dump($bar->getAmount()); // Yields some positive value
            $bar->setAmount(0);
            $bar = $em->createQuery('SELECT b FROM Foo:Bar b WHERE b.id = :id')
                        ->setParameter('id', 150)
                        ->setLockMode(\Doctrine\DBAL\LockMode::PESSIMISTIC_WRITE)
                        // ->setHint(\Doctrine\ORM\Query::HINT_REFRESH, true)
                        ->getSingleResult();
            var_dump($bar->getAmount()); // Yields 0

            $em->flush();
            $em->commit();
        } catch (\Exception $e) {
            $em->rollback();
        }

This is similar to DDC-1846

(Tested on 2.4.0 and 2.4.1)






[DDC-2930] Pessimistic locking using $em->find('Entity', $id, LockMode::PESSIMISTIC_WRITE) and $em->lock($entiy, LockMode::PESSIMISTIC_WRITE) differs in (not)refreshing entity state from DB Created: 23/Jan/14  Updated: 23/Jan/14

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

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

ubuntu 12.04, mysql, zf2



 Description   

When using pessimistic locking on MySQL(InnoDB tables) there is difference which surprised me:

$em->find('Entity', $id, LockMode::PESSIMISTIC_WRITE);

will reload entity state from DB even when entity was already managed in cache (implemented in DDC-2929)
So I supposed that

$em->lock($entiy, LockMode::PESSIMISTIC_WRITE);

will work alike even when in this case entity is sure already loaded and managed
But it is not the case, actual query log showed only

SELECT 1 FROM table WHERE id FOR UPDATE

If this difference is intended it would be nice to mention it in http://docs.doctrine-project.org/en/latest/reference/transactions-and-concurrency.html

As a workaround I use

$em->refresh($entiy);





[DDC-2922] Flushing new Entities reachable over several paths that do not all "cascade persist" Created: 17/Jan/14  Updated: 17/Jan/14

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

Type: Bug Priority: Major
Reporter: Matthias Pigulla Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None


 Description   

Please consider the following associations:

  A <>--> B <-- C  

A is an "aggregate" type object w/ a OneToMany collection of Bs. This association is set to cascade persist operations.

C has a unidirectional OneToOne association to B as well.

Adding a new B to A's collection and flushing the EntityManager works - B is persisted (persistence by reachability).

However, when also creating a new C and pointing it to the new B, adding C to the EntityManager and then flushing leads to an exception because B is discovered as a new Entity through a relationship not set to cascade persist operations.

Obviously the problem here is that there are two paths through which we can discover new Entities. The UoW currently starts search from newly (explicitly) added Entities first before it walks through collections of already-managed entities.

I am unsure if it is just a documentation issue or a deeper problem?

If the UoW worked the other way round, the same problem would occur if the cascade persist was on the other association.

A solution would probably require the UoW to first collect all offending (new) Entities and the link they were discovered through, but later on remove Entities from this list if they are found through another association with the cascade persist option. The exception must not be thrown unless the whole reachability graph has been traversed.






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

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

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


 Description   

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

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

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

Most interesting are rowCount and error related methods.



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

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

Comment by Flip [ 15/Jan/14 ]

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

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

or another situation ..

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





[DDC-2917] Inheritance using joins generates invalid SQL when used in SELECT queries with GROUP BY on Postgresql Created: 15/Jan/14  Updated: 15/Jan/14

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

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


 Description   

Say you have an entity with InheritanceType("JOINED"), some child entities defined in the DiscriminatorMap which include additional columns and are using PostgreSQL then try and execute a DQL query as below:

SELECT parententity FROM MyStuff\Entity\ParentEntity parententity GROUP BY parententity

Note: This is simplified for ease of reproduction, obviously the GROUP BY is pointless but in my actual query, which is significantly larger, the GROUP BY is actually useful.

PostgreSQL will give the following error:

SQLSTATE[42803]: Grouping error: 7 ERROR:  column "f2_.my_additional_column" must appear in the GROUP BY clause or be used in an aggregate function

Where f2_ is an alias in the actual SQL for one of the child entities.

This is because the SELECT in the actual SQL attempts to fetch the columns from the joined child entities but does not include them in the GROUP BY clause.

Bad SQL generated:

SELECT f0_.id AS id0, <f0_.* columns>, f2_.my_additional_column AS my_additional_column6
FROM parententitys f0_
LEFT JOIN childentity f2_ ON f0_.id = f2_.id
GROUP BY f0_.id, <f0_.* columns>

The SQL should be:

SELECT f0_.id AS id0, <f0_.* columns>, f2_.my_additional_column AS my_additional_column6
FROM parententitys f0_
LEFT JOIN childentity f2_ ON f0_.id = f2_.id
GROUP BY f0_.id, <f0_.* columns>, f2_.my_additional_column

N.b later versions of PostgreSQL don't require the GROUP BY on all the columns, just the primary key. Therefore the following would be sufficient:

SELECT f0_.id AS id0, <f0_.* columns>, f2_.my_additional_column AS my_additional_column6
FROM parententitys f0_
LEFT JOIN childentity f2_ ON f0_.id = f2_.id
GROUP BY f0_.id, f2_.id





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

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

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


 Description   

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

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

Message:

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

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

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

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

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



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

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





[DDC-2911] IndexBy doesn' work with arbitrary join Created: 13/Jan/14  Updated: 13/Jan/14

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

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


 Description   
        $statsQb = $em->createQueryBuilder()
            ->select('d AS date')
            ->from('MetalStatisticBundle:Day', 'd', 'd.date')
            ->leftJoin('MetalStatisticBundle:StatsDaily', 'sd', 'WITH', 'd.date = sd.date', 'sd.date')
            ->addSelect('sd AS stats')
            ->andWhere('sd.company = :company_id')
            ->setParameter('company_id', $company->getId())
            ->orderBy('sd.date', 'DESC')
            ->setMaxResults(10)

expected: array like

2012-10-10 => array(date => object, stats => object)
2012-10-09 => array(date => object)
2012-10-08 => array(date => object, stats => object)

got: exception Expected Literal, got 'BY'






[DDC-2901] entity-listeners are not propagated to children of mapped superclasses Created: 09/Jan/14  Updated: 09/Jan/14

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

Type: Bug Priority: Major
Reporter: Stuart Carnie Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mapping


 Description   

If I have event-listeners set on the subclass and mapped superclass, event-listeners will not be propagated, per this code. Conversely, lifecycle events are, per this






[DDC-2888] [GH-899] Add travis build matrix for all built-in PostgreSQL versions Created: 06/Jan/14  Updated: 06/Jan/14

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

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


 Description   

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

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

Message:

[Travis now ships with PostgreSQL version 9.1, 9.2 and 9.3 built-in](http://about.travis-ci.org/blog/2013-11-29-postgresql-92-93-now-available/). We should extend our build matrix to test on all versions.






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

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

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


 Description   

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

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

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



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

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

Comment by alex [ 08/Jan/14 ]

MySql

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

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

Comment by alex [ 08/Jan/14 ]

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

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





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

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

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


 Description   

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

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

Message:

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

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






[DDC-2875] [GH-890] [DBAL-563] Add general IDENTITY generator type support for sequence emulating platforms Created: 29/Dec/13  Updated: 31/Dec/13

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

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


 Description   

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

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

Message:

This is a follow-up PR for https://github.com/doctrine/dbal/pull/428 as discussed in DBAL-563(http://www.doctrine-project.org/jira/browse/DBAL-563) which adds IDENTITY generator type support for platforms that do not natively support identity columns but can emulate them via sequences.
This replaces the current workaround for PostgreSQL `SERIAL` columns in favour of a more general approach. With this patch now IDENTITY generator can also be used with Oracle which did not work before. Future platforms can also make use of this approach if necessary.



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

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





[DDC-2869] [GH-886] [DDC-1256] Fix applying ON/WITH conditions to first join in Class Table Inheritance Created: 22/Dec/13  Updated: 17/Feb/14

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

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


 Description   

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

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

Message:

Some related issues:
http://www.doctrine-project.org/jira/browse/DDC-1256
http://www.doctrine-project.org/jira/browse/DDC-2131

I think that applying custom user joins conditions to last join in CTI is ok because only in last join DB will know about all joined table aliases. And I can't see any other probles with this.

Tests are not passed, because, I think, problem in tests.

To be discussed, of course



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

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





[DDC-2865] [GH-882] Efficient counting on Criteria Created: 19/Dec/13  Updated: 02/Jan/14

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

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


 Description   

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

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

Message:

Hi,

This is an attempt to solve this very annoying issue: http://www.doctrine-project.org/jira/browse/DDC-2217

I'm not sure about my solution as I'm not really into Doctrine internals.

  1. Use case

I have a library that is based exclusively on Criteria API. A Paginator adapter uses an empty Criteria to count how many elements are in the collection. However, EntityRepository's matching method always initialize the whole collection into an ArrayCollection. This is unusable in most cases and make the API unusable for my use case.

  1. Solution

I've created a new LazyCollectionCriteria that implements an efficient count. I think the cleanest solution would be to add a method to the Selectable interface: with a count method. But I think this is not possible now, unfortunately.

If the solution seems nice to you, I'll write the tests.

ping @ocramius, @mac_nibblet and @thinkscape (this should make ZfrRest usable )






[DDC-2861] [GH-881] Fix persistence exception on a table with a schema on a platform without schema support Created: 18/Dec/13  Updated: 18/Dec/13

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

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


 Description   

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

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

Message:

This PR solves two related issues with the use of a database schema on platforms (such as SQLite) that don't support schemas.

I discovered the issues when I generated the schema from my Doctrine entities on SQLite (for unit test purposes of my application) whereas my main application uses PostgreSQL.

This is one of my first PR on Doctrine, so sorry if I made some things in the wrong way and I'm open to discussion.

*First problem: table names dots are not converted in the ORM*

On a platform like SQLite, DBAL converts table names with dots (ie. a schema is declared) to double underscores.
However, the ORM doesn't do it, and persisting leads to an exception.

Example:

```
MyNamespace\Mytable:
type: entity
table: myschema.mytable

  1. ...
    ```

And then somewhere in the code:

```
$myTable = new MyNamespace\Mytable();
$entityManager->persist($myTable);
$entityManager->flush();
```

This doesn't work in the current version of Doctrine. The table is created as `myschema__mytable` but entities are unsuccessfully saved in `myschema.mytable`.

*Second problem: table names with reserved keywords in a database schema are not correctly escaped*

When a table name is declared as `myschema.order` (or any other reserved keyword), only the reserved keyword part is escaped when creating the table, leading to the creation of a table name like myschema__\`order\`, which is invalid and therefore fails.

*How this PR solves the problem*

The classmetadata now stores in 2 separated properties the name of the table and the name of the schema. The schema property was partially implemented but I now make a full use of it.

When metadata is read (from Annotations, YAML, ...), if the table name has a dot (`myschema.mytable`), it's splitted into 2 parts, and `myschema` is saved in the `schema` table property, and `mytable` is saved in the `name` table property, instead of storing the whole `myschema.mytable` in the `name` table property.

This allows to do specific things about schemas everywhere in Doctrine, and not splitting again parts everywhere it's needed.

By the way, the `schema` property can now fully be used.

For instance, these 2 YAML configurations are valid and do the same thing:

```
MyNamespace\Mytable:
type: entity
table: myschema.mytable
```

and:

```
MyNamespace\Mytable:
type: entity
table: mytable
schema: myschema
```

This was something which was not finished to be implented since Doctrine 2.0.

The Default quote strategy now converts back the schema and table names to a unique table name, depending on the platform (e.g. `myschema.mytable` if the platform supports schemas, and `myschema__mytable` otherwise).

As a result, there is no problem anymore and entities can be persisted without getting any exception.
I added some unit tests for this (the same unit tests failed before of course).

There's however a slight tradeoff on performance, as the `getTableName` of the `DefaultQuoteStrategy` class adds some tests to return the correct table name.

This solved these Doctrine issues: DDC-2825(http://www.doctrine-project.org/jira/browse/DDC-2825) and DDC-2636(http://www.doctrine-project.org/jira/browse/DDC-2636).

Again, this is one of my first PRs on Doctrine, so if there's anything wrong or if you have any question, feel free to comment this PR.

@Ocramius This PR is about what we talked about in DDC-2825(http://www.doctrine-project.org/jira/browse/DDC-2825)






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

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

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


 Description   

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

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

Current workaround:

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

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

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






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

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

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


 Description   

Hi

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

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

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

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



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

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

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





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

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

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


 Description   

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

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

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

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

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






[DDC-2839] [GH-869] Detach objects in original object data Created: 04/Dec/13  Updated: 05/Dec/13

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

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


 Description   

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

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

Message:

The PR makes Doctrine ORM update the database when you execute something like this:

```php
// MyEntity.php

/**

  • @Entity
    */
    class MyEntity
    {
    // ...

/**

  • @Column(type="datetime")
    */
    private $created;

// ...

public function setCreated(\DateTime $created)

{ $this->created = $created; }

public function getCreated()

{ return $this->created; }

// ...
}
```

```php
// Current problem

$entity = $entityManager->find('MyEntity', 1);

$entity->getCreated()->setDate('2001-01-01');

$entityManager->persist($entity);

$entityManager->flush();

// At this point no changes have been made to the database!
```

The reason this doesn't work currently is because the array of original data stored in the UnitOfWork contains the actual DateTime object which is in the entity. When you update the object in the entity the original data is updated also so the entity are the original value are still equal and therefore the object is not seen as changed.

I have chosen to clone all objects rather than just DateTime object include more types are included in the future.



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

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





[DDC-2835] No Lock Hint on Joins Created: 03/Dec/13  Updated: 03/Dec/13

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

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

Microsoft SQL Server 2008/2012



 Description   

There seems to be no lock hits added to the joins on a query. For example, take the following query :

SELECT w0_.name AS name0, w1_.name AS name1, c2_.name AS name2, count(w3_.id) AS sclr3 FROM workflow_request w3_ WITH (NOLOCK) INNER JOIN workflow_request_status w1_ ON w3_.status_id = w1_.id INNER JOIN workflow_action w0_ ON w3_.action_id = w0_.id LEFT JOIN workflow_transition w4_ ON w3_.transition_id = w4_.id INNER JOIN core_mno_account c5_ ON w4_.mno_account_id = c5_.id INNER JOIN core_mno c2_ ON c5_.mno_id = c2_.id LEFT JOIN workflow_state w6_ ON w3_.current_state_id = w6_.id WHERE w1_.ident IN GROUP BY w0_.name, w1_.name, c2_.name ORDER BY w0_.name ASC, w1_.name ASC, c2_.name ASC [["waiting"]]

the "with(nolock)" is only added to the FROM clause .... it should be added after each join too






[DDC-2838] Leaky abstraction when applying Criteria to hydrated/non-hydrated PersistentCollection Created: 03/Dec/13  Updated: 03/Dec/13

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

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


 Description   

When applying a Criteria to a PersistentCollection that has been hydrated the field names must be camel case, if the collection has not yet been hydrated the field names must be underscore separated.

The github repo linked here contains a simplified testcase for the matrix of hydrated/non-hydrated entities and camel case/underscore separated fields.

https://github.com/ptlis/DoctrineTestcase






[DDC-2834] [GH-868] Added documentation section for Memcached Created: 02/Dec/13  Updated: 02/Dec/13

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

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


 Description   

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

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

Message:

The documentation only talked about Memcache, an old PHP extension that can now be safely replaced by Memcached.

I've add a section of documentation about Memcached because the code to have it working is not the same.



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

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





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

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

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


 Description   

In Hibernate we can do something like this:

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

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

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



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

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





[DDC-2824] [GH-863] The new configuration option: defaultQueryHints Created: 27/Nov/13  Updated: 02/Jan/14

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

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


 Description   

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

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

Message:

I propose the new configuration option: `defaultQueryHints`, where developer can set array of hints, which will be applied to every query, created by doctrine. This option will be useful to set global AST walker, for example.






[DDC-2819] [GH-860] Mention SQL Anywhere in basic mapping documentation Created: 25/Nov/13  Updated: 25/Nov/13

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

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


 Description   

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

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

Message:

Just for documentation completion of the new SQL Anywhere platform.



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

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





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

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

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


 Description   

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






[DDC-2813] [GH-857] free more resources Created: 22/Nov/13  Updated: 23/Nov/13

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

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


 Description   

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

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

Message:

use unset to free resources better



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

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





[DDC-2809] [GH-853] Fix for PHP entity default values generated by EntityGenerator Created: 21/Nov/13  Updated: 21/Nov/13

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

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


 Description   

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

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

Message:

When specifying a default value for a column in the YAML, this value should be set in the entities that are generated by the EntityGenerator. The EntityGenerator looked for the default value in the wrong place of the field mapping and therefore defaults were never set. This issue has been fixed in this branch.



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

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





[DDC-2811] [GH-854] fix relative path to doctrine/common Created: 22/Nov/13  Updated: 23/Nov/13

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

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


 Description   

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

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

Message:

While testing your framework on HHVM I found this test doesn't pass because the path doesn't find what composer was installing into



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

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





[DDC-2799] [GH-850] Event listener to programmatically attach entity listeners. Created: 18/Nov/13  Updated: 25/Nov/13

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

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


 Description   

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

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

Message:

This patch adds a event listener to programmatically attach entity listeners.

Especially useful to attach listeners to external bundles/modules..



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

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





[DDC-2797] [GH-848] eliminate duplicate placeholders in "walkComparison" function within Que... Created: 18/Nov/13  Updated: 18/Nov/13

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

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


 Description   

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

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

Message:

...ryExpressionVisitor

I've run into an issue when using Criteria with QueryBuilder when Criteria uses multiple checks on same variable in different context, example:
field1 = value OR (field1 in values AND field2 = true)... what happens is field 1 placeholder is duplicated, and an error occures in code complaining about invalid # of parameters. The fix eliminates this issue, making sure parametername is unique.

I have not had time to check any other possible issues this may cause, but a review of the code doesn't appear to impact any other function.



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

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





[DDC-2795] the queryBuider Expr\Join class has a ON type but unsupported by the parser Created: 14/Nov/13  Updated: 14/Nov/13

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

Type: Bug Priority: Major
Reporter: Christophe Coevoet Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: documentation, dql, querybuilder,


 Description   

The Doctrine\ORM\Query\Expr\Join class has 2 cosntants for the condition types: WITH and ON.

None of them are documented. The only place where WITH appear is the EBNF, which is outdated in the doc as it does not show arbitrary joins (added in 2.3) but only association joins.

and when looking at the EBNF in the code, I find 2 different ones (none of them matching the one given in the doc):

  • in Doctrine\ORM\query\Parser::Join:
Join ::= ["LEFT" ["OUTER"] | "INNER"] "JOIN"
         (JoinAssociationDeclaration | RangeVariableDeclaration)
         ["WITH" ConditionalExpression]

This is matching the implementation and ON is not supported.

  • in Doctrine\ORM\Query\AST\Join:
Join ::= ["LEFT" ["OUTER"] | "INNER"] "JOIN" JoinAssociationPathExpression
         ["AS"] AliasIdentificationVariable [("ON" | "WITH") ConditionalExpression]

This one is missing 2 features also missing in the doc (INDEX BY for associations, and arbitrary joins) and adds the support of ON which is not implemented.

What is the reason to have this ON constant in the query builder ? It is confusing to get a DQL parse exception when using it if it is there.

On a side note, what is the canonical source for the EBNF ? There is 2 different locations in the code (the phpdoc of parser methods and the phpdoc of AST nodes created by the parser), plus the doc. Shouldn't we try to limit the duplication and have a way to check the consistency of the doc ?






[DDC-2794] the Paginator does not support arbitrary join Created: 14/Nov/13  Updated: 23/Dec/13

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

Type: Bug Priority: Major
Reporter: Christophe Coevoet Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 2
Labels: paginator


 Description   

Using the following query with the paginator fails:

SELECT u
FROM User u
JOIN Message m WITH m.author = u
WHERE m.status = 'draft' -- a condition justifying the join

The CountWalker and the CountOutputWalker both throw a exception saying "Cannot count query which selects two FROM components, cannot make distinction"

This message is wrong (I can make distinction here. Only User is selected in the result set) and confusing (I spent some time finding the second FROM before figuring it was related to the use of an arbitrary join instead of an association join).



 Comments   
Comment by Pierre-Antoine Pinel [ 23/Dec/13 ]

Hi,

I have the same issue.
My query is : SELECT entity FROM W\XBundle\Entity\X entity LEFT JOIN Z\YBundle\Entity\Y y WITH y.x = entity LEFT JOIN y.v v WHERE v.name LIKE :like

Is there a way to fix this issue ? I really need this to work with the Paginator.

Best,

Comment by Christophe Coevoet [ 23/Dec/13 ]

Why changing the status to "Awaiting feedback" ? It is not waiting for a feedback of the reporter to check the fix. It is an open ticket which does not have a fix yet





[DDC-2791] Constant value in JoinColumn Created: 13/Nov/13  Updated: 13/Nov/13

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

Type: New Feature Priority: Major
Reporter: Pavel S. Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: joins, mapping, orm

Attachments: JPEG File realty_reference.jpeg    

 Description   

My situation:
I have realty entities (flat, house, ...) they have hundreds parameters, wich title places in REFERENCE table. For example House has a few floor materials (stone, wood, etc.) and I want to get them. But each parameter type defined by type_id field in REFERENCE table, for example for floor material is's 115. My raw SQL:
SELECT h.id,... FROM HOUSE h
LEFT JOIN object_detail mf /material_floor/ ON mf.realty_id = h.id AND mf.data_class = h.data_class AND mf.type_id = 115
LEFT JOIN Reference mfr ON mfr.city_id = h.city_id AND mfr.id = mf.detail_id

And its not possible to set type_id directly in join table






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

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

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


 Description   

When I try running the following query:

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

I get

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

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






[DDC-2785] spl_object_hash_collisions Created: 08/Nov/13  Updated: 08/Nov/13

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

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

Ubuntu 12.04



 Description   

After reading DDC-1896 and DDC-136, I'm not exactly sure if this qualifies as a bug, but anyways, here's my code to reproduce:

    public function test_hash_collision()
    {
        $counter = 0;
        do
        {
            $object = $this->create_object();
            $counter++;
            if ($counter > 1000)
            {
                //mark as skipped ? (I never hit this on PHP 5.3 at least)
                break;
            }
        }
        while ($object === false);

        // This fails with "Failed asserting that 1 matches expected 2."
        $this->assertEquals(\Doctrine\ORM\UnitOfWork::STATE_NEW, $this->_em->getUnitOfWork()->getEntityState($object));
    }

    private function create_object()
    {
        static $hashes = array();
        $phone = new CmsPhonenumber();
        $phone->phonenumber = "1234";
        $hash = spl_object_hash($phone);
        $this->_em->persist($phone);

        if (!array_key_exists($hash, $hashes))
        {
            $hashes[$hash] = true;
            $this->_em->flush($phone);
            $this->_em->remove($phone);
            $this->_em->flush($phone);
            return false;
        }
        // Bingo! We have a new object with a recycled hash
        return $phone;
    }


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

Are you able to reproduce the test also without statics?

Comment by flack [ 08/Nov/13 ]

Yes, if I switch to $this->hashes (private $hashes = array()), the result is the same

Comment by flack [ 08/Nov/13 ]

Here's the complete test without statics & according to Doctrine CS (AFAICT):

<?php

namespace Doctrine\Tests\ORM\Functional\Ticket;

use Doctrine\Tests\Models\CMS\CmsPhonenumber;

require_once __DIR__ . '/../../../TestInit.php';

/**
 * @group DDC-2785
 */
class DDC2785Test extends \Doctrine\Tests\OrmFunctionalTestCase
{
    public function setUp()
    {
        $this->useModelSet('cms');
        parent::setUp();
    }

    private $hashes = array();

    public function testIssue()
    {
        $counter = 0;
        do
        {
            $object = $this->createObject();
            $counter++;
            if ($counter > 1000)
            {
                //mark as skipped ? (I never hit this on PHP 5.3 at least)
                break;
            }
        }
        while ($object === false);

        $this->assertEquals(\Doctrine\ORM\UnitOfWork::STATE_NEW, $this->_em->getUnitOfWork()->getEntityState($object));
    }

    private function createObject()
    {
        $phone = new CmsPhonenumber();
        $phone->phonenumber = "1234";
        $hash = spl_object_hash($phone);
        $this->_em->persist($phone);

        if (!array_key_exists($hash, $this->hashes))
        {
            $this->hashes[$hash] = true;
            $this->_em->flush();
            $this->_em->remove($phone);
            $this->_em->flush();
            return false;
        }

        return $phone;
    }
}

I can try and send this as a pull request, if it helps





[DDC-2786] [GH-843] Add failing test for DDC-2785 Created: 08/Nov/13  Updated: 08/Nov/13

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

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


 Description   

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

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

Message:

Add a failing test for

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






[DDC-2781] [GH-841] Enable saving native queries using ResultSetMappingBuilder. Created: 07/Nov/13  Updated: 02/Jan/14

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

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


 Description   

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

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

Message:

At present, a useful feature of ResultSetMappingBuilder, which creates the SELECT clause relevant to the built result set mapping, is unusable with named native queries.

This feature adds two additional, optional parameters to named native queries which stores an arbitrary string placeholder and an array of table aliases with the query.

Upon creation of the named native query, if the ResultSetMapping is a ResultSetMappingBuilder, and the placeholder is specified, the arbitrary string specified as the placeholder will be replaced with the output of ResultSetMappingBuilder::generateSelectClause(), passed the table aliases.

This allows native queries to be bootstrapped into an application as named queries, while also allowing the select clause to be automatically updated in the query as the metadata for the mapped entities changes.

Because native queries are not parsed in any way, a string placeholder is required to be able to interpolate the select clause into the query.






[DDC-2771] [GH-834] Add example use of repositoryClass in YAML Created: 01/Nov/13  Updated: 04/Nov/13

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

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


 Description   

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

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

Message:



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

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





[DDC-2763] Inheritance. CTI & STI. Improve lazy load associated entity, when target entity in association mapping is not last leaf in class hierarchy. Created: 27/Oct/13  Updated: 27/Oct/13

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

Type: Improvement Priority: Major
Reporter: Artur Eshenbrener Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: inheritance


 Description   

If we look inside documentation, we can see this:

There is a general performance consideration with Class Table Inheritance: If the target-entity of a many-to-one or one-to-one association is a CTI entity, it is preferable for performance reasons that it be a leaf entity in the inheritance hierarchy, (ie. have no subclasses). Otherwise Doctrine CANNOT create proxy instances of this entity and will ALWAYS load the entity eagerly.

I think it can be improved, if we will load only discriminator column value for resolve target class name, instead of loading whole entity. When we perform query from root entity, dicriminator value is already present in fetched database row.
What do you think?



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

Queries to fetch the discriminator column cannot be avoided (that's a limitation we can't workaround as far as I know).

What can be improved is avoiding instantiation of the joined results, and instead keep a proxy and a copy of the data for deferred hydration. That would allow avoiding recursive queries which are seen quite often when referencing the root of a STI/JTI

Comment by Artur Eshenbrener [ 27/Oct/13 ]

Queries to fetch the discriminator column cannot be avoided (that's a limitation we can't workaround as far as I know).

Of course, but fetching the discriminator value will produce less overhead than loading whole entity (with recursive loading joined entities). And, when you querying from root entity (with mapped sicriminator column), discriminator value already present in db result row (no need to extra query for dicriminator value).

What can be improved is avoiding instantiation of the joined results, and instead keep a proxy and a copy of the data for deferred hydration. That would allow avoiding recursive queries which are seen quite often when referencing the root of a STI/JTI

The result of my proposal will ability to get proxy class without loading whole entity.





[DDC-2767] ID property of MayToOne association has wrong type Created: 30/Oct/13  Updated: 07/Nov/13

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

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


 Description   

I'm seeing the following behaviour in some Doctrine code I'm writing:

$entity = array_pop($qb->getQuery()->getResult());
echo gettype($entity->getId()) . ' ' . $entity->getId();
// prints: integer 123

$association = $entity->getAssociation(); // unidirectional ManyToOne link to some other entity
echo gettype($association->getId()) . ' ' . $association->getId();
// prints: string 345

When I load the associated entity directly (via find() f.x.), it's ID has the integer type as expected, and the database structure looks correct, too.

I'm not entirely sure if this is a problem in my code or some issue in QueryBuilder or some other Doctrine component, but if someone could point me into the right direction, that would really be helpful.

I guess normally the type of the ID is not so important because you're not supposed to access it directly anyways, but I need to provide backward compatibility for a lot of code written against a different ORM API that provided exactly this behaviour.



 Comments   
Comment by flack [ 07/Nov/13 ]

After some research, the problem sounds kind of similar to

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

only that in my case, it's not a custom type, but a builtin one that is not working. But AFAICT, in both cases it's getting the ID from a proxy that is problematic





[DDC-2751] [GH-823] Elaborate description of the classIsNotAValidEntityOrMappedSuperClass ex... Created: 20/Oct/13  Updated: 02/Jan/14

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

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


 Description   

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

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

Message:

...ception



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

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





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

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

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

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



 Description   

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

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

Example:
CO_SEQ_NOMEGIGANTEPRAKCTMEUDEUS

Alias formed was
_SEQ_NOMEGIGANTEPRAKCTMEUDEUS101

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



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

Hi there!

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

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

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

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

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

What do you guys think?

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

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

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

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

Pablo,

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

The current code create a sql:
DT_VERIFICACAO_SITUACAO_ACESSO AS _VERIFICACAO_SITUACAO_ACESSO23,

My sugestion will produce:
DT_VERIFICACAO_SITUACAO_ACESSO AS DT_VERIFICACAO_SITUACAO_ACES23,

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

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

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

Comment by Benjamin Eberlei [ 26/Oct/13 ]

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





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

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

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


 Description   

Hello, I have an inheritance problem with the following classes

<?php

namespace Proj\Bundle\MyBundle\Entity;

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

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

class ClassSubOne extends ClassTop
{
    ....
}

class ClassSubTwo extends ClassTop
{
    ....
}

class ClassSubThree extends ClassTop
{
    ....
}

When i call findAll method my query is not correct

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

the query builded

SELECT field, field2 FROM CLASSTOP WHERE AVAL IN () 

The value for the discriminator column is not passed

Thanks for your help






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

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

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


 Description   

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

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

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






pager produces wrong results on postgresql (DDC-1958)

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

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

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

SQL Server 10.50.1617
unixODBC 2.2.14
PHP 5.4.19



 Description   

If the class is patched with the following:

if ($this->platform instanceof SQLServer2008Platform)

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

It fixes the issue.






[DDC-2727] "Expression" or "Update" API, similar to the Criteria API Created: 07/Oct/13  Updated: 07/Oct/13

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

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


 Description   

I created a discussion in the mailing list (https://groups.google.com/forum/#!topic/doctrine-dev/7HfEqOwhkDk) but no answer, so I'm moving the discussion here.


The Criteria API provides an abstraction to filter collections/repositories, may they be in memory (filtering in PHP) or in a database (filtering using a SQL query).

I was thinking about an "Expression" API which would work like array_map to apply changes in bulk to entities.

For example, if you have a collection where entities have a $position field, if I insert an item in the list, I have to increment the position of all the following items. For this, I have 2 options:

  • PHP: loading the entities in memory, iterate over them and increment $position
  • SQL: run a UPDATE position=position + 1 WHERE …

The second option is much more efficient, but it breaks the abstraction of the model because I have some behavior written explicitely in SQL. Furthermore, the objects loaded in memory will note be updated with the SQL query.

So the "Expression" API would work like the Criteria API:

interface Updatable {
    public function apply(Expression $e);
}

$expression = new Expression();

// For each item after position "10"
$expression->criteria->where(Criteria::expr()->gt('position', 10));
// Increment the position
$expression->set('position', 'position + 1');

$collection->map($expression);

The expression here would be applied:

  • in memory if the collection is already loaded
  • else in database using SQL

The expression could be applied to a Collection and to a Repository (like the Criteria).


About the API offered by the Expression class, there are several options:

// Option 1
// More powerful, but needs to parse and evaluate the string
class Expression
{
    public $criteria;
    public function set($field, $value);
}
 
$expression->set('position', 'position + 1');
 
// Option 2
// Easier to implement, more limited
class Expression
{
    public $criteria;
    public function setValue($field, $value);
    public function setValueFromField($targetField, $sourceField);
    public function add($field, $number);
    public function multiply($field, $number);
    public function divide($field, $number);
}
 
// Option 3
// Like option 2 but more extensible
class Expression
{
    public $criteria;
    public function set($field, Operation $operation);
}

I think I like the third one better because we have full control over the supported operations, and adding support to new kinds of operation is easy. The first one would require defining a whole language of allowed expressions...


What do you think of all that?



 Comments   
Comment by Matthieu Napoli [ 07/Oct/13 ]

Added option 3 after trying to write a POC

Comment by Matthieu Napoli [ 07/Oct/13 ]

Here is a POC on the doctrine/collections side: https://github.com/mnapoli/collections/compare/master...feature;Updatable works with ArrayCollection

I'm looking at the ORM side.

Feedback welcome, especially with the class/namespace/method names.





[DDC-2726] EventSubscriber PreUpdate Error Bug? Created: 06/Oct/13  Updated: 17/Oct/13

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

Type: Bug Priority: Major
Reporter: Nelson Ford Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm


 Description   

Should this:

public function preUpdate(PreUpdateEventArgs $eventArgs)
{
    $entity = $eventArgs->getEntity();
    $em = $eventArgs->getEntityManager();
    $uow = $em->getUnitOfWork();

    if ($entity instanceof User) {
        if ($eventArgs->hasChangedField('finalStatus')) {
            $entity->setFinalStatusDate(new \DateTime('now'));
            $uow->recomputeSingleEntityChangeSet(
                $em->getClassMetadata("MyAdminBundle:User"),
                $entity
            );
        }
        if ($eventArgs->hasChangedField('membershipCode')) {
            $entity->setMembershipCodeDate(new \DateTime('now'));
            $uow->recomputeSingleEntityChangeSet(
                $em->getClassMetadata("MyAdminBundle:User"),
                $entity
            );
        }
    }
}

...result in this?

Catchable Fatal Error: Argument 3 passed to Doctrine\ORM\Event\PreUpdateEventArgs::__construct() must be an array, null given, called in /var/www/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php on line 995 and defined in /var/www/vendor/doctrine/orm/lib/Doctrine/ORM/Event/PreUpdateEventArgs.php line 47

I'm just setting a time stamp for two updated values. Dumping the 3rd argument in PreUpdateEventArgs.php on line 47 reveals an array of changes. I'm not sure if this is a bug or if I'm performing this simple operation incorrectly.



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

Can you write an integration test around it? Looks like the changeset is removed in a particular edge case, but it's hard to figure it out without a test.





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

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

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


 Description   

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

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

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






[DDC-2704] When using Discriminator EntityManager#merge fails Created: 25/Sep/13  Updated: 25/Sep/13

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

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


 Description   

I have the following hierarchy:

  • AgentConfig has relation ManyToOne with AgentTask.
  • AgentTask has DiscriminatorColumn & DiscriminatorMap assigned to it.
  • AgentTask has relation ManyToOne with AgentTaskConfig.

I believe the problem is because of the following:

UnitOfWork#doMerge has the tries to get properties the following way:

// Merge state of $entity into existing (managed) entity
foreach ($class->reflClass->getProperties() as $prop) {

This obviously doesn't get the parent class (AgentTask) properties.

Later on UnitOfWork fails on line:

$prevClass->reflFields[$assocField]->getValue($prevManagedCopy)->add($managedCopy);

because $prevManagedCopy doesn't have properties set from entity.

My proposal is to get the properties the following way:

$properties = $class->reflClass->getProperties();
$parent = $class->reflClass;
while (($parent = $parent->getParentClass()) != null) {
    $properties = array_merge($parent->getProperties(), $properties);
}

// Merge state of $entity into existing (managed) entity
foreach ($properties as $prop) {





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

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

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

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



 Description   

The test suite is trying to run the command

DROP DATABASE doctrine_tests

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

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





[DDC-2690] Doctrine ORM test suite failing on PostgresSQL Created: 19/Sep/13  Updated: 01/Oct/13

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

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

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



 Description   

This issue is related to: http://www.doctrine-project.org/jira/browse/DDC-2689

PHPUnit 3.7.27 by Sebastian Bergmann.

Configuration read from C:\inetpub\symfony23\vendor\doctrine\orm\postgres.phpunit.xml

......................SSSSSS.................................   61 / 2074 (  2%)
.............................................................  122 / 2074 (  5%)
.....................................................S.......  183 / 2074 (  8%)
.............................................................  244 / 2074 ( 11%)
.............................................................  305 / 2074 ( 14%)
.............................................................  366 / 2074 ( 17%)
.............................................................  427 / 2074 ( 20%)
.............................................E...............  488 / 2074 ( 23%)
.............................................................  549 / 2074 ( 26%)
.............................................................  610 / 2074 ( 29%)
..SSSS..................................................S....  671 / 2074 ( 32%)
.............................................................  732 / 2074 ( 35%)
...........................S................................S  793 / 2074 ( 38%)
.............................................................  854 / 2074 ( 41%)
.....S..SS.................................S.................  915 / 2074 ( 44%)
.............................................................  976 / 2074 ( 47%)
............................................................. 1037 / 2074 ( 50%)
............................................................. 1098 / 2074 ( 52%)
............................................................. 1159 / 2074 ( 55%)
.................................................S........... 1220 / 2074 ( 58%)
..................................S.......................... 1281 / 2074 ( 61%)
............................................................. 1342 / 2074 ( 64%)
............................................................. 1403 / 2074 ( 67%)
............................................................. 1464 / 2074 ( 70%)
............................................................. 1525 / 2074 ( 73%)
............................................................. 1586 / 2074 ( 76%)
............................................................. 1647 / 2074 ( 79%)
............................................................. 1708 / 2074 ( 82%)
............................................................. 1769 / 2074 ( 85%)
............................................................. 1830 / 2074 ( 88%)
............................................................. 1891 / 2074 ( 91%)
...................................................S......... 1952 / 2074 ( 94%)
....S...............................S........................ 2013 / 2074 ( 97%)
..................................

Time: 42.33 seconds, Memory: 83.50Mb

There was 1 error:

1) Doctrine\Tests\ORM\Functional\ProxiesLikeEntitiesTest::testPersistUpdate
Exception: [Doctrine\Common\Proxy\Exception\OutOfBoundsException] Missing value for primary key id on Doctrine\Tests\Models\CMS\CmsUser

With queries:
7. SQL: '"COMMIT"' Params: 
6. SQL: 'INSERT INTO cms_users (id, status, username, name, email_id) VALUES (?, ?, ?, ?, ?)' Params: '385', '', 'ocramius', 'Marco', ''
5. SQL: '"START TRANSACTION"' Params: 
4. SQL: 'SELECT NEXTVAL('cms_users_id_seq')' Params: 
3. SQL: 'CREATE TABLE cms_users (id INT NOT NULL, email_id INT DEFAULT NULL, status VARCHAR(50) DEFAULT NULL, username VARCHAR(255) NOT NULL, name VARCHAR(255) NOT NULL, PRIMARY KEY(id))' Params: 
2. SQL: 'SHOW search_path' Params: 

Trace:
C:\inetpub\symfony23\vendor\doctrine\common\lib\Doctrine\Common\Proxy\AbstractProxyFactory.php:125
C:\inetpub\symfony23\vendor\doctrine\orm\tests\Doctrine\Tests\ORM\Functional\ProxiesLikeEntitiesTest.php:51
C:\inetpub\symfony23\vendor\phpunit\phpunit\PHPUnit\Framework\TestCase.php:983
C:\inetpub\symfony23\vendor\phpunit\phpunit\PHPUnit\Framework\TestCase.php:838
C:\inetpub\symfony23\vendor\phpunit\phpunit\PHPUnit\Framework\TestResult.php:648
C:\inetpub\symfony23\vendor\phpunit\phpunit\PHPUnit\Framework\TestCase.php:783
C:\inetpub\symfony23\vendor\phpunit\phpunit\PHPUnit\Framework\TestSuite.php:775
C:\inetpub\symfony23\vendor\phpunit\phpunit\PHPUnit\Framework\TestSuite.php:745
C:\inetpub\symfony23\vendor\phpunit\phpunit\PHPUnit\Framework\TestSuite.php:705
C:\inetpub\symfony23\vendor\phpunit\phpunit\PHPUnit\TextUI\TestRunner.php:349
C:\inetpub\symfony23\vendor\phpunit\phpunit\PHPUnit\TextUI\Command.php:176
C:\inetpub\symfony23\vendor\phpunit\phpunit\PHPUnit\TextUI\Command.php:129
C:\inetpub\symfony23\vendor\phpunit\phpunit\phpunit.php:46


C:\inetpub\symfony23\vendor\doctrine\orm\tests\Doctrine\Tests\OrmFunctionalTestCase.php:477
C:\inetpub\symfony23\vendor\doctrine\common\lib\Doctrine\Common\Proxy\AbstractProxyFactory.php:125
C:\inetpub\symfony23\vendor\doctrine\orm\tests\Doctrine\Tests\ORM\Functional\ProxiesLikeEntitiesTest.php:51

Caused by
Doctrine\Common\Proxy\Exception\OutOfBoundsException: Missing value for primary key id on Doctrine\Tests\Models\CMS\CmsUser

C:\inetpub\symfony23\vendor\doctrine\common\lib\Doctrine\Common\Proxy\Exception\OutOfBoundsException.php:41
C:\inetpub\symfony23\vendor\doctrine\common\lib\Doctrine\Common\Proxy\AbstractProxyFactory.php:125
C:\inetpub\symfony23\vendor\doctrine\orm\tests\Doctrine\Tests\ORM\Functional\ProxiesLikeEntitiesTest.php:51

FAILURES!
Tests: 2047, Assertions: 7055, Errors: 1, Skipped: 23.



 Comments   
Comment by Flip [ 30/Sep/13 ]

How can this possibly pass on the travis-ci builds ?? Maybe this is an indication that something is wrong with the travis setup.

This is the setup/input: https://github.com/doctrine/doctrine2/blob/master/tests/Doctrine/Tests/ORM/Functional/ProxiesLikeEntitiesTest.php#L51

This is where execution fails: https://github.com/doctrine/common/blob/master/lib/Doctrine/Common/Proxy/AbstractProxyFactory.php#L125

Comment by Flip [ 01/Oct/13 ]

This is a related PR https://github.com/doctrine/common/pull/298





[DDC-2689] Doctrine ORM test suite failing on MySQL Created: 19/Sep/13  Updated: 30/Sep/13

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

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

Windows 7 Professional 64 bits
PHP 5.4.11 (cli) (built: Jan 16 2013 20:26:26)
Doctrine dev-master from 18-9-2013
mysql-5.6.13-winx64
Commit for doctrine/common d9dea98243c733ff589aab10e321de4f14a63ab4



 Description   

This issue is related to http://www.doctrine-project.org/jira/browse/DDC-2690

PHPUnit 3.7.27 by Sebastian Bergmann.

Configuration read from C:\inetpub\symfony23\vendor\doctrine\orm\mysql.phpunit.xml

......................SSSSSS.................................   61 / 2074 (  2%)
.............................................................  122 / 2074 (  5%)
.....................................................S.......  183 / 2074 (  8%)
.............................................................  244 / 2074 ( 11%)
.............................................................  305 / 2074 ( 14%)
.............................................................  366 / 2074 ( 17%)
.............................................................  427 / 2074 ( 20%)
............................................SE...............  488 / 2074 ( 23%)
.............................................................  549 / 2074 ( 26%)
.............................................................  610 / 2074 ( 29%)
......SSSSSS.............S..............................S...S  671 / 2074 ( 32%)
...........S..............................S................E.  732 / 2074 ( 35%)
...........................S.................................  793 / 2074 ( 38%)
.............................................................  854 / 2074 ( 41%)
.....S..SS...................................................  915 / 2074 ( 44%)
.............................................................  976 / 2074 ( 47%)
............................................................. 1037 / 2074 ( 50%)
............................................................. 1098 / 2074 ( 52%)
............................................................. 1159 / 2074 ( 55%)
.................................................S........... 1220 / 2074 ( 58%)
..................................S.......................... 1281 / 2074 ( 61%)
............................................................. 1342 / 2074 ( 64%)
............................................................. 1403 / 2074 ( 67%)
............................................................. 1464 / 2074 ( 70%)
............................................................. 1525 / 2074 ( 73%)
............................................................. 1586 / 2074 ( 76%)
............................................................. 1647 / 2074 ( 79%)
............................................................. 1708 / 2074 ( 82%)
............................................................. 1769 / 2074 ( 85%)
............................................................. 1830 / 2074 ( 88%)
............................................................. 1891 / 2074 ( 91%)
...................................................S......... 1952 / 2074 ( 94%)
....S...............................S........................ 2013 / 2074 ( 97%)
..................................

Time: 39.42 seconds, Memory: 79.50Mb

There were 2 errors:

1) Doctrine\Tests\ORM\Functional\ProxiesLikeEntitiesTest::testPersistUpdate
Exception: [Doctrine\Common\Proxy\Exception\OutOfBoundsException] Missing value for primary key id on Doctrine\Tests\Models\CMS\CmsUser

With queries:
5. SQL: '"COMMIT"' Params: 
4. SQL: 'INSERT INTO cms_users (status, username, name, email_id) VALUES (?, ?, ?, ?)' Params: '', 'ocramius', 'Marco', ''
3. SQL: '"START TRANSACTION"' Params: 
2. SQL: 'CREATE TABLE cms_users (id INT AUTO_INCREMENT NOT NULL, email_id INT DEFAULT NULL, status VARCHAR(50) DEFAULT NULL, username VARCHAR(255) NOT NULL, name VARCHAR(255) NOT NULL, UNIQUE INDEX UNIQ_3AF03EC5F85E0677 (username), UNIQUE INDEX UNIQ_3AF03EC5A832C1C9 (email_id), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB' Params: 

Trace:
C:\inetpub\symfony23\vendor\doctrine\common\lib\Doctrine\Common\Proxy\AbstractProxyFactory.php:125
C:\inetpub\symfony23\vendor\doctrine\orm\tests\Doctrine\Tests\ORM\Functional\ProxiesLikeEntitiesTest.php:51
C:\inetpub\symfony23\vendor\phpunit\phpunit\PHPUnit\Framework\TestCase.php:983
C:\inetpub\symfony23\vendor\phpunit\phpunit\PHPUnit\Framework\TestCase.php:838
C:\inetpub\symfony23\vendor\phpunit\phpunit\PHPUnit\Framework\TestResult.php:648
C:\inetpub\symfony23\vendor\phpunit\phpunit\PHPUnit\Framework\TestCase.php:783
C:\inetpub\symfony23\vendor\phpunit\phpunit\PHPUnit\Framework\TestSuite.php:775
C:\inetpub\symfony23\vendor\phpunit\phpunit\PHPUnit\Framework\TestSuite.php:745
C:\inetpub\symfony23\vendor\phpunit\phpunit\PHPUnit\Framework\TestSuite.php:705
C:\inetpub\symfony23\vendor\phpunit\phpunit\PHPUnit\TextUI\TestRunner.php:349
C:\inetpub\symfony23\vendor\phpunit\phpunit\PHPUnit\TextUI\Command.php:176
C:\inetpub\symfony23\vendor\phpunit\phpunit\PHPUnit\TextUI\Command.php:129
C:\inetpub\symfony23\vendor\phpunit\phpunit\phpunit.php:46


C:\inetpub\symfony23\vendor\doctrine\orm\tests\Doctrine\Tests\OrmFunctionalTestCase.php:477
C:\inetpub\symfony23\vendor\doctrine\common\lib\Doctrine\Common\Proxy\AbstractProxyFactory.php:125
C:\inetpub\symfony23\vendor\doctrine\orm\tests\Doctrine\Tests\ORM\Functional\ProxiesLikeEntitiesTest.php:51

Caused by
Doctrine\Common\Proxy\Exception\OutOfBoundsException: Missing value for primary key id on Doctrine\Tests\Models\CMS\CmsUser

C:\inetpub\symfony23\vendor\doctrine\common\lib\Doctrine\Common\Proxy\Exception\OutOfBoundsException.php:41
C:\inetpub\symfony23\vendor\doctrine\common\lib\Doctrine\Common\Proxy\AbstractProxyFactory.php:125
C:\inetpub\symfony23\vendor\doctrine\orm\tests\Doctrine\Tests\ORM\Functional\ProxiesLikeEntitiesTest.php:51

2) Doctrine\Tests\ORM\Functional\Ticket\DDC1514Test::testIssue
Exception: [PHPUnit_Framework_Error_Notice] Trying to get property of non-object

With queries:
14. SQL: '"COMMIT"' Params: 
13. SQL: 'INSERT INTO DDC1514EntityB (entityAFrom_id, entityATo_id) VALUES (?, ?)' Params: '2', '1'
12. SQL: 'INSERT INTO DDC1514EntityB (entityAFrom_id, entityATo_id) VALUES (?, ?)' Params: '1', '2'
11. SQL: 'INSERT INTO DDC1514EntityA (title, entityC_id) VALUES (?, ?)' Params: 'bar', '1'
10. SQL: 'INSERT INTO DDC1514EntityA (title, entityC_id) VALUES (?, ?)' Params: 'foo', ''
9. SQL: 'INSERT INTO DDC1514EntityC (title) VALUES (?)' Params: 'baz'
8. SQL: '"START TRANSACTION"' Params: 
7. SQL: 'ALTER TABLE DDC1514EntityB ADD CONSTRAINT FK_B7F2235B64DC3373 FOREIGN KEY (entityATo_id) REFERENCES DDC1514EntityA (id)' Params: 
6. SQL: 'ALTER TABLE DDC1514EntityB ADD CONSTRAINT FK_B7F2235B4D8FF1AD FOREIGN KEY (entityAFrom_id) REFERENCES DDC1514EntityA (id)' Params: 
5. SQL: 'ALTER TABLE DDC1514EntityA ADD CONSTRAINT FK_2EFB72E12014DB0 FOREIGN KEY (entityC_id) REFERENCES DDC1514EntityC (id)' Params: 
4. SQL: 'CREATE TABLE DDC1514EntityC (id INT AUTO_INCREMENT NOT NULL, title VARCHAR(255) NOT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB' Params: 
3. SQL: 'CREATE TABLE DDC1514EntityB (id INT AUTO_INCREMENT NOT NULL, entityAFrom_id INT DEFAULT NULL, entityATo_id INT DEFAULT NULL, INDEX IDX_B7F2235B4D8FF1AD (entityAFrom_id), INDEX IDX_B7F2235B64DC3373 (entityATo_id), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB' Params: 
2. SQL: 'CREATE TABLE DDC1514EntityA (id INT AUTO_INCREMENT NOT NULL, title VARCHAR(255) NOT NULL, entityC_id INT DEFAULT NULL, INDEX IDX_2EFB72E12014DB0 (entityC_id), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB' Params: 

Trace:
C:\inetpub\symfony23\vendor\doctrine\orm\tests\Doctrine\Tests\ORM\Functional\Ticket\DDC1514Test.php:60
C:\inetpub\symfony23\vendor\phpunit\phpunit\PHPUnit\Framework\TestCase.php:983
C:\inetpub\symfony23\vendor\phpunit\phpunit\PHPUnit\Framework\TestCase.php:838
C:\inetpub\symfony23\vendor\phpunit\phpunit\PHPUnit\Framework\TestResult.php:648
C:\inetpub\symfony23\vendor\phpunit\phpunit\PHPUnit\Framework\TestCase.php:783
C:\inetpub\symfony23\vendor\phpunit\phpunit\PHPUnit\Framework\TestSuite.php:775
C:\inetpub\symfony23\vendor\phpunit\phpunit\PHPUnit\Framework\TestSuite.php:745
C:\inetpub\symfony23\vendor\phpunit\phpunit\PHPUnit\Framework\TestSuite.php:705
C:\inetpub\symfony23\vendor\phpunit\phpunit\PHPUnit\TextUI\TestRunner.php:349
C:\inetpub\symfony23\vendor\phpunit\phpunit\PHPUnit\TextUI\Command.php:176
C:\inetpub\symfony23\vendor\phpunit\phpunit\PHPUnit\TextUI\Command.php:129
C:\inetpub\symfony23\vendor\phpunit\phpunit\phpunit.php:46


C:\inetpub\symfony23\vendor\doctrine\orm\tests\Doctrine\Tests\OrmFunctionalTestCase.php:477
C:\inetpub\symfony23\vendor\doctrine\orm\tests\Doctrine\Tests\ORM\Functional\Ticket\DDC1514Test.php:60

Caused by
Trying to get property of non-object

C:\inetpub\symfony23\vendor\doctrine\orm\tests\Doctrine\Tests\ORM\Functional\Ticket\DDC1514Test.php:60

FAILURES!
Tests: 2047, Assertions: 7035, Errors: 2, Skipped: 28.



 Comments   
Comment by Flip [ 30/Sep/13 ]

First error is the same as this one: http://www.doctrine-project.org/jira/browse/DDC-2690#comment-21186

Second error has a bugfix here: https://github.com/doctrine/doctrine2/pull/805





[DDC-2701] Collections in originalEntityData gets over written Created: 23/Sep/13  Updated: 23/Sep/13

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

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


 Description   

I was trying to use the UnitOfWork::getOriginalEntityData method and i noticed that if there is a collection in that object, it changes in the uow original datas when i change it on my original object

In my case the collection is ManyToMany unidirectional

I think this happens because both the uow and the object work with the same reference to the collection
maybe adding a clone of the collection instead of the real one, i don't know if it is possible

Thank you for taking a look and for Doctrine!

Tom






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

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

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

All



 Description   

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

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

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

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

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



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

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

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

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

Comment by Austin Morris [ 06/Dec/13 ]

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

Comment by Benjamin Eberlei [ 06/Dec/13 ]

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





[DDC-2695] Order by clause left in subquery when using MSSQL and Paginator Created: 20/Sep/13  Updated: 20/Sep/13

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

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

Windows, Microsoft SQL Server



 Description   

When using the Doctrine paginator and Fetch Join Collections = true and when the original query has an "ORDER BY" clause in it - the subquery created is something like "SELECT DISTINCT FROM (.... ORDER BY ....) as dctrn_result" - when using Microsoft SQL server having the "ORDER BY" clause in a subquery throws an error. This is a similar problem to http://doctrine-project.org/jira/browse/DDC-2282 but that was for the Count Walker - this is for the LimitSubqueryOutputWalker. The fix is the same.



 Comments   
Comment by Paul Mansell [ 20/Sep/13 ]

Problem still occurs in 2.4 - but different error message,

Query :

SELECT * FROM (SELECT DISTINCT id0, ROW_NUMBER() OVER (ORDER BY c1_.iccid ASC) AS doctrine_rownum FROM (SELECT w0_.id AS id0, w0_.batch_id AS batch_id1, c1_.id AS id2, c1_.iccid AS iccid3, c2_.id AS id4, c2_.msisdn AS msisdn5, c3_.id AS id6, c3_.name AS name7, c4_.id AS id8, c5_.id AS id9, c5_.name AS name10, w6_.id AS id11, w6_.created AS created12, w7_.id AS id13, w7_.ident AS ident14, w8_.id AS id15, w8_.ident AS ident16, c9_.id AS id17, c10_.id AS id18, c10_.contract_length AS contract_length19, c10_.rental AS rental20, w11_.id AS id21, w11_.ident AS ident22 FROM workflow_request w0_ WITH (NOLOCK) INNER JOIN core_sim c1_ ON w0_.sim = c1_.id LEFT JOIN core_connection c2_ ON c1_.active_connection_id = c2_.id INNER JOIN core_billing_account c3_ ON c1_.billing_account_id = c3_.id INNER JOIN core_mno_account c4_ ON c1_.mno_account_id = c4_.id INNER JOIN core_mno c5_ ON c4_.mno_id = c5_.id INNER JOIN workflow_request_log w6_ ON w0_.id = w6_.request INNER JOIN workflow_action w7_ ON w0_.action = w7_.id INNER JOIN workflow_request_status w8_ ON w0_.status = w8_.id INNER JOIN core_customer_solution c9_ ON w0_.customer_solution = c9_.id INNER JOIN core_customer_tariff c10_ ON c9_.customer_tariff_id = c10_.id INNER JOIN workflow_request_action w11_ ON w6_.request_action = w11_.id WHERE w7_.ident IN AND w8_.ident = ? AND w11_.ident = ?) dctrn_result) AS doctrine_tbl WHERE doctrine_rownum BETWEEN 1 AND 25' with params ["activate", "network", "approved"]

Error :

SQLSTATE[42000]: [Microsoft][SQL Server Native Client 11.0][SQL Server]The multi-part identifier "c1_.iccid" could not be bound.





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

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

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

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

 Description   

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

new Country(country, some_extra_stuff)

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






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

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

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

MSSQL 2008 R2



 Description   

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

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

The errors:

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

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



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

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

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

Comment by Flip [ 15/Jan/14 ]

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





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

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

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


 Description   

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

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

Ping Thomas RabaixGuilherme Blanco



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

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





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

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

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

Symfony2 With PHP 5.5 on Ubuntu 12.04 LTS using Apache 2


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

 Description   

I am getting this error:

 Notice: Undefined index: sourceToTargetKeyColumns

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

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

While the user data fixture looks like:

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

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

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

My Client.php entity:

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

My User.php entity:

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

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






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

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

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


 Description   

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






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

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

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


 Description   

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

The following problem occur:

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

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






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

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

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

PostgreSQL



 Description   

The summary pretty much sums it up.

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






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

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

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

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

 Description   

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

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

Message:

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



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

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

Comment by Doctrine Bot [ 15/Apr/14 ]

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





[DDC-2636] Handle SQLite with dot notation in @Table and @JoinTable Created: 27/Aug/13  Updated: 20/Dec/13

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

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


 Description   

When using SQLite and having dot notation in @Table or @JoinTable this is already handled in DBAL Schema and transformed to __. However it is not handled in ORM tables, so it breaks.



 Comments   
Comment by Michaël Perrin [ 20/Dec/13 ]

I opened a PR to solve this issue: https://github.com/doctrine/doctrine2/pull/881
This PR also adds better schema support.

If there are things I did the wrong way, any comment is welcome.





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

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

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


 Description   

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






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

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

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


 Description   

Hello,

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

In the SqlWalker, the methods 'generateFilterConditionSQL' says :

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

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

Thanks a lot



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

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





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

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

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


 Description   

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



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

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

Comment by Benjamin Eberlei [ 08/Sep/13 ]

Assigning Fabio





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

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

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

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


Attachments: PNG File thcontract.png    

 Description   

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

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

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

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

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

Thanks for your time and consideration.






pager produces wrong results on postgresql (DDC-1958)

[DDC-2593] Same bug occurs in MariaDB 5.5 Created: 06/Aug/13  Updated: 06/Aug/13

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

Type: Sub-task Priority: Major
Reporter: Bojidar Hristov Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

//if ($this->platform instanceof PostgreSqlPlatform)

{ //http://www.doctrine-project.org/jira/browse/DDC-1958 $this->getPostgresqlSql($AST, $sqlIdentifier, $innerSql, $sql); //}

That way it works for MariaDB too.






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

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

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


 Description   

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

Prerequisite:

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

How to Reproduce:

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

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

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






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

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

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





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

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

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


 Description   

Hi,

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

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

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

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

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

}

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

Let me know if you require more information

Thanks






[DDC-2535] [GH-712] Extra lazy get for inverse side of many-to-many Created: 01/Jul/13  Updated: 01/Jul/13

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

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


 Description   

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

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

Message:

This is the cange requested by @stof and @beberlei in PR #710. It implements an extra lazy get on the working side of the relationship. As mentioned in #710 the unit tests fails for reasons I don't quite understand. The error I get is:

```
1) Doctrine\Tests\ORM\Functional\ExtraLazyCollectionTest::testGetIndexByManyToMany
Exception: [PHPUnit_Framework_Error_Notice] Undefined index: joinColumns

Trace:
/home/sander/src/doctrine2/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php:1665
/home/sander/src/doctrine2/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php:1610
/home/sander/src/doctrine2/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php:1701
/home/sander/src/doctrine2/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php:1115
/home/sander/src/doctrine2/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php:746
/home/sander/src/doctrine2/lib/Doctrine/ORM/Persisters/ManyToManyPersister.php:55
/home/sander/src/doctrine2/lib/Doctrine/ORM/PersistentCollection.php:529
/home/sander/src/doctrine2/tests/Doctrine/Tests/ORM/Functional/ExtraLazyCollectionTest.php:578
```

If someone with a little more understanding of the Doctrine internals can help me fix this, then we could restore some of the functionality that PR #710 had to remove.






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

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

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

Windows 8



 Description   

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

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

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






[DDC-2516] Undefined offset in ObjectHydrator while working with iterableResult Created: 19/Jun/13  Updated: 01/Jul/13

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

Type: Bug Priority: Major
Reporter: Johanny Clerc-Renaud Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm
Environment:

using Symfony2



 Description   

Following this documentation page http://doctrine-orm.readthedocs.org/en/2.0.x/reference/batch-processing.html#iterating-large-results-for-data-processing I tried to create a batch process on 75k entities. But an error came in the ObjectHydrator on line 511 there's an Undefined offset. Now, i just use the SimpleObjectHydrator and it solve the problem. but i'm wondering if it's a real bug or just a miss use of Doctrine.
Reproduce this error could be hard so ask if you want me to give you more informations about it.



 Comments   
Comment by Benjamin Eberlei [ 30/Jun/13 ]

Can you provide more information? The stack trace of the error for example? The entity you try to process+mapping and the DQL query. The current information is not enough to reproduce this error.

Comment by Johanny Clerc-Renaud [ 01/Jul/13 ]

Hello Benjamin,

here is the Entity and with the corresponding Mapping :

Entity.php
    /**
     * @var string
     * @ORM\Id
     * @ORM\Column(name="id_source", type="string", length=32, nullable=false)
     */
    private $idSource;
    
    /**
     * @var string
     *
     * @ORM\Column(name="id_page", type="string", length=32, nullable=false)
     */
    private $idPage;

    /**
     * @var string
     *
     * @ORM\Column(name="url", type="string", length=500, nullable=true)
     */
    private $url;

    /**
     * @var float
     *
     * @ORM\Column(name="similitude", type="decimal", nullable=true)
     */
    private $similitude;

    /**
     * @var string
     *
     * @ORM\Column(name="alerte", type="string", length=512, nullable=true)
     */
    private $alerte;

The Entity have been generated by using this documentation page : http://symfony.com/doc/current/cookbook/doctrine/reverse_engineering.html

In this project I work with 2 databases, and one of it already exist.

Working with symfony I use the DQL Query obtain with those methods :

EntityRepository.php
    public function getAllUrl($limit)
    {
        $queryBuilder = $this->createQueryBuilder('s');

        $this->setStatsParameters($queryBuilder);

        $queryBuilder->setMaxResults($limit);
        
        return $queryBuilder->getQuery()
                            ->iterate();
    }

    private function setStatsParameters(\Doctrine\ORM\QueryBuilder $queryBuilder)
    {
        $queryBuilder->where('s.similitude > 1')
                     ->andWhere('s.url NOT LIKE :url')
                     ->setParameter('url', 'some_string%');
    }

And here is the stack trace, when the eror comes :

stackTrace.log
Exception trace:
 () at \path\to\project\vendor\doctrine\orm\lib\Doctrine\ORM\Internal\Hydration\ObjectHydrator.php:511
 Symfony\Component\Debug\ErrorHandler->handle() at \path\to\project\vendor\doctrine\orm\lib\Doctrine\ORM\Internal\Hydration\ObjectHydrator.php:511
 Doctrine\ORM\Internal\Hydration\ObjectHydrator->hydrateRowData() at \path\to\project\vendor\doctrine\orm\lib\Doctrine\ORM\Internal\Hydration\AbstractHydrator.php:136
 Doctrine\ORM\Internal\Hydration\AbstractHydrator->hydrateRow() at \path\to\project\vendor\doctrine\orm\lib\Doctrine\ORM\Internal\Hydration\IterableResult.php:76
 Doctrine\ORM\Internal\Hydration\IterableResult->next() at \path\to\project\src\Compilatio\RecolteurBundle\Command\RecolteurCommand.php:42
 CompanyName\RecolteurBundle\Command\RecolteurCommand->execute() at \path\to\project\vendor\symfony\symfony\src\Symfony\Component\Console\Command\Command.php:244
 Symfony\Component\Console\Command\Command->run() at \path\to\project\vendor\symfony\symfony\src\Symfony\Component\Console\Application.php:906
 Symfony\Component\Console\Application->doRunCommand() at \path\to\project\vendor\symfony\symfony\src\Symfony\Component\Console\Application.php:191
 Symfony\Component\Console\Application->doRun() at \path\to\project\vendor\symfony\symfony\src\Symfony\Bundle\FrameworkBundle\Console\Application.php:80
 Symfony\Bundle\FrameworkBundle\Console\Application->doRun() at \path\to\project\vendor\symfony\symfony\src\Symfony\Component\Console\Application.php:121
 Symfony\Component\Console\Application->run() at \path\to\project\app\console:27

You can also see here the source code that lead to this error :

command.php
  $sources = $urlLoader->getAllSources(50000);

  $number = 0;
  while (($source = $sources->next()) !== false) {
      $number++;
  }
  echo 'Nombre de sources : ' . $number;

There are all the information you ask, if you need more just tell me. For now i can see how to be more specific. Remember that if I switch the hydrator to Query::HYDRATE_SIMPLEOBJECT it solve the bug.

I hope all of this will help.

Regards,

Johanny





[DDC-2504] [GH-696] extra lazy joined test Created: 14/Jun/13  Updated: 14/Jun/13

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

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


 Description   

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

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

Message:

Hi,

This is just a bug report, not an actual PR, you don't have to merge.

When you have a JOINED inheritance, and you have another class, which is related to the parent class of the inheritance, and you only have an association for one of the child classes, EXTRA_LAZY fetch mode creates a fatal error, because it is not joining the parent table to the count query.

There are many ways around this fortunately, but I thought I should report it anyway.






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

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

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

Symfony2 project, Doctrine ORM with MySQL database backend


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

 Description   

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

DQL:
SELECT partial v.

{id, setupDate, flipDate}

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

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



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

Could you please provide your entities ?

Thanks

Comment by Radoslaw Ejsmont [ 11/Jun/13 ]

This is the whole class hierarchy.

Comment by Radoslaw Ejsmont [ 11/Jun/13 ]

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

Right now the following query:

SELECT e, partial p.

{id}

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

would result in the following SQL:

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

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

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

Best,

R.

Comment by Radoslaw Ejsmont [ 11/Jun/13 ]

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





[DDC-2477] [GH-681] Sequence generator fix Created: 29/May/13  Updated: 29/May/13

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

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


 Description   

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

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

Message:

$this->_sequenceName=$em->getClassMetadata(get_class($entity))->sequenceGeneratorDefinition['sequenceName'];

The sequence generator does not read the class metadata, so if there is table remapping via event listeners, any new entity won't have the appropriate changes in table names.

This pull request adds a remap the Sequence Generator to read the class metadata to determine the sequence name if there is an entity passed to the generate function.

Tests: 1854, Assertions: 6224, Skipped: 96.






[DDC-2452] Additional `WITH` condition in joins between JTI roots cause invalid SQL to be produced Created: 16/May/13  Updated: 27/Mar/14

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

Type: Bug Priority: Major
Reporter: Marco Pivetta Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: dql, sql-walker
Environment:

irrelevant



 Description   

Given a simple Joined Table Inheritance like following:

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

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

Following DQL

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

Will produce broken SQL:

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

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

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

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

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






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

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

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


 Description   

Scenario:

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

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

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

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

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

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

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

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

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

Code example:

<?php

// Create some entities

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

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

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

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

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

// Now let's try modifying the book

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

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

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

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



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

Hi Simon,

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

Cheers

Comment by Benjamin Eberlei [ 09/May/13 ]

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





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

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

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

Attachments: Zip Archive Testcase.zip    

 Description   

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

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

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

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

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



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

Hi Quintenvk

Could you please try to write a failing test case ?

Thanks

Comment by Quintenvk [ 18/Apr/13 ]

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

Apart from that all should run well immediately.

Comment by Quintenvk [ 18/Apr/13 ]

Fabio,

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

Thanks,
Quinten

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

Thanks Quintenvk,

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

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

Also the INDEX BY documentations seems wrong to me.

The given DQL :

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

Show the following result :

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

Which IMHO represents another DQL, something like :

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

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

Thanks,
Quinten

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

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

Something like :

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

or something like :

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

And than :

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

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

Thanks for your help though!





[DDC-2390] Remove Parser and SQLWalker dependency on Query Created: 04/Apr/13  Updated: 07/Sep/13

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

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


 Description   

Query is too powerful to be available in Parser and SQLWalker, because it may lead to accessing data that changes on subsequent runs of a query that is cached.

Idea is to introduce a MetadataBag that contains only the values that are allowed to be accessed.






[DDC-2364] [GH-625] [DDC-2363] Duplicated record with orphanRemoval and proxy Created: 22/Mar/13  Updated: 27/Mar/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: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates DDC-2363 Duplicated record with orphanRemoval ... Awaiting Feedback

 Description   

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

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

Message:

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






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

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

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


 Description   

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

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

Message:

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

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






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

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

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


 Description   

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

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



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

onFlush and postFlush should be propagated to entity listeners as well





[DDC-2352] [GH-615] Update SqlWalker.php Created: 15/Mar/13  Updated: 15/Mar/13

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

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


 Description   

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

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

Message:

Always be sure that only a-z characters are used for table alias, otherwise use generic "t" for "table"






[DDC-2339] [GH-605] DDC-2338 Added failing test for composite foreign key persistance Created: 07/Mar/13  Updated: 09/May/13

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

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


 Description   

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

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

Message:

I've added this test regarding ticket DDC-2338



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

This is documented behavior and would just be an improvement





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

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

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

Attachments: Text File persister.patch    

 Description   

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






[DDC-2316] [GH-588] ClassMetadataInfo: use reflection for creating new instance (on PHP >=5.4) Created: 23/Feb/13  Updated: 04/May/13

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


 Description   

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

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

Message:

On PHP >=5.4, use proper way for instantiating classes without invoking constructor.



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

Scheduling this for 3.0, when we move to php 5.4 or higher requirement





[DDC-2290] Infer custom Types from the field for query parameters Created: 08/Feb/13  Updated: 28/Jan/14

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

Type: Improvement Priority: Major
Reporter: Matthieu Napoli Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 3
Labels: None


 Description   

When using a mapping Type that declares convertToDatabaseValue, the method is not always called in queries.

Example:

SELECT ... WHERE entity.field = ?1

(with entity.field being of custom type 'the_mapping_type')

Type::convertToDatabaseValue() is correctly called when using:

$query->setParameter('1', 'foo', 'the_mapping_type');

But it is not called when using:

$query->setParameter('1', 'foo');

which gives a query that returns invalid results.

Like other mapping types in this situation, there is no reason the type is not inferred automatically from the field.

I have written a failing test case in Doctrine\Tests\ORM\Functional\TypeValueSqlTest:

    public function testQueryParameterWithoutType()
    {
        $entity = new CustomTypeUpperCase();
        $entity->lowerCaseString = 'foo';

        $this->_em->persist($entity);
        $this->_em->flush();

        $id = $entity->id;

        $this->_em->clear();

        $query = $this->_em->createQuery('SELECT c.id from Doctrine\Tests\Models\CustomType\CustomTypeUpperCase c where c.lowerCaseString = ?1');
        $query->setParameter('1', 'foo');

        $result = $query->getResult();

        $this->assertCount(1, $result);
        $this->assertEquals($id, $result[0]['id']);
    }


 Comments   
Comment by Matthieu Napoli [ 08/Feb/13 ]

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

Comment by Matthieu Napoli [ 08/Feb/13 ]

The test is in this branch: https://github.com/myc-sense/doctrine2/tree/DDC-2290

Comment by Matthieu Napoli [ 29/Oct/13 ]

The organization name has changed so the previous URL is a 404.

Here is the branch containing the failing testcase: https://github.com/myclabs/doctrine2/tree/DDC-2290

Comment by Benjamin Morel [ 28/Jan/14 ]

Any news on this one? Also, I just noticed that it does not cover the original problem I've reported in DDC-2224: I was specifically talking about convertToDatabaseValueSQL() and not convertToDatabaseValue().
My problem is that even when passing the third parameter $type, it does not use the conversion function from convertToDatabaseValueSQL().

Should we reopen DDC-2224?





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

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

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

OSX



 Description   

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

This is what I am doing:

$parts = $qb->getDQLParts();

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

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


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

I wrote a test showing the issue.

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

Comment by Benjamin Eberlei [ 04/May/13 ]

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





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

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

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


 Description   

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



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

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





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

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

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


 Description   

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

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

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

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






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

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

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

(not affected by this bug)



 Description   

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

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

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






[DDC-2217] Return a lazy collection from PersistentCollection::match($criteria) Created: 31/Dec/12  Updated: 12/Oct/13

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

Type: Improvement Priority: Major
Reporter: Christophe Coevoet Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 8
Labels: collection


 Description   

In 2.3, PersistentCollection::match() has been implemented by doing the query directly. But sometimes, the only meaningful information about the matched collection would be its length. In this case, it would be great to handle it in the same way than extra lazy collections are handled: the matched collection would be initialized lazily, and could do the count in an extra lazy way (if the original collection was extra lazy).
This would of course not change anything in the case where the original collection was already initialized.



 Comments   
Comment by Maciej Klemarczyk [ 20/Sep/13 ]

It will be very usefull, for example to compute count of rows.

In 300 rows, you do not want fetch data from database to compute length of this.

Function matching(Criteria $criteria) fetch too many data for just compute count of rows.

Comment by Christophe Coevoet [ 21/Sep/13 ]

This is exactly the use case I add in mind actually

Comment by Michaël Gallego [ 12/Oct/13 ]

+1 on this one! This is absolutely needed when we use the Selectable API as the abstraction for some libraries.





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

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

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


 Description   

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

Is there an issue for that?



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

Changesets of collections are computed separately from those of entities.

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

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

Comment by Benjamin Eberlei [ 06/Jan/13 ]

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

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

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

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





[DDC-2213] Paginator does not work with composite primary key entity Created: 25/Dec/12  Updated: 15/Aug/13

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

Type: New Feature Priority: Major
Reporter: Stanislav Anisimov Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 3
Labels: composed, key, paginator
Environment:

php 5.4



 Description   

Paginator does not work with composed primary key.

"Single id is not allowed on composite primary key in entity" exception is thrown here
https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Tools/Pagination/WhereInWalker.php#L90

Only first column values are fetched while retrieving primary keys here
https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Tools/Pagination/Paginator.php#L173



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

Limitation was confused by issue reporter and considered bug

Comment by Austin Morris [ 15/Aug/13 ]

I'd like to add some additional information because the title and description are misleading.

Paginator does work with composite primary key entities. You just cannot use the Paginator when your query does a fetch join with a collection (a one-to-many or many-to-many association). See the documentation for a brief description:
http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/tutorials/pagination.html

In order to use Paginator with a composite primary key entity, you need to instantiate the Paginator with the $fetchJoinCollection flag set to false (it defaults to true). Now, pagination will skip the WhereInWalker which throws an exception when using a composite primary key. Fetch joins with entities (one-to-one or many-to-one) will still work. You can even use a regular join with a collection.

The only "problem" is when your Paginator query calls for a fetch join to a collection. The work around for this is to use a regular join as mentioned above. The drawback is that your paginated entities will not be hydrated with the collection. The collection will have to be lazy-loaded when called upon.





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

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

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

Attachments: File DDC2190Test.php    

 Description   

The following code works:

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

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

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


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

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

Comment by Benjamin Eberlei [ 09/May/13 ]

Attaching failing testcase.

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

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





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

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

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


 Description   

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

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

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

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

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

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



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

An additional observation:

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

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





[DDC-2170] Decorator base classes for query related objects Created: 26/Nov/12  Updated: 26/Nov/12

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

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


 Description   

Doctrine\ORM\Query should not be directly extendable but it would be nice to decorate query objects and add additional methods. Use cases are e.g. doctrine-fun (see https://github.com/lstrojny/doctrine-fun/blob/master/src/Doctrine/Fun/Query.php) or even cases where users want to add domain specific methods. As Doctrine\ORM\Query is final it is not so easy to decorate correctly. I would propose:

  • Add a new interfaces: Doctrine\ORM\QueryInterface that provides a contract for all methods Doctrine\ORM\Query provides
  • Add a decorator base class Doctrine\ORM\QueryDecorator as an extension point
  • Some for NativeQuery and QueryBuilder


 Comments   
Comment by Lars Strojny [ 26/Nov/12 ]

Related:





[DDC-2167] [GH-522] [DDC-2166] Refactor identity hash generation Created: 25/Nov/12  Updated: 01/May/13

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

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


 Description   

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

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

Message:

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






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

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

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


 Description   

There are currently some drawbacks with identifier hashing:

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

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

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






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

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

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


 Description   

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






[DDC-2141] Query should not be final Created: 13/Nov/12  Updated: 13/Nov/12

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

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

All



 Description   

The Query class should not be marked final as this makes it impossible to Mock it.






[DDC-2133] Issue with Query::iterate and query mixed results Created: 09/Nov/12  Updated: 01/May/13

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

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

Issue Links:
Duplicate
is duplicated by DDC-1314 DQL permits partial select using SQL Resolved

 Description   

Consider this code:

$dql = "
    SELECT Page, Product.name
    FROM Dlayer\\Entity\\Page Page
    INNER JOIN Page.Product Product
    ";
$q = ($em->createQuery($dql));
foreach ($q->iterate() as $entry) {
  $page = $entry[0][0];
  $name = $entry[0]['name'];
}

This results with undefined index: 'name' for the second entry.

First result keys are (notice just one array element with index 0):

0
array(2) {
  [0] =>
  int(0)
  [1] =>
  string(4) "name"
} 

but all others are different (notice two array elements with index 0 and the other one that is incrementing):

the second one:
0
array(1) {
  [0] =>
  int(0)
}
1
array(1) {
  [0] =>
  string(4) "name"
} 
the third one:
0
array(1) {
  [0] =>
  int(0)
}
2
array(1) {
  [0] =>
  string(4) "name"
} 

What's wrong with this approach? Is it a bug or mixed results should not be used with the iterate method?



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

This is a known issue that we don't have found a BC fix for and as I understand Guilherme Blanco requires considerable refactoring.





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

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

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

Attachments: File dump.sql     File SSWTestBundle.rar    

 Description   

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

I had found a solution.

In Doctrine\ORM\Tools\SchemaTool
...

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

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

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

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

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

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

public function walkSelectExpression($selectExpression)
...

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

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

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

Sorry for my english.



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

Hi SergSW

Could you try to write a failing test case ?

Thanks

Comment by SergSW [ 06/Nov/12 ]

SSW/TestBundle with the problem

Comment by SergSW [ 07/Nov/12 ]

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

Comment by SergSW [ 07/Nov/12 ]

MySQL dump

Comment by Benjamin Eberlei [ 12/Nov/12 ]

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

Comment by Benjamin Eberlei [ 24/Dec/12 ]

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

Comment by Marco Pivetta [ 23/Jan/13 ]

SergSW news?





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

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

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

This is a new feature, not a bug



 Description   

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

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






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

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

Type: Improvement Priority: Major
Reporter: Martin Hasoň Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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






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

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

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

ubuntu 1204 php5.3.8



 Description   

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

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






[DDC-2093] Doctrine Criteria does not support sorting by relationed field Created: 20/Oct/12  Updated: 06/Jan/13

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


 Description   
// Here I call Criteria filter
public function getWalletsActive() {
	$criteria = Criteria::create()
		->where(Criteria::expr()->eq("isRemoved", "0"))
		->orderBy(array("currency.id" => "ASC"));
	return $this->wallets->matching($criteria);
}

// Relation
/**
 * @var Currency
 *
 * @ORM\ManyToOne(targetEntity="Currency")
 * @ORM\JoinColumns({
 * @ORM\JoinColumn(name="id_currency", referencedColumnName="id")
 * })
 */
protected $currency;

// File BasicEntityPersister.php
// This cause the problem:
if ( ! isset($this->_class->fieldMappings[$fieldName])) {
    throw ORMException::unrecognizedField($fieldName);
}
// There are no relations in $this->_class->fieldMappings at all!


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

Mark as improvement.





[DDC-2089] Modify OneToMany to allow unidirectional associations without the need of a JoinTable Created: 19/Oct/12  Updated: 07/Sep/13

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

Type: Improvement Priority: Major
Reporter: Enea Bette Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: onetomany, persister, unidirectional
Environment:

Debian Wheezy, Mysql 5.1, Apache2, PHP 5.4



 Description   

As I sayd in the title, it would be nice if the ORM layer could permit to map a 1:n association in the db as an unidirectional OneToMany in the classes, without using a JoinTable in the database.
This would permit us to get rid of the unnecessary database JoinTable, which creates disorder and decreases performance for no valuable reason.

Is it possible?



 Comments   
Comment by Enea Bette [ 16/Dec/12 ]

A little up... for inspiration from JPA

http://en.wikibooks.org/wiki/Java_Persistence/OneToMany#Undirectional_OneToMany.2C_No_Inverse_ManyToOne.2C_No_Join_Table_.28JPA_2.0_ONLY.29





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

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

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


 Description   

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

SELECT u.id FROM User as u

getResult give

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

but how can take this

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



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

for example

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

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





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

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

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

CentOS, PHP 5.3.10



 Description   

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

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

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

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



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

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

Comment by Bogdan Albei [ 26/Sep/12 ]

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





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

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

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


 Description   

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

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

Such as :

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

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

Such as :

if ( ! ClassLoader::classExists($mapping['targetEntity']) ) {
throw MappingException::invalidTargetEntityClass($mapping['targetEntity'], $this->name, $mapping['fieldName']);
}

cro.



 Comments   
Comment by Oleg Namaka [ 31/Mar/14 ]

We need this feature too. Why is this ticket in a limbo? Someone please add a comment whether this will be fixed.

Comment by Marco Pivetta [ 31/Mar/14 ]

Oleg Namaka you can open a pull request with a test and suggested improvement for this at https://github.com/doctrine/doctrine2





[DDC-2021] Array Data in Member OF Created: 09/Sep/12  Updated: 09/Sep/12

Status: Open
Project: Doctrine 2 - ORM
Component/s: DQL
Affects Version/s: 2.2.3
Fix Version/s: None
Security Level: All

Type: New Feature Priority: Major
Reporter: vahid sohrabloo Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: array, dql


 Description   

Hi.
First sorry for my bad english.
In
SELECT u.id FROM CmsUser u WHERE :groupId MEMBER OF u.groups
DQL we can't use Array of groupId like






[DDC-2007] [GH-434] allowed to pass filter objects to the configurator Created: 31/Aug/12  Updated: 18/Dec/13

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: New Feature Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of bamarni:

Url: https://github.com/doctrine/doctrine2/pull/434

Message:

If DDC-2004 gets approved.



 Comments   
Comment by Doctrine Bot [ 18/Dec/13 ]

A related Github Pull-Request [GH-434] was closed:
https://github.com/doctrine/dbal/pull/434





[DDC-1999] Lazy loading doesn't get the field type when generating sql Created: 29/Aug/12  Updated: 29/Aug/12

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: victor Velkov Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

When calling with lazy loading the Sql generated doesn't convert the parameters according to their types. After debugging the problem I found that the problem is in the getType($field, $value) function in the BasicEntityPersister as it is it will never be able to return the filed type when called for lazy loading for oneToMany or ManyToMany. I put a quick fix for my self

 private function getType($field, $value)
    {

        switch (true) {
           //here we have original code
            default:

            	$type = null;
               // my fix starts here
            	$fieldParts = explode('.', $field);
            	if (count($fieldParts > 1)) {
	            	foreach ($this->_class->associationMappings as $mapping) {
						if (isset($mapping['joinColumnFieldNames'][$fieldParts[1]])) {
							$targetClass  = $this->_em->getClassMetadata($mapping['targetEntity']);

							if (isset($targetClass->fieldNames[$fieldParts[1]])) {
								$type = $targetClass->fieldMappings[$targetClass->fieldNames[$fieldParts[1]]]['type'];
							}

							break;
						}
	            	}
            	}
//my fix end here
        }

       //here we have original code

        return $type;
    }


i have only added that check in the default case of the switch. I am not sure if that is the most elegant way. I hope that helps and that it will be fixed soon. Thanks for the great work .



 Comments   
Comment by Benjamin Eberlei [ 29/Aug/12 ]

Fabio B. Silva Guilherme Blanco do we have a current best practice/policy regarding casting of join column types? There are some issues regarding it, this is another one.

Comment by Guilherme Blanco [ 29/Aug/12 ]

We avoid the manual breakdown of path expressions.
Also, in BasicEntityPersister it is done behind the scenes and can get into weird scenarios. Personally speaking, I don't see how we can easily fix this issue.





[DDC-2002] [GH-432] Add DBAL\TypeAwareObject type inference. Created: 29/Aug/12  Updated: 27/Nov/13

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: New Feature Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of Romain-Geissler:

Url: https://github.com/doctrine/doctrine2/pull/432

Message:

DBAL allows you to define custom field types for your entities, and those are seamlessly converted from PHP to SQL value. However, you can't those custom types as parameters without type hinting it :

```php
$qb->select('e')
->from('Entity', 'e')
->where('e.customField = :customFieldValue')
->setParameter('customFieldValue',$customFieldValue,$customFieldDBALType);
//this third argument is for now compulsory
:
```

In my case, ``$customFieldValue`` is an object that won't work well if converted with the default string type. I added a new DBAL interface (see doctrine/dbal#193 ) and tweaked the parameter type inference so that custom values can advertise their DBAL type.

There is currently no way to dynamically override the parameter type inference logic, this is one design that allows it in some cases.



 Comments   
Comment by Benjamin Eberlei [ 30/Aug/12 ]

A related Github Pull-Request [GH-432] was closed
https://github.com/doctrine/doctrine2/pull/432

Comment by Doctrine Bot [ 27/Nov/13 ]

A related Github Pull-Request [GH-432] was closed:
https://github.com/doctrine/dbal/pull/432





[DDC-1991] Add parameter indexBy to EntityRepository->createQueryBuilder() Created: 20/Aug/12  Updated: 20/Aug/12

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: Git Master
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Major
Reporter: Philipp Cordes Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

createQueryBuilder() currently doesn’t have a parameter to set the third option on the FROM fragment: indexBy. Right now you have to read it, create a new From with the read properties and your desired indexBy value and replace the existing one on the QueryBuilder.

Should be ten minutes’ work including tests. Thanks a lot!






[DDC-1971] [GH-419] Add ODM embedded-like functionality Created: 07/Aug/12  Updated: 20/Dec/13

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: New Feature Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of djlambert:

Url: https://github.com/doctrine/doctrine2/pull/419

Message:

This PR adds ODM embedded-like functionality to the ORM.

Including the new @MappedAssociation annotation on a field having a one-to-one association adds a discriminator column to the table for storing the class name of a "mapped" entity.

This allows a class or mapped superclass with a one-to-one identifying association to be extended by additional entities without requiring any code changes (as is required with the discriminator map when using inheritance).

I apologize if this is the incorrect way to submit a feature request. Currently just the annotation driver has been updated, I wanted to get feedback before continuing with the remaining drivers. Models and tests are included.



 Comments   
Comment by Doctrine Bot