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

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

Type: Bug Priority: Critical
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-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-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-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-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-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-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-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-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-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-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-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-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-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-2675] WITH (NOLOCK) failing when using JOIN Created: 12/Sep/13  Updated: 31/Jan/14

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

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

MSSQL 2008 R2


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

 Description   

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

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

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

One example, test 20)
Generated SQL:

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

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



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

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

Comment by Doctrine Bot [ 31/Jan/14 ]

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





[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-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-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-2560] Schema tool invalid DDL syntax for default values Created: 19/Jul/13  Updated: 19/Jul/13

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

Type: Bug Priority: Major
Reporter: Ben Davies Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: schematool
Environment:

Postgresql



 Description   

Not sure if this is Postgresql specific or not, but here are the reproduction steps:

Have a table with a column setup like so:

ALTER TABLE usr ADD COLUMN contact_count integer;
ALTER TABLE usr ALTER COLUMN contact_count SET NOT NULL;
ALTER TABLE usr ALTER COLUMN contact_count SET DEFAULT 0;

Have a Entity Column Definition like so:

    /**
     * @var integer $contactCount
     *
     * @ORM\Column(name="contact_count", type="integer", nullable=false)
     */
    private $contactCount = 0;

orm:schema-tool:update will generate the following SQL:

ALTER TABLE usr ALTER contact_count SET ;

adding

options={"default":0}

to the column definition results in no sql being generated (correctly I assume)



 Comments   
Comment by Marco Pivetta [ 19/Jul/13 ]

The ORM doesn't support default column values.
That's fine-tuning you can do on the column definitions.

Your "workaround" is actually the correct way of dealing with this kind of DDL change.

Comment by Ben Davies [ 19/Jul/13 ]

I realise the ORM doesn't support default values, but the point is that the schematool picks up a diff in the columns, tries to generate a diff, and generates an invalid sql statement. Surely that is a bug?

Comment by Marco Pivetta [ 19/Jul/13 ]

Ben Davies the DBAL is responsible for generating this wrong DDL... Are you able to reproduce this in DBAL only?

Comment by Ben Davies [ 19/Jul/13 ]

Happy to try.

Comment by Ben Davies [ 19/Jul/13 ]

here you go
https://github.com/bendavies/dbal/blob/DBAL-561/tests/Doctrine/Tests/DBAL/Functional/Ticket/DBAL561Test.php





[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-2524] Wrong commit order with cascade remove and double association Created: 24/Jun/13  Updated: 15/Jan/14

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

Type: Bug Priority: Major
Reporter: Matthieu Napoli Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None


 Description   

We have stumbled upon a bug in a situation where a class A has the following associations to a class B:

  • A has one B (oneToOne unidirectional)
  • A has many B (oneToMany bidirectional)

Associations are with cascade remove.

We will submit a PR soon with a failing test case.

The failure is a MySQL foreign key violation exception when removing A (removals for B are executed after removals for A).



 Comments   
Comment by Valentin Claras [ 24/Jun/13 ]

Here a link to the pull request https://github.com/doctrine/doctrine2/pull/707

Comment by Matthieu Napoli [ 25/Jun/13 ]

The tests on Travis are failing as expected.

https://travis-ci.org/doctrine/doctrine2/builds/8382962

Here is the list of the queries executed for MySQL:

SQLSTATE[23000]: Integrity constraint violation: 1451 Cannot delete or update a parent row: a foreign key constraint fails (`doctrine_tests`.`CascadeRemoveOrderEntityG`, CONSTRAINT `FK_23681E8F99938CE5` FOREIGN KEY (`ownerO_id`) REFERENCES `CascadeRemoveOrderEntityO` (`id`))

With queries:

13. SQL: 'DELETE FROM CascadeRemoveOrderEntityO WHERE id = ?' Params: '1'
12. SQL: '"START TRANSACTION"' Params: 
11. SQL: 'SELECT t0.id AS id1, t0.ownerO_id AS ownerO_id2 FROM CascadeRemoveOrderEntityG t0 WHERE t0.ownerO_id = ?' Params: '1'
10. SQL: 'SELECT t0.id AS id1, t0.oneToOneG_id AS oneToOneG_id2 FROM CascadeRemoveOrderEntityO t0 WHERE t0.id = ?' Params: '1'
9. SQL: '"COMMIT"' Params: 
8. SQL: 'INSERT INTO CascadeRemoveOrderEntityG (ownerO_id) VALUES (?)' Params: '1'
7. SQL: 'INSERT INTO CascadeRemoveOrderEntityO (oneToOneG_id) VALUES (?)' Params: ''
6. SQL: '"START TRANSACTION"' Params: 

As you can see, the latest query causes a foreign key constraint violation (wrong order with the next, non-executed query).

Comment by Matthieu Napoli [ 25/Jun/13 ]

On the sqlite tests we can see better the order the queries are executed:

14. SQL: 'DELETE FROM CascadeRemoveOrderEntityG WHERE id = ?' Params: '1'
13. SQL: 'DELETE FROM CascadeRemoveOrderEntityO WHERE id = ?' Params: '1'
12. SQL: '"START TRANSACTION"' Params: 
11. SQL: 'SELECT t0.id AS id1, t0.ownerO_id AS ownerO_id2 FROM CascadeRemoveOrderEntityG t0 WHERE t0.ownerO_id = ?' Params: '1'
10. SQL: 'SELECT t0.id AS id1, t0.oneToOneG_id AS oneToOneG_id2 FROM CascadeRemoveOrderEntityO t0 WHERE t0.id = ?' Params: '1'
9. SQL: '"COMMIT"' Params: 
8. SQL: 'INSERT INTO CascadeRemoveOrderEntityG (ownerO_id) VALUES (?)' Params: '1'
7. SQL: 'INSERT INTO CascadeRemoveOrderEntityO (oneToOneG_id) VALUES (?)' Params: ''
6. SQL: '"START TRANSACTION"' Params: 

13 and 14 are in the wrong order.

Comment by Guilherme Blanco [ 03/Aug/13 ]

This situation is not supported and cannot be resolved within current Doctrine code.
You created a circular dependency between the entities A and B. It happened because A contains one B (oneToOne) and because B contains a pointer to A as part of oneToMany association.
That way, you'll always have a foreign key constraint issue from RDBMS, no matter which entity you try to remove first.

Because of that, I'mm marking this ticket as "can't fix".

Comment by Matthieu Napoli [ 05/Aug/13 ]

Guilherme Blanco I see what you mean, but the case we submitted is with a nullable foreign key. So the operation is permitted by the RDBMS.

A has one B (nullable oneToOne), and B has a pointer to A (manyToOne, not nullable).

As I said for the query log, B should be removed first, which is not the case (see above, line 13 and 14 should be inversed).

So this is fixable on the Doctrine side if I'm not mistaken.

Comment by Benjamin Eberlei [ 03/Jan/14 ]

Matthieu Napoli is this fixed with your DDC-2775 PR?

Comment by Matthieu Napoli [ 15/Jan/14 ]

Just for clarity (I answered this question in the pull request): no this is not fixed (see https://github.com/doctrine/doctrine2/pull/707#issuecomment-31564035).





[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-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-2405] Changing strategy generates bad query. Created: 19/Apr/13  Updated: 21/Apr/13

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

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


 Description   

For (unit, acceptance, functional) testing purpose I need to change the strategy of my GameStuff Entity class.

In previous version is was using php instruction below, but since doctrine orm 2.3, it doesn't work anymore.

$orm->getClassMetaData('Entities\GameStuff')->setIdGeneratorType(\Doctrine\ORM\Mapping\ClassMetadata::GENERATOR_TYPE_NONE);

will trigger:

Doctrine\DBAL\DBALException: An exception occurred while executing 'INSERT INTO vbank_accounts (game_id, updated_at, created_at) VALUES (?, ?, ?)' with params

{"1":1000010, "2":0,"3":"2013-04-19 17:16:05","4":"2013-04-19 17:16:05"}

:

SQLSTATE[HY093]: Invalid parameter number: number of bound variables does not match number of tokens



 Comments   
Comment by Benjamin Eberlei [ 20/Apr/13 ]

The problem is that changing ClassMetadata after generating it from the cache is not really supported and depends on the Internal State of other classes. Have you tried creating a completly new EntityManager and then directly setting this? It could be that the SQL for the entity was already generated inside Doctrine, with the ID Generator information at IDENTITY_AUTO.

Comment by Van Rotemberg [ 21/Apr/13 ]

> The problem is that changing ClassMetadata after generating it from the cache is not really supported

Yeah, it is a problem indeed, why set ticket status to resolved ?
Do you think it's normal to have a public method that trigger a fatal error ?

Please fix it or put setIdGeneratorType as private, or AT LEAST add a context exception ...

Comment by Marco Pivetta [ 21/Apr/13 ]

Almost every interaction with metadata outside the `loadClassMetadata` event will cause unexpected problems. I don't think throwing an exception there helps in any way.

Comment by Van Rotemberg [ 21/Apr/13 ]

@marco pivetta

The generation of the actual exception comes from DBALException on the query excetion and point a bad generated query (Invalid parameter number),
when the problem comes from setting ClassMetada, and concerns a problem of cache generated after loadClassMetadata.

Adding an exception is just the fast way pointing where the problem comes from and that "setting metadata after loadMetadata is not supported anymore". (It will spare developper's time that used to set metadata, but also help future contribution)

> Please fix it or put setIdGeneratorType as private, or AT LEAST add a context exception ...
Note: BTW, my favorite solution would be to fix it (re-generate cache, or edit cache, or disable cache or whatever)





[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-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-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-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-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-2210] PHP warning in ProxyFactory when renaming proxy file Created: 20/Dec/12  Updated: 20/Aug/13

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

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

Windows



 Description   

Getting a PHP Warning:

rename(**/models/Proxies_CGAF_Model_Component_Group.php.50d2dd2c079bb9.35271255,**/models/Proxies__CG_AF_Model_Component_Group.php):

in ProxyFactory line 194.

I haven't more information in the warning.

This is the moment when the ProxyFactory writes the proxy to a temporary file and then tries to rename the temp file to the correct file.

This warning appears randomly, but mostly on pages with lots of concurrent AJAX requests. I guess this happens because several requests try to write the proxy file at the same time. I get this warning but the app works fine.

This happens in dev environment, on a Windows machine.

I don't know why rename generates a warning, it should just return false... The doc doesn't say anything about warnings (except for long file names, but I checked even with the full path this is around 135 characters, not 255).



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

Thats why you shouldn't generate proxies at runtime. The problem happens on windows, because the atomic rename operation doesn't work as perfectly there as on linux.

We cannot fix this in Doctrine.

Comment by Matthieu Napoli [ 24/Dec/12 ]

Benjamin Eberlei What do you mean "you shouldn't generate proxies at runtime"? I'm not in production, this is in dev. And I'm using the default configuration.

What I don't understand is why will Doctrine regenerate proxies on every request? The warning is reproductible, and even when no PHP entity has been touched.

Comment by Matthieu Napoli [ 27/Dec/12 ]

Benjamin Eberlei To simplify my previous message (I don't want to bury you under questions) I'll sum it up like that:

What can I do?

Thanks!

Comment by Matthieu Napoli [ 28/Feb/13 ]

Benjamin Eberlei ping: what can be done?

Can we suppress the error with @rename($tmpFileName, $fileName); ?

https://github.com/doctrine/common/blob/master/lib/Doctrine/Common/Proxy/ProxyGenerator.php#L287

I can make a PR if you think that's a valid solution.

Comment by Marco Pivetta [ 28/Feb/13 ]

Matthieu Napoli no, if you have warnings, please disable them via ini setting. With error suppression there, we may have further problems identifying more serious issues.

About proxy generation: that happens EVERY time in dev environments. Generate them once and disable it afterwards.

Comment by Matthieu Napoli [ 28/Feb/13 ]

Marco Pivetta OK I can disable the auto generation then (I'll have to remember to regenerate them when I edit the model).

Thanks for the feedback

Is that possible to make those proxies generate only if the entity file has been modified since the last generation? (only asking if can and should be done, I can look for implementing it myself if that's the case)

Comment by Marco Pivetta [ 28/Feb/13 ]

Matthieu Napoli that would be very obnoxious when changing entities often. I wouldn't do that (generating only if not already available)

Comment by Matthieu Napoli [ 28/Feb/13 ]

Marco Pivetta Yes but for now they are regenerated at every request when in dev mode (at least with the default configuration http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/configuration.html#obtaining-an-entitymanager)

Which one is worse: generating every proxy class at every request, or generate only those which changed (in dev environment of course, not prod)?

If neither of these options are good (i.e. auto generation should be disabled), I don't understand why the docs say to enable auto generation when in dev environment.

Comment by Marco Pivetta [ 28/Feb/13 ]

Matthieu Napoli that's because in dev environments you shouldn't care about that one exception (usually happens when you got concurrent requests).

It is worse to generate only on changes: that's a lot of additional checks, variables to keep in memory and additional logic that is not needed.

Let's keep it as it is (generating at each request) for dev environments: works fine

Another (eventual) solution for dev environments would be not to write the proxy file, but to eval it.

Comment by Matthieu Napoli [ 28/Feb/13 ]

eval it would be a good solution IMO, no more "woops the directory is not writable" and it's more neutral for the user filesystem (but not as easy to debug). But OK, I see what you mean, it works let's keep it that way.

Actually the problem on my setup is that PHP errors are turned into exceptions, so on an (poorly designed) AJAX treeview (lots of nodes to load => lots of requests), I end up with some nodes not loaded because of the exception. And it feels weird to either silently log all PHP warnings or silently ignore the specific warning for the rename.

Comment by Marco Pivetta [ 28/Feb/13 ]

Matthieu Napoli I'd go with `eval` then. Needs refactoring of the abstract proxy factory and of the proxy generator (proxy generator should no longer write files).

Comment by Marco Pivetta [ 28/Feb/13 ]

Re-opening: the proxy factory could directly `eval()` the produced proxy code. The ProxyGenerator should no longer write the generated files to disk automatically.

Comment by Matthieu Napoli [ 28/Mar/13 ]

I've opened a PR: https://github.com/doctrine/common/pull/269

Comment by Oleg Namaka [ 16/Aug/13 ]

Thats why you shouldn't generate proxies at runtime. The problem happens on windows, because the atomic rename operation doesn't work as perfectly there as on linux.

  • In my case that is observed on a Linux machine (see http://www.doctrine-project.org/jira/browse/DDC-2613). If the rename operation is atomic then why it still happens? As I indicated in the description it's because of the way uniqid function works.
  • Is there a plan to merge the PR in this ticket? The fix in it would eliminate my issue whatsoever.
Comment by Doctrine Bot [ 20/Aug/13 ]

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





[DDC-2193] Named native query bug? Created: 11/Dec/12  Updated: 31/Dec/12

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

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

Attachments: File DDC2193Test.php    

 Description   

@NamedNativeQueries is a useful thing, but I have found some problems during my using.
1、Normal

 /**
 * @NamedNativeQueries({
 *      @NamedNativeQuery(
 *          name            = "fetchMultipleJoinsEntityResults",
 *          resultSetMapping= "mappingMultipleJoinsEntityResults",
 *          query            = "SELECT * FROM test "
 *      )
 * })
 */

2、Error,cannot connect to the server

 /**
 * @NamedNativeQueries({
 *      @NamedNativeQuery(
 *          name            = "fetchMultipleJoinsEntityResults",
 *          resultSetMapping= "mappingMultipleJoinsEntityResults",
 *          query            = "SELECT * 
            FROM test "
 *      )
 * })
 */

3、Cannot use alias.The same problem as the second one.

.......
 query            = "SELECT a as test FROM test "


 Comments   
Comment by Fabio B. Silva [ 12/Dec/12 ]

Hi

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

Could you provide more details please?

Cheers

Comment by dingdangjyz [ 13/Dec/12 ]

Doctrine\Common\Lexer.php

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

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

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

            $this->tokens[] = array(
                'value' => $match[0],
                'type'  => $type,
                'position' => $match[1],
            );
Comment by Fabio B. Silva [ 13/Dec/12 ]

Hi

Could you try to add a failing test case please ?

Cheers

Comment by dingdangjyz [ 14/Dec/12 ]

xp php5.3.8 Apache

<?php

namespace Models\Entities;

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

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

@NamedNativeQueries query

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

Comment by Fabio B. Silva [ 16/Dec/12 ]

Can't reproduce,

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

Cheers

Comment by Benjamin Eberlei [ 24/Dec/12 ]

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

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

Comment by dingdangjyz [ 31/Dec/12 ]

I'm sorry my English is too bad.

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





[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-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-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-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-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 [ 20/Dec/13 ]

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





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

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

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


 Description   

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

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






[DDC-1938] [GH-406] [WIP] - DCOM-96 - Moving proxy generation and autoloading to common Created: 21/Jul/12  Updated: 09/Nov/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 Ocramius:

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

Message:

This PR is related to doctrine/common#168.

In this PR, the `ProxyFactory` has been reduced to an object builder and it's public API has been kept intact (While the proxy `Autoloader` has been moved to doctrine/common). It would be interesting to define what this builder could do with the `ProxyFactory` to get its own customizations introduced.



 Comments   
Comment by Benjamin Eberlei [ 25/Jan/13 ]

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

Comment by Benjamin Eberlei [ 26/Jan/13 ]

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

Comment by Doctrine Bot [ 09/Nov/13 ]

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





[DDC-1923] Type conversion error with oracle Created: 12/Jul/12  Updated: 12/Jul/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: Alexander Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None


 Description   

https://github.com/symfony/symfony/pull/4730






[DDC-1899] [GH-385] set metadata for interface to be able to fetch entites by interface name Created: 29/Jun/12  Updated: 13/Nov/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 Burgov:

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

Message:

using the new ResolveTargetEntity functionality we noticed we needed another feature:

From the Symfony Bundle defining the interface, we'd like to be able to fetch entities by this very interface name, e.g.:

``` php
$em->find('Foo\BarBundle\Entity\PersonInterface', 1);
```

or

``` php
$em->getRepository('Foo\BarBundle\Entity\PersonInterface')->findAll();
```

This PR sets metadata for the interface when metadata for a class is loaded that the interface is configured for



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

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





[DDC-1860] Make usage of Composer for CLI optional Created: 09/Jun/12  Updated: 09/Jun/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: Marco Pivetta Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

There's two problems with current CLI implementation:

1 - composer `autoload.php` file is hardcoded, which means that it is making assumptions about where `doctrine/orm` has been installed, and it also makes the assumption that `doctrine/orm` is not the main package.
2 - composer is a requirement, while requiring it should just fail silently and allow the end user to use his own autoloading strategy



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

Merged at https://github.com/doctrine/doctrine2/pull/365





[DDC-1859] Implement console command to convert DQL into object running NativeQuery Created: 08/Jun/12  Updated: 08/Jun/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: Guilherme Blanco Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

As per our conversation during SFLive Paris 2012, we should create a command that receives a DQL and exposes back to you a PHP code of an object holding a conversion to NativeQuery, which is faster.






[DDC-1840] Create ParameterCollection indexed and implement it on AbstractQuery and QueryBuilder Created: 26/May/12  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: Guilherme Blanco Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Currently, method setParameters in AbstractQuery and QueryBuilder only appends new parameters to the list. It should actually override the existing ones.
To be able to correctly fix this, we need to create a ParameterCollection which we can use/reuse to set/remove/append new parameters.
These elements should also support parameter types.



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

Not a bug





[DDC-1829] [GH-352] Add the posibility to add a custom Comparator for Schema tool Created: 21/May/12  Updated: 22/May/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   

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

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

Message:

See catacgc/dbal#153






[DDC-1814] Save quoted info in ClassmetadataInfo#quotedColumns instead of ClassmetadataInfo#fieldmappings['fieldname']['quoted'] Created: 06/May/12  Updated: 06/May/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: ross neacoders Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Similar to DDC-1813 I propose saving 'quote' status in ClassmetadataInfo#quotedColumns instead of ClassmetadataInfo#fieldmappings['fieldname']['quoted']

Otherwise you have quotation info only for fieldColumns and not association columns






[DDC-1813] Save column types in ClassMetadataInfo#columnTypes array instead of ClassMetadataInfo#fieldMappings['type'] Created: 06/May/12  Updated: 06/May/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: ross neacoders Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Because you save column types in fieldmappings only, type information is not saved for join columns.

Not having type info for join columns, makes it impossible to do call 'convertToPhpValue' on join columns.

For example see a demo of problem here:
https://github.com/doctrine/doctrine2/pull/347






[DDC-1812] Modify ResultSetMapping#addMetaResult function definition Created: 06/May/12  Updated: 06/May/12

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

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


 Description   

Give correct names to arguments

    public function addMetaResult($alias, $columnName, $fieldName, $isIdentifierColumn = false)
    {

$alias - should be $tableAlias
$columnName should be $columnAlias
$fieldName should be $columnName

Here are some exmple calls from code:
AbstractEntityInheritancePersister.php
79: $this->_rsm->addMetaResult('r', $columnAlias, $joinColumnName);
SqlWalker.php
$this->_rsm->addMetaResult($dqlAlias, $columnAlias, $discrColumn['fieldName']);
$this->_rsm->addMetaResult($dqlAlias, $columnAlias, $srcColumn, (isset($assoc['id']) && $assoc['id'] === true));
$this->_rsm->addMetaResult($dqlAlias, $columnAlias, $srcColumn);






[DDC-1820] [GH-348] [DDC-1819][WIP] Arbitrary object hydrator Created: 14/May/12  Updated: 27/May/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   

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

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

Message:

Initial work (in progress) on a test suite for the arbitrary object hydrator, as discussed in DDC-1819[1]. Any tips are appreciated. I'm not too sure what the test suite should and should not cover.

Other questions I have include:

1. Should the `HYDRATE_ARBITRARY_OBJECT` constant be added to the `AbstractQuery` class or the `NativeQuery` class? It only makes sense in the former but it might be missed when more constants are added in the future...
2. Should I use data providers in my tests for the result set data?
3. Should my tests be added to a `DDC1819` namespace?
4. Should I add functional tests?

[1]: http://www.doctrine-project.org/jira/browse/DDC-1819






[DDC-1785] Paginator problem with SQL Server around DISTINCT keyword. Created: 18/Apr/12  Updated: 19/Jan/13

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

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


 Description   

PDOException: SQLSTATE[42000]: [Microsoft][SQL Server Native Client 10.0][SQL Server]Incorrect syntax near the keyword 'DISTINCT'. (uncaught exception)



 Comments   
Comment by Craig Mason [ 18/Oct/12 ]

There are four major issues with this:

1: SQLServerPlatform.php modifies the query to prepend 'SELECT ROW_NUMBER() OVER ($over)', which is inserted before the DISTINCT keyword.

2: The order needs to be placed inside the OVER($over) block. At this point, the regex is using the exact column name rather than the alias, so the outer query cannot ORDER.

3: The DISTINCT queries select only the ID columns - as OVER() required the sort column to be available in the outer query, IDs alone will not work.

4: SQL Server cannot DISTINCT on TEXT columns. 2005,2008 and 2012 recommend using VARCHAR(MAX) instead, which does support it. That doesn't help us with 2003. We work around that with a custom TEXT type that casts as varchar.

Incidentally, 2012 supports LIMIT, which gets rid of this issue altogether.

Edit: Added #3

Comment by Craig Mason [ 18/Oct/12 ]

I have a (very hacky) implementation working that uses regexes to correct the query so that it will execute. This also required modification in the ORM paginator, to select all columns instead of just IDs.

https://github.com/CraigMason/dbal/commit/4ecd018c73e387904f78d81f1d327e34e905c5f1
https://github.com/CraigMason/doctrine2/commit/b416d3b2a38495e4435bde872b19fec371fe5657

This is certainly not a patch - more guidance.

One interesting point... I had to wrap the whole query in a second SELECT *, as the WHERE IN confusingly returns non-distinct rows when part of the first inner query. No idea why this happens, but moving it out one layer makes it operate correctly.

Comment by Craig Mason [ 25/Oct/12 ]

Updated, view all commits for this experimental branch here:

https://github.com/CraigMason/dbal/commits/mssql-distinct

Comment by Craig Mason [ 29/Oct/12 ]

This got waaaay too messy with regex alone due to the complicated nesting. As such, I have written the basis of a new SqlWalker class which can be used to create DISTINCT queries based on the root identifiers. It's not proper DISTINCT support, but it's a step forward.

https://github.com/CraigMason/DoctrineSqlServerExtensions

I've also added a Paginator (which was the original issue I had!)

The current SqlWalker always sticks the ORDER BY on the end of the query, which just doesn't work properly with SqlServer. Is a vendor-specific walker breaking the DQL abstraction? Should this type of code be on the Platform object in the DBAL?

Anyway, this repo fixes our immediate problem, and it would be good to revisit this in a wider context. Hopefully we can get some good SQL server support - there are plenty of other issues to deal with (UTF-8/UCS2, nvarchar etc)

Comment by Benjamin Eberlei [ 19/Jan/13 ]

Craig Mason We don't have an SQL Server expert on the team, so if you want really good support you should join and help us with it.





[DDC-1760] [GH-324] simplified __call method Created: 03/Apr/12  Updated: 07/Apr/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   

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

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

Message:



 Comments   
Comment by Benjamin Eberlei [ 04/Apr/12 ]

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

Comment by Benjamin Eberlei [ 06/Apr/12 ]

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

Comment by Benjamin Eberlei [ 07/Apr/12 ]

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





[DDC-1750] [GH-319] [WIP] Added support to Multiple ID Generators Created: 01/Apr/12  Updated: 27/May/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   

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

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

Message:



 Comments   
Comment by Benjamin Eberlei [ 01/Apr/12 ]

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

Comment by Benjamin Eberlei [ 01/Apr/12 ]

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

Comment by Benjamin Eberlei [ 02/Apr/12 ]

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

Comment by Benjamin Eberlei [ 02/Apr/12 ]

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

Comment by Benjamin Eberlei [ 03/Apr/12 ]

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

Comment by Benjamin Eberlei [ 03/Apr/12 ]

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

Comment by Benjamin Eberlei [ 04/Apr/12 ]

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

Comment by Benjamin Eberlei [ 06/Apr/12 ]

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

Comment by Benjamin Eberlei [ 07/Apr/12 ]

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





[DDC-1723] Custom ID Generators Created: 22/Mar/12  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: New Feature Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Allow specify custom id generators, pull request is GH-206

https://github.com/doctrine/doctrine2/pull/206






[DDC-1681] loadRelated() - Method to efficiently load sets of related entities in "sub"-select strategies Created: 05/Mar/12  Updated: 06/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: Benjamin Eberlei Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 1
Labels: None


 Description   

As per Request of Seldaek



 Comments   
Comment by Jordi Boggiano [ 05/Mar/12 ]

Sample:

$result = $queryBuilder->select('a')->from('User', 'a')->getQuery()->getResult();
$result->loadRelated('roles'); // loads all a.roles

Would be the equivalent of:

$result = $queryBuilder->select('a, r')->from('User', 'a')->join('a.roles', 'r')->getQuery()->getResult();

Except that the above does one simple query without join, then one WHERE IN query with all ids from the collection.
The latter obviously does a join and retrieves everything in one - more complex - query.

Bonus points if you can loadRelated multiple relations at once.

Comment by Christophe Coevoet [ 05/Mar/12 ]

I see an issue here: if you do a WHERE IN with the multiple ids, how do you know which entity the role is related to ?

and btw, the interface you suggested above would require breaking the BC: ``$result`` is an array right now.

Comment by Jordi Boggiano [ 05/Mar/12 ]

The interface is just an example mimicking the way it worked in D1, take it with a grain of salt.

As for the implementation, if you assume the roles table has a user_id and role column, then you can do WHERE user_id IN (1, 2, 3) and you'll get back the user ids so you know where to attach them. It might still require some joining in some cases, but the point is to keep the joins out of the main query.

Comment by Guilherme Blanco [ 05/Mar/12 ]

The one to be implemented would be:

$result = $queryBuilder->select('a')->from('User', 'a')->getQuery()->getResult();
$em->loadRelated($result, 'roles'); // loads all a.roles

The reason for that is not all the times you have a PersistentCollection. You may have an ArrayCollection too.
I just don't know yet how to handle array and ArrayCollection situations, since you may not know which class you're trying to fetch.
Maybe I can try to grab the first item of array and retrieve Association information from ClassMetadata retrieved via get_class on first item. That would solve the problem.

Any other ideas, feel free to give me.

Comment by Vasily Khayrulin [ 06/Sep/13 ]

Any news? it's really cool to use "WHERE primary_key IN " instead of joins.





[DDC-1621] Add support for FROM Class1 a1 JOIN Class2 a2 WITH cond queries Created: 25/Jan/12  Updated: 07/Sep/13

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

Type: New Feature Priority: Major
Reporter: Benjamin Eberlei Assignee: Alexander
Resolution: Unresolved Votes: 1
Labels: None


 Description   

Check feasibility of this kind of query different from FROM Class1 a1, Class2 a2 to allow arbitrary joins between classes.



 Comments   
Comment by Alex [ 30/Nov/12 ]

Hi all!
Maybe if this task is hard, you could do a simplier variant, "FROM Class1 a1 JOIN a1,a2 WITH a2 INSTANCE OF Class2"?
Doctrine 2.3 supports it, but in fact, it does not work. I can't use Class2 fields in query, and Doctrine ignores the INSTANCE OF operator when building a native queries.
I am working with system where I have many inherited classes with Class Table Inheritance. When I do a JOIN query, it generates native sql query more than 1KB(?!) length, and MySQL freezes for more than 7 minutes (?!) on it. It must join only tables for Class2, but it joins all my 20 tables inherited of my base class
I don't know where to send bugreport
It will be very good if I could manually select a joined class to make Doctrine do a better queries.
Sorry for my english, I am from Moscow.





[DDC-1570] GH-243: Add ProxyFactoryInterface to allow custom proxy factories Created: 28/Dec/11  Updated: 23/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   

Pull-Request was automatically synchronized: https://github.com/doctrine/doctrine2/pull/243

I'd love to have my custom proxy factory used with ORM, which is not possible at the moment

(my experimental proxy https://github.com/juzna/doctrine2/commit/7822446036201b066e390b2e182cac1dc0c85430 and some comments about it http://blog.juzna.cz/2011/06/lazy-loading-in-php/)



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

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





[DDC-1564] MySQL Failure when using setFirstResult() and omitting setMaxResults() Created: 25/Dec/11  Updated: 28/Dec/11

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

Type: Improvement Priority: Major
Reporter: Timo A. Hummel Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

When using setFirstResult() and omitting setMaxResults(), MySQL throws an error. This was very confusing for me until I dumped the SQL statements and found out the reason.

I know that MySQL doesn't directly support this, their manual says that you should set the second parameter to LIMIT to a very high number (18446744073709551615 in their example).

I'd recommend that either throwing an error in the specific platform driver or follow the MySQL example.



 Comments   
Comment by Benjamin Eberlei [ 28/Dec/11 ]

Changed into improvement, i am not sure how this relates to other databases.

You can just use this workaround yourself so long.





[DDC-1552] JTI Owning table for identifier columns could/should be the entitytable Created: 22/Dec/11  Updated: 22/Dec/11

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: Alexander Assignee: Alexander
Resolution: Unresolved Votes: 0
Labels: None


 Description   

When ordering a JTI entity on id, the generated SQL will use the table of the root entity. This is because the root entity is listed as owner of the field in the _owningTableMap, leading to non-optimal queries.

More information see:
https://groups.google.com/forum/#!topic/doctrine-user/znkkP7IF_Aw



 Comments   
Comment by Alexander [ 22/Dec/11 ]

I can pick this up if it's agreed upon that this could indeed be improved.

Comment by Marco Pivetta [ 22/Dec/11 ]

The problem here is that joining with a JTI causes LEFT JOINS, which don't perform very well when it comes to sorting the results.

Just as a quick reference, here's where "something" should be changed to get this working:
https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Query/SqlWalker.php#L316

When the field is part of the primary key, the field used for sorting results should be the one of the table of the entity itself, and not of the root of the CTI.





[DDC-1553] JTI Joining root tables could include ON ... AND root.id IS NOT NULL for each root in the inheritance Created: 22/Dec/11  Updated: 22/Dec/11

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: Alexander Assignee: Alexander
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Would lead to more optimal queries, while still allowing for LEFT JOIN. Also related to this:
https://groups.google.com/forum/#!topic/doctrine-user/znkkP7IF_Aw



 Comments   
Comment by Alexander [ 22/Dec/11 ]

Again I can pick this up if this improvement is agreed upon.





[DDC-1549] GH-232: Recursive check for entity identifiers and hashes Created: 20/Dec/11  Updated: 22/Mar/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   

Pull-Request was automatically synchronized: https://github.com/doctrine/doctrine2/pull/232

Hi all!
This PR will add a better support for entities with association keys.

getType will check recursively to find a type for the identifier.
getIndividualValue will search recursively to find the identifier value

trygetById improved, using a recursive function to find an id value instead of implode functions (that cause exceptions if the identifier is an object and do not implements __toString method).



 Comments   
Comment by Benjamin Eberlei [ 28/Dec/11 ]

Mark as improvement

Comment by Benjamin Eberlei [ 22/Mar/12 ]

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





[DDC-1543] Support for Mapping Files on Traits Created: 17/Dec/11  Updated: 17/Dec/11

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

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


 Description   

With PHP 5.4 and traits coming we should find a way where you can add xml and yml configurations for a trait and upon loading an entity X, it also loads the trait configuration of this entity.






[DDC-1538] GH-217: [BUG] Schema Manager had no way to define extra options Created: 14/Dec/11  Updated: 17/Dec/11

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   

Pull-Request was automatically synchronized: https://github.com/doctrine/doctrine2/pull/217

Schema Manager had no way to define extra options ("comment" option for example). It is possible to add these options via Annotations. After the fix adding `@ORM\Column(type="string", options=

{"comment" = "test"}

)` starts to work producing valid SQL schema with COMMENT output.






[DDC-1530] HIDDEN values cannot be used in WhereClause Created: 12/Dec/11  Updated: 25/Jan/12

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

Type: Improvement Priority: Major
Reporter: Guilherme Blanco Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: None


 Description   
SELECT  u, u.name AS HIDDEN n FROM User u WHERE n = ?1

Is broken. Error:

SQLSTATE[42S22]: Column not found: 1054 Unknown column 'sclr16' in 'where clause

On a query like:

SELECT s0_.id AS id0, s0_.a AS a1, s0_.b AS b2, s0_.c AS c3, s0_.d AS d4, s0_.e AS e5, s0_.f AS f6, s0_.g AS g7, s0_.h AS h8, s0_.i AS i9, s0_.j AS j10, s0_.k AS k11, s0_.l AS l12, s0_.m AS m13, s0_.n AS n14, s0_.o AS o15, 123456789 AS sclr16, s0_.p AS p17 FROM myEntity s0_ WHERE s0_.a = 1 AND sclr16 <= ? ORDER BY sclr16 ASC 


 Comments   
Comment by Guilherme Blanco [ 20/Dec/11 ]

Updating fix version

Comment by Christian Raue [ 09/Jan/12 ]

It occurs even if the value is not HIDDEN.

Comment by Benjamin Eberlei [ 10/Jan/12 ]

@Christian this sounds like a completly different error, please explain why you think this belongs here or open a new ticket.

Comment by Christian Raue [ 10/Jan/12 ]

Benjamin: Because I get exactly the same error message regardless of using HIDDEN. So HIDDEN doesn't seem to be liable here.

Comment by Benjamin Eberlei [ 10/Jan/12 ]

Can you paste your DQL and SQL?

Comment by Christian Raue [ 10/Jan/12 ]

Code:

$queryBuilder
	->select('myEntity, 123456789 AS distance')
	->where('distance <= 10')
;

DQL:

SELECT myEntity, 123456789 AS distance FROM MyCompany\MyBundle\Entity\MyEntity myEntity WHERE distance <= 10

SQL:

SELECT s0_.id AS id0, s0_.a AS a1, s0_.b AS b2, s0_.c AS c3, s0_.d AS d4, s0_.e AS e5, s0_.f AS f6, s0_.g AS g7, s0_.h AS h8, s0_.i AS i9, s0_.j AS j10, s0_.k AS k11, s0_.l AS l12, s0_.m AS m13, s0_.n AS n14, s0_.o AS o15, 123456789 AS sclr16, s0_.p AS p17 FROM myEntity s0_ WHERE sclr16 <= 10
Comment by Benjamin Eberlei [ 11/Jan/12 ]

That is expected behavior, ANSI SQL defines SELECT to be evaluated AFTER WHERE.

SELECT 1234 AS foo FROM `test` HAVING foo = 1234

DQL has a HAVING clause as well, not sure it works without the group by. Please try.

Comment by Christian Raue [ 21/Jan/12 ]

So we might just close this issue then?

Comment by Benjamin Eberlei [ 25/Jan/12 ]

Its not a bug, just the error message is supposed to be improved (if possible) in a cheap way.





[DDC-1459] Move DDC-331, DDC-448, DDC-493, DDC-513, DDC-698 Tests into SQLGeneration Testsuite Created: 29/Oct/11  Updated: 01/Aug/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





[DDC-1415] EventListener delegate on entity basis Created: 11/Oct/11  Updated: 20/Dec/11

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

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


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

Removed from master, as i dont like the api at all

Comment by Guilherme Blanco [ 20/Dec/11 ]

Updating fix version





[DDC-1393] Skipping tables or columns in database driver or SchemaTool Created: 24/Sep/11  Updated: 20/Dec/11

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

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


 Description   

There should be a sane way to skip sources of errors in SchemaTool and the DatabaseDriver.



 Comments   
Comment by Benjamin Eberlei [ 24/Sep/11 ]

Idea:

Develop a datastructure of sorts that allows saving information about skipping tables and columns therein when reverse engeneering.

Comment by Guilherme Blanco [ 09/Dec/11 ]

This is not possible unless you take advantage of Topological Sorting to map class dependencies like we do inside of UnitOfWork AFTER creating the ClassMetadata.

The necessity of having this is mandatory because we can never skip classes that have associations to other ones though FK.
You may try that, but it doesn't compensate the effort. I'd rather mark this bug as won't fix, but I'm leaving for you do that. =)

Comment by Guilherme Blanco [ 20/Dec/11 ]

Updating fix version





[DDC-1371] Optimistic Locking using hash column or all columns Created: 10/Sep/11  Updated: 10/Sep/11

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   

We can implement optimistic locking using hash values or other all columns of an entity






[DDC-1438] Add test for DDC-1437 Created: 19/Oct/11  Updated: 19/Oct/11

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   

Add test for DDC-1437






[DDC-1445] Improve error messages Created: 22/Oct/11  Updated: 20/Dec/11

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

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


 Description   

Error messages throughout ClassMetadata validation and UnitOfWork cycles can be significantly improved.

Work is being done on: https://github.com/doctrine/doctrine2/tree/ImproveErrorMessages



 Comments   
Comment by Guilherme Blanco [ 20/Dec/11 ]

Updating fix version





[DDC-1347] Github-PR-110 by shesek: Support NULL in EntityRepository's magic findBy and findOneBy methods Created: 25/Aug/11  Updated: 25/Aug/11

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

{username}

:

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

Message:

The magic `findBy` and `findOneBy` methods don't support passing NULL as the value, because ["we cannot (yet) transform it into IS NULL"](https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/EntityRepository.php#L207).

However, `BasicEntityPersister::_getSelectConditionSQL()` [does support that](https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php#L1229). It seems like leftovers from when there was no support for it. I tried it locally (after applying this change) and it does seem to work well.






[DDC-1342] Github-PR-109: Remove trailing spaces Created: 21/Aug/11  Updated: 21/Aug/11

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   

alOneh created a pull request on Github:

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






[DDC-1259] Atomic creation of Proxy files Created: 08/Jul/11  Updated: 09/Jul/11

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   
From 265e5086ea51ebcafc73f91abc64334d17e2f416 Mon Sep 17 00:00:00 2001
From: Karsten Dambekalns <karsten@typo3.org>
Date: Wed, 25 May 2011 12:11:55 +0200
Subject: [PATCH 4/5] Use temporary file and rename for proxy class creation

Instead of a simple file_put_contents() the proxy class code is written to a
temporary file and renamed to the final filename. This allows file access even
if only allowed by the directory permission.
---
 lib/Doctrine/ORM/Proxy/ProxyFactory.php |   10 +++++++++-
 1 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/lib/Doctrine/ORM/Proxy/ProxyFactory.php b/lib/Doctrine/ORM/Proxy/ProxyFactory.php
index f0cf19c..b2d42fb 100644
--- a/lib/Doctrine/ORM/Proxy/ProxyFactory.php
+++ b/lib/Doctrine/ORM/Proxy/ProxyFactory.php
@@ -152,7 +152,15 @@ class ProxyFactory
 
         $file = str_replace($placeholders, $replacements, $file);
 
-        file_put_contents($fileName, $file, LOCK_EX);
+        $temporaryFileName = $fileName . uniqid( ) . '.temp';
+        $result = file_put_contents( $temporaryFileName, $file );
+
+        if($result === FALSE) throw new \RuntimeException('The temporary proxy class file "' . $temporaryFileName . '" could not be written.');
+        $i = 0;
+        while(!rename( $temporaryFileName, $fileName ) && $i < 5) {
+            $i++;
+        }
+        if($result === FALSE) throw new \RuntimeException('The proxy class file "' . $fileName . '" could not be written.');
     }
 
     /**
-- 
1.7.4.1


 Comments   
Comment by Benjamin Eberlei [ 09/Jul/11 ]

Nette Framework uses a safe stream: https://github.com/nette/nette/blob/master/Nette/Utils/SafeStream.php





[DDC-1264] Add more math related DQL funcs (trig, round, stuff?) Created: 09/Jul/11  Updated: 09/Jul/11

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

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





[DDC-1263] @ManyToOne Arbitrary References Created: 09/Jul/11  Updated: 09/Jul/11

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   

Could it be possible to allow for arbitrary many to one entities through a "class + id" construct as join columns?






[DDC-1164] doctrine:schema:update --force == doctrine:schema:create Created: 20/May/11  Updated: 20/May/11

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: Geoff Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Doctrine:schema:update --force is the same as doctrine:schema:create.

Under the hood, this may not be true, but they basically accomplish the same task. Schema:create should be removed, as it is redundant.

Just look at django, one command to update db:

./manage.py syncdb

Not saying that django gets everything correct, but the one command to synchronize the database is consistent. doctrine:schema:update should be smart enough to do all of the work, instead of relying on the redundant doctrine:schema:create.






[DDC-1154] Proxies should take convention while loading *ToOne associations to reduce 1 extra query Created: 17/May/11  Updated: 17/May/11

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: Guilherme Blanco Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Read the IRC log:

[2:38pm] guilhermeblanco: beberlei: ping
[2:38pm] guilhermeblanco: I'm curious about a feature if Doctrine supports
[2:38pm] guilhermeblanco: if we do this on a proxy:
[2:38pm] guilhermeblanco: $proxy->getOneToOneAssoc()
[2:39pm] guilhermeblanco: shouldn't Doctrine already populate the assoc entity?
[2:39pm] guilhermeblanco: it would be an inner join
[2:39pm] beberlei: how would doctrine know it needs it?
[2:39pm] guilhermeblanco: beberlei: it always repass the ClassMetadata to Persister
[2:40pm] guilhermeblanco: so all needed item is to also pass the fieldname/assocname
[2:40pm] beberlei: but how would doctrine know getOneToOneASsoc() really returns this assoc
[2:40pm] beberlei: it could contain any logic
[2:40pm] guilhermeblanco: it wouldn't... but as soon as we trigger __load($fieldName)
[2:40pm] guilhermeblanco: we know that we could populate not only the Proxy, but also assoc
[2:40pm] beberlei: by convention?
[2:40pm] guilhermeblanco: ya
[2:41pm] beberlei: sounds good, can you open a ticket?
[2:41pm] guilhermeblanco: getUser() would trigger __load('user')
[2:41pm] guilhermeblanco: sure!
[2:41pm] guilhermeblanco: I'll pastie this as content... it would be awesome to have
[2:41pm] guilhermeblanco: I see a lot of queries here that could be optimized 





[DDC-998] Code example for custom AST functions incorrect Created: 23/Jan/11  Updated: 23/Jan/11

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: Timo A. Hummel Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

On http://www.doctrine-project.org/docs/orm/2.0/en/reference/dql-doctrine-query-language.html#adding-your-own-functions-to-the-dql-language the code example is slightly incorrect.

Mistakes:

  • Lexer::T_ABS doesn't exist anymore, I assume Lexer::T_IDENTIFIER is what one wants to use
  • Missing use for \Doctrine\ORM\Query\Lexer

Additionally, the section should tell the user that he best has a look at lib/Doctrine/ORM/Query/AST/Functions/* to learn how to write custom functions. It also could be noted that stored procedures can be called with custom functions.






[DDC-947] Optmize Code-Generation Strategies Created: 24/Dec/10  Updated: 29/Mar/11

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

Type: Improvement Priority: Major
Reporter: Benjamin Eberlei Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None


 Description   

We should optimize code-generation somehow.



 Comments   
Comment by Benjamin Eberlei [ 29/Mar/11 ]

Descheduled to 2.x





[DDC-810] Issue with detaching entities and updating when using change notification Created: 17/Sep/10  Updated: 04/Jul/11

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

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

Attachments: File DDC810Test.php    

 Description   

More information coming soon. Attaching a test case



 Comments   
Comment by Benjamin Eberlei [ 20/Sep/10 ]

From reading the issue i know what the bug is, indeed this sucks.

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

@Jon: Any more information coming?

@Benjamin: Can you summarize the essence of the issue shortly?

Comment by Benjamin Eberlei [ 29/Sep/10 ]

@Roman: The UnitOfWork (may) still be pushed as a listener into that entity, and still recieve noticies of update. Which may throw notices because the oid hashes are removed everywhere. Additionally you cant serialize the thing because you still got the UoW inside there.

Comment by Jonathan H. Wage [ 04/Oct/10 ]

I don't have anymore information currently. The issue was relayed to me. I will try and find some more information and report back.

Comment by Benjamin Eberlei [ 03/Apr/11 ]

There is no way to "fix" this issue, i am turning it into a feature request. There needs to be a "postDetach" event that is triggered where the developer can detach the change notification objects.





[DDC-803] Create subselect queries within join statements Created: 14/Sep/10  Updated: 14/Sep/10

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: Martijn Evers Assignee: Roman S. Borschel
Resolution: Unresolved Votes: 0
Labels: None





[DDC-776] Persisters use a fixed "SELECT" SQL statements Created: 29/Aug/10  Updated: 23/Apr/13

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

Type: Improvement Priority: Major
Reporter: Aaron DM Assignee: Roman S. Borschel
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Windows 7, Apache 2.2, MSSQL Server, PHP 5.3.3



 Description   

I am currently trying to work with BINARY columns with Doctrine 2 and MSSQL. In order to get my Entities working I had to create a custom Mapping Type for Binary columns. All went well in this case and I've got it running.

The problem arises when I am attempting to use Associative mapping (OneToOne/ManyToMany). The problem is, in order to do a select for an SQL column, I had to create a DQL function called "CONVERT" so that I use WHERE statements:

return $this->createQueryBuilder('u')
->where("u.id = CONVERT('binary', :id, 1)")
->setParameter('id', $id)
->getQuery()
->getSingleResult();

As you see, I must do this in order to get a result.

However, when I'm using associative mapping; this is what it does:

return 'SELECT ' . $this->_getSelectColumnListSQL()
. ' FROM ' . $this->_class->getQuotedTableName($this->_platform) . ' '
. $this->_getSQLTableAlias($this->_class->name)
. $joinSql
. ($conditionSql ? ' WHERE ' . $conditionSql : '')
. $orderBySql
. $lockSql;

As you can see, its some what hard coded and I cannot change it without changing the actual code in
Doctrine\ORM\Persisters\BasicEntityPersister.php

So, I would first like to know if there was maybe a way you could allow us to customize the SELECT statement that the persisters use - or maybe (though I'm not sure how this will be done) make them use user-defined repository functions?

Like $myRepo->find($identifier)

Not entirely sure if I explained this properly and I do realize my circumstance is highly odd - but this does seem like a limitation and because of this I cannot use associative mapping.



 Comments   
Comment by locs [ 23/Apr/13 ]

Hi, i try to make my custom type for binary field in MSSQL.
I don't find own, can you please show me your custom type binary?
Thks a lot.





[DDC-769] Disabling discriminator column in WHERE clause Created: 26/Aug/10  Updated: 07/Sep/10

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

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


 Description   

Per default Doctrine 2 adds an IN(...)-part to the query when hydrating an entity where a discriminator column is defined. While this makes sense as a default behavior, it would be pretty helpful if one could disable the WHERE-clause for discriminator columns alltogether for performance optimization.



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

That would obviously produce wrong results. Maybe you can elaborate more with an example.

Comment by Lars Strojny [ 07/Sep/10 ]

I use ENUM("foo","bar") as discriminator columns. That means, the column will contain the right values out of the box, no further result set limiting required with WHERE.





[DDC-678] OneToMany/OneToOne + onDelete=CASCADE may corrupt UoW. Created: 10/Jul/10  Updated: 05/Jun/11

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: Roman S. Borschel Assignee: Roman S. Borschel
Resolution: Unresolved Votes: 0
Labels: None


 Description   

OneToMany/OneToOne associations together with an onDelete=CASCADE schema generation hint on the @JoinColumn and appropriate foreign key constraints can potentially result in a corrupt UoW if the associated objects are already managed. We need to add tests for such scenarios and settle on a well-defined behavior in such cases.



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

I think to preserve the semantics the following has to happen:

"on-delete" => "cascade" has to implicitly set cascade = remove. This hurts performance of course vs just using the on-delete, however it won't corrupt the UoW.

Comment by Benjamin Eberlei [ 02/Jan/11 ]

Not entirely would it hurt performance, you could check if on-delete => cascade is set. If this is the case you wouldnt need to do an explicit remove using the UnitOfWorks cascade.

Comment by Benjamin Eberlei [ 05/Jun/11 ]

Changed to improvement





[DDC-624] Partial object query that leaves out an association to avoid loading it fetches the association anyway. Created: 03/Jun/10  Updated: 11/Nov/11

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

Type: Bug Priority: Major
Reporter: Roman S. Borschel Assignee: Roman S. Borschel
Resolution: Unresolved Votes: 2
Labels: None

Issue Links:
Duplicate
is duplicated by DDC-1465 Fetching partial objects doesn't work... Open

 Description   

Assuming:

Customer <onetoone> Cart

where Cart is the owning side.

Since the association from Customer to Cart can not be lazy, it would make sense to leave out the association in a query to avoid loading the carts like this:

select partial c.{id,name, ... anything except cart} from Customer c"

But this is ignored and the carts of all customers are fetched anyway. Query::HINT_FORCE_PARTIAL_LOAD is an alternative solution, however it has the disadvantage that it disables lazy-loading for all queried objects. If partial querying would honor associations this would allow more fine-grained control.



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

Might need to be pushed back to a 2.0.x / 2.x.x bugfix release. Not clear yet.





[DDC-586] Repo does not find "unflushed" object Created: 14/May/10  Updated: 26/Aug/10

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

Type: Improvement Priority: Major
Reporter: John Kleijn Assignee: Roman S. Borschel
Resolution: Unresolved Votes: 0
Labels: None


 Description   

The problem is this:

$bar = new \entity\content\ContentTag();
$bar->setName('bar');
$em->persist($bar);

$existingTag = $em->getRepository('entity\content\ContentTag')->findOneByName('bar');

Seeing as in EntityRepository "find()" queries the Unit of Work first, and "findBy()" goes directly to the persister, only remotely stored objects will be found. Now if I want a tag object to attach related tags, it would have to query by name to see if an object already exist, BUT it wont find one as the UoW has not been committed, resulting in a new one being created, ultimately resulting in a PDO error on the unique name constraint.

This can be "solved" by inserting a flush, but it is impossible to know whether a flush is required, without knowledge of what comes next. I.e. for one part to know it has to flush, it has to know another wants to fetch an object you just created.

This causes an unacceptable amount of coupling.

Somehow the repo will have to be able execute DQL against the objects in the UoW. This does not have to be full support (straight away), but it should fail (throw an exception) if the possibility exists that the UoW contains items that are excluded (e.g. the operation is not supported and the UoW still contains items).

For right now, this means the EntityManager should throw an exception if DQL is executed on the type when the UoW is not empty. Until the time that the EntityManager can query the UoW using DQL. The alternative would be to "flush" before every operation that goes to the database for data.



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

Hi,

you mention a good point, however, this currently only affects findBy queries made through a repository. A DQL query already triggers a flush when there are pending insertions but this still has its own problems. First of, querying against the objects in the UoW is not a viable solution in my eyes.

For a regular find() (by identifier) the situation is clear anyway, you must flush prior to a lookup on an entity you previously persisted in the same request because, by definition, generated primary key values are only guaranteed to be available after the next flush.

Automatic flushing if the UoW has pending inserts (new objects) and a query is executed (either through DQL or a repository) currently has its own set of problems, namely that it is still subject to infinite recursion if such a query is triggered in an event (listener) that executes during commit of a UoW, and secondly, that it will easily lead to double-flushes that cause unnecessary overhead (currently a flush() even if nothing needs to be done is not free because the UoW actually has to check whether nothing needs to be done). Both of these problems could be addressed with some sort of flags, but the question still is whether its not better to flush manually in the first place.
That would mean, in your example, you should flush after persisting the new objects, irrespectively of what code comes next, you persisted (a) new object(s) and you want to make sure these are fully available to the rest of the script.

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

Furthermore, automatic flushing when there is no transaction active is probably also not a great idea, as it may split a single unit of work (that was supposed to be atomic) into 2 without the user knowing about it. So auto-flushing should better only happen when a transaction is active (i.e. explicit transaction demarcation is used).

Comment by John Kleijn [ 14/May/10 ]

That would mean, in every example, you should flush after persisting new objects, period. If I flush in some cases and not in others, I'm asking for issues that may not be caught by tests. It's an inconsistency that I personally am not comfortable with.

Could be that I'm overlooking something, I've just started playing with D2.

Why is querying against registered objects not viable? It's not easy, granted, but it doesn't seem impossible. There should probably be a layer between the UoW and the "persisters" (Data Mappers?).

RE: the UoW double flush: state management on the UoW as a whole should prevent that. i.e. after a commit the whole UoW is clean? Just a suggestion, as I said, still getting my bearings.

On a side note I just want to say that what I've seen so far, for the better part, pleases me greatly. Kudos.

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

@"That would mean, in every example, you should flush after persisting new objects, period."

Yes, if you want the objects to be visible to queries in the same request. Generally, you should flush when you complete a unit of work and that is usually not the whole request (but can be).

I don't want to "query" against registered objects because it is a) not easy b) likely a lot of code and c) very likely error-prone. And in addition I don't see this helping with solving any inconsistency. If you want to use find() you have to flush anyway because you can not find() without having the identifier in the first place, which is only available after a flush.

@RE: the UoW double flush:

Yes, like I said, it can be done but it is a compromise. Having a "clean/dirty" flag in addition to calculating the changesets of the work to do (which implicitly tells us whether the UoW is dirty) adds more code and more potential for errors. Forget to update the flag in one location and you get flushes that don't do anything, because the flag was not updated. A dirty-flag for the UoW is not really required for proper working. It is similar to the approach of maintaining a separate counter for the number of elements in a collection implementation: can make many size/count requests faster but complicates the internal implementation and increases the likelihood for errors (and lock contention for the counter in a thread-safe/concurrent implementation, an interesting case where performance goes against scalability, but I digress and that does not apply to php obviously). That said, I am not strongly opposed to doing this.

If you're interested in how this is specified by "big brother", take a look at section 3.8.7 of the JPA 2 specification. Shortly, with the default behavior it requires the implementation to ensure that unflushed changes are visible to queries which can be achieved by flushing these to the database automatically but only if a transaction is active, otherwise the implementation must not flush to the database. There is alternatively also a "MANUAL" flush mode, in that case the effect of updates made to entities in the UoW upon queries is unspecified. We do not have different flush modes anymore, however, in Doctrine.

So I see two possible ways to go here:

1) More effort, more code, (really better?)

  • Maintaining a dirty flag in the UoW (this could be done anyway at some point, even if 2) is chosen)
  • Maintaining a flag to avoid infinite recursion triggered from events within a UoW commit/flush
  • Flushing automatically when querying while there are pending inserts and a transaction is active

2) No effort, less code

  • Removing the current auto-flush on DQL queries which is still subject to infinite recursion
  • No automatic flushes, anywhere (less magic, so to speak?)
  • Clearly documenting that new, unflushed entities are not visible in subsequent queries issued in the same request, and if this is desired, a flush should be issued.

That's how I see it. Now we need some votes and volunteers for the implementation Personally, I am not sure yet about which version I prefer, 2) does not sound too bad for me.

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

In Nr. 1) the case with the infinite recursion may actually be more problematic. I think you simply can not see unflushed new objects in queries made during a UoW commit.

Comment by John Kleijn [ 14/May/10 ]

When there's no in-memory objects inclusion, I'd say 2) as well. Again, I have no idea how this is implemented currently, but I would prefer something like this:

$repo->start();

$repo->register($object);

$repo->commit();

Why?

  • Commit instead of flush: "flush" has little semantic value IMO, "commit" leaves no questions: you're committing your changes (which implies that they are not, before)
  • Operating on the repo leaves no question to what you are committing: changes of the associated type and relations configured to cascade, made after start()
  • Register instead of persist: "persist" is misleading as the object is not immediately persisted, and as my example shows, may not be.

The way I see it "start" would create a UoW associated with the repo, "commit" would calculate changes and write (the enitity manager would make sure references in other UoWs are removed).

Because the way it is currently implemented (or so it seems), it's unclear when to flush and when not to flush, and unclear what I'm flushing at any one point in the code (because it is not locally isolated). If I have to decide whether to flush in some bit of client code, I am apparently making an assumption about the target entity, i.e. coupling.

I know, you already went beta, so it's unlikely you would consider such a large change, but anyway, for your consideration.

Finally, I realize I'm borderline nagging now as you've made it clear you see nothing it, but a Repository (as in the PoEAA pattern, p 322) may provide a method of fetching native in-memory objects using criteria, acting as a "buffer" between code and database. The Repository in D2 does effectively nothing but delegate to the UoW (or mostly to the underlying persister). Ref PoEAA 327 for an example of an in-memory strategy. As a final point of critique, the Repository does not always seem to be used as entry point for data requests, which is the whole point of the pattern. Most of what's in EntityManager, should be in EntityRepository ("manager" is a bit to abstract a concept to expect clear responsibilities anyway). EntityManager::find() delegates to EntityRepository, but pretty much everything else is the other way around. EntityManager would be better off named DataGateway, as that accurately describes its intended function.

I admit, it would be very difficult to use DQL on in memory objects, but it would be far superior and if it work lead to much more predictable behaviour. It's the ONLY way the data store is ever going to be truly transparent. A few examples (DQL from the docs):

SELECT
u,
UPPER(u.name) nameUpper
FROM MyProject\Model\User u

  • Fetch everything from the db
  • Select all objects from the User UoW
  • Iterate over the in memory ones and modify the name property to upper case
  • Merge the results and return

SELECT u FROM User u WHERE u.id = ?1 OR u.nickname LIKE ?2 ORDER BY u.surname DESC

  • Execute against database
  • Iterate over the User UoW, indexing by "surname", adding items that match the criteria
  • Merge the results and return

With joins it could get more complex, provided you want to intelligently merge results into existing objects. Question is whether that is really needed, but there's obviously a performance benefit. Actually this may already be implemented.

I suspect there are edge cases, rooted in DQL still being based on SQL, but in theory it should be possible. Likely you would still want to do start(), and delegate to the driver to start an actual transaction to prevent inconsistent reads... The only way to find out if it's truly feasible is to to try it, I think.

Ramble, ramble, ramble, I'm done. I know I seem critical, but it's positive critique, I love the direction you went with D2.

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

Maybe I was not clear, with approach Nr.1 there would be in-memory objects inclusion (of new objects), in fact, there always is, due to the identity map. When you query for objects and some of them are already in memory, these are used, not again reconstructed.

The EntityRepository provided by Doctrine is just a convenient mechanism for writing your own repositories. There are many different understandings for what a repository is, you can make it whatever you want it to be. Is a PoEAA repository the same as a DDD repository? Anyway, the repository could be stripped of the project, it is optional, the state management is handled by the EntityManager and UnitOfWork. These are the core components. I agree that the delegation from EntityManager#find to the repository is suboptimal in this regard and should be the other way around.

Now to your question: "When should I flush?". Generally, you should flush at the end of a transaction, which in turn is a unit of work. That means, use explicit transaction demarcation. begin() ... flush() commit(). I've added some control abstractions recently that should make this even easier. I can only recommend to explicitly demarcate your transaction boundaries. As you probably know, you can not talk to your database outside of a transaction anyway. The default behavior (flush() wrapping all its stuff in a transaction) is for convenience mostly and so as not to alienate or confuse people even more who are used to autocommit mode.

Concerning the naming, we mostly stick with the JPA specification and I, for one, really like the naming and I don't want to invent new names. PoEAA is far more abstract (and the examples far too specific) than what is specified in JPA, so I recommend giving that a read. The patterns in PoEAA obviously and intentionally leave a lot of room for different variants of implementation and also leave open a lot of open questions (many of the difficult questions especially, it is for a reason that the author recommends using an existing tool instead of writing your own). In my opinion it is just not feasible to query in-memory objects in a generic way, all the examples in PoEAA do not have generic but rather concrete code examples, which is obviously a lot easier. The feasible strategy, and that is what we do, is to do in-memory lookups only when querying by PK, otherwise the query is executed and afterwards nevertheless any objects reused that are already in memory (based on the PK) and not reconstructed. This is the approach we use.

Thanks for your input, I do see that you are an experienced fellow in object-relational persistence, maybe we can see you as a committer some day?

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

@ "SELECT u, UPPER(u.name) nameUpper FROM MyProject\Model\User u"

This selects all users and their names in uppercase, the uppercase names are scalar values, the users are not modified! Scalar values are separate from objects.

@ "... and unclear what I'm flushing at any one point in the code"

flush() means: Synchronize the in-memory state of my objects with the database, making any changes that are only in-memory persistent. Nothing more, nothing less.

Again, objects are always reused based on the identity map and the state that is in-memory prevails, unless you use refresh() or execute a query with the Query::HINT_REFRESH query hint. All objects you fetch from DQL, be it as a root object or as a joined association, are first looked up in-memory (but after the SQL query has been issued!).

Maybe we have been talking past each other here, what I refer to as not feasible is querying the in-memory objects first in some way, even before the SQL query. This is just too complicated and error-prone, except for the simple case of a PK lookup and that is where we do it already.

Comment by John Kleijn [ 14/May/10 ]

> Scalar values are separate from objects.

Right. Bad example.

> flush() means: Synchronize the in-memory state of my objects with the database, making any changes that are only in-memory persistent. Nothing more, nothing less.

I realize that it means that, but commit() would be more obvious.

> Maybe we have been talking past each other here, what I refer to as not feasible is querying the in-memory objects first in some way, even before the SQL query. This is just too complicated and error-prone, except for the simple case of a PK lookup and that is where we do it already.

Fair enough, you don't think it's feasible, so we'll keep it at that. Maybe I'll give it a shot some time.





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

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

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


 Description   

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

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

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

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


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

i just found a possible BC issue with this.

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

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

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

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

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

Comment by Benjamin Eberlei [ 27/Apr/10 ]

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

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

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

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

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

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

Comment by Johnny Peck [ 19/Nov/10 ]

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

Comment by Guilherme Blanco [ 16/Apr/14 ]

Moving to 3.0 as this can potentially create BC breaks





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

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

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


 Description   

We need a new coding standards document for Doctrine 2.



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

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

Comment by Marco Pivetta [ 29/Jan/13 ]

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

Comment by Benjamin Morel [ 29/Jan/13 ]

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

Comment by Benjamin Morel [ 30/Jan/13 ]

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

Please comment!

Comment by Benjamin Morel [ 11/Feb/13 ]

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

Comment by Benjamin Morel [ 02/Aug/13 ]

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

Comment by Marco Pivetta [ 02/Aug/13 ]

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

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

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





[DDC-3098] [GH-1016] improved error handling for invalid association values Created: 23/Apr/14  Updated: 23/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 flip111:

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

Message:

Possibly to do:
1. Make custom Exception for line 713
2. Make custom Exception for line 817
3. Does the object check on line 816 slow down the code too much? Alternatively a try-catch could be put around line 1415 or higher up.






[DDC-3110] paginator doesn't respect order by clause when using the fetchJoinCollection flag Created: 30/Apr/14  Updated: 30/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: Greg Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

MariaDB 5.5



 Description   

I have a DQL query with a ORDER BY clause.
When I paginate the result with new Paginator($query, $fetchJoinCollection = true); the orderind isn't correct.
The order is lost in the second request (Perform a Limit Subquery with DISTINCT to find all ids of the entity in from on the current page)

It creates a SQL query like that :
SELECT
DISTINCT id0
FROM
(
SELECT
d0_.id AS id0,
d0_.name AS name1,
d0_.note AS note2,
FROM
data d0_
ORDER BY
d0_.note DESC
) dctrn_result
LIMIT
20 OFFSET 0

The external SELECT don't keep the order so it just fetch the 20 first elements from the whole table.






[DDC-2339] [GH-605] DDC-2338 Added failing test for composite foreign key persistance Created: 07/Mar/13  Updated: 13/May/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: 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

Comment by Doctrine Bot [ 13/May/14 ]

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





[DDC-2424] Removing an inherited entity via a delete cascade constraint does not remove the parent row Created: 02/May/13  Updated: 25/Apr/14

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

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

Mysql 5.1.66 / Symfony 2.2.1



 Description   

For a parent class:

/**
 * @ORM\Entity
 * @ORM\Table(name="Base")
 * @ORM\InheritanceType("JOINED")
 * @ORM\DiscriminatorColumn(name="discr", type="string")
 * @ORM\DiscriminatorMap({"child1" = "Child1", "child2" = "Child2"})
 */

and simple Child1 & Child2 entities.

With another entity (let's call it ExternalEntity) having a bidirectional OneToOne relation owned by Child1:

class Child1 extends Base
{
  /**
   * @ORM\OneToOne(targetEntity="ExternalEntity", inversedBy="xxx")
   * @ORM\JoinColumn(onDelete="CASCADE", nullable=false)
   */
   private theForeignKey;
}

Enough for the context.
The symptoms:

$em->remove(instanceOfExternalEntity);

removes the ExternalEntity row and the Child1 row. But a dangling row in the Base table is still there for the now inexistent Child1 instance.

Though, a manual delete of either the associated Child1 OR Base row and then the ExternalEntity works.

The problem with the cascading deletion of the parent seems to be only present when deleting through a MYSQL cascading delete from another row which has a foreign key on a child. (Not tested with a foreign key on the parent though)



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

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

Comment by Bruno Jacquet [ 06/May/13 ]

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

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

Comment by Bruno Jacquet [ 06/May/13 ]

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

Comment by Bruno Jacquet [ 06/May/13 ]

Maybe using

cascade={"remove"}

, instead of

onDelete="CASCADE"

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

Comment by J [ 25/Apr/14 ]

I've got a similar problem but I have InheritanceType("SINGLE_TABLE") instead of JOINED.
Any updates on when this is getting fixed?





[DDC-3122] Querying entities with ResolveTargetEntity Created: 14/May/14  Updated: 15/May/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: Heo Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Hello

The problem refers to a following situation:
You have 2 classes that use a quite simple inheritance and an interface:

interface CInterface { /* ... */ }
class AClass implements CInterface { /* ... */ }
class BClass extends class AClass { /* ... */ }

When we configure the ResolveTargetEntityListener the following way:

array(
  'CInterface' => 'BClass'
)

when using the entity manager to find an entity:

$entityManager->find('BClass', $id);

we'll get a following Doctrine\DBAL\DBALException:

An exception occurred while executing 'SELECT t1.id AS id2 FROM bclass_table_name t1 WHERE t0.id = ?' with params [1]:

SQLSTATE[42S22]: Column not found: 1054 Unknown column 't0.id' in 'where clause'

As you can see the column names are generated properly but the WHERE clause has an invalid refference to t0 table (should be t1).

Similar problem:

http://stackoverflow.com/questions/17588682/doctrine-inheritance-replacement



 Comments   
Comment by Marco Pivetta [ 14/May/14 ]

Is AClass a mapped superclass or the root of the inheritance?

Comment by Heo [ 15/May/14 ]

AClass is the root of the inheritance. I would like to add that the only problem is the "find" method. Database relations are created properly (with the SchemaTool), all keys refer to proper columns.

Comment by Marco Pivetta [ 15/May/14 ]

Heo can you abstract a test case for this?





[DDC-3130] [GH-1033] [WIP] Lazy criteria for ManyToMany collection Created: 18/May/14  Updated: 18/May/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/1033

Message:

This continues my previous work on making Criteria most efficient.

Currently we are wrapping matching calls on repositories and matching calls on EXTRA_LAZY associations around a LazyCriteria. However, ManyToMany are still completely loaded: https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/PersistentCollection.php#L874

This is still problematic from a performance point of view because count, contains... cannot be optimized. I think the solution is similar to previous one, hence creating a Lazy collection for that kind of associations.

However, this is really tricky to do because of the whole mess inside the persisters (can't wait for them to be completely refactored, it's getting really hard to maintain this mess ).






[DDC-1739] [GH-314] [WIP] Doctrine\Common metadata drivers reuse Created: 30/Mar/12  Updated: 19/May/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: 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 Ocramius:

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

Message:

This PR is strictly related with https://github.com/doctrine/common/pull/98 and tests won't pass until the doctrine-common submodule points to a merged version of it (will do so later, so please don't merge now ).

Basically, I just stripped any code duplicate of what already available in dcom master under Doctrine\Common\Persistence\Mapping\Driver.

Tests are OK on my environment when using the new commons submodule.

(This is a cleanup for #263, where I sadly did pull from the remote branch after rebasing)

Tests are still failing.



 Comments   
Comment by Benjamin Eberlei [ 30/Mar/12 ]

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

Comment by Benjamin Eberlei [ 30/Mar/12 ]

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

Comment by Benjamin Eberlei [ 30/Mar/12 ]

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

Comment by Benjamin Eberlei [ 30/Mar/12 ]

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

Comment by Benjamin Eberlei [ 01/Apr/12 ]

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

Comment by Benjamin Eberlei [ 04/Apr/12 ]

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

Comment by Benjamin Eberlei [ 06/Apr/12 ]

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

Comment by Benjamin Eberlei [ 07/Apr/12 ]

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

Comment by Doctrine Bot [ 19/May/14 ]

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





[DDC-3016] Criterias do not work with embeddables when matching in memory Created: 07/Mar/14  Updated: 22/May/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


 Comments   
Comment by Matthieu Napoli [ 22/May/14 ]

I have opened a PR with a potential fix: https://github.com/doctrine/collections/pull/27





[DDC-3149] [GH-1046] Fix the "Erroneous data format for unserializing" error message Created: 03/Jun/14  Updated: 03/Jun/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 peterjmit:

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

Message:

Backport patch from PR #1045 to 2.3 branch.

@ocramius - I'm not sure if this is viable, but based on the comments from people it could be helpful to have this fixed in 5.3? I'm not 100% sure whether PHP or Doctrine is at fault here?



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

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





[DDC-3161] [GH-1054] SQLFilters enahancements Created: 10/Jun/14  Updated: 10/Jun/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 v3labs:

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

Message:

SQL filters in Doctrine are a bit too limited for my taste.
This pull request makes the current connection available inside sql filter classes.
The connection is needed to quote identifiers or values and generate sql statements for the current database. (sample use-case https://github.com/Atlantic18/DoctrineExtensions/blob/master/lib/Gedmo/SoftDeleteable/Filter/SoftDeleteableFilter.php)
Currently you can access the connection only through reflection which let's face it - is a hack.

I've also made the class depend on EntityManagerInterface instead of EntityManager.

There's a test for the new method.






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

Status: Awaiting Feedback
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: 2.3.5, 2.4.2
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

Comment by Litz Ouille [ 28/May/14 ]

Doctrine ORM 2.4.2 Here.

Here are my annotations
https://gist.github.com/LitzOuille/3cf2e73e169c032147ea

The thing I'm trying to do is
$questionRepository->findBy(array('contacts' => $ids)); // $ids = array(1,2,3, ...)

Comment by Marco Pivetta [ 30/May/14 ]

Calin Pristavu did you validate your mappings?

Comment by Calin Pristavu [ 30/May/14 ]

I failed, sorry.
The error came from the many-to-many condition in the entity.
Sorry for generating confusion, comment deleted !

The many-to-one works just fine !

Comment by Litz Ouille [ 03/Jun/14 ]

A little feedback? Is this a bug? Can it be fixed?
Thanks

Comment by Marco Pivetta [ 03/Jun/14 ]

Litz Ouille that particular repository call cannot work. How are we supposed to find an entity from a list of associated IDs? It would have to be the exact match...

Assuming that API would work as I envision it, it looks like a missing feature.

Dennis Væversted in order to accept a patch, we first need a failing test case demonstrating the failing scenario.

Comment by Litz Ouille [ 03/Jun/14 ]

EDIT: Ok my bad.

I am using findBy(array('id', $arrayIds)) and it is working. I thought I was using on a ManyToOne relationship, but no.

EDIT2: @ocramius In fact I would like to find all questions for which the contacts' list contains at least one id. Something like
SELECT q.*
FROM Question q, QuestionContact qc //qc = jointable
WHERE q.id = qc.question_id
AND qc.contact_id IN ($ids)

EDIT3: Actually when I try to findBy('ManyToMany', $id), it does not work either. I think I will have to use a repository for every query using a ManyToMany relationship.

EDIT4: Ok, so, as said in the original post, findBy does not work with many-to-many.
Notice: Undefined index: joinColumns (BasicEntityPersister.php line 1666)
Dump($this->class->associationMappings[$field]): https://gist.github.com/LitzOuille/51929fdc3eda5576ed31

Comment by Xander ten Boden [ 13/Jun/14 ]

I've got the same issue, also running doctrine 2.4.2:

multiple users can have multiple departments:

/**
 * @ORM\ManyToMany(targetEntity="CartelAuthDepartment", inversedBy="users")
 * @ORM\JoinTable(name="cartel_auth_user_has_cartel_auth_department",
 *		joinColumns={@ORM\JoinColumn(name="cartel_auth_user_id", referencedColumnName="id")},
 *		inverseJoinColumns={@ORM\JoinColumn(name="cartel_auth_department_id", referencedColumnName="id")}
 * )
 */
private $departments;

/**
 * @ORM\ManyToMany(targetEntity="\Cartel\AuthBundle\Entity\CartelAuth\CartelAuthUser", mappedBy="departments")
 */
private $users;

Then I want to find all the users that are within the departments that the current user has:

$aAuthUsers = $oEm->getRepository('CartelAuthBundle:CartelAuth\CartelAuthUser')->findByDepartments($aAuthDepartments);

This results in this error:

Notice: Undefined index: joinColumns in .../vendor/doctrine/orm/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php line 1665





[DDC-3171] [GH-1060] [DDC-3170] SimpleObjectHydrator fails to get discriminator column from mapped SQL result Created: 17/Jun/14  Updated: 17/Jun/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 ureimers:

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

Message:

This PR fixes DDC-3170(http://www.doctrine-project.org/jira/browse/DDC-3170).

When querying a simple entity which uses single table- or class table inheritance using simple object hydration (``AbstractQuery::HYDRATE_SIMPLEOBJECT``), the mapped discriminator column was not retrieved correctly.

If the column got an alias during result set mapping other than it's actual name (e.g. ``type34`` instead of ``type``) than this alias wasn't correctly resolved when retrieving the discriminator column from the SQL result set.



 Comments   
Comment by Ulf Reimers [ 17/Jun/14 ]

I created DDC-3170 for this and put it into the PR like stated in https://github.com/doctrine/doctrine2/blob/master/CONTRIBUTING.md#doctrinebot-tickets-and-jira.

Unfortunately the BOT still created this issue here which can be removed in my opinion.

Comment by Doctrine Bot [ 17/Jun/14 ]

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





[DDC-3182] [GH-1066] Added jsonSerialize method to PersistentCollection Created: 22/Jun/14  Updated: 22/Jun/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 gabrielbull:

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

Message:

Added jsonSerialize.

Here is to commit on collections:
https://github.com/doctrine/collections/pull/33



 Comments   
Comment by Doctrine Bot [ 22/Jun/14 ]

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





[DDC-3191] [GH-1072] Fix attempt of traversing bool in FileLockRegion Created: 26/Jun/14  Updated: 26/Jun/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 kamazee:

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

Message:

Minor fix: on some platforms (i.e. ArchLinux) `glob()` returns `false` when nothing matched even though no errors occurred. As docs for `glob` say, such behavior is expected (see ‘Note’ at http://php.net/glob)

This made 1 existing test fail:

./vendor/bin/phpunit 
PHPUnit 4.3-g58f3a0e by Sebastian Bergmann.

Configuration read from /home/alex/git/doctrine2/phpunit.xml.dist

.............................................................   61 / 2495 (  2%)
........S.............E......................................  122 / 2495 (  4%)
.............................................................  183 / 2495 (  7%)
.............................................................  244 / 2495 (  9%)
.............................................................  305 / 2495 ( 12%)
.............................................................  366 / 2495 ( 14%)
.........................S...SSSS.S..........................  427 / 2495 ( 17%)
.............................................................  488 / 2495 ( 19%)
....................................................SS.......  549 / 2495 ( 22%)
.............................................................  610 / 2495 ( 24%)
.............................................................  671 / 2495 ( 26%)
.............................................................  732 / 2495 ( 29%)
.............................................................  793 / 2495 ( 31%)
.......................................................S.SSSS  854 / 2495 ( 34%)
SSSSSSSS.....................................................  915 / 2495 ( 36%)
.........................................SS..................  976 / 2495 ( 39%)
............S...S...........S..............................S. 1037 / 2495 ( 41%)
............................................................. 1098 / 2495 ( 44%)
..................S.......................................... 1159 / 2495 ( 46%)
.................................................SS.......... 1220 / 2495 ( 48%)
.......................S..................................... 1281 / 2495 ( 51%)
............................................................. 1342 / 2495 ( 53%)
............................................................. 1403 / 2495 ( 56%)
............................................................. 1464 / 2495 ( 58%)
............................................................. 1525 / 2495 ( 61%)
............................................................. 1586 / 2495 ( 63%)
.........S.................................................S. 1647 / 2495 ( 66%)
............................................................. 1708 / 2495 ( 68%)
............................................................. 1769 / 2495 ( 70%)
............................................................. 1830 / 2495 ( 73%)
............................................................. 1891 / 2495 ( 75%)
............................................................. 1952 / 2495 ( 78%)
............................................................. 2013 / 2495 ( 80%)
............................................................. 2074 / 2495 ( 83%)
............................................................. 2135 / 2495 ( 85%)
............................................................. 2196 / 2495 ( 88%)
............................................................. 2257 / 2495 ( 90%)
............................................................. 2318 / 2495 ( 92%)
............................................................S 2379 / 2495 ( 95%)
.......S......S.......S.....................S...........S.... 2440 / 2495 ( 97%)
.......................................................

Time: 14.37 seconds, Memory: 164.50Mb

There was 1 error:

1) Doctrine\Tests\ORM\Cache\FileLockRegionTest::testEvictAll
Invalid argument supplied for foreach()

/home/alex/git/doctrine2/lib/Doctrine/ORM/Cache/Region/FileLockRegion.php:204
/home/alex/git/doctrine2/tests/Doctrine/Tests/ORM/Cache/AbstractRegionTest.php:80

Traversing bool is no good and casting to array wouldn't hurt there as far as I can tell.






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

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

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


 Description   

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

Examples:

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

Comment by Glen Ainscow [ 25/Jan/10 ]

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

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

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

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

Close if you disagree.

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

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

There's just no point in arguing about readability.

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

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

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

Comment by Guilherme Blanco [ 25/Jan/10 ]

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

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

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

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

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

Comment by Glen Ainscow [ 25/Jan/10 ]

@Roman,

Just a feeling I got.

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

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

I agree that Id. is an abbreviation.

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

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

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

Thanks for your help!

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

Comment by Glen Ainscow [ 25/Jan/10 ]

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

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

Comment by Glen Ainscow [ 25/Jan/10 ]

Found some time ...

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

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

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

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

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

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

We should try to go through that list before beta.

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

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

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

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

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

Pushing the rest of the name changes towards beta2.

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

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

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

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

Comment by Benjamin Eberlei [ 31/Oct/10 ]

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

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

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

Comment by Guilherme Blanco [ 16/Apr/14 ]

Scheduled to 3.0 as this may potentially create BC breaks





[DDC-213] Persist order of collections Created: 15/Dec/09  Updated: 27/Jun/14

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

Type: New Feature Priority: Major
Reporter: Roman S. Borschel Assignee: Roman S. Borschel
Resolution: Unresolved Votes: 15
Labels: None

Issue Links:
Duplicate
is duplicated by DDC-181 Order of many-to-many relationship Resolved
Reference
is referenced by DDC-250 ArrayCollection Key Column @indexBy Resolved

 Description   

A Collection is like a php array, an ordered map. Hence there should be the possibility to persist this order.



 Comments   
Comment by Christian Heinrich [ 21/May/10 ]

Roman, I'd like to do this one as I have currently a use case for this. Do you have any idea of how to do this? What I'm wondering is whether it is possible to implement this without user intervention. (This would simply mean "store the entities as they were added"). But this would need another column in DB that we'd have to add within oneToMany / manyToMany relationships, but in this case one could save a serialized array holding "entityId => position" key / value pairs.

Afterwards, one could easily rebuild / reorder the collection via $collection->set($entity, $order[$entity->identifier]);

If you've got another thought about this, please don't hesitate to point me into the right direction!

Comment by Benjamin Eberlei [ 22/May/10 ]

this won't be implemented until 2.1, since its a pretty complex feature.

Changes are probably required in:

1. CollectionPersister - Add a new collection persister that takes the position into account
2. SchemaTool - Add a 'col_position' column to either the many-to-many or the one-to-many tables.
3. EntityPersister - Use and extend current order-by support to make the sorting happen

You can implement this already though with some performance hit in update scenarios. If you use the ORDER BY support and implement an API around your entity that abstracts those changes and always sets a "position" field on the many entity that is supposed to be sorted.

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

I don't think we necessarily need a new collection persister. Simply adjusting the ManyToManyPersister to be able to deal with it might be sufficient.

For OneToMany, that is always persisted from the "many" side, thus there is no collection persister, we would need to adjust the normal persisters.

They key element for the user should be a new annotation (or corresponding xml/yaml element) @OrderColumn. By default the order should not be persistent, only when an @OrderColumn annotation is present. The name of the order column can have a default, i.e. "position". Thus this enhancement of persisting the order should be fully backwards compatible.

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

On another note, the getInsertDiff/getDeleteDiff methods of PersistentCollection should already be "ready" for this. That is, when an element in the collection changed only its position, this is already tracked as a change. However the ManyToManyPersister issues no "UPDATE" queries, it simply deletes and inserts. A position change may be more effectively persisted with an UPDATE.

Comment by Benjamin Eberlei [ 30/Sep/10 ]

From a mailinglist entry, required check/changepoints:

1. ClassMetadata of Many-To-Many associations have to be extended to publish the required datastructure to the ORM.
2. All Metadata Mapping Drivers have to be extended
3. Persisters\ManyToManyCollectionPersister has to be extended to save the key in the many to many table if desired by the user.
4. Schema-Tool has to be extended to create the additional column.
5. PersistentCollection has to be extended so that lazy loading of collections with additional key works.
6. Array- and ObjectHydrator have to be extended to allow fetch join of collections with key column.
7. Discuss wheather to support this for One-To-Many also with the key-column on the many side. This is much more tricky internally though.

Comment by Benjamin Eberlei [ 24/Dec/10 ]

Push back to 2.x, we will have support for DDC-250 first and for this at a later release.

Comment by Thomas Tourlourat - Armetiz [ 07/Feb/12 ]

Hi there,
I'm looking for this feature.

Benjamin Eberlei said that : "You can implement this already", but I don't understand the "how to".

Also,
The problem should be solve if RDBMS had a "natural" order. An order based on item position inside table.

To get this feature without any change on Doctrine, I have remplace the PK defined by the target & mapped field identifier. The new PK is a new field with type "integer" and with auto-increment enable.
In this configuration, Doctrine use the "natural" order of the RDBMS. And I can change order of my item inside Collection and persist it.

It's an very bad solution, but It work before an official support.

Waiting for advices, and solutions,

Thomas.

Comment by Thomas Tourlourat - Armetiz [ 08/Feb/12 ]

Answering to Benjamin Eberlei on the "7. Discuss wheather to support this for One-To-Many also with the key-column on the many side. This is much more tricky internally though.".

I think that for One-To-Many relations, if user want to store the collection order, Doctrine can store the One-To-Many as Many-To-Many with a "model" limitation.
In that case, if storing order collection for Many-To-Many work, it should work for One-To-Many.

What do you think about it ?

Comment by Nicolas [ 29/Feb/12 ]

I think that it must be possible to have two keys ordering : the order isn't obligatory reversible.

For exemple with user and group :

  • You can order groups for one user : with preference by exemple, or importance.
  • And with a different order, users for a group : rank by example.

And maybe more, if you decide to add multi-order : an user show group by his rank in it, if his rank is identical, the order is make by love preference, and after by the importance given by the user (not necessary a number, if we imagine filter on them).

So a default order can be choice with parametized fields and could be :

 
@ManyToMany(targetEntity="Group")
...
@JoinFields ( rank: { type: int} , preference:{type:int}, importance:{type: string, length: 40} )
@OrderByJoinFields({"rank" = "ASC", "preference"="ASC", "importance"="ASC" } )

In this case the order must be optional and would be clean if another order appears in the same scope (DQL...). And manytomany became virtual entities act as other entities except they don't appears permetting in the same time a better conception.

So if the solution take in DDC-181 will become the only solution. This would a good idea to document this. Because, this seems to me a very important point.

My last point is even an unique ordering field created in the join table will be a big and usefull improvement.

Thank a lot for your beautiful work.

Comment by Thomas Tourlourat - Armetiz [ 29/Feb/12 ]

In my point of view, a collection can be order in a single way only.
If you want to add more than one order between User & Group, it's a new collection, a new relation.
Like :

  • User.memberOf() : Group[]
  • Group.members() : User[]
  • Group.importantMembers() : User[]

And it's your role to keep a consistency between members & importantMembers array.

Because ManyToMany join table is the reflection of a state of an ArrayCollection. It's not a usefull feature to be able to store all of the state of an ArrayCollection, even the order of this Array. It's just a normal feature that is really missing

Thomas.

Comment by Nicolas [ 29/Feb/12 ]

I don't think:

If you have three collection, you duplicate one relation 3 times and it's easy in consequence to lost the data integrity and unicity.

By example :

  • Thomas have rank 10 in Admin
  • Thomas think the admin group has importance noted 3 on all of his groups.
  • If a responsable of admin group decide to delete Thomas from it.
  • Thomas, in his ordered list of groups, think always to be in group admin.

So in my idea, the many to many relation isn't just an array collection, but should be an virtual entity. In UML or in Merise method this is a common problem to have a parametized relation. I think an orm should just implement this.

Comment by Thomas Tourlourat - Armetiz [ 29/Feb/12 ]

Hum,
I agree with you.. In a SQL Schema, it's a good choice to add many fields in a ManyToMany join table to description "order".

Comment by Thomas Tourlourat - Armetiz [ 07/Mar/12 ]

I just want to add a piece of Doctrine ORM Document :

"When working with collections, keep in mind that a Collection is essentially an ordered map (just like a PHP array). That is why the remove operation accepts an index/key. removeElement is a separate method that has O ( n) complexity using array_search, where n is the size of the map."

Comment by Thomas Tourlourat - Armetiz [ 23/Mar/12 ]

Hi there,
After several discussions. on IRC, I have changed my point of view.

Doctrine Documentation says : "When working with collections, keep in mind that a Collection is essentially an ordered map (just like a PHP array)".
So, I think that Doctrine have to be able to store or not the order of a Collection. By adding a new field on the Joined table to store the position of each elements.

But I not agree with @Nicolas. Because in his case, he's talking about Association Class : http://etutorials.org/Programming/UML/Chapter+6.+Class+Diagrams+Advanced+Concepts/Association+Class/
Because he's talking of a business logic, he's talking of a dedicated Entity class.

What do you think about it ?

Thomas;

Comment by Thomas Tourlourat - Armetiz [ 31/Aug/12 ]

Any news ?

Comment by Matthieu Napoli [ 16/Oct/12 ]

Hi, any news on this?

If I may add any info to this feature request, maybe something like JPA/Hibernate could be a good start?

See http://docs.oracle.com/javaee/6/api/javax/persistence/OrderColumn.html or http://docs.jboss.org/hibernate/core/3.6/reference/en-US/html/collections.html#collections-indexed

The idea in Hibernate is that you persist the order of the list in an extra column. This column is not a field of the entity however.

Comment by Albert Casademont [ 27/Jun/14 ]

+1, this would be indeed a very nice thing. We are using the @OrderBy annotation as a workaround but it's not quite the same thing

Comment by Marco Pivetta [ 27/Jun/14 ]

Moved to 3.x





[DDC-2364] [GH-625] [DDC-2363] Duplicated record with orphanRemoval and proxy Created: 22/Mar/13  Updated: 30/Jun/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.



 Comments   
Comment by Doctrine Bot [ 30/Jun/14 ]

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





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

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

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


 Description   

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

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

Message:

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

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

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






[DDC-3203] "Orphan Removal" for ManyToMany and "Cascade remove" doesn't trigger "preRemove" callback on related entity Created: 01/Jul/14  Updated: 02/Jul/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: Tadej Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Latest ZendFramework2, latest ZF2 DoctrineModule and latest ZF2 DoctrineORMModule



 Description   

I'm not sure if it's me, but I couldn't get "preRemove" callback/event working when "remove" action is triggered from related entity, but it works where the entity itself (the one with "preRemove" event) is removed directly.

According to documentation:
"If an association is marked as CASCADE=REMOVE Doctrine 2 will fetch this association. If its a Single association it will pass this entity to ´EntityManager#remove()`"....and similar for multiple entities.
DOC: http://doctrine-orm.readthedocs.org/en/latest/reference/working-with-objects.html?highlight=working-with-objects%20removing-entities#removing-entities

"preRemove event is called on every entity when its passed to the EntityManager#remove()"
DOC: http://docs.doctrine-project.org/en/latest/reference/events.html#preremove

So according to documentation "preRemove" should get triggered on "cascade remove", but it doesn't get in my case. Is this normal behavior or a bug?

I'm not sure if it the problem might be in any of ZF2 modules, but I've decided to post the issue here, since I'm referring to documentation of this project.

Beside that I've also noticed that "orphan removal" doesn't work on ManyToMany, although documentation says that it's supported (on IRC they've said that it may be a bug in documentation, that it is not really yet supported...they found no code changes when documentation was changed).
DOC:
http://docs.doctrine-project.org/en/latest/reference/working-with-associations.html#orphan-removal






[DDC-3197] [GH-1074] [DDC-3160] Alternate fix for DDC-2996 bug Created: 26/Jun/14  Updated: 06/Jul/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 zimmermanj42:

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

Message:

The fix implemented for DDC-2996 seems to have broken quite a bit of code outside of Doctrine (for instance, the popular DoctrineExtensions project).

I'm not too well versed in Doctrine internals, but looking at the fix, I found it odd that an entity would live in both the insertion and update tracking in the unit of work.

This implementation should fix the case described in DDC-2996, while not creating any side effects with objects that are scheduled to be inserted.

I've ran this test with the Doctrine test suite and have also tested this change with the DoctrineExtensions project; unless I'm doing something wrong, it seems to have good results.

Again, I'm not too well versed in the inner workings of Doctrine, but I did a little research, poked around some code, and came up with this.



 Comments   
Comment by Doctrine Bot [ 06/Jul/14 ]

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

Comment by Doctrine Bot [ 06/Jul/14 ]

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





[DDC-3164] [GH-1057] Add failing test for DDC-3160 Created: 12/Jun/14  Updated: 06/Jul/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 flack:

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

Message:

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



 Comments   
Comment by Doctrine Bot [ 06/Jul/14 ]

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

Comment by Doctrine Bot [ 06/Jul/14 ]

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





[DDC-3105] Doctrine Console Error (ORMPurger) Created: 29/Apr/14  Updated: 29/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: Carlos Mendoza Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: Cli, schematool


 Description   

In symfony2 the command doctrine:fixtures:load Fails One-To-Many, Self-referencing using Doctrine\Common\DataFixtures\Purger\ORMPurger in example:

class DescriptionArea

{ //.. /** * @ORM\OneToMany(targetEntity="DescriptionArea", mappedBy="parent") */ protected $descriptionAreas; /** * @ORM\ManyToOne(targetEntity="DescriptionArea", inversedBy="descriptionAreas") */ protected $parent; //.. }

Throw error:
[Doctrine\DBAL\DBALException]

An exception occurred while executing 'DELETE FROM prefix_DescriptionArea':

SQLSTATE[23000]: Integrity constraint violation: 1451 Cannot delete or update a parent row: a foreign key constraint fails (sigtec_dev.prefix_DescriptionArea,

CONSTRAINT FK_7265873E727ACA70 FOREIGN KEY (parent_id) REFERENCES prefix_DescriptionArea (id))

Before running the query should delete the index when the table has self-reference.






[DDC-3220] Association mappings of embedded class not loaded into entity classMetadata Created: 21/Jul/14  Updated: 21/Jul/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: Anatolie Marinescu Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None


 Description   

method inlineEmbeddable from Doctrine\ORM\Mapping\ClassMetadataInfo mapped only columns, but relations is omitted






[DDC-3221] Invalid binding for primary key of entity relation Created: 21/Jul/14  Updated: 21/Jul/14

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

Type: Bug Priority: Major
Reporter: Alexandr Smaga Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm


 Description   

Hello.

We use doctrine2 ORM with doctrine/doctrine-bundle in our symfony2 based project. We developed functionality which is similar to some kind of import process.

And we have an issue that appears from time to time in different points during the import.

Issue is following:
Lets imagine we have 3 entities Account, Contact, Contact Address.
Account has many to one relation on contact and contact has one to many relation on contact address.

Our import creates all 3 entities and persist only Account, contact and address are persisted via cascade persist.
We have writer that contains following code

    public function write(array $items)
    {
        try {
            $this->entityManager->beginTransaction();
            foreach ($items as $item) {
                $this->entityManager->persist($item);
            }
            $this->entityManager->commit();
        } catch (\Exception $exception) {
            $this->entityManager->rollback();

            throw $exception;
        }
        $this->entityManager->flush();
        $this->entityManager->clear();
    }

So we clear EntityManager for each batch in order to avoid high memory consumption.
Import fails during different entities insert, but errors are very similar.
Example of error is

> [error] An exception occurred while executing 'INSERT INTO ... VALUES (?, ?, ?, ?, ?)' with params ["__start__", "2014-07-21 00:55:35", 0, null, 21]:
>
> SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (`DB`.`account`, CONSTRAINT `FK_B3D57B301023C4EE` FOREIGN KEY (`contact_id`) REFERENCES `contact` (`id`) ON DELETE CASCADE)

After debugging I found that problem is in BasicEntityPersister#prepareUpdateData

$uow->getEntityIdentifier($newVal);


returns oid that is real one, but UOW contains not the same ID as in $newVal entity. It seems like spl_object_hash duplicates oid.

Any help is appreciated.
Thanks in advance.






[DDC-3236] Quote table names Created: 31/Jul/14  Updated: 31/Jul/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: Benjamin Horn Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Different dbs have different reserved words. I started my project with mysql where i couldnt name my table as "order". After changing to postgre it turned out that "user" is reserved. Although

ALTER TABLE "member" RENAME TO "user";

works.

I know i could use prefixes in yml eg

Com\ApiBundle\Entity\User:
    type: entity
    table: prefix_user

but
-i build my db
-automatically generate my yaml files from it
-then i generate the entities

If i have prefixed table names my entities will have them too.
Besides doctrine is a layer on top of different dbs, it would be nice not to worry about reserved words when i naming my tables.

What is your opinion on this feature.



 Comments   
Comment by Steve Müller [ 31/Jul/14 ]

Benjamin Horn this looks more like a DBAL related issue. Can you please give more details how the broken SQL is created by you? Also please provide information about which DBAL and/or ORM version you are referring to as we have fixed a lot of quotation problems with DDL statements in current DBAL master over the last few months. So please also try using the latest master and see if you can reproduce the issue.
If the issue still persists it would be helpfult to know which database vendor and which version you are using (as different vendors and versions have different reserved keywords).





[DDC-3239] [GH-1097] `expandParameters`/`getType` in BasicEntityPersister seems to really cover just few cases Created: 01/Aug/14  Updated: 01/Aug/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 kamazee:

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

Message:

The test case below seems fairly simple, but I believe that it might uncover a bigger issue.

It seems odd that [`getType` (and, hence, `expandParameters`)](https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php#L1731-1795) in BasicEntityPersister clearly expects field name but often gets different things.

Just set a breakpoint there and watch values through the test suite. There might be not just field name, but a column with alias as well. This works:
![screenshot from 2014-08-01 14 03 44](https://cloud.githubusercontent.com/assets/231518/3778796/c5cc3e66-1979-11e4-9279-5c322b7e8402.png)

But this, apparently, doesn't:
![screenshot from 2014-08-01 14 07 29](https://cloud.githubusercontent.com/assets/231518/3778816/20da192c-197a-11e4-90b4-4c37ee454fb6.png)

There are multiple places (more than one) that call `expandParameters` with criteria that can't be resolved with `getType`. Is this situation expected or worth further investigation/fixing?






[DDC-3241] object type fails to save serialized class to postgresql Created: 05/Aug/14  Updated: 05/Aug/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: Reno Reckling Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Reference
relates to DBAL-964 [GH-653] Update docs to include warni... Resolved

 Description   

Doctrine 2 fails to properly store data from serialize() into postgresql.
This happens because the postgresql pdo driver truncates text on NULL bytes when escaping values. This leads to truncated serialized objects being inserted into the database.

A ugly but working workaround for us is to call json_encode(serialize()) when saving to the database and unserialize(json_decode()) when reading the value back because json_encode properly serializes the NULL bytes of the serialize() output to readable text.

This is pretty ugly though and it would help if doctrine would provide a minimal encoding/decoding function for postgresql that converts all NULL bytes to something else to not break the object type on postgresql.



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

I'm fairly sure that we don't want to invent our own serialization format. Instead, base64_encode could work.

Due to BC compat, we can't introduce it for 2.x, so it would have to be a completely new type.

Comment by Reno Reckling [ 05/Aug/14 ]

Agreed, we'll just go with base64_encode for now.
Maybe someone should update the documentation that using the object type on postgresql is not working as well as that using binary strings containing a NULL byte in any varchar/text column on postgresql is not working either.

Comment by Marco Pivetta [ 05/Aug/14 ]

Reno Reckling just open a pull request against the doctrine/doctrine2 repository

Comment by Reno Reckling [ 05/Aug/14 ]

Marco Pivetta Here you go: https://github.com/doctrine/dbal/pull/653
http://www.doctrine-project.org/jira/browse/DBAL-964

Thanks for the reply.

Comment by Doctrine Bot [ 05/Aug/14 ]

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

Comment by Marco Pivetta [ 05/Aug/14 ]

Merged DBAL-964, but the issue persists here.





[DDC-1695] SQLs for PostgreSQL case sensite tables/fields are wrongly generated Created: 09/Mar/12  Updated: 06/Aug/14

Status: Reopened
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: 2.1.6, 2.4.2
Fix Version/s: 2.1.7, 2.2.2
Security Level: All

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

PostgreSQL 9.x, Symfony 2


Attachments: Text File doctrine-2.1.6.patch     Text File SqlWalker.patch    

 Description   

The SQLs for case sensitive schemas in postgreSQL are wronly generated.

Example:
Schema:

CREATE TABLE "News" (
  "IdNews" serial NOT NULL,
  "IdUser" bigint NOT NULL,
  "IdLanguage" integer NOT NULL,
  "IdCondition" integer,
  "IdHealthProvider" integer,
  "IdSpeciality" integer,
  "IdMedicineType" integer,
  "IdTreatment" integer,
  "Title" character varying,
  "SmallText" character varying,
  "LongText" character varying,
  "PublishDate" timestamp with time zone,
  "IdxNews" tsvector,
  "Highlight" boolean NOT NULL DEFAULT false,
  "Order" integer NOT NULL DEFAULT 0,
  "Deleted" boolean NOT NULL DEFAULT false,
  "Active" boolean NOT NULL DEFAULT false,
  "UpdateToHighlighted" boolean DEFAULT false,
  CONSTRAINT "News_pkey" PRIMARY KEY ("IdNews" ));

Object (I added quotes trying to generate the SQLs quoted.:

<?php

namespace GlobalTreatments\ApplicationBundle\Entity;

use Doctrine\ORM\Mapping as ORM;

/**
 * @ORM\Table(name="""News""")
 * @ORM\Entity
 */
class News
{
    /**
     * @var integer $idNews
     *
     * @ORM\Column(name="""IdNews""", type="integer", nullable=false)
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="SEQUENCE")
     * @ORM\SequenceGenerator(sequenceName="""News_IdNews_seq""", allocationSize="1", initialValue="1")
     */
    private $idNews;

    /**
     * @var bigint $iduser
     *
     * @ORM\Column(name="""IdUser""", type="bigint", nullable=false)
     */
    private $idUser;

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

    /**
     * @var integer $idCondition
     *
     * @ORM\Column(name="""IdCondition""", type="integer", nullable=true)
     */
    private $idCondition;

    /**
     * @var integer $idHealthProvider
     *
     * @ORM\Column(name="""IdHealthProvider""", type="integer", nullable=true)
     */
    private $idHealthProvider;

    /**
     * @var integer $idSpeciality
     *
     * @ORM\Column(name="""IdSpeciality""", type="integer", nullable=true)
     */
    private $idSpeciality;

    /**
     * @var integer $idMedicineType
     *
     * @ORM\Column(name="""IdMedicineType""", type="integer", nullable=true)
     */
    private $idMedicineType;

    /**
     * @var integer $idTreatment
     *
     * @ORM\Column(name="""IdTreatment""", type="integer", nullable=true)
     */
    private $idTreatment;

    /**
     * @var string $title
     *
     * @ORM\Column(name="""Title""", type="string", nullable=true)
     */
    private $title;

    /**
     * @var string $smallText
     *
     * @ORM\Column(name="""SmallText""", type="string", nullable=true)
     */
    private $smallText;

    /**
     * @var string $longText
     *
     * @ORM\Column(name="""LongText""", type="string", nullable=true)
     */
    private $longText;

    /**
     * @var datetimetz $publishDate
     *
     * @ORM\Column(name="""PublishDate""", type="datetimetz", nullable=true)
     */
    private $publishDate;

    /**
     * @var tsvector $idxNews
     *
     * @ORM\Column(name="""IdxNews""", type="tsvector", nullable=true)
     */
    private $idxNews;

    /**
     * @var boolean $highlight
     *
     * @ORM\Column(name="""Highlight""", type="boolean", nullable=false)
     */
    private $highlight;

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

    /**
     * @var boolean $deleted
     *
     * @ORM\Column(name="""Deleted""", type="boolean", nullable=false)
     */
    private $deleted;

    /**
     * @var boolean $active
     *
     * @ORM\Column(name="""Active""", type="boolean", nullable=false)
     */
    private $active;

    /**
     * @var boolean $updateToHighlighted
     *
     * @ORM\Column(name="""UpdateToHighlighted""", type="boolean", nullable=true)
     */
    private $updateToHighlighted;

    /**
     * @var condition
     *
     * @ORM\ManyToOne(targetEntity="Condition")
     * @ORM\JoinColumns({
     *   @ORM\JoinColumn(name="""IdCondition""", referencedColumnName="""IdCondition""")
     * })
     */
    private $condition;

    /**
     * @var healthProvider
     *
     * @ORM\ManyToOne(targetEntity="HealthProvider")
     * @ORM\JoinColumns({
     *   @ORM\JoinColumn(name="""IdHealthProvider""", referencedColumnName="""IdHealthProvider""")
     * })
     */
    private $healthProvider;

    /**
     * @var language
     *
     * @ORM\ManyToOne(targetEntity="Language")
     * @ORM\JoinColumns({
     *   @ORM\JoinColumn(name="""IdLanguage""", referencedColumnName="""IdLanguage""")
     * })
     */
    private $language;

    /**
     * @var medicineType
     *
     * @ORM\ManyToOne(targetEntity="MedicineType")
     * @ORM\JoinColumns({
     *   @ORM\JoinColumn(name="""IdMedicineType""", referencedColumnName="""IdMedicineType""")
     * })
     */
    private $medicineType;

    /**
     * @var speciality
     *
     * @ORM\ManyToOne(targetEntity="Speciality")
     * @ORM\JoinColumns({
     *   @ORM\JoinColumn(name="""IdSpeciality""", referencedColumnName="""IdSpeciality""")
     * })
     */
    private $speciality;

    /**
     * @var treatment
     *
     * @ORM\ManyToOne(targetEntity="Treatment")
     * @ORM\JoinColumns({
     *   @ORM\JoinColumn(name="""IdTreatment""", referencedColumnName="""IdTreatment""")
     * })
     */
    private $treatment;

    /**
     * @var user
     *
     * @ORM\ManyToOne(targetEntity="User")
     * @ORM\JoinColumns({
     *   @ORM\JoinColumn(name="""IdUser""", referencedColumnName="""IdUser""")
     * })
     */
    private $user;

    ....

}

DQL:

'SELECT n.smallText, n.publishDate ' .
'FROM News n ' .
	'INNER JOIN n.language la ' .
'WHERE la.languageCode = :languageCode ' .
'ORDER BY n.publishDate DESC'

Generated SQL:

SELECT "0_."SmallText" AS "SmallText"0, "0_."PublishDate" AS "PublishDate"1 FROM "News" "0_ INNER JOIN "Language" "1_ ON "0_."IdLanguage" = "1_."IdLanguage" WHERE "1_."LanguageCode" = ? ORDER BY "0_."PublishDate" DESC LIMIT 6

Notice there are unmattched " in the SQL.



 Comments   
Comment by Ignacio Larranaga [ 09/Mar/12 ]

If there is another approach to specify the table/column names are case sensitive in PGSQL please let me know.

Comment by Ignacio Larranaga [ 09/Mar/12 ]

Just to comment. I also tried the normal quoting.

Example: @ORM\Column(name="`IdNews`", type="integer", nullable=false)

And does not work too because of the same reason.

Comment by Ignacio Larranaga [ 09/Mar/12 ]

Hi, I generate this patch and seems to be working for me (at least what I'm testing right now).

I used ´ to quote tables and single attributes (not relationships) and the SQLs are correctly generated.

Comment by Ignacio Larranaga [ 09/Mar/12 ]

Adding a new patch for another files I need to change.

Comment by Benjamin Eberlei [ 11/Mar/12 ]

Formatted code

Comment by Benjamin Eberlei [ 11/Mar/12 ]

Fixed and merged into 2.1.x and 2.2 branches

Comment by Julian Aicardo [ 05/Aug/14 ]

This bug still unresolved for version 2.3.6-DEV included in Symfony 2.3.18.

The patches does not work with this version.

Generated query:

SELECT "0_.id AS id0, "0_."verFirmware" AS verfirmware1, "0_."idEstacion" AS idestacion2, "0_."fechaHora" AS fechahora3, "0_.global AS global4, "0_.directa AS directa5, "0_.difusa AS difusa6, "0_."tempSensDirecta" AS tempsensdirecta7, "0_.vbat1 AS vbat18, "0_.vbat2 AS vbat29, "0_.flags AS flags10, "0_."Estacion" AS estacion11 FROM "RegistroRS" "0_ WHERE "0_."idEstacion" = '1' AND "0_."fechaHora" >= '2014-02-01 03:00:00' AND "0_."fechaHora" <= '2014-08-01 03:00:00'

Notice there are unmattched " in the SQL.

Comment by Marco Pivetta [ 05/Aug/14 ]

Julian Aicardo why are you using 2.3.6-DEV? Shouldn't you use a stable version? Is the bug reproducible also with later versions?

Comment by Julian Aicardo [ 06/Aug/14 ]

After changing to version 2.4.2 the bug still there. The same SQL query was generated.

Comment by Julian Aicardo [ 06/Aug/14 ]

The error occurs when try to get an alias based on case sensitive table name, because the alias is generated with the first character of table's name which is ".
Ex:
Table: car Alias: c0_
Table: "Car" Alias: "0_

Is in file SqlWalker.php line 295 in Doctrine 2.4.4:

SqlWalker.php
public function getSQLTableAlias($tableName, $dqlAlias = '')
{
    $tableName .= ($dqlAlias) ? '@[' . $dqlAlias . ']' : '';
        
    if ( ! isset($this->tableAliasMap[$tableName])) {
        $this->tableAliasMap[$tableName] = strtolower(substr($tableName, 0, 1)) . $this->tableAliasCounter++ . '_';
    }

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




[DDC-3248] PreUpdateEventArgs::setNewValue() does not update Entity state Created: 11/Aug/14  Updated: 11/Aug/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: Lukas Kahwe Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

see https://github.com/doctrine/doctrine2/commit/bc6714c2c8d015cb2e3ae198fcb1b98b3bbe35e0#commitcomment-7329820

as well as https://github.com/doctrine/phpcr-odm/pull/539#discussion_r16027731






[DDC-3251] Segmentation fault in ClassMetadataInfo.php Created: 12/Aug/14  Updated: 18/Aug/14

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

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

Linux dev1 3.9.9-302.fc19.x86_64 #1 SMP Sat Jul 6 13:41:07 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Fedora release 19 (Schrödinger’s Cat)

PHP 5.5.14 (cli) (built: Jul 16 2014 11:41:07)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies
with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2014, by Zend Technologies
with Xdebug v2.2.5, Copyright (c) 2002-2014, by Derick Rethans

Doctrine Command Line Interface version 2.3.6-DEV



 Description   

I'm seeing a segfault when doing a EntityManager->merge(). Specifically, when on this line in ClassmetadataInfo.php. Details below.

$value = $this->reflFields[$this->identifier[0]]->getValue($entity);

/var/log/messages

Aug 12 08:39:01 dev1 kernel: [62152.629221] php[3539]: segfault at f434172bd1 ip 00007ff432c3aae9 sp 00007fffa060b1b0 error 4 in php[7ff4329e7000+38c000]

strace

--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xc4f1053d11} ---
+++ killed by SIGSEGV ++

gdb backtrace:

(gdb) bt
#0  0x00007f8c8f5ceae9 in zend_std_read_property ()
#1  0x00007f8c8f5b61d7 in zend_read_property ()
#2  0x00007f8c8f4ab66e in zim_reflection_property_getValue ()
#3  0x00007f8c8f59a4ab in dtrace_execute_internal ()
#4  0x00007f8c8abb9a46 in xdebug_execute_internal () from /usr/lib64/php/modules/xdebug.so
#5  0x00007f8c8f65a895 in zend_do_fcall_common_helper_SPEC ()
#6  0x00007f8c8f5d45c8 in execute_ex ()
#7  0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#8  0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#9  0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#10 0x00007f8c8f5d45c8 in execute_ex ()
#11 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#12 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#13 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#14 0x00007f8c8f5d45c8 in execute_ex ()
#15 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#16 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#17 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#18 0x00007f8c8f5d45c8 in execute_ex ()
#19 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#20 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#21 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#22 0x00007f8c8f5d45c8 in execute_ex ()
#23 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#24 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#25 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#26 0x00007f8c8f5d45c8 in execute_ex ()
#27 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#28 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#29 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#30 0x00007f8c8f5d45c8 in execute_ex ()
#31 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#32 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#33 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#34 0x00007f8c8f5d45c8 in execute_ex ()
#35 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#36 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#37 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#38 0x00007f8c8f5d45c8 in execute_ex ()
#39 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#40 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#41 0x00007f8c8f659852 in ZEND_INCLUDE_OR_EVAL_SPEC_VAR_HANDLER ()
#42 0x00007f8c8f5d45c8 in execute_ex ()
#43 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#44 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#45 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#46 0x00007f8c8f5d45c8 in execute_ex ()
#47 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#48 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#49 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#50 0x00007f8c8f5d45c8 in execute_ex ()
#51 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#52 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
---Type <return> to continue, or q <return> to quit---
#53 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#54 0x00007f8c8f5d45c8 in execute_ex ()
#55 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#56 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#57 0x00007f8c8f659852 in ZEND_INCLUDE_OR_EVAL_SPEC_VAR_HANDLER ()
#58 0x00007f8c8f5d45c8 in execute_ex ()
#59 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#60 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#61 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#62 0x00007f8c8f5d45c8 in execute_ex ()
#63 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#64 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#65 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#66 0x00007f8c8f5d45c8 in execute_ex ()
#67 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#68 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#69 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#70 0x00007f8c8f5d45c8 in execute_ex ()
#71 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#72 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#73 0x00007f8c8f659852 in ZEND_INCLUDE_OR_EVAL_SPEC_VAR_HANDLER ()
#74 0x00007f8c8f5d45c8 in execute_ex ()
#75 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#76 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#77 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#78 0x00007f8c8f5d45c8 in execute_ex ()
#79 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#80 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#81 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#82 0x00007f8c8f5d45c8 in execute_ex ()
#83 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#84 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#85 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#86 0x00007f8c8f5d45c8 in execute_ex ()
#87 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#88 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#89 0x00007f8c8f659852 in ZEND_INCLUDE_OR_EVAL_SPEC_VAR_HANDLER ()
#90 0x00007f8c8f5d45c8 in execute_ex ()
#91 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#92 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#93 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#94 0x00007f8c8f5d45c8 in execute_ex ()
#95 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#96 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#97 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#98 0x00007f8c8f5d45c8 in execute_ex ()
#99 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#100 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#101 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#102 0x00007f8c8f5d45c8 in execute_ex ()
#103 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#104 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#105 0x00007f8c8f5abed0 in zend_execute_scripts ()
---Type <return> to continue, or q <return> to quit---
#106 0x00007f8c8f54bc65 in php_execute_script ()
#107 0x00007f8c8f65c8a8 in do_cli ()
#108 0x00007f8c8f436420 in main ()

xdebug trace:

   54.4457   16731856                                           -> Tekelec\DVAT\Service\TagService->createTag() /home/vagrant/dvat/library/Tekelec/DVAT/Service/TagService.php:51
   54.4457   16731856                                             -> Doctrine\ORM\EntityManager->merge() /home/vagrant/dvat/library/Tekelec/DVAT/Service/TagService.php:28
   54.4457   16731904                                               -> is_object() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php:632
   54.4457   16731856                                               -> Doctrine\ORM\EntityManager->errorIfClosed() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php:636
   54.4457   16731856                                               -> Doctrine\ORM\UnitOfWork->merge() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php:638
   54.4458   16731992                                                 -> Doctrine\ORM\UnitOfWork->doMerge() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1701
   54.4458   16732136                                                   -> spl_object_hash() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1744
   54.4458   16732448                                                   -> get_class() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1752
   54.4458   16732496                                                   -> Doctrine\ORM\EntityManager->getClassMetadata() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1752
   54.4458   16732496                                                     -> Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->getMetadataFor() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php:268
   54.4458   16732448                                                   -> Doctrine\ORM\UnitOfWork->getEntityState() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1760
   54.4458   16732496                                                     -> spl_object_hash() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1367
   54.4458   16732400                                                   -> Doctrine\ORM\Mapping\ClassMetadataInfo->getIdentifierValues() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1766
   54.4458   16732448                                                     -> ReflectionProperty->getValue() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php:672

The reproducing steps are complicated and require propriety code, but this happens most of the time (80+ percent).

Here is the php bug for this: https://bugs.php.net/bug.php?id=67828



 Comments   
Comment by Marco Pivetta [ 12/Aug/14 ]

Did you try clearing your opcode caches? Is this reproducible in insulated environment?

Comment by Kshitij Parajuli [ 12/Aug/14 ]

Yes, I tried clearing the opcode caches (and clearing proxies and restarting the server). This was also reproducible in multiple servers (one production and one development).

It is not yet reproducible in isolated environment, but I am looking at it. Will update the ticket if I find easy reproducing steps.

Comment by Benjamin Eberlei [ 12/Aug/14 ]

Please try without xdebug, this is enabled according to stacktrace.





[DDC-3238] GROUP BY does not work as expected in MS SQL Server Created: 31/Jul/14  Updated: 18/Aug/14

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

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

MS SQL Server 2012



 Description   

Running the query taken from this page: <http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/dql-doctrine-query-language.html>

$query = $em->createQuery('SELECT u, count(g.id) FROM FundAsset u JOIN u.locations g GROUP BY u.id');

I receive the following error from MS SQL Server:

SQLSTATE[42000]: [Microsoft][SQL Server Native Client 11.0][SQL Server]Column 'fund_assets.active' is invalid in the select list because it is not contained in either an aggregate function or the GROUP BY clause.

It appears that Doctrine's GROUP BY clause does not work correctly in Microsoft SQL Server.



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

Needs a failing test case.





[DDC-3243] [GH-1099] Fixed a bug so that a versioned entity with a OneToOne defined as an id can be created Created: 07/Aug/14  Updated: 18/Aug/14

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

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


 Description   

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

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

Message:

Changed the visibility of UnitOfWork::flattenIdentifier for use in BasicEntityPersister.

In BasicEntityPersister::fetchVersionValue I have added a line to flatten the id's before fetching the version value.

Without this change, an entity with a OneToOne relationship defined as an Id, with a Version property, could not be created. Rather than trying to use the ID in the query to select the version, the related entity was being passed.






[DDC-3231] [GH-1089] Entity repository generator default repository Created: 27/Jul/14  Updated: 18/Aug/14

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

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


 Description   

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

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

Message:

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

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






[DDC-3246] [GH-1103] Update Expr.php Created: 09/Aug/14  Updated: 18/Aug/14

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

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


 Description   

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

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

Message:

adding NOT EXISTS statement



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

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





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

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

Type: Bug Priority: Major
Reporter: 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-3044] [GH-986] Add last modified time for metadata Created: 22/Mar/14  Updated: 18/Aug/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 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-3005] Events::postLoad fires without filled associations Created: 02/Mar/14  Updated: 18/Aug/14

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

Type: Bug Priority: Major
Reporter: Artur Eshenbrener Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Dependency
depends on DDC-3070 [GH-1001] [DDC-3005] Defer invoking o... Open

 Description   

When we load entities throw one dql query like this:

SELECT e, joined_link FROM Entity LEFT JOIN e.link joined_link

In event subscriber, subscribed to postLoad event for instances of Entity property "link" of entity does not contains fetched in same query joined entity, and does not contains proxy object.

Tell me if failing test case needed.



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

The postLoad event is fired without warranty that association entities/proxies will be set:

http://docs.doctrine-project.org/en/latest/reference/events.html#lifecycle-events

Comment by Artur Eshenbrener [ 03/Mar/14 ]

But why? This shounds like involuntary restriction, and I think it can be fixed. Will my PR with fix accepted, or collaborators don't want to change this behaviour?

Comment by Marco Pivetta [ 03/Mar/14 ]

Artur Eshenbrener triggering `postLoad` in the correct moment in time (when all dependencies are loaded) requires a lot of additional complexity to be inserted in various locations of the ORM.

Since `postLoad` is supposed to be used like `__wakeup` and in general for simple tasks, this kind of refactoring/rewrite would be an overkill.

Comment by Artur Eshenbrener [ 04/Mar/14 ]

> requires a lot of additional complexity to be inserted in various locations of the ORM.
Sounds like "It is very hard to implement, and no one want to do this"

> and in general for simple tasks, this kind of refactoring/rewrite would be an overkill.
Disagree with this. Why only simple? I need to deal with associations in this event. Without this I should inject whole EntityManager to my entity, but I dont want to do this.

And I forced to repeat the question: will PR with fix accepted or not?

Comment by Marco Pivetta [ 04/Mar/14 ]

Sounds like "It is very hard to implement, and no one want to do this"

Not really, the main problem here is performance, since hydration would have to be completely redesigned.
Yes, "too hard" is a good reason for something that is an edge case.

And I forced to repeat the question: will PR with fix accepted or not?

Sure thing! Just needs to avoid a massive rewrite though.

Comment by Marco Pivetta [ 04/Mar/14 ]

To give you some hints, Doctrine\ORM\Events::postLoad is triggered in https://github.com/doctrine/doctrine2/blob/15432fc55f83c2d6ce8d9b86fd3139dd2a4fc328/lib/Doctrine/ORM/UnitOfWork.php#L2788, and Doctrine\ORM\UnitOfWork#createEntity() is used by all the various hydrators internally.

To ensure that Doctrine\ORM\Events::postLoad is triggered after an entity is fully loaded, the various hydrators must trigger the events after being sure that all data has been set, and that the entity is "ready" for use. That's some copy-paste work :\

Comment by Artur Eshenbrener [ 04/Mar/14 ]

I think the entry point is here: https://github.com/doctrine/doctrine2/blob/15432fc55f83c2d6ce8d9b86fd3139dd2a4fc328/lib/Doctrine/ORM/Internal/Hydration/AbstractHydrator.php#L140,
so, copy-paste work is not needed )

Comment by Artur Eshenbrener [ 05/Apr/14 ]

PR is ready: https://github.com/doctrine/doctrine2/pull/1001





[DDC-3070] [GH-1001] [DDC-3005] Defer invoking of postLoad event to the end of hydration cycle. Created: 04/Apr/14  Updated: 18/Aug/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:
Dependency
is required for DDC-3005 Events::postLoad fires without filled... Reopened

 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-2881] [GH-895] Fix for no dot on Class Names Created: 04/Jan/14  Updated: 18/Aug/14

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

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


 Description   

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

Url: