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

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

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

Symfony 2, linux



 Description   

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

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

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

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

Thanks!



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

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





[DDC-585] Create a coding standards document Created: 13/May/10  Updated: 16/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...





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

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

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


 Description   

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

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

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

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


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

i just found a possible BC issue with this.

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

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

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

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

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

Comment by Benjamin Eberlei [ 27/Apr/10 ]

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

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

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

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

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

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

Comment by Johnny Peck [ 19/Nov/10 ]

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

Comment by Guilherme Blanco [ 16/Apr/14 ]

Moving to 3.0 as this can potentially create BC breaks





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

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

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


 Description   

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



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

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





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

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

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

Ubuntu 12.04, PHP 5.3.10


Attachments: File bootstrap.php     File Opportunities.php    

 Description   

<?php
//
/**

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

{"name"}

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

{"assigned_user_id"}

)}) **/ //

@ORM\index instead of @ORM\Index

//
?>

throw this error

[Doctrine\Common\Annotations\AnnotationException]

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



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

Can you provide the entire generated file as an attachment?

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

Generated class.

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

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

Comment by Marco Pivetta [ 17/Oct/13 ]

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

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

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

Comment by Marco Pivetta [ 17/Oct/13 ]

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

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

Ok, I'll try. I use 2.2.1.

Comment by Guilherme Blanco [ 16/Apr/14 ]

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





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

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

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


 Description   

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






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

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

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


 Description   

The schema validator should analyze mapped lifecycle callbacks and:

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



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

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





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

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

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


 Description   

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

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

Is this something that is difficult to implement?



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

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

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





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

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

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

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



 Description   

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

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

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

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

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

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

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

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

            $i++;
        }
    }
    

My results:

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

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

2) Reading with using clear

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

3) Inserting without clearing

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

4) Inserting with using clear

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



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

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

Additionally, the ORM version being affected is also needed.





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

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

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


 Description   

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

Examples:

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

Comment by Glen Ainscow [ 25/Jan/10 ]

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

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

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

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

Close if you disagree.

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

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

There's just no point in arguing about readability.

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

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

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

Comment by Guilherme Blanco [ 25/Jan/10 ]

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

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

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

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

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

Comment by Glen Ainscow [ 25/Jan/10 ]

@Roman,

Just a feeling I got.

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

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

I agree that Id. is an abbreviation.

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

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

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

Thanks for your help!

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

Comment by Glen Ainscow [ 25/Jan/10 ]

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

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

Comment by Glen Ainscow [ 25/Jan/10 ]

Found some time ...

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

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

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

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

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

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

We should try to go through that list before beta.

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

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

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

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

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

Pushing the rest of the name changes towards beta2.

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

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

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

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

Comment by Benjamin Eberlei [ 31/Oct/10 ]

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

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

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

Comment by Guilherme Blanco [ 16/Apr/14 ]

Scheduled to 3.0 as this may potentially create BC breaks





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

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

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

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

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

Whats the status here? Do we have any?

Comment by Guilherme Blanco [ 19/May/10 ]

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

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

Comment by Benjamin Eberlei [ 20/May/10 ]

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

Comment by Benjamin Eberlei [ 19/Jun/10 ]

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

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

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

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

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

Comment by Guilherme Blanco [ 16/Apr/14 ]

This is not valid anymore as we use Symfony CLI component





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

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

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


 Description   

Hi!

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

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

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

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






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

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

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


 Description   

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

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






[DDC-2937] [GH-920] SingleScalarHydrator reports ambiguous error. Created: 27/Jan/14  Updated: 16/Apr/14  Resolved: 16/Apr/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

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

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

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



 Comments   
Comment by Flip [ 27/Jan/14 ]

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

Comment by Doctrine Bot [ 16/Apr/14 ]

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

Comment by Guilherme Blanco [ 16/Apr/14 ]

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





[DDC-2975] [GH-951] More informational entity not found exception Created: 11/Feb/14  Updated: 16/Apr/14

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

Type: Bug Priority: Major
Reporter: 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 md2perpe:

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

Message:



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

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





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

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

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

Attachments: File testDoctrine.php    

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

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

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

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

}

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

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

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

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

Result:

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

...

Need result:

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


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

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

Comment by Andrey Kolyshkin [ 12/May/11 ]

Attach test file

I run

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

and run testDoctrine.php

Result

SELECT t0.user_id AS user_id1 FROM users t0

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

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

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

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

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

Comment by Vladimir [ 25/Mar/13 ]

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

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

but additional users_count queries for

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

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

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

with unique user_id executed twice

Comment by Konstantin [ 04/Aug/13 ]

Please fix this issue

Comment by Madhav Krishna [ 14/Nov/13 ]

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

Comment by CoL [ 28/Nov/13 ]

Any news on this issue?

Comment by Flip [ 17/Jan/14 ]

sounds very useful !

Comment by Guilherme Blanco [ 16/Apr/14 ]

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





[DDC-2907] [GH-907] [DDC-1632] OneToMany Fetch eager Created: 11/Jan/14  Updated: 16/Apr/14  Resolved: 16/Apr/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

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



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

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

Comment by Doctrine Bot [ 16/Apr/14 ]

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

Comment by Guilherme Blanco [ 16/Apr/14 ]

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





[DDC-2902] [GH-905] [DDC-1632] OneToMany Fetch eager Created: 10/Jan/14  Updated: 16/Apr/14  Resolved: 23/Mar/14

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

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


 Description   

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

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

Message:

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



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

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

Comment by Doctrine Bot [ 16/Apr/14 ]

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





[DDC-3049] [GH-988] Exporter support for association fetch modes Created: 26/Mar/14  Updated: 16/Apr/14  Resolved: 16/Apr/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

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

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



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

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

Comment by Guilherme Blanco [ 16/Apr/14 ]

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





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

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

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


 Description   

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

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

Will try to come up with a PR + test



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

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

Comment by Guilherme Blanco [ 16/Apr/14 ]

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





[DDC-3060] [GH-995] Allow cascaded clearing of associated Entities Created: 30/Mar/14  Updated: 16/Apr/14  Resolved: 16/Apr/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:



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

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

Comment by Guilherme Blanco [ 16/Apr/14 ]

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





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

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

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

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


 Description   

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

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

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

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

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


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

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

Comment by Doctrine Bot [ 16/Apr/14 ]

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





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

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:



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

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

Comment by Doctrine Bot [ 16/Apr/14 ]

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





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

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

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


 Description   

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

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



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

DDC-2176 duplicates DDC-1998

Some clarifications:

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

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

Comment by Alexander Miertsch [ 16/Feb/14 ]

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

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

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

Comment by Alexander Miertsch [ 24/Feb/14 ]

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

Comment by Guilherme Blanco [ 16/Apr/14 ]

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





[DDC-1197] Proxies should handle variable argument lists Created: 05/Jun/11  Updated: 15/Apr/14  Resolved: 15/Apr/14

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

Type: Improvement Priority: Major
Reporter: Benjamin Eberlei Assignee: Marco Pivetta
Resolution: Can't Fix Votes: 0
Labels: None


 Description   

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

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



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

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

Comment by Marco Pivetta [ 15/Apr/14 ]

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

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

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

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

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





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

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

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


 Description   

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






[DDC-3086] [GH-1011] Single quotes can't nest Created: 15/Apr/14  Updated: 15/Apr/14  Resolved: 15/Apr/14

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

Type: Documentation Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

I decided to use "... '...' ...", but perhaps you prefer '... \'...\' ...'?



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

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

Comment by Marco Pivetta [ 15/Apr/14 ]

Merged: https://github.com/doctrine/doctrine2/commit/68d477a4c6d2dc2c201015a6fceb4e64e5ce744a





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

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

Two scenarios:

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


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

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

Comment by Marco Pivetta [ 15/Apr/14 ]

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





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

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

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


 Description   

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

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

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

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





[DDC-3084] Native query removes duplicate root entities Created: 14/Apr/14  Updated: 15/Apr/14  Resolved: 14/Apr/14

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

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


 Description   

I have a query like that:

        $rsm = new ResultSetMappingBuilder($this->_em);
        $rsm->addScalarResult('rank', 'rank');
        $rsm->addRootEntityFromClassMetadata('Application\Entity', 'e');

		$query = $this->_em->createNativeQuery('
            SELECT
            	r.rank, ' . $rsm->generateSelectClause(array('e')) . '
            FROM ...
	    ', $rsm);

        return $query->getResult();

When I issue it at the mysql side it returns 3 rows but doctrine returns only 2 - I have tried getArrayResults() with the same results

The query could return the same entity multiple times for different values of the "rank" scalar value but it seems that doctrine removes those duplicates



 Comments   
Comment by Przemyslaw Wrobel [ 14/Apr/14 ]

the result should be like this: ("rank", "entity")
1, entity1
2, entity2
3, entity2

Comment by Marco Pivetta [ 14/Apr/14 ]

Doctrine ORM groups the values of the root of the selection by identifier during hydration: this is the expected result.

Comment by Przemyslaw Wrobel [ 15/Apr/14 ]

If it is really grouping than I shoud have something like that
entity1, 1
entity2, array(2,3)

Now the problem is that I am losing data - the row: 3, entity2 is missing and I have to resort to DBAL query or do not map to entities but than I cannot use my model logic





[DDC-2629] [GH-768] DDC-391: Add support to configure custom persister classes Created: 22/Aug/13  Updated: 15/Apr/14  Resolved: 02/Jan/14

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates DDC-2637 [GH-769] Add Custom Persisters Open

 Description   

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

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

Message:

Based on https://github.com/doctrine/doctrine2/commit/8c3ad50bb5ad51f9064543768745f3d85f4b7d64 (from the http://github.com/doctrine/doctrine2/tree/OverridePersisters branch)

Basis for feature: http://www.doctrine-project.org/jira/browse/DDC-391



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

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

Comment by Doctrine Bot [ 15/Apr/14 ]

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





[DDC-2637] [GH-769] Add Custom Persisters Created: 28/Aug/13  Updated: 15/Apr/14

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

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

Issue Links:
Duplicate
is duplicated by DDC-2629 [GH-768] DDC-391: Add support to conf... Resolved
Reference
relates to DDC-391 Allow to specifiy custom Entity and C... In Progress

 Description   

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

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

Message:

Adding support for custom persisters as defined by DDC-391.
Implementing both Entity and Collection based Persisters



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

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

Comment by Doctrine Bot [ 15/Apr/14 ]

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





[DDC-3014] [GH-973] Added index flags support in annotation, xml & yaml mapping drivers. Created: 06/Mar/14  Updated: 13/Apr/14  Resolved: 13/Apr/14

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

It allows specifying eg. fulltext index for MysqlPlatform (the platform already supports it - https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Platforms/MySqlPlatform.php#L714 , but it couldn't be used in annotations/xml/yaml/php schemas). And also other platforms use flags for indexes (virtual, clustered etc.).

So now flags can be used like:

```php
/**

  • @Table(...,indexes=
    Unknown macro: {@Index(columns={"description"},flags={"fulltext"})}

    )
    */
    class Foo

    { ... }

    ```

```xml
...
<indexes>
<index name="0" columns="description" flags="fulltext"/>
</indexes>
...
```

```yml
Foo:
...
indexes:
-
columns: [ description ]
flags: [ fulltext ]
```

```php
$metadata->setPrimaryTable(array(
...
'indexes' => array(
array(
'columns' => array('description'),
'flags' => array('fulltext'),
)
),
...
));
```



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

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

Comment by Marco Pivetta [ 13/Apr/14 ]

Merged: https://github.com/doctrine/doctrine2/commit/3a1e24e6801961128c27104919050d40d745030b





[DDC-3032] [GH-980] Added options attribute export to Annotation, Xml & Yaml exporters. Created: 16/Mar/14  Updated: 13/Apr/14  Resolved: 13/Apr/14

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

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


 Description   

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

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

Message:

Options were already supported in annotation/xml/yaml drivers. So now they are taken into account eg in orm:convert-mapping task.



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

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

Comment by Marco Pivetta [ 13/Apr/14 ]

Merged: https://github.com/doctrine/doctrine2/commit/da24133306d0b5d313605a7f4c501399ced25198





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

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

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


 Description   

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

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

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

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



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

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

Comment by Frank Liepert [ 13/Apr/14 ]

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

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

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

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

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

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

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

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


/** 
 * NEW REQUEST
 */

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

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

Comment by Marco Pivetta [ 13/Apr/14 ]

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

Comment by Frank Liepert [ 13/Apr/14 ]

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





[DDC-2272] [GH-565] Removed an unused local variable. Created: 03/Feb/13  Updated: 13/Apr/14  Resolved: 05/Feb/13

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

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


 Description   

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

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

Message:

This PR removes an unused (redundant) local variable declaration.



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

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

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

Merged : https://github.com/doctrine/doctrine2/commit/114827a4b32fe309519cf3f9bdfedb3599d52f37

Comment by Doctrine Bot [ 13/Apr/14 ]

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





[DDC-3082] [GH-1010] Fixed validation message Created: 11/Apr/14  Updated: 11/Apr/14  Resolved: 11/Apr/14

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

Type: Bug Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

A message of the SchemaValidator erroneously mentions the source entity instead of the target entity.



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

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

Comment by Marco Pivetta [ 11/Apr/14 ]

Merged: https://github.com/doctrine/doctrine2/commit/8b6b1c68a05035822804ef7ce516dbb2471f6efe





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

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

Message:

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

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






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

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

 Description   

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

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

Message:

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






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

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

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

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

 Description   

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

I'm writing a PoC patch right now.






[DDC-3079] preUpdate in EntityListener not run in transaction Created: 10/Apr/14  Updated: 10/Apr/14

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

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


 Description   

I have entity:

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

And Entity Listener with preRemove.

I call

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

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

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






[DDC-3005] Events::postLoad fires without filled associations Created: 02/Mar/14  Updated: 10/Apr/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


 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-3077] [GH-1007] Minor dockblock change Created: 09/Apr/14  Updated: 09/Apr/14  Resolved: 09/Apr/14

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

Type: Documentation Priority: Trivial
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:



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

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

Comment by Marco Pivetta [ 09/Apr/14 ]

Merged: https://github.com/doctrine/doctrine2/commit/ac956f2b8c231416da5c683e295fb6b8aa61b177





[DDC-3075] [GH-1005] Added support of the subselect expressions into NEW expressions Created: 08/Apr/14  Updated: 08/Apr/14

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

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


 Description   

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

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

Message:

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






[DDC-3074] [GH-1004] Removed all useless occurrence of require_once TestInit.php Created: 07/Apr/14  Updated: 07/Apr/14

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

Type: 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 giosh94mhz:

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

Message:

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

I've removed all occurrence from the test cases.



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

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





[DDC-3040] doctrine:schema:update datetimetz field type not null Created: 19/Mar/14  Updated: 07/Apr/14  Resolved: 07/Apr/14

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

Type: Bug Priority: Major
Reporter: Coroliov Oleg Assignee: Benjamin Eberlei
Resolution: Can't Fix Votes: 0
Labels: console, orm, schematool


 Description   

I have some fields like

    /**
     * Adding date in format ISO-8601 YYYY-MM-DDThh:mm:ss±hhmm
     *
     * @var \DateTime
     *
     * @ORM\Column(name="added_at", type="datetimetz", nullable=false)
     */
    private $addedAt;

    /**
     * Expire date in format ISO-8601 YYYY-MM-DDThh:mm:ss±hhmm
     *
     * @var \DateTime
     *
     * @ORM\Column(name="expired_at", type="datetimetz", nullable=false)
     */
    private $expiredAt;

@ORM\Column -> nullable=false

In database this field already not null
But when i execute in console:

./app/console doctrine:schema:update --dump-sql --env=dev

answer:

ALTER TABLE test CHANGE added_at added_at DATETIME NOT NULL, CHANGE expired_at expired_at DATETIME NOT NULL;

If I change datetimetz to datetime type fot $expiredAt
and execute:

./app/console doctrine:schema:update --dump-sql --env=dev

answer:

ALTER TABLE test CHANGE added_at added_at DATETIME NOT NULL;



 Comments   
Comment by Coroliov Oleg [ 05/Apr/14 ]

have some news about this problem ?

Comment by Marco Pivetta [ 06/Apr/14 ]

Coroliov Oleg does the DDL update statement persist in the diffs even after running it?

Comment by Coroliov Oleg [ 06/Apr/14 ]
$ ./app/console doctrine:schema:update --dump-sql --env=dev
ALTER TABLE device CHANGE added_at added_at DATETIME NOT NULL;
ALTER TABLE device_audit CHANGE added_at added_at DATETIME DEFAULT NULL;
ALTER TABLE package_activated CHANGE start_at start_at DATETIME NOT NULL, CHANGE expire_at expire_at DATETIME NOT NULL;
ALTER TABLE package_activated_audit CHANGE start_at start_at DATETIME DEFAULT NULL, CHANGE expire_at expire_at DATETIME DEFAULT NULL;
ALTER TABLE package CHANGE created_at created_at DATETIME NOT NULL;
ALTER TABLE package_audit CHANGE created_at created_at DATETIME DEFAULT NULL;
ALTER TABLE coupon CHANGE added_at added_at DATETIME NOT NULL, CHANGE expired_at expired_at DATETIME NOT NULL;
ALTER TABLE coupon_audit CHANGE added_at added_at DATETIME DEFAULT NULL, CHANGE expired_at expired_at DATETIME DEFAULT NULL;
ALTER TABLE company CHANGE added_at added_at DATETIME NOT NULL;
ALTER TABLE company_audit CHANGE added_at added_at DATETIME DEFAULT NULL;
$ ./app/console doctrine:schema:update --force
Updating database schema...
Database schema updated successfully! "10" queries were executed
$ ./app/console doctrine:schema:update --dump-sql --env=dev
ALTER TABLE device CHANGE added_at added_at DATETIME NOT NULL;
ALTER TABLE device_audit CHANGE added_at added_at DATETIME DEFAULT NULL;
ALTER TABLE package_activated CHANGE start_at start_at DATETIME NOT NULL, CHANGE expire_at expire_at DATETIME NOT NULL;
ALTER TABLE package_activated_audit CHANGE start_at start_at DATETIME DEFAULT NULL, CHANGE expire_at expire_at DATETIME DEFAULT NULL;
ALTER TABLE package CHANGE created_at created_at DATETIME NOT NULL;
ALTER TABLE package_audit CHANGE created_at created_at DATETIME DEFAULT NULL;
ALTER TABLE coupon CHANGE added_at added_at DATETIME NOT NULL, CHANGE expired_at expired_at DATETIME NOT NULL;
ALTER TABLE coupon_audit CHANGE added_at added_at DATETIME DEFAULT NULL, CHANGE expired_at expired_at DATETIME DEFAULT NULL;
ALTER TABLE company CHANGE added_at added_at DATETIME NOT NULL;
ALTER TABLE company_audit CHANGE added_at added_at DATETIME DEFAULT NULL;

or if i use additional bundle

$ ./app/console doctrine:schema:update --dump-sql --env=dev
ALTER TABLE device CHANGE added_at added_at DATETIME NOT NULL;
ALTER TABLE device_audit CHANGE added_at added_at DATETIME DEFAULT NULL;
ALTER TABLE package_activated CHANGE start_at start_at DATETIME NOT NULL, CHANGE expire_at expire_at DATETIME NOT NULL;
ALTER TABLE package_activated_audit CHANGE start_at start_at DATETIME DEFAULT NULL, CHANGE expire_at expire_at DATETIME DEFAULT NULL;
ALTER TABLE package CHANGE created_at created_at DATETIME NOT NULL;
ALTER TABLE package_audit CHANGE created_at created_at DATETIME DEFAULT NULL;
ALTER TABLE coupon CHANGE added_at added_at DATETIME NOT NULL, CHANGE expired_at expired_at DATETIME NOT NULL;
ALTER TABLE coupon_audit CHANGE added_at added_at DATETIME DEFAULT NULL, CHANGE expired_at expired_at DATETIME DEFAULT NULL;
ALTER TABLE company CHANGE added_at added_at DATETIME NOT NULL;
ALTER TABLE company_audit CHANGE added_at added_at DATETIME DEFAULT NULL;
$ ./app/console doctrine:migrations:diff
Generated new migration class to "/Users/ruscon/projects/xxx/app/DoctrineMigrations/Version20140407004542.php" from schema differences.
$ ./app/console doctrine:migrations:migrate

                    Application Migrations


WARNING! You are about to execute a database migration that could result in schema changes and data lost. Are you sure you wish to continue? (y/n)y
Migrating up to 20140407004542 from 20140405144932

  ++ migrating 20140407004542

     -> ALTER TABLE device CHANGE added_at added_at DATETIME NOT NULL
     -> ALTER TABLE device_audit CHANGE added_at added_at DATETIME DEFAULT NULL
     -> ALTER TABLE package_activated CHANGE start_at start_at DATETIME NOT NULL, CHANGE expire_at expire_at DATETIME NOT NULL
     -> ALTER TABLE package_activated_audit CHANGE start_at start_at DATETIME DEFAULT NULL, CHANGE expire_at expire_at DATETIME DEFAULT NULL
     -> ALTER TABLE package CHANGE created_at created_at DATETIME NOT NULL
     -> ALTER TABLE package_audit CHANGE created_at created_at DATETIME DEFAULT NULL
     -> ALTER TABLE coupon CHANGE added_at added_at DATETIME NOT NULL, CHANGE expired_at expired_at DATETIME NOT NULL
     -> ALTER TABLE coupon_audit CHANGE added_at added_at DATETIME DEFAULT NULL, CHANGE expired_at expired_at DATETIME DEFAULT NULL
     -> ALTER TABLE company CHANGE added_at added_at DATETIME NOT NULL
     -> ALTER TABLE company_audit CHANGE added_at added_at DATETIME DEFAULT NULL

  ++ migrated (3.46s)

  ------------------------

  ++ finished in 3.46
  ++ 1 migrations executed
  ++ 10 sql queries
$ ./app/console doctrine:schema:update --dump-sql --env=dev
ALTER TABLE device CHANGE added_at added_at DATETIME NOT NULL;
ALTER TABLE device_audit CHANGE added_at added_at DATETIME DEFAULT NULL;
ALTER TABLE package_activated CHANGE start_at start_at DATETIME NOT NULL, CHANGE expire_at expire_at DATETIME NOT NULL;
ALTER TABLE package_activated_audit CHANGE start_at start_at DATETIME DEFAULT NULL, CHANGE expire_at expire_at DATETIME DEFAULT NULL;
ALTER TABLE package CHANGE created_at created_at DATETIME NOT NULL;
ALTER TABLE package_audit CHANGE created_at created_at DATETIME DEFAULT NULL;
ALTER TABLE coupon CHANGE added_at added_at DATETIME NOT NULL, CHANGE expired_at expired_at DATETIME NOT NULL;
ALTER TABLE coupon_audit CHANGE added_at added_at DATETIME DEFAULT NULL, CHANGE expired_at expired_at DATETIME DEFAULT NULL;
ALTER TABLE company CHANGE added_at added_at DATETIME NOT NULL;
ALTER TABLE company_audit CHANGE added_at added_at DATETIME DEFAULT NULL;
Comment by Steve Müller [ 07/Apr/14 ]

I assume from the syntax that you are using MySQL. MySQL does not have a native type for DateTimeTz, therefore the mapping always falls back to the native DATETIME type. See the DBAL documentation (footnote 15): http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/types.html#mapping-matrix

The problem here is not the nullable flag but the type you use. Therefore you get the irrgeular update statements from the schema tool. Use Doctrine's "datetime" type instead and you'll be fine. You won't be able to store time zone information for a date time in MySQL anyways as it does not have a type for this.

Comment by Coroliov Oleg [ 07/Apr/14 ]

Steve Müller, you right. Thanks.





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

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

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


 Description   

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






[DDC-3072] [GH-1003] Let user extend EntityManager Created: 06/Apr/14  Updated: 06/Apr/14  Resolved: 06/Apr/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

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

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

Message:

change new EntityManager into new self in static function create



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

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





[DDC-3071] [GH-1002] Fixed wrongly initialized property. Created: 04/Apr/14  Updated: 04/Apr/14  Resolved: 04/Apr/14

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

Type: Bug Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

This removes an incorrect `= array()` initialization on `$parameters`, which is actually an `ArrayCollection` and has its value set in the constructor.



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

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

Comment by Marco Pivetta [ 04/Apr/14 ]

Merged: https://github.com/doctrine/doctrine2/commit/4d950a9e10936eb44d2a77953000e3f067a1b8fe





[DDC-3070] [GH-1001] [DDC-3005] Defer invoking of postLoad event to the end of hydration cycle. Created: 04/Apr/14  Updated: 04/Apr/14

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

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


 Description   

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

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

Message:

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






[DDC-3069] [GH-1000] [DDC-3068] EntityManager::find accept array of object as id Created: 04/Apr/14  Updated: 04/Apr/14

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

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


 Description   

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

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

Message:

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

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






[DDC-3042] select issue field names with numbers Created: 21/Mar/14  Updated: 04/Apr/14  Resolved: 04/Apr/14

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

Type: Bug Priority: Critical
Reporter: Marc Lindemann Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Duplicate
is duplicated by DDC-3043 [GH-985] [WIP] [DDC-3042] SQL Alias c... Resolved

 Description   
$qb = $this->_em->createQueryBuilder();
$qb->select('k.aktiv, k.id, k.firma, k.firma2, k.strasse, k.plz, k.ort, k.plzpostfach, k.postfach, k.bemerkung,
         k.uuid, k.telefon,k.telefonzentrale, k.istmutter, k.isttochter, k.email, k.internet, k.fax, l.id as land, m.id as mutter, m.firma as mutterv, t.id as tochter, t.firma as tochterv, kg.id as kundengruppe, s.id as sic, s.title as sicv,
         kg.title as kundengruppev,m.telefon as telefonmutter,t.telefon as telefontochter, k.id as kdnr')

will create this sql:

SELECT c0_.id AS id0, c0_.aktiv AS aktiv1, c0_.firma AS firma2, c0_.firma2 AS firma23, c0_.strasse AS strasse4, c0_.plz AS plz5, c0_.ort AS ort6, c0_.plzpostfach AS plzpostfach7, c0_.postfach AS postfach8, c0_.hotel AS hotel9, c0_.kuerzel AS kuerzel10, c0_.stornofrist AS stornofrist11, c0_.uuid AS uuid12, c0_.telefon AS telefon13, c0_.telefonzentrale AS telefonzentrale14, c0_.istmutter AS istmutter15, c0_.isttochter AS isttochter16, c0_.trainer AS trainer17, c0_.email AS email18, c0_.internet AS internet19, c0_.fax AS fax20, l6_.id AS id21, c3_.id AS id22, c3_.firma AS firma23, c3_.telefon AS telefon24, c0_.id AS id25, t1_.content AS anfahrt26, t2_.content AS beschreibung27 

as you see, it will create co.firma2 as firma23 and c3_.firma AS firma23,

now when you do:

$query = $qb->getQuery();
$result = $query->getArrayResult();
Array
(
    [0] => Array
        (
            [id] => 11
            [aktiv] => 1
            [firma] => Test GmbH
            [mutterv] => Mutter Test
            [strasse] => 
            [plz] => 
            [ort] => 
            [plzpostfach] => 
            [postfach] => 
            [hotel] => 
            [kuerzel] => 
            [stornofrist] => 0
            [uuid] => 524459b5-7f1c-442b-98dd-3d5cc0a81420
            [telefon] => 0211/415583810
            [telefonzentrale] => 
            [istmutter] => 
            [isttochter] => 
            [trainer] => 
            [email] => 
            [internet] => 
            [fax] => 
            [land] => 3
            [mutter] => 
            [telefonmutter] => 
            [kdnr] => 11
            [anfahrt] => 
            [beschreibung] => 
        )
)

when i change the order of the select , it will work

 $qb->select('k.id, k.aktiv, k.firma, k.strasse, k.plz, k.ort, k.plzpostfach, k.postfach, k.hotel, k.kuerzel, k.stornofrist,  k.firma2,
         k.uuid, k.telefon,k.telefonzentrale, k.istmutter, k.isttochter, k.trainer, k.email, k.internet, k.fax, l.id as land, m.id as mutter, m.firma as mutterv,
         m.telefon as telefonmutter, k.id as kdnr, k.anfahrt, k.beschreibung')


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

Marc Lindemann can you reduce the example to only the fields that are affected? Does this affect also latest ORM?

Comment by Marc Lindemann [ 21/Mar/14 ]

Marco, the Problem only exists when you select like my example

c0_.id AS id0, c0_.aktiv AS aktiv1, c0_.firma AS firma2, (...),  c0_.firma2 AS firma23, 

as you see "firma2" is on the fourth place so it´s selected as "firma23", "m.firma" is on place 24, so it´s also selected as "firma23" (m.firma as mutterv)

Comment by Marco Pivetta [ 21/Mar/14 ]

Marc Lindemann ah, I see it now. This probably requires a change in how the DQL is generated by prefixing numerical indexes with something like an `_`.

Comment by Marco Pivetta [ 21/Mar/14 ]

Marc Lindemann I provided a fix at https://github.com/doctrine/doctrine2/pull/985 - can you try it?

Comment by Marc Lindemann [ 24/Mar/14 ]

Yeah, this works.

Comment by Doctrine Bot [ 04/Apr/14 ]

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

Comment by Marco Pivetta [ 04/Apr/14 ]

Merged: https://github.com/doctrine/doctrine2/commit/bfb66f1d85509db9e24ce33e30382c8cccaf2dd7





[DDC-3043] [GH-985] [WIP] [DDC-3042] SQL Alias collisions in DQL Created: 21/Mar/14  Updated: 04/Apr/14  Resolved: 21/Mar/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates DDC-3042 select issue field names with numbers Resolved

 Description   

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

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

Message:

Verifies DDC-3042

Still WIP, no fixes so far.



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

Dupe of DDC-3042

Comment by Doctrine Bot [ 04/Apr/14 ]

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





[DDC-2621] Paginator with ORDER BY not working in MSSQL Created: 20/Aug/13  Updated: 04/Apr/14  Resolved: 08/Sep/13

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

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

SQL Server 2008 R2, Symfony 2.3 FOS User Bundle



 Description   

PHP code to test (A symfony 2.3 controller):
<?php
public function testAction() {
$em = $this->getDoctrine()->getManager();
$query = $em->createQuery("
SELECT report, user
FROM Report:Report report

JOIN report.user user

WHERE user.id = ?1
ORDER BY report.created DESC
");
$query->setMaxResults(10);
$query->setParameter(1, 1);
$results = new Paginator($query, $fetchJoinCollection = true);
foreach ($results as $result) {}; // This was needed to trigger the query o_O

return new Response();
}

Schema:
One User to Many Reports

SQL + ERROR:
An exception occurred while executing '
SELECT DISTINCT TOP 10 id0
FROM (
SELECT r0_.id AS id0
,r0_.Naam AS Naam1
,r0_.Omschrijving AS Omschrijving2
,r0_.aangemaakt AS aangemaakt3
,r0_.gewijzigd AS gewijzigd4
,r0_.verwijderd AS verwijderd5
,g1_.username AS username6
,g1_.username_canonical AS username_canonical7
,g1_.email AS email8
,g1_.email_canonical AS email_canonical9
,g1_.enabled AS enabled10
,g1_.salt AS salt11
,g1_.password AS password12
,g1_.last_login AS last_login13
,g1_.locked AS locked14
,g1_.expired AS expired15
,g1_.expires_at AS expires_at16
,g1_.confirmation_token AS confirmation_token17
,g1_.password_requested_at AS password_requested_at18
,g1_.roles AS roles19
,g1_.credentials_expired AS credentials_expired20
,g1_.credentials_expire_at AS credentials_expire_at21
,g1_.id AS id22
FROM Rapporten r0_
INNER JOIN Gebruiker g1_ ON r0_.GebruikerId = g1_.id
WHERE (g1_.id = ?)
AND (r0_.verwijderd IS NULL)
ORDER BY r0_.aangemaakt DESC
) dctrn_result
' with params [1]:

SQLSTATE[42000]: [Microsoft][SQL Server Native Client 11.0][SQL Server]The ORDER BY clause is invalid in views, inline functions, derived tables, subqueries, and common table expressions, unless TOP or FOR XML is also specified.

FIX:
Unknown



 Comments   
Comment by Flip [ 20/Aug/13 ]

I didn't get the Paginator working yet, but as i understand this is the first of 3 (maybe 2) queries, as described here: http://docs.doctrine-project.org/en/latest/tutorials/pagination.html It seems that in this first query it's not necessary to SELECT all these columns, so there is an opportunity here for a performance boost when not selecting them. (They still have to be selected in the final query to get the results).

Comment by Benjamin Eberlei [ 08/Sep/13 ]

Duplicate of DDC-2622

Comment by Flip [ 08/Sep/13 ]

It's not because, that one is on a different Doctrine version and the SQL looks differently as well.

Comment by Doctrine Bot [ 04/Apr/14 ]

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





[DDC-2687] Paginator with ORDER BY not working in MSSQL Created: 18/Sep/13  Updated: 04/Apr/14  Resolved: 12/Jan/14

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

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

Symfony 2.3, SQL Server 2008 R2



 Description   

This bug report is similar to this one:
http://www.doctrine-project.org/jira/browse/DDC-2622

It's decided to make a new bug report to keep things cleaner (commits have already been done on the other report).

PHP code to test (A symfony 2.3 controller):

Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
<?php
public function testAction() {
	$em = $this->getDoctrine()->getManager();
	$query = $em->createQuery("
		SELECT report, user
		FROM Report:Report report

		JOIN report.user user

		WHERE user.id = ?1
		ORDER BY report.created DESC
	");
	$query->setMaxResults(10);
	$query->setParameter(1, 1);
	$paginator = new Paginator($query, $fetchJoinCollection = true);
	$result = $paginator->getIterator(); // Trigger querying, using paginator
	//$result = $query->getResult();

	return [
		'var' => $result
	];
}
// returning the result to a template debug function

Schema:
One User to Many Reports

SQL + ERROR:

An exception occurred while executing '
SELECT *
FROM (
	SELECT DISTINCT id0
		,ROW_NUMBER() OVER (
			ORDER BY r0_.aangemaakt DESC
			) AS doctrine_rownum
	FROM (
		SELECT r0_.id AS id0
			,r0_.Naam AS Naam1
			,r0_.Omschrijving AS Omschrijving2
			,r0_.aangemaakt AS aangemaakt3
			,r0_.gewijzigd AS gewijzigd4
			,r0_.verwijderd AS verwijderd5
			,g1_.username AS username6
			,g1_.username_canonical AS username_canonical7
			,g1_.email AS email8
			,g1_.email_canonical AS email_canonical9
			,g1_.enabled AS enabled10
			,g1_.salt AS salt11
			,g1_.password AS password12
			,g1_.last_login AS last_login13
			,g1_.locked AS locked14
			,g1_.expired AS expired15
			,g1_.expires_at AS expires_at16
			,g1_.confirmation_token AS confirmation_token17
			,g1_.password_requested_at AS password_requested_at18
			,g1_.roles AS roles19
			,g1_.credentials_expired AS credentials_expired20
			,g1_.credentials_expire_at AS credentials_expire_at21
			,g1_.id AS id22
		FROM Rapporten r0_ WITH (NOLOCK)
		INNER JOIN Gebruiker g1_ ON r0_.GebruikerId = g1_.id
		WHERE (g1_.id = ?)
			AND (r0_.verwijderd IS NULL)
		) dctrn_result
	) AS doctrine_tbl
WHERE doctrine_rownum BETWEEN 1
		AND 10
' with params [1]:

SQLSTATE[42000]: [Microsoft][SQL Server Native Client 11.0][SQL Server]The multi-part identifier "r0_.aangemaakt" could not be bound. 

FIX:
Change

ORDER BY r0_.aangemaakt DESC

to

ORDER BY aangemaakt3 DESC

This fix should only be applied in case of the Paginator scenario, which looks like this:

Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
	$paginator = new Paginator($query, $fetchJoinCollection = true);
	$result = $paginator->getIterator(); // Trigger querying, using paginator
	//$result = $query->getResult();

When getting a normal result, like this:

Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
	//$paginator = new Paginator($query, $fetchJoinCollection = true);
	//$result = $paginator->getIterator(); // Trigger querying, using paginator
	$result = $query->getResult();

it works fine without any problems.

The "normal" result should keep working correctly!

The SQL produced by the non-paginator result:

FROM (
	SELECT r0_.id AS id0
		,r0_.Naam AS Naam1
		,r0_.Omschrijving AS Omschrijving2
		,r0_.aangemaakt AS aangemaakt3
		,r0_.gewijzigd AS gewijzigd4
		,r0_.verwijderd AS verwijderd5
		,g1_.username AS username6
		,g1_.username_canonical AS username_canonical7
		,g1_.email AS email8
		,g1_.email_canonical AS email_canonical9
		,g1_.enabled AS enabled10
		,g1_.salt AS salt11
		,g1_.password AS password12
		,g1_.last_login AS last_login13
		,g1_.locked AS locked14
		,g1_.expired AS expired15
		,g1_.expires_at AS expires_at16
		,g1_.confirmation_token AS confirmation_token17
		,g1_.password_requested_at AS password_requested_at18
		,g1_.roles AS roles19
		,g1_.credentials_expired AS credentials_expired20
		,g1_.credentials_expire_at AS credentials_expire_at21
		,g1_.id AS id22
		,r0_.GebruikerId AS GebruikerId23
		,g1_.group_id AS group_id24
		,ROW_NUMBER() OVER (
			ORDER BY r0_.aangemaakt DESC
			) AS doctrine_rownum
	FROM Rapporten r0_ WITH (NOLOCK)
	INNER JOIN Gebruiker g1_ ON r0_.GebruikerId = g1_.id
	WHERE (g1_.id = ?)
		AND (r0_.verwijderd IS NULL)
	) AS doctrine_tbl
WHERE doctrine_rownum BETWEEN 1
		AND 10

Notice

ORDER BY r0_.aangemaakt DESC

this is correct!

The difference is that the Paginator wraps the query in in a query with distinct, this is done here:
https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Tools/Pagination/LimitSubqueryOutputWalker.php#L160

So far i know two different solutions.

1.
Detect the wrapping query in SQLServerPlatform::doModifyLimitQuery with regex. See relevant code snippet below

Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
if (preg_match('/SELECT DISTINCT .* FROM \(.*\) dctrn_result/', $query)) {
		$isWrapped = true;
} else {
		$isWrapped = false;
}

//Find alias for each colum used in ORDER BY
if ( ! empty($orderbyColumns)) {
		foreach ($orderbyColumns as $column) {

				if ($isWrapped) {
						$pattern    = sprintf('/%s\.%s\s+(AS\s+)?([^,\s\)]+)/i', $column['table'], $column['column']);
						$overColumn = preg_match($pattern, $query, $matches) ? $matches[2] : $column['column'];
				} else {
						$pattern    = sprintf('/%s\.(%s)\s*(AS)?\s*([^,\s\)]*)/i', $column['table'], $column['column']);
						$overColumn = preg_match($pattern, $query, $matches)
								? ($column['hasTable'] ? $column['table']  . '.' : '') . $column['column'] 
								: $column['column'];
				}

				if (isset($column['sort'])) {
						$overColumn .= ' ' . $column['sort'];
				}

				$overColumns[] = $overColumn;
		}
}

This code would replace:
https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Platforms/SQLServerPlatform.php#L856-L870
And takes two lines of codes from this commit:
https://github.com/doctrine/dbal/blob/5d7bcb6637646eb1daf6d90827233f5562cbda29/lib/Doctrine/DBAL/Platforms/SQLServerPlatform.php#L860-L861

Another solution is that the Paginator should be responsible for notifying the SQLServerPlatform::doModifyLimitQuery method if the query is wrapped or not. In that case, this line of code
https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Tools/Pagination/LimitSubqueryOutputWalker.php#L171
should be replaced by

Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
$sql, $this->maxResults, $this->firstResult, true

And this line of code:
https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Platforms/SQLServerPlatform.php#L818
should be replaced by

Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
protected function doModifyLimitQuery($query, $limit, $offset = null, $isWrapped = false)

Of course parts of the code from the previous solution are still needed. But the $isWrapped detection is not done anymore by regex this way.



 Comments   
Comment by Flip [ 18/Sep/13 ]

I ran the full doctrine orm testsuite on a SQL Server 2008 R2 database. A before and after the first suggested bug fix has been applied. Tests results showed no difference at all. This means:
1. The change does not break any other stuff
2. There is no test yet to cover this case

Comment by Flip [ 12/Jan/14 ]

solved bug, can be closed. See: https://github.com/doctrine/dbal/pull/383

Comment by Marco Pivetta [ 12/Jan/14 ]

Merged: https://github.com/doctrine/dbal/commit/b4bcc18fe0d1b99e37ad51a4a25a04a83ab9d99a

Comment by Doctrine Bot [ 04/Apr/14 ]

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





[DDC-2622] Paginator with ORDER BY not working in MSSQL Created: 20/Aug/13  Updated: 04/Apr/14  Resolved: 12/Jan/14

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

Type: Bug Priority: Major
Reporter: Flip Assignee: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: None
Environment:

SQL Server 2008 R2, Symfony 2.3 FOS User Bundle



 Description   

PHP code to test (A symfony 2.3 controller):

<?php
public function testAction() {
	$em = $this->getDoctrine()->getManager();
	$query = $em->createQuery("
		SELECT report, user
		FROM Report:Report report
		
		JOIN report.user user

		WHERE user.id = ?1
		ORDER BY report.created DESC
	");
	$query->setMaxResults(10);
	$query->setParameter(1, 1);
	$results = new Paginator($query, $fetchJoinCollection = true);
	foreach ($results as $result) {}; // This was needed to trigger the query o_O

	return new Response();
}

Schema:
One User to Many Reports

SQL + ERROR:

An exception occurred while executing '
SELECT *
FROM (
	SELECT DISTINCT id0
		,ROW_NUMBER() OVER (
			ORDER BY r0_.aangemaakt DESC
			) AS doctrine_rownum
	FROM (
		SELECT r0_.id AS id0
			,r0_.Naam AS Naam1
			,r0_.Omschrijving AS Omschrijving2
			,r0_.aangemaakt AS aangemaakt3
			,r0_.gewijzigd AS gewijzigd4
			,r0_.verwijderd AS verwijderd5
			,g1_.username AS username6
			,g1_.username_canonical AS username_canonical7
			,g1_.email AS email8
			,g1_.email_canonical AS email_canonical9
			,g1_.enabled AS enabled10
			,g1_.salt AS salt11
			,g1_.password AS password12
			,g1_.last_login AS last_login13
			,g1_.locked AS locked14
			,g1_.expired AS expired15
			,g1_.expires_at AS expires_at16
			,g1_.confirmation_token AS confirmation_token17
			,g1_.password_requested_at AS password_requested_at18
			,g1_.roles AS roles19
			,g1_.credentials_expired AS credentials_expired20
			,g1_.credentials_expire_at AS credentials_expire_at21
			,g1_.id AS id22
		FROM Rapporten r0_ WITH (NOLOCK)
		INNER JOIN Gebruiker g1_ ON r0_.GebruikerId = g1_.id
		WHERE (g1_.id = ?)
			AND (r0_.verwijderd IS NULL)
		) dctrn_result
	) AS doctrine_tbl
WHERE doctrine_rownum BETWEEN 1
		AND 10
' with params [1]:

SQLSTATE[42000]: [Microsoft][SQL Server Native Client 11.0][SQL Server]The multi-part identifier "r0_.aangemaakt" could not be bound. 

FIX:
Change

ORDER BY r0_.aangemaakt DESC

to

ORDER BY aangemaakt3 DESC


 Comments   
Comment by Flip [ 20/Aug/13 ]

I didn't get the Paginator working yet, but as i understand this is the first of 3 (maybe 2) queries, as described here: http://docs.doctrine-project.org/en/latest/tutorials/pagination.html It seems that in this first query it's not necessary to SELECT all these columns, so there is an opportunity here for a performance boost when not selecting them. (They still have to be selected in the final query to get the results).

Comment by Marco Pivetta [ 15/Sep/13 ]

Just a note: the DQL query you're doing here is very dangerous hydration-wise. Don't ever filter on fetch-joined results.

Comment by Marco Pivetta [ 15/Sep/13 ]

Provided patches at https://github.com/doctrine/doctrine2/pull/789 and https://github.com/doctrine/dbal/pull/371

Comment by Flip [ 16/Sep/13 ]

I don't understand your comment about filtering on fetch-join results being dangerous for hydration, could you please elaborate?

Comment by Marco Pivetta [ 16/Sep/13 ]

Flip it's unrelated to this change. I'd just explain that on IRC to avoid cluttering the issue here.

Comment by Doctrine Bot [ 16/Sep/13 ]

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

Comment by Flip [ 12/Jan/14 ]

Can be closed in favor of http://www.doctrine-project.org/jira/browse/DDC-2687

Comment by Marco Pivetta [ 12/Jan/14 ]

Handled in DDC-2687

Comment by Doctrine Bot [ 04/Apr/14 ]

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





[DDC-2680] [GH-789] DDC-2622 - SQLServer expects column names in the `OVER` clause to not contain any table alias Created: 15/Sep/13  Updated: 04/Apr/14  Resolved: 15/Sep/13

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: None


 Description   

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

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

Message:

This PR contains the failing test case for DDC-2622

Strictly depends on doctrine/dbal#371



 Comments   
Comment by Marco Pivetta [ 15/Sep/13 ]

Duplicate of DDC-2622

Comment by Doctrine Bot [ 04/Apr/14 ]

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





[DDC-3061] [GH-996] [DDC-3027] Embedded in MappedSuperclass Created: 31/Mar/14  Updated: 03/Apr/14

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

Type: Bug Priority: Minor
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mappedsuperclass, mapping


 Description   

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

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

Message:

The fields from the MappedSuperclass embedded properties are getting mapped directly into the MappedSuperclass fields causing the error.

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






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

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

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


 Description   

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

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

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

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

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

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






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

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

 Description   

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

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

Message:

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

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

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

Where before, `null` was just ignored



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

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





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

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

Type: Bug Priority: Critical
Reporter: Sam Adams Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: IN, null, orm

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

 Description   

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

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

it is converted into:

mycol IN (?)

With the final query looking like:

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

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

Possible change to getSelectConditionStatementSQL method:

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

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

resulting in a final query like:

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


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

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

Comment by Doctrine Bot [ 03/Apr/14 ]

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





[DDC-3066] [GH-998] DDC-3065 null value in in criteria support Created: 03/Apr/14  Updated: 03/Apr/14  Resolved: 03/Apr/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None

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

 Description   

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

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

Message:

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

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

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

Where before, `null` was just ignored



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

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

Comment by Marco Pivetta [ 03/Apr/14 ]

Wrong branch name.





[DDC-3064] Parse Error which is pointing to the method getSingleResult(); Created: 02/Apr/14  Updated: 02/Apr/14  Resolved: 02/Apr/14

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

Type: Bug Priority: Major
Reporter: Haneefa Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: orm
Environment:
  1. DoctrineModule for Zend Framework 2


 Description   

syntax error, unexpected ''sidebar_bann' (T_ENCAPSED_AND_WHITESPACE), expecting ']'

TracedError reported from New Relic
Application: ENV2
Timestamp: 02/26/14 10:49:15
Exception Class: E_PARSE
Error Action: /index.php
Uri: /blog
Error message
E_PARSE: syntax error, unexpected ''sidebar_bann' (T_ENCAPSED_AND_WHITESPACE), expecting ']'



 Comments   
Comment by Haneefa [ 02/Apr/14 ]

Please help me to find out the cause of this issue.
Thanks!

Comment by Marco Pivetta [ 02/Apr/14 ]

Could you provide the DQL?

Comment by Haneefa [ 02/Apr/14 ]

I don't have the DQL as this error was logged by newrelic, see the zend stack trace here
…dor/doctrine/mongodb-odm/lib/Doctrine/ODM/MongoDB/Hydrator/
HydratorFactory.php (144)
…dor/doctrine/mongodb-odm/lib/Doctrine/ODM/MongoDB/Hydrator/
in Doctrine\ODM\MongoDB\Hydrator\HydratorFactory::getHydratorFor called at /vendor/doctrine/mongodb-odm/lib/Doctrine/ODM/MongoDB/Hydrator/HydratorFactory.php
HydratorFactory.php (404)
/vendor/doctrine/mongodb-odm/lib/Doctrine/ODM/MongoDB/
UnitOfWork.php (2518)
/vendor/doctrine/mongodb-odm/lib/Doctrine/ODM/MongoDB/
Cursor.php (118)
in Doctrine\ODM\MongoDB\Cursor::current called at ?
…alled at /vendor/doctrine/mongodb/lib/Doctrine/MongoDB/
Cursor.php (371)
…alled at /vendor/doctrine/mongodb/lib/Doctrine/MongoDB/
Cursor.php (419)
…alled at /vendor/doctrine/mongodb/lib/Doctrine/MongoDB/
Cursor.php (372)
…alled at /vendor/doctrine/mongodb/lib/Doctrine/MongoDB/
Cursor.php (384)
… at /vendor/doctrine/mongodb/lib/Doctrine/MongoDB/Query/
Query.php (277)

Comment by Marco Pivetta [ 02/Apr/14 ]

Not an ORM issue

Comment by Haneefa [ 02/Apr/14 ]

Can you just light me on this issue? what would I need to do? It is happening when I add a domain name(xxx.extample.com) in where condition. It would be great if you can help me.

Comment by Marco Pivetta [ 02/Apr/14 ]

Haneefa this is an issue tracker, not a support forum. You report issues here once you verified that it is actually a bug, a mistake on our side or something that has to be added or cleaned up in future versions of the software.

Your issue is a problem with MongoDB ODM (not with the ORM), and you should ask on either the mailing list (once you have more detail) or stackoverflow, or IRC (irc.freenode.net#doctrine).

Comment by Haneefa [ 02/Apr/14 ]

Thank you so much!





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

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

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


 Description   

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



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

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

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

Do we need to keep this ticket open?

Comment by Flip [ 02/Apr/14 ]

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

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





[DDC-1025] Please repalce 'Doctrine\XXX\YYY' with '\Doctrine\XXX\YYY' in code and document Created: 09/Feb/11  Updated: 01/Apr/14  Resolved: 01/Apr/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Documentation, DQL, Mapping Drivers, ORM, Tools
Affects Version/s: 2.0.1
Fix Version/s: 2.1, 2.2
Security Level: All

Type: Improvement Priority: Major
Reporter: ben yan Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 7
Labels: None


 Description   

It will help us use the namespace and code autocomplete in some IDE.



 Comments   
Comment by Matthieu Napoli [ 08/Apr/11 ]

Hi, do you have any more information about this ?

I'm confused because the php documentation uses the Doctrine\XXX way, and everywhere I've seen, it is used like that.

Thanks

Comment by Karsten Dambekalns [ 11/Apr/11 ]

The issue is simple and logical.

When an IDE (I am using PhpStorm and it does it like this) sees a namespace in a file, upon seeing namespaces afterwards, it sees them as absolute if they have a leading backslash, or relative when it does not. This affects the resolution of classes for type navigation, code inspection, ... The same rules as for actual PHP code should be used within comments.

Here is an example:

namespace Foo;

class Bar {

  /**
   * @var Baz
   */
  protected $baz;

  /**
   * @var \Quux
   */
  protected $quux;

}

The IDE will think $baz is \Foo\Baz and $quux will be seen as being \Quux. Now if you have some reference to Doctrine here, and it was relative, the IDE would assume it's \Foo\Doctrine\...

Comment by Benjamin Eberlei [ 11/Apr/11 ]

Well yes, but since all our code examples have no leading namespace argument this means the code is in the default namespace, making Doctrine\XXX\YY a relative namespace that is actually valid.

Comment by Karsten Dambekalns [ 11/Apr/11 ]

Yes, but the source code docblocks are what is meant here as far as I am concerned.

Comment by Andrey Kolyshkin [ 13/May/11 ]

Example (Entitymanager.php):

namespace Doctrine\ORM;

and

/**
  * The used Configuration.
  *
  * @var Doctrine\ORM\Configuration
  */
   private $config;

Result:
Doctrine\ORM\Doctrine\ORM\Configuration

Should be:

/**
  * The used Configuration.
  *
  * @var Configuration
  */
   private $config;

Or

/**
  * The used Configuration.
  *
  * @var \Doctrine\ORM\Configuration
  */
   private $config;
Comment by Miha Vrhovnik [ 27/May/11 ]

Why don't you take this to the PhpStorm tracker as it surely is a bug in IDE?

Comment by Karsten Dambekalns [ 27/May/11 ]

Miha, what makes you think it's an IDE bug? In a class in namespace Foo another class named Bar is \Foo\Bar, but \Bar is \Bar. Why is it a bug if the IDE follows the namespace resolution rules?

Comment by Michael Ridgway [ 11/Jul/11 ]

The issue is that PHPStorm and NetBeans have different class resolution rules. I also use PHPStorm and most of Doctrine does not resolve auto-completion correctly because of this issue.

I'd be willing to work on this if it would be accepted.

Comment by Andrew Mackrodt [ 29/Sep/11 ]

I've been evaluating PhpStorm and also came across this issue; I believe the problem is due to Doctrine rather than being a bug with the IDE although it would be nice if PhpStorm would assume namespaces are absolute if they're not resolved upon an initial lookup.

I created a quick c# app to append the beginning forward slash to any @var or @return attributes within Doctrine's source. It's working for me with Doctrine 2.1.2 and PhpStorm (IntelliJ): http://pastebin.com/4HxiWvJA - hopefully this will be of use for anyone else using these IDEs;. Note: the application doesn't detect multiple line annotations although the only one I'm aware of is the getAST method in Doctrine\ORM\Query.php.

Comment by Benjamin Eberlei [ 13/Dec/11 ]

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

Comment by Benjamin Eberlei [ 13/Dec/11 ]

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

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

Fixed in commits:
https://github.com/doctrine/doctrine2/commit/3b259dcb42e8ba332231846401d8d97296f3dd65
https://github.com/doctrine/doctrine2/commit/bda98150c4e876f0b1b89d757c864a70ad7c583a





[DDC-1143] deprecated or missing method, $cacheDriver->setManageCacheIds(true); Created: 10/May/11  Updated: 01/Apr/14  Resolved: 01/Apr/14

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

Type: Documentation Priority: Major
Reporter: raiz Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

http://www.doctrine-project.org/docs/orm/2.0/en/reference/caching.html
mentions $cacheDriver->setManageCacheIds(true);.
But method absent from V 2.04, possibly just needs a version note next to it.



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

Fixed in commit: https://github.com/doctrine/orm-documentation/commit/95b8e27bc5ec26f7655a04cebba4de6edb71f297

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

Fix version unknown

Comment by Marco Pivetta [ 01/Apr/14 ]

Steve Müller this doesn't look like fixed, this is an old issue about doctrine/cache.

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

Marco Pivetta the issue is about documentation and the method call is not referenced anymore so I thought the documentation issue in ORM is fixed...

Comment by Marco Pivetta [ 01/Apr/14 ]

Yeah, not valid anymore in ORM indeed, plus the cache adapters changed a lot in between.





[DDC-1106] Wrong inversedBy in example Created: 07/Apr/11  Updated: 01/Apr/14  Resolved: 01/Apr/14

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

Type: Documentation Priority: Major
Reporter: cristobal castro Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None

Attachments: Zip Archive screen-shot.zip    

 Description   

on page http://www.doctrine-project.org/docs/orm/2.0/en/reference/working-with-objects.html
section : 8.1. Association Example Entities, first example. Please see the .jpg in attachement(it explains clearly what I think is an error)
Regards.



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

Fixed in commit: https://github.com/doctrine/doctrine2/commit/10c48bad7b79af84855f7c63590f1f426770ed6b





[DDC-1235] Provide fluent interfaces in stub methods Created: 28/Jun/11  Updated: 01/Apr/14  Resolved: 01/Apr/14

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

Type: Improvement Priority: Major
Reporter: Andreas Hörnicke Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

Or maybe some template-files could be provided for all stubs.

private static $_setMethodTemplate =
'/**
 * <description>
 *
 * @param <variableType>$<variableName>
 */
public function <methodName>(<methodTypeHint>$<variableName>)
{
<spaces>$this-><fieldName> = $<variableName>;

<spaces>return $this;</spaces>
}';


 Comments   
Comment by Christophe Coevoet [ 29/Oct/12 ]

@beberlei this should be closed as it is the case since 2.2

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

Fixed in commit: https://github.com/doctrine/doctrine2/commit/2b334977f536e0d4f473ed1faa748d8c37de97db





[DDC-1269] Unexpected behavior while using association on a non primary key field Created: 11/Jul/11  Updated: 01/Apr/14  Resolved: 01/Apr/14

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

Type: Improvement Priority: Major
Reporter: Alexandr Torchenko Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None

Issue Links:
Reference
is referenced by DDC-1114 Association on a non primary key fiel... Closed

 Description   

We have association on non primary key. Something like this:

Entities\Payment:
  type: entity
  table: payments
  fields:
    id: 
      id: true
      type: integer
      nullable: false
      generator:
        strategy: IDENTITY
[-- skipped --]
  manyToOne:
    order:
      targetEntity: Entities\Order
      inversedBy: payments
      joinColumn:
        name: scode
        referencedColumnName: scode
Entities\Order:
  type: entity
  table: h_orders
  fields:
    id:
      id: true
      type: integer
      unsigned: false
      nullable: false
      generator:
        strategy: IDENTITY
    scode:
      type: integer
      unsigned: false
      nullable: false
[-- skipped --]
  oneToMany:
    payments:
      targetEntity: Entities\Payment
      mappedBy: order

When I try to fetch Order from Payment with lazy loading I receive empty Order object with null properties. If I use eager fetching Order object is valid.
SQL generated for lazy loading seems to be valid, so I suppose the problem is in mapping result to the object. At the same time lazy loading works fine with 2.0.6 version.

Another problem appears while persisting new Payment.

$payment = new \Entities\Payment();
...
$order = $this->em->getRepository('\Entities\Order')->find(46320);
$payment->setOrder($order);
$order->addPayments($payment);
$this->em->persist($payment);
$this->em->flush();

I get this error: Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'scode' cannot be null' in /usr/share/php/Doctrine/DBAL/Statement.php:131

I found issue which is still open and looks like mine – http://www.doctrine-project.org/jira/browse/DDC-1114. What do you think about this?



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

Formatting, please add a second ticket for the second issue.

Comment by Benjamin Eberlei [ 12/Jul/11 ]

I don't think its supported to use a non primary id for foreign key matching. I cant tell for sure though since i wasnt responsible to design this part of the Doctrine code. I would strongly suggest not to do this.

Comment by Benjamin Eberlei [ 12/Jul/11 ]

Marked as improvement. The problem is we cannot detect this invalid mapping, so no exception is thrown during compilation of the mappings,

Comment by Benjamin Eberlei [ 12/Jul/11 ]

This kind of mapping error is already acknowledged by the schema-validator console task.

Comment by Alexandr Torchenko [ 13/Jul/11 ]

Should I create second ticket?

Please confirm that I understood correctly. Should we avoid such mapping as it is considered as invalid.

Comment by Benjamin Eberlei [ 13/Jul/11 ]

Yes, it will not work at all. You dont need to create the second ticket as that error steams from the mapping error.

You will see an error message when calling ./doctrine orm:schema:validate with this mapping.

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

This usage is not supported. See: http://www.doctrine-project.org/jira/browse/DDC-1114





[DDC-1270] Incorrect QueryBuilder example Created: 11/Jul/11  Updated: 01/Apr/14  Resolved: 01/Apr/14

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

Type: Documentation Priority: Major
Reporter: Alex Bogomazov Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

In the QueryBuilder section of the documentation (http://www.doctrine-project.org/docs/orm/2.1/en/reference/query-builder.html#the-expr-class) there's an example with statements like

 
$qb->expr()->select('u')

But this doesn't work anymore.



 Comments   
Comment by Michael Ridgway [ 11/Jul/11 ]

PR at https://github.com/doctrine/orm-documentation/pull/35

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

Fixed in commit: https://github.com/doctrine/orm-documentation/commit/c0860a6018698701c63c80bf8c62e2be7b2c9268





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

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

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

CentOS, PHP 5.4, mysql



 Description   

I tried to set version to 2.4.0 but was prevented.

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

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

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


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

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

Comment by Tim Stamp [ 01/Apr/14 ]

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

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

Comment by Marco Pivetta [ 01/Apr/14 ]

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

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

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

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

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

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

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

Comment by Marco Pivetta [ 01/Apr/14 ]

Thats to avoid having an SQL statement like

SELECT * FROM foo WHERE bar IN()

, which is invalid.

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

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

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

Comment by Marco Pivetta [ 01/Apr/14 ]

Makes sense. Re-opening.

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

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

Comment by Marco Pivetta [ 01/Apr/14 ]

Steve Müller existing apps should do following anyway:

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

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

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

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





[DDC-1180] Indexed Associations: foreign key (association) cannot be used as indexBy field Created: 29/May/11  Updated: 01/Apr/14  Resolved: 01/Apr/14

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

Type: Improvement Priority: Major
Reporter: Petr Sobotka Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 3
Labels: None
Environment:

Using Doctrine ORM 2.1.0BETA1



 Description   

I am trying to index a collection by its entity's column which is also a foreign key (association). It seems to me that it is not possible at the moment.

For example:

/**
 * @Entity
 */
class Hotel
{

    // $id column and other stuff

    /**
     * @oneToMany(targetEntity="Booking", mappedBy="hotel", indexBy="room")
     * @var Booking[]
     */
    private $bookings;
}

/**
 * @Entity
 */
class Booking
{
    /**
     * @var Hotel
     *
     * @Id 
     * @ManyToOne(targetEntity="Hotel", inversedBy="bookings")
     * @JoinColumns({
     *   @JoinColumn(name="hotel_id", referencedColumnName="id")
     * })
     */
    private $hotel;

    /**
     * @var Room
     *
     * @Id
     * @ManyToOne(targetEntity="Room")
     * @JoinColumns({
     *   @JoinColumn(name="room_id", referencedColumnName="id")
     * })
     */
    private $room;
}

Only possible workaround I found is to define another (plain) entity's property mapped to the same table column and index by it:

/**
 * @Entity
 */
class Hotel
{

    // $id column and other stuff

    /**
     * @oneToMany(targetEntity="Booking", mappedBy="hotel", indexBy="roomId")
     * @var Booking[]
     */
    private $bookings;
}

/**
 * @Entity
 */
class Booking
{
    // ...

    /**
     * @var Room
     *
     * @Id
     * @ManyToOne(targetEntity="Room")
     * @JoinColumns({
     *   @JoinColumn(name="room_id", referencedColumnName="id")
     * })
     */
    private $room;
    
    /**
     * @var integer $roomId
     *
     * @Column(name="room_id", type="integer", nullable=false)
     */
    private $roomId;
}

Wouldn't it be easy to support it?



 Comments   
Comment by Benjamin Eberlei [ 05/Jun/11 ]

It is not so easy to implement from the first gimplse and it is not a bug but an improvement/feature request.

Comment by Benjamin Morel [ 02/Mar/13 ]

Related PR: https://github.com/doctrine/doctrine2/pull/204

Comment by Benjamin Morel [ 30/Mar/14 ]

This seems to have been integrated now:
https://github.com/doctrine/doctrine2/pull/639

Should this be marked as resolved?

Comment by Petr Sobotka [ 01/Apr/14 ]

Resolved. Thanks!





[DDC-1721] LIKE clausule should accept functions on the pattern Created: 21/Mar/12  Updated: 01/Apr/14

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

Type: Improvement Priority: Major
Reporter: Ignacio Larranaga Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 2
Labels: querybuilder,, sql-walker

Attachments: Text File Parser.patch     Text File SqlWalker.patch    

 Description   

Example:
SELECT .... WHERE upper(n.title) LIKE upper(:filter)

should be a valid SQL, now is rejected because the walker only accept a variable or an string expression.

I'm adding a patch to address this.



 Comments   
Comment by Ignacio Larranaga [ 21/Mar/12 ]

Sorry the Parser has to be modified also to allow expressions to be recognized, I'm attaching the necessary patch.

Comment by Benjamin Eberlei [ 22/Mar/12 ]

I am sure there is a reason why the walker doesn't accept this such as not all supported vendors allowing functions in right hand side LIKE expressions, but i am not sure about this.

Comment by Glen Ainscow [ 03/Oct/12 ]

This is not possible either:

WHERE CASE WHEN p.name IS NULL THEN u.username ELSE p.name END LIKE :name

Comment by Thomas Mayer [ 24/Jan/13 ]

In my case it worked when using "=" instead of "LIKE".

//works:
(CASE WHEN (Book.id = BookFrom.id) THEN BookTo.displayName ELSE BookFrom.displayName END) = :name

//[Syntax Error] line 0, col 1217: Error: Expected =, <, <=, <>, >, >=, !=, got 'LIKE'
(CASE WHEN (Book.id = BookFrom.id) THEN BookTo.displayName ELSE BookFrom.displayName END) LIKE :name

So the LIKE operator only needs to be allowed here.

I'm wondering which vendor should not be able to handle that:
The CASE WHEN ... THEN ... END is documented in DQL, and allowed.
LIKE itself is allowed.
If an RDBMs cannot use CASE WHEN and LIKE in combination, this would be a strange limitation.

Comment by Martin Keckeis [ 31/Mar/14 ]

Having the same problem here.

LIKE + CASE is often used in my application at the WHERE part.
(e.g. data filtering of a datagrid column)





[DDC-2262] [GH-559] [Paginator] Added support for order by scalar Created: 26/Jan/13  Updated: 01/Apr/14  Resolved: 27/Jan/13

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

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


 Description   

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

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

Message:



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

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

Comment by Doctrine Bot [ 01/Apr/14 ]

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





[DDC-2266] [GH-562] Fix error in QueryBuilder example Created: 30/Jan/13  Updated: 01/Apr/14  Resolved: 05/Feb/13

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

Type: Documentation Priority: Trivial
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:



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

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

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

Merged : https://github.com/doctrine/doctrine2/commit/4651d92d634784d5d8d02af378afccb74935058c

Comment by Doctrine Bot [ 01/Apr/14 ]

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





[DDC-2042] Metadata association overriding : allow to override 'targetEntity' Created: 26/Sep/12  Updated: 31/Mar/14

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

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


 Description   

While associating object to an descriminated table I wasn't enable to fix the entityTarget (only one can be set in entity annotation).

It could be resolve by adding the possibility to override 'targetEntity' value in Doctrine\ORM\Mapping\ClassMetadataInfo::ClassMetadataInfo().

Such as :

if (isset($overrideMapping['targetEntity'])) {
$mapping['targetEntity'] = $overrideMapping['targetEntity'];
}

That would need to add a control on the new targetEntity in Doctrine\ORM\Mapping\ClassMetadataInfo::_validateAndCompleteAssociationMapping().

Such as :

if ( ! ClassLoader::classExists($mapping['targetEntity']) ) {
throw MappingException::invalidTargetEntityClass($mapping['targetEntity'], $this->name, $mapping['fieldName']);
}

cro.



 Comments   
Comment by Oleg Namaka [ 31/Mar/14 ]

We need this feature too. Why is this ticket in a limbo? Someone please add a comment whether this will be fixed.

Comment by Marco Pivetta [ 31/Mar/14 ]

Oleg Namaka you can open a pull request with a test and suggested improvement for this at https://github.com/doctrine/doctrine2





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

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

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


 Description   

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

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

Message:

Hi,

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

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

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

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

All tests pass, test were added for other operators.






[DDC-3017] UnitOfWork::$entityIdentifiers does not get updated when saving composite PK with a JoinColum as PK Created: 08/Mar/14  Updated: 31/Mar/14  Resolved: 23/Mar/14

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

Type: Bug Priority: Critical
Reporter: Thomas Rabaix Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

The Sonata Admin Bundle rely on the ``UnitOfWork::getEntityIdentifier`` method to retrieve the object identifier.

We are adding support for composite PK with a FK as described in the gist: https://gist.github.com/rande/9439778 .

The bug occurs when the Material reference is updated on the Color object. The Color has a new set of PK. However the UnitOfWork::$entityIdentifiers is not updated when the object is persisted. So the values stored ``UnitOfWork::$entityIdentifiers`` are invalid for the Color object.

The consequence is that we are unable to redirect the user once the object is saved as the UnitOfWork::getEntityIdentifier refers to the old values.



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

Thomas Rabaix can you please come up with a failing test case for this issue?

Comment by Benjamin Eberlei [ 23/Mar/14 ]

It is not supported to change the identifier. They are assumed to be immutable by Doctrine and we cannot change that, as the consequences are impossible to handle.

Comment by Thomas Rabaix [ 31/Mar/14 ]

Thanks for commenting this issue. So with composite keys the assumption is wrong and from your comment this bug is the expected behavior.

Now, should doctrine provide a secure method to retrieve the identifier keys ?

Comment by Marco Pivetta [ 31/Mar/14 ]

Thomas Rabaix shouldn't you extract identifiers via metadata by having an instance of an entity?

Comment by Thomas Rabaix [ 31/Mar/14 ]

It is what I did: https://github.com/sonata-project/SonataDoctrineORMAdminBundle/blob/master/Model/ModelManager.php#L277-L303

However it will be better to have a clean implementation in the ORM.





[DDC-2780] IS [NOT] NULL conditions with JOINs Created: 06/Nov/13  Updated: 30/Mar/14  Resolved: 30/Mar/14

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

Type: Bug Priority: Major
Reporter: Marek Štípek Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

<?php
When trying to apply a [NOT] NULL condition on LEFT JOINed association. It ends with an error.

"Cannot add having condition on a non result variable."

$queryBuilder
->leftJoin('r.players', 'players', 'WITH', 'players = :player')
->where('players IS NULL');

It was working 3 month ago. But then, this commit broke it.

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

Or in other words if this is not a bug. How to test if the collection does not contain let's say a user with ID 5 (AND XX OR YY) with DQL/queryBuilder API? IN SQL I would just simply LEFT JOIN it with ON condition and then i would test it for existence using IS NULL in WHERE condition. How to do this using DQL when the pasted example ends with an error?



 Comments   
Comment by Marek Štípek [ 30/Mar/14 ]

OK. players.id IS NULL (but it's uglier)





[DDC-3059] [GH-994] Update EntityGenerator comment Created: 29/Mar/14  Updated: 29/Mar/14  Resolved: 29/Mar/14

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

Type: Documentation Priority: Trivial
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

fieldVisibility was referred to as a boolean, where it is actually a string.



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

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

Comment by Marco Pivetta [ 29/Mar/14 ]

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





[DDC-2259] [GH-557] [DDC 2004] addFilter class name or instance Created: 26/Jan/13  Updated: 28/Mar/14  Resolved: 26/Jan/13

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

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


 Description   

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

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

Message:

Make it possible to add filter class name or instance to addFilter. This is useful to use services to inject other dependencies.



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

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

Comment by Doctrine Bot [ 28/Mar/14 ]

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





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

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

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


 Description   

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

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

Message:

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


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






[DDC-2258] [GH-556] Create queryBuilder from parts. Created: 25/Jan/13  Updated: 28/Mar/14  Resolved: 04/May/13

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

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

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

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

Message:

Add a feature that can create a queryBuilder from queryBuilder parts.

This can be used when a query is build and needs to be stored somehow and restore it later.



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

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

Comment by Doctrine Bot [ 28/Mar/14 ]

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





[DDC-3057] [GH-992] Fixed typos Created: 28/Mar/14  Updated: 28/Mar/14  Resolved: 28/Mar/14

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

Type: Documentation Priority: Trivial
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:



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

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

Comment by Marco Pivetta [ 28/Mar/14 ]

Merged: https://github.com/doctrine/doctrine2/commit/8f688509c83f2176d0c3bb01f024ddf021d36c93





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

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

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

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



 Description   

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

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

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

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

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



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

I suggest reporting it to the HHVM team as a bug

Comment by Marco Pivetta [ 28/Mar/14 ]

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

Comment by Christophe Coevoet [ 28/Mar/14 ]

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

Comment by Marco Pivetta [ 28/Mar/14 ]

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





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

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

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


 Description   

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



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

Hilz Simon did you try this with master as well?





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

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

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


 Description   

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

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

Message:

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

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

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

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

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

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

);
```

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






[DDC-2363] Duplicated record with orphanRemoval and proxy Created: 22/Mar/13  Updated: 27/Mar/14

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

Type: Bug Priority: Major
Reporter: Manuele Menozzi Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orphanRemoval, proxy
Environment:

Tested both Mac OS X and Ubuntu


Issue Links:
Duplicate
is duplicated by DDC-2364 [GH-625] [DDC-2363] Duplicated record... Open

 Description   

There is a problem that causes duplicate records are created when EntityManager has to remove an entity due to orphanRemoval. The problem occurs only with a double flush and referred object is a proxy.

I'm trying to submit a pull request for this ticket. Please, stand by.



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

Hey Manuele Menozzi, do you remember if this has been fixed? Are you still able to reproduce the problem?

Comment by Manuele Menozzi [ 27/Mar/14 ]

Hi Marco,
I made a PR (https://github.com/doctrine/doctrine2/pull/625) with an automated test that reproduce the problem. I just ran this test over latest version of doctrine2 and it's still failed. So, the problem has not be fixed and I (or you) can reproduce it easily.

Let me know if I can help you somehow.

Comment by Marco Pivetta [ 27/Mar/14 ]

Thanks, didn't see it!





[DDC-2364] [GH-625] [DDC-2363] Duplicated record with orphanRemoval and proxy Created: 22/Mar/13  Updated: 27/Mar/14

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

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

Issue Links:
Duplicate
duplicates DDC-2363 Duplicated record with orphanRemoval ... Awaiting Feedback

 Description   

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

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

Message:

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






[DDC-3053] [GH-990] Typo in documentation Created: 27/Mar/14  Updated: 27/Mar/14  Resolved: 27/Mar/14

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

Type: Documentation Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

This method from AbstractQuery accepts constants from ClassMetadata rather than string



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

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

Comment by Marco Pivetta [ 27/Mar/14 ]

Merged: https://github.com/doctrine/doctrine2/commit/ca19db34d2bdea7b661fdd05f0e0991feca80a0c





[DDC-2452] Additional `WITH` condition in joins between JTI roots cause invalid SQL to be produced Created: 16/May/13  Updated: 27/Mar/14

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

Type: Bug Priority: Major
Reporter: Marco Pivetta Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: dql, sql-walker
Environment:

irrelevant



 Description   

Given a simple Joined Table Inheritance like following:

/**
 * @Entity @Table(name="foo") @InheritanceType("JOINED")
 * @DiscriminatorColumn(name="discr", type="string")
 * @DiscriminatorMap({"foo" = "DDC2452Foo", "bar" = "DDC2452Bar"})
 */
class DDC2452Foo
{
    /** @Id @Column(type="integer") @GeneratedValue */
    public $id;
}

/** @Entity @Table(name="bar") */
class DDC2452Bar extends DDC2452Foo
{
}

Following DQL

SELECT foo1 FROM DDC2452Foo foo1 JOIN DDC2452Foo foo2 WITH 1=1

Will produce broken SQL:

SELECT
    f0_.id AS id0, f0_.discr AS discr1 
FROM 
    foo f0_ 
LEFT JOIN bar b1_ 
    ON f0_.id = b1_.id 
LEFT JOIN foo f2_ 
LEFT JOIN bar b3_ 
    ON f2_.id = b3_.id 
    ON (1 = 1)

(please note the duplicate `ON` in the SQL)

That is caused because of the SQL walker producing the JTI filter with already the `ON` clause in it.

That happens because the JTI join conditions are added in https://github.com/doctrine/doctrine2/blob/2.4.0-BETA2/lib/Doctrine/ORM/Query/SqlWalker.php#L823-L825 (`walkRangeVariableDeclaration`), while the additional defined `WITH` conditions are considered in `walkJoinAssociationDeclaration` later on.

Added a test case and fix at https://github.com/doctrine/doctrine2/pull/668






[DDC-3051] PersistentCollection::removeElement() leads to deletion of element, even if it is re-added via add() Created: 26/Mar/14  Updated: 27/Mar/14  Resolved: 26/Mar/14

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

Type: Bug Priority: Minor
Reporter: Daniel Richter Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

PersistentCollection::removeElement() leads to deletion of element, even if it is re-added via add(). This is because internally the element is scheduled for orphan deletion. This leads to unexpected effects, because until the UOW is committed, the relationships are re-established, but after the element is gone.

Suggested fix would be to add the ability to un-schedule an orphan removal and call this from the add() method.



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

This has been normal behavior for a lot of time now. The correct approach is to either avoid removal of the associated object from the collection or re-persisting the object (manually) after having it removed from the collection.

Comment by Daniel Richter [ 26/Mar/14 ]

I worked around by cloning the object, but still I find this unnecessarily inconsistent.

For example:

$order = new Order(); //new object working with ArrayCollection internally
$promotion = new Promotion();

//a sequence of events which might be distributed over different areas of code
$order->addPromotion($promotion);
$order->removePromotion($promotion);
$order->addPromotion($promotion);

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

//at this point $promotion is persisted properly.

Compare this to the same sequence of events, but an order that was loaded from the database:

$order = $repository->find(1); //existing order, working with PersistentCollection internally
$promotion = new Promotion();

//same sequence of events
$order->addPromotion($promotion);
$order->removePromotion($promotion);
$order->addPromotion($promotion);

$em->flush();

//now the promotion will NOT be persisted, even though $order->getPromotions() will still return it.

To me this violates the idea that Doctrine stays out of your way and lets you work with your domain objects without worrying too much about the persistence details.

Comment by Marco Pivetta [ 26/Mar/14 ]

Daniel Richter The problem is pretty much the same as creating/removing any element in the object graph.
OrphanRemoval currently allows removal of items from the object graph, and the assumption is that these items will be "gone" when this happens.

To have something like what you are suggesting (persist on addition to a collection) we would need another similar (complementary) feature that doesn't affect OrphanRemoval at all.

OrphanRemoval just works like it should: if you want to propose a complementary functionality, please open a new issue.

Comment by Daniel Richter [ 27/Mar/14 ]

I appreciate your time and response. I don't want to be complainy or unreasonable, but I'm not sure my point has come across.

The persist is happening properly, via cascase: persist. No issue there.

The issue is that the object in question ($promotion in my example) is not an orphan, but still it is removed. I would expect orphan removal to look at the orphan status of objects at the time of the commit, not whether at any point an object has become temporarily detached. I don't think it is reasonable in a large OOP application to keep track of relationship changes during the course of a transaction, it should only matter what the relationships are at the time of the commit.

My suggestion of simply "unscheduling" the orphan removal seems a simple addition to the PersistentCollection. Schedule on removal, unschedule on addition. This seems consistent and symmetric.
I would be happy to submit a PR with this addition, I just want to make sure I understand your objection first.

Thank you for helping me understand.

Comment by Marco Pivetta [ 27/Mar/14 ]

Daniel Richter it could work if the PersistentCollection kept track of removed entities.

You can try with a pull request, but I'm not sure if the feature is going to be accepted by the lead.

Giving it a try won't hurt though, and adding a PersistOnAdd (or something like that) would eventually also be acceptable in my opinion.





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

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

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


 Description   

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

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

Message:

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

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






[DDC-3050] between does not support literal in first argument Created: 26/Mar/14  Updated: 26/Mar/14  Resolved: 26/Mar/14

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

Type: Bug Priority: Trivial
Reporter: Ryan Korczykowski Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None
Environment:

MySQL



 Description   

This may not be a bug since this feature may not be portable.

The following dql results in an error:

select e from Entity e 
where '2011-01-01' BETWEEN e.periodStart AND e.periodEnd

[Syntax Error] line 0, col 263: Error: Expected =, <, <=, <>, >, >=, !=, got 'BETWEEN'

If I replace the date literal with a bound param it will work as expected.



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

We discourage usage of magic constants in DQL, as well as any form of inclusion of parameters in DQL strings via string concatenation.





[DDC-2590] Class inheritance - left join between child and parent entities Created: 06/Aug/13  Updated: 25/Mar/14

Status: Awaiting Feedback
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.3.1, 2.3.2, 2.3.3, 2.3.4
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Tomáš Ďuračka Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: inheritance, joins, orm, sql-walker


 Description   

The piece of code given under creates wrong sql to me.

Module is parent entity for BusinessModule entity. Category is joined with BusinessModule.

Module entity is only left joined to its child entity and that's the problem because it contains a field "name" used for filtering. So even if there is no module having the name, categories are still included.

I need the parent entity to be inner joined to child entity not left joined.

File doctrine2/lib/Doctrine/ORM/Query/SqlWalker.php line 353:

// If this is a joined association we must use left joins to preserve the correct result.
$sql .= isset($this->queryComponents[$dqlAlias]['relation']) ? ' LEFT ' : ' INNER ';
$qb->select('c')
->from('Category', 'c')
->join('c.module', 'm', 'WITH', 'm.name = :moduleName')
->setParameter('moduleName', $moduleName);
SELECT c0_.category_id AS category_id0, c0_.title AS title1, c0_.h1 AS h12, c0_.alias AS alias3,
c0_.insertion_fee AS insertion_fee4, c0_.description AS description5, c0_.parent_category_id AS
parent_category_id6, c0_.module_id AS module_id7 
FROM category c0_ 
INNER JOIN business_module b1_ ON c0_.module_id = b1_.module_id 
LEFT JOIN module m2_ ON b1_.module_id = m2_.module_id AND (m2_.name = ?)


 Comments   
Comment by Marek Štípek [ 06/Nov/13 ]

I am experiencing the same issue. The workarround could be to use LEFT JOIN with IS NOT NULL condition... But it also doesnt work after this commit
https://github.com/doctrine/doctrine2/commit/d9c1782a4f6d46f66e9deb2c375830f9192d4482 (i had to revert to dev-master#13c1efb240dd0af25ad0abe230df98ec895892c7)





[DDC-2996] UnitOfWork::recomputeSingleEntityChangeSet() will not add a new change set Created: 23/Feb/14  Updated: 25/Mar/14  Resolved: 23/Mar/14

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

Type: Bug Priority: Major
Reporter: Matthieu Napoli Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

I have noticed something weird in the UnitOfWork::recomputeSingleEntityChangeSet() and I suspect it is a bug.

If I write a Listener that, on the onFlush() event, changes an entity: the documentation says to call "recomputeSingleEntityChangeSet()". However, in that method, if a change set DOESN'T EXIST, then no changeset seems to be set at all: https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/UnitOfWork.php#L940

        if ($changeSet) {
            if (isset($this->entityChangeSets[$oid])) {
                $this->entityChangeSets[$oid] = array_merge($this->entityChangeSets[$oid], $changeSet);
            }

            $this->originalEntityData[$oid] = $actualData;
        }

As you can see, if a changeset exist, we merge it, but there is no "else".

That "bug" would be consistent with a problem I'm facing: calling recomputeSingleEntityChangeSet() in onFlush() on an entity that previously (at the time of the flush) had no changes, then that entity's changes are not persisted.

Related: people saying recomputeSingleEntityChangeSet() doesn't work (just like me):

So it is a bug? Or is it intended?



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

That "bug" would be consistent with a problem I'm facing

Matthieu Napoli can you provide an example of what your listener is doing? And yes, the assumption is that a changeset for that entity already exists (otherwise it is an insert or delete operation)

Comment by Matthieu Napoli [ 23/Feb/14 ]

I have User which has a UserPreference. When UserPreference is updated in any way, I need to set "User::updatedAt" with the current time. (FYI this is because Timestampable doesn't monitor changes on a "sub-entity").

So indeed, when User is not changed but UserPreference is, the listener will introduce changes on User.

Comment by Marco Pivetta [ 23/Feb/14 ]

Matthieu Napoli tricky. What if the suggested else would just trigger UnitOfWork#computeSingleEntityChangeSet()? I'm not sure if that's going to be a BC break though.

You can workaround that by doing it manually to see if your problem is fixed by this:

if ($uow->getEntityChangeSet()) {
    $uow->recomputeSingleEntityChangeSet(...);
} else {
    $uow->computeSingleEntityChangeSet(...);
}
Comment by Matthieu Napoli [ 25/Feb/14 ]

I was going to try that but computeSingleEntityChangeSet() is private anyway...

> What if the suggested else would just trigger UnitOfWork#computeSingleEntityChangeSet()? I'm not sure if that's going to be a BC break though.

That would be the best solution I think, but I have no idea about BC.

Comment by juan maia [ 17/Mar/14 ]

Is anyone taking a look at this?

I also had a problem that maybe is related to this one.
I was calling (computeChangeSet) inside the same listener, 3 different times, for 3 different entities, but the first one doesnt change the entity (the other 2 was just fine). Then I tried recomputeSingleEntityChangeSet and nothing happened to the entities (the entities are already persisted and I'm just trying to modifying it).

Comment by Benjamin Eberlei [ 23/Mar/14 ]

Fixed

Comment by Matthieu Napoli [ 23/Mar/14 ]

Awesome news thanks

Comment by Vitaliy Zhuk [ 25/Mar/14 ]

I have a problem after update with this commit.
My application control entity insertions/updated and change another field in entity.

Logic example:

Check each entity in insertions
Check each entity in updated

And i call recompute change set in entity in check insertion, this entity added to updated, and the second step not good working, because entity INSERTIONS!

Subscriber, for example:

<?php

namespace Acme\DemoBundle\EventListener\Doctrine;

use Acme\DemoBundle\Entity\Top;
use Doctrine\Common\EventSubscriber;
use Doctrine\ORM\Event\OnFlushEventArgs;
use Doctrine\ORM\Events;

class TopChangedSubscriber implements EventSubscriber
{
    /**
     * On flush event
     *
     * @param OnFlushEventArgs $event
     */
    public function onFlush(OnFlushEventArgs $event)
    {
        $em = $event->getEntityManager();
        $uow = $em->getUnitOfWork();

        $topMetadata = $em->getClassMetadata('DemoBundle:Top');

        foreach ($uow->getScheduledEntityInsertions() as $top) {
            if ($top instanceof Top) {
                $top->setChanged(301 -  $top->getPosition());
 
                // So, i call to recompute, because entity changed.
                // BUG #1? This entity added to entity updates, and getScheduledEntityUpdates returned incorrect data
                // BUG #2? This entity has been insert (1 SQL query) and update (2 SQL query)!
                $uow->recomputeSingleEntityChangeSet($topMetadata, $top);
            }
        }

        foreach ($uow->getScheduledEntityUpdates() as $top) {
            if ($top instanceof Top) {
                $changes = $uow->getEntityChangeSet($top);

                if (isset($changes['position'])) {
                    list ($oldPosition, $newPosition) = $changes['position'];

                    $top->setChanged($oldPosition - $newPosition);

                    $uow->recomputeSingleEntityChangeSet($topMetadata, $top);
                }
            }
        }
    }

    /**
     * {@inheritDoc}
     */
    public function getSubscribedEvents()
    {
        return array(Events::onFlush);
    }
}

Thank.

Comment by Marco Pivetta [ 25/Mar/14 ]

Vitaliy Zhuk as I've already explained in https://github.com/doctrine/doctrine2/commit/d473824279bfee19772bb1692d2a3453a2aff233#commitcomment-5796295, you are not supposed to re-compute changes for insertions.

Comment by Vitaliy Zhuk [ 25/Mar/14 ]

Ok, i can change entity field in insert action?





[DDC-3048] [GH-987] Fixes typo in dql-doctrine-query-language.rst Created: 25/Mar/14  Updated: 25/Mar/14  Resolved: 25/Mar/14

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

Type: Documentation Priority: Trivial
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

Changes "If you a query" to "If you have a query"



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

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

Comment by Steve Müller [ 25/Mar/14 ]

Fixed in commit: https://github.com/doctrine/doctrine2/commit/048c56bdb0e586524747913360d9063e7df53cc3





[DDC-2251] [GH-552] Added new query hints: HINT_NO_STORE_IDENTITY_MAP, HINT_NO_LOAD_ASSOCIATED_SUBTYPES Created: 20/Jan/13  Updated: 25/Mar/14  Resolved: 20/Jan/13

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

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


 Description   

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

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

Message:

1. `HINT_NO_STORE_IDENTITY_MAP` usable for situations when we have article with big text fields and use partial loading for list articles. When we try load article by id from loaded list on same request we got partial entity. `HINT_NO_STORE_IDENTITY_MAP` allow avoid this.

2. `HINT_NO_LOAD_ASSOCIATED_SUBTYPES` usable when we have entity which has `one-to-one` or `many-to-one` association to abstract entity with subtypes.



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

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

Comment by Doctrine Bot [ 25/Mar/14 ]

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





[DDC-2211] [GH-541] Fix DDC-1690 Created: 20/Dec/12  Updated: 25/Mar/14  Resolved: 22/Dec/12

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

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


 Description   

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

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

Message:

Added the lines suggested by the original reporter.



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

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

Comment by Doctrine Bot [ 25/Mar/14 ]

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





[DDC-2216] [GH-544] Partially back out commit from Dec 5 Created: 28/Dec/12  Updated: 25/Mar/14  Resolved: 06/Jan/13

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

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


 Description   

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

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

Message:

It works in my instance. No getObject() methods anywhere found on head of doctrine.



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

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

Comment by Doctrine Bot [ 25/Mar/14 ]

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





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

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

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

ubuntu 13.10, mysql 5.5.35



 Description   

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






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

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

Message:

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



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

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





[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-2909] different entity state after flush() Created: 12/Jan/14  Updated: 23/Mar/14  Resolved: 23/Mar/14

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

Type: Bug Priority: Major
Reporter: Jacek Hensoldt Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: entity, flush, orm, state


 Description   

Example 1:

I add a new address to the repository and remove it before flush

$user = new User();
$user->setName('Mr. Test');

$address1 = new Address();
$address1->setCity('Hamburg');

//$user->addAddress($address1);
$em->persist($address1);
$em->persist($user);

echo "<br>Address entity state before remove:".$unitOfWork->getEntityState($address1);

$em->remove($address1);

echo "<br>Address entity state after remove:".$unitOfWork->getEntityState($address1)."<br>";

$em->flush();

echo "<br>Address entity state after flush:".$unitOfWork->getEntityState($address1);

Output:

Address entity state before remove:1 (MANAGED)
Address entity state after remove:2 (NEW)
Address entity state after flush:2 (NEW)

everything ok, new address entity was not stored and has the state NEW

Example 2:

now i add the address entity to the user entity (the addresses-property in user entity has cascade=

{"persist"})

I change a line
$user->addAddress($address1);
//$em->persist($address1);
$em->persist($user);


Output:

Address entity state before remove:1 (MANAGED)
Address entity state after remove:2 (NEW)
Address entity state after flush:1 (MANAGED)

Oops, my removed address is after flush() stored and managed?

I think I know what happened, but I do not think that's right. If I check the state of an entity before flush and the entity is in NEW state than i think it will not be stored.

"An entity is in NEW state if has no persistent state and identity and is not associated with an EntityManager"

My User & Address code:



class User {
/** @Id @Column(type="integer") @GeneratedValue **/
protected $id;
/** @Column(type="string") **/
protected $name;

/**
* @OneToMany(targetEntity="Address", mappedBy="user", cascade={"persist"}

)

  • @var Address[]
    **/
    protected $addresses = null;

public function __construct()

{ $this->addresses = new ArrayCollection(); }

public function getId()

{ return $this->id; }

public function setName($name) { $this->name = $name; }

public function getName() { return $this->name; }

public function addAddress(Address $address) { $this->addresses[] = $address; $address->setUser($this); }

public function addAddresses(\Doctrine\Common\Collections\ArrayCollection $addresses) { $this->addresses = $addresses; }

public function removeAddress(\Model\Address $address) { $this->addresses->removeElement($address); $address->removeUser(); }

/**
* @return \Doctrine\Common\Collections\ArrayCollection
*/
public function getAddresses() { return $this->addresses; }
}


class Address {
/** @Id @Column(type="integer") @GeneratedValue **/
protected $id;
/** @Column(type="string") **/
protected $zipcode;
/** @Column(type="string") **/
protected $city;

/**
* @ManyToOne(targetEntity="User", inversedBy="addresses")
* @var User;
**/
protected $user = null;

public function setCity($city) { $this->city = $city; }

public function getCity() { return $this->city; }

public function getId() { return $this->id; }

public function setZipcode($zipcode)

{ $this->zipcode = $zipcode; }

public function getZipcode()

{ return $this->zipcode; }

public function setUser(\Model\User $user)

{ $this->user = $user; }

public function removeUser()

{ $this->user = null; }

public function getUser()

{ return $this->user; }

}




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

This is because you cascade persist. The feature is called "persist by reachability", which propagates managed state to related entities when cascade=persist is configured. Which it is in your case.





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

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

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

MySQL, using DoctrineORMModule (zf2 integration)



 Description   

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

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

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

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

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

Doing this:

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

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

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

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

Leads to

integrity constraint violation, b_id can not be null

aka

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

I have no idea why this happens. This works:

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

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

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

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


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

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





[DDC-2991] [GH-957] makes doctrine less dependent upon the symfony yamp component Created: 20/Feb/14  Updated: 23/Mar/14  Resolved: 23/Mar/14

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

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


 Description   

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

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

Message:

This is the last place in the framework where the class is just too tightly coupled with the symfony yaml component, that the yaml parser alone cannot be overridden without overriding an entire class.
I simply brought it in accordance with "Doctrine\ORM\Mapping\Driver\YamlDriver" where a separate method called loadMappingFile exists to parse the mapping file.



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

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





[DDC-2896] [GH-903] add test showing how postPersist can be registered and executed twice us... Created: 09/Jan/14  Updated: 23/Mar/14  Resolved: 23/Mar/14

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

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


 Description   

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

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

Message:

...ing the AnnotationDriver.



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

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





[DDC-2997] [GH-960] allow passing EntityManagerInterface when creating a HelperSet Created: 23/Feb/14  Updated: 23/Mar/14  Resolved: 23/Mar/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 1
Labels: None


 Description   

I've was "extending" EntityManager by decoration-wrapping and was trying to pass my EntityManager to ConsoleRunner::createHelperSet() and the type-hinting didn't allow it.
This fix will allow the $entityManager parameter to be an instance of EntityManagerInterface instead of EntityManager

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

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



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

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





[DDC-2985] [GH-955] iteration risk note Created: 17/Feb/14  Updated: 23/Mar/14  Resolved: 23/Mar/14

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

Type: Documentation Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

> instead of loading the whole result into memory at once

is not the full truth.

There is a certain risk of processes getting killed due to memory allocation with large iteration. This is caused by result buffering of the client. It is not always being visible to PHP as http://www.php.net/manual/en/mysqlinfo.concepts.buffering.php suggests.

This is only a proposal for discussion as I am not certain how to best add the information or if to add it at all (was it obvious before?). Is buffered iteration even a good suggestion for anything but small sets?

On a side-note: is there a way to run unbuffered queries with Doctrine?



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

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





[DDC-2995] Joined Inheritance Mapping and Filters Created: 22/Feb/14  Updated: 23/Mar/14

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

Type: Bug Priority: Major
Reporter: Bojidar Hristov Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: orm


 Description   

Is there any reason why Inheritance Mapping IS LEFT JOINED not INNER JOINED?

When there is a filter and it's left joined it happens a record might not have parent table record. For example

Class B extends Class A.
Class A have column is_active | and filter activated with is_active = 1 condition.

Final query: LEFT JOIN parent_table s1_ ON p2_.id = s1_.id AND (s1_.is_active = '1')

Record 1 have is_active = false, so result set looks like this:

table_b | table_a
id | id is_active discriminatorColumn
1 | null null null

and occurs exception: The discriminator column ... is missing for ....



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

JTI MUST be left-joined, since not every subclass of the root of the inheritance causes inserts on all of the inheritance tables.

What is the DQL query that is causing the problem?

Comment by Bojidar Hristov [ 22/Feb/14 ]

Hello Marco, I don't query from parent table, but from child. No sense to be LEFT JOINED.

DQL is something like that:

SELECT class1, class2 FROM Class1 class1 JOIN class1.class2 class2;

(Class2 extends Class3)
Class3 have is_active column.

And following filter:

public function addFilterConstraint(ClassMetadata $targetEntity, $targetTableAlias) {
if (!$targetEntity->reflClass->implementsInterface('ActivateableInterface'))

{ return ""; }

return $targetTableAlias . '.is_active = ' . $this->getParameter('isActive');
}

Filter condition is added in LEFT JOINED parent_table. Full example SQL:
SELECT ....
FROM class1 c1
INNER JOIN class2 c2 ON c1.c2_id = c2.id
LEFT JOIN table3 c3 ON c2.id = c3.id AND (c3.is_active = '1')

Comment by Marco Pivetta [ 26/Feb/14 ]

There are two possible solutions here:

  • verify if the selected entity is a leaf of a JTI, and use INNER JOIN on that if possible (probably not optimal, since the selection may be part of a LEFT JOIN itself)
  • add filtering on the discriminator column

Bojidar Hristov can you provide a failing test case to make it easier to work on this?

Comment by Bojidar Hristov [ 26/Feb/14 ]

Yes. Here is it sample failing test.

http://pastebin.com/xi8uUNX5 - Parent Class
http://pastebin.com/XRZLbyGX - Child Class
http://pastebin.com/HuPFb98u - Assoc Class
http://pastebin.com/hGqRk74e - TestCase

Here it should found 0 records because ot JOIN and is_active = true filter.

Comment by Benjamin Eberlei [ 23/Mar/14 ]

Since filters are only available on the root, i guess inner join is really necessary here.





[DDC-3000] [GH-963] SQLFilter -- allows to check if a parameter was set Created: 26/Feb/14  Updated: 23/Mar/14  Resolved: 23/Mar/14

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

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


 Description   

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

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

Message:

Small change to SQLFilter, which allows to check if a parameter was set on filter



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

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





[DDC-2999] [GH-962] Stop executeDeletions when there is nothing to to delete anymore Created: 25/Feb/14  Updated: 23/Mar/14  Resolved: 23/Mar/14

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

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


 Description   

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

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

Message:

A small improvement in `UOW::commit`. Only continue executing the for-loop when there's something to delete. This may save quite some calls to `UOW::executeDeletions`.



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

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





[DDC-3011] [GH-970] [DDC-357] Effective toOne joins Created: 05/Mar/14  Updated: 23/Mar/14  Resolved: 23/Mar/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 1
Labels: None

Issue Links:
Reference
relates to DDC-357 Lazy-loading in OneToOne-bidirectiona... Resolved

 Description   

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

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

Message:

  1. What is this?

I've kind of rewriten querying of toOne relations. It is more data and query-count effective.

  1. How?

Let's demonstrate it on `CmsUser` and `CmsAddress` from tests models. Let's solve behaviour for toOne relations that are not mentioned in the query.

SELECT u FROM CmsUser u
    1. lazy + mapped by side

Already implemented, result is that CmsAddress would be proxy.

    1. lazy + inverse side

`CmsUser` has `CmsAddress` relation that is mapped and owned by `CmsAddress` entity.

What has to happen? The identifier of `CmsAddress` cannot be loaded from users table nad has to be added automatic join for the table. Because it's lazy it will be hydrated as proxy, becase that is exactly what I've asked for.

If it would have been eagerly loaded, It would create 1+N queries problem that I'm trying to avoid with this. I have the relation as lazy, if I knew I would have needed it and wanned to optimized, I'd join it, but I didn't.

Result is therefore `CmsUser` entity + `CmsAddress` proxy

    1. eager - both inverse and mapped by sides

The appropriate query component is generated with autojoin and auto selecting of the entity.

If it is self-referencing, the auto join is not generated becase it would cause infinite recursion.

  1. Why?

I've given this a lot of thought and tested it on our not-so-small application. We have unfortunately lot of entitiy relations that are mapped on the inverse side than we need to select, which is effectively killing performace DDC-357(http://www.doctrine-project.org/jira/browse/DDC-357)

I would have to go and list all the entities as partials to save performace creating such monsters as this

$builder = $repository->createQueryBuilder("o")
	->leftJoin("o.voucher", "vu")->addSelect("partial vu.{id}")
	->leftJoin("o.address", "a")->addSelect("a")
	->leftJoin("o.restaurant", "r")->addSelect("partial r.{id, name}")
	->leftJoin("o.payment", "p")->addSelect("partial p.{id}")
	->leftJoin("o.rating", "rat")->addSelect("partial rat.{id}")
	->leftJoin("r.settings", "rs")->addSelect("partial rs.{id}")
	->leftJoin("r.address", "ra")->addSelect("ra")
	->leftJoin("r.position", "rp")->addSelect("partial rp.{id}");
# plus about five more just to make save performace

We all know that hydrating a large result set is a bottleneck and if I say the relation is lazy and I'm not joining it I *really don't want it to be joined with all it's data*!

Now imagine I just want to select few orders and render some data on the page.. I have tens of queries like this just because I have to. This is wrong that the ORM is tripping my feet like this.

  1. What now?

I know I have to solve theese:

  • [ ] more refactoring?
  • [ ] more tests
  • [ ] what to do with issue tests that now have changed behaviour?

Any suggestions?



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

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





[DDC-531] Collections broken in self-referenced Entities Created: 20/Apr/10  Updated: 23/Mar/14  Resolved: 23/May/10

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

Type: Bug Priority: Critical
Reporter: Nico Kaiser Assignee: Roman S. Borschel
Resolution: Fixed Votes: 0
Labels: None

Attachments: File DDC531Test.php    
Sub-Tasks:
Key
Summary
Type
Status
Assignee
DDC-597 Add check for public properties in Va... Sub-task Resolved Benjamin Eberlei  

 Description   

When dealing with parent / children entities, the UnitOfWork does not always hydrate all data correctly.

This example generates Group1 and its child Group2. Then Clears the Entity Manager, loads Group2 (so it is in the EM), loads Group1 and then the children of Group1 (Group2 is the child of Group1).
However the children of Group1 cannot be loaded, because $group4->children is not there:

Warning: Invalid argument supplied for foreach() in /Users/nico/Projects/test/test.php on line 20

When calling Debug::dump($group4), I get this:

object(stdClass)#56 (2) {
  ["__CLASS__"]=>
  string(26) "Proxies\EntitiesGroupProxy"
  ["id"]=>
  string(1) "1"
}

test.php
http://pastebin.com/7Q3wwtn6

Group entity:
http://pastebin.com/hBj2Emrf



 Comments   
Comment by Nico Kaiser [ 20/Apr/10 ]

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

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

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

Comment by Nico Kaiser [ 23/Apr/10 ]

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

Comment by Christian Heinrich [ 07/May/10 ]

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

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

Comment by Christian Heinrich [ 12/May/10 ]

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

$proxy->publicProperty

instead of

$proxy->getPublicProperty()

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

Therefore, I mark this ticket as invalid.

Comment by Nico Kaiser [ 12/May/10 ]

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

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

Comment by Christian Heinrich [ 12/May/10 ]

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

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

Comment by Nico Kaiser [ 17/May/10 ]

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

Comment by Nico Kaiser [ 17/May/10 ]

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

Comment by Christian Heinrich [ 17/May/10 ]

Hi Nico,

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

regards
christian

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

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

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

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

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

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

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

Comment by Doctrine Bot [ 23/Mar/14 ]

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





[DDC-1714] Prevent inverse side lazy loading owning side of the oneToOne relationsip if owning side's id is an assosiationKey of inversed side Created: 18/Mar/12  Updated: 23/Mar/14

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

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


 Description   

This issue was originally discussed in http://www.doctrine-project.org/jira/browse/DDC-357

Say there is User and UserData with oneToOne bidirectional relationship. When we fetch User objects, UserData is lazy loaded right away.

If we were to set UserData 's id as asssosiationKey of User, then user_id becomes the id of UserData and User object can already know that UserData owning side's id will equal it's own User->id.

Can this be implemented?



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

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





[DDC-357] Lazy-loading in OneToOne-bidirectional associations not working for inverse side Created: 21/Feb/10  Updated: 23/Mar/14  Resolved: 21/Feb/10

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.0-ALPHA4
Fix Version/s: None
Security Level: All

Type: Bug Priority: Minor
Reporter: Marcel Walter Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 0
Labels: None
Environment:

XAMPP 1.7.3


Attachments: File getRelation.php    
Issue Links:
Reference
is referenced by DDC-3011 [GH-970] [DDC-357] Effective toOne joins Resolved

 Description   

I am referring to the following situation:
http://www.doctrine-project.org/documentation/manual/2_0/en/association-mapping#one-to-one,-bidirectional

In this example: if I fetch an object of type "Customer" from my database, a second query is executed immediately that fetches the corresponding "Cart" even if I do not access the $cart property of "Customer". Annotating fetch="LAZY" to the $cart property does not make any difference. This is even worse in case of self-referencing objects, e.g. those having at most one parent object and at most one child object. Here, all associations are created by single database queries at once (e.g. fetching the child object, then the child of the child object and so forth).

By contrast, OneToMany associations are lazy-loaded from the inverse side (as expected).

Perhaps I should add, that I am using annotation mappings for my entities (no YAML, no XML).



 Comments   
Comment by Roman S. Borschel [ 21/Feb/10 ]

This is expected behavior. Inverse sides of one-to-one associations can not be lazy, technically. There is no foreign key on the inverse side, hence it is impossible to decide whether to proxy it or not. We must query for the associated object or join it. Note that this only affects inverse sides of single-valued associations, that is, really only the inverse side of bidirectional one-to-one associations.

In the future, you can use fetch="EAGER" to automatically load the associated objects in a join whenever the inverse side object is loaded. That is a planned enhancement.
So when fetch="EAGER" is used on a single-valued association, it is automatically fetch-joined, even when you just do ->find('Object', 1).

Right now, you can use an eager fetch join in DQL to avoid the extra query. Fetch-joins on single-valued associated are usually very cheap, compared to collections.

Note that you need a join anyway, because the foreign key is on the other side, thus it doesnt make much sense to join just for the sake of getting the foreign key. If we join we can as well grab the associated object completely.

The "fetch" mode is a "hint", that means, Doctrine tries to do that when possible. Its not always possible.

If you have a suggestion, feel free to speak up.

Comment by Roman S. Borschel [ 21/Feb/10 ]

If you have an example of a self-referential association that causes extreme ripple-loading of the whole hierarchy, can you please file a new jira issue for that?

Thanks!

Comment by Roman S. Borschel [ 21/Feb/10 ]

Here some other ways to get around the extra queries:

1) $query->setHint(Query::HINT_FORCE_PARTIAL_LOAD, true);

2) $query->getArrayResult() / ->getScalarResult()

Just for the sake of completeness.

Comment by Konstantin [ 13/Mar/12 ]

Why we cannot create proxy without FK?

Comment by Christian Stoller [ 10/Dec/12 ]

Hi. I have a problem with this solution.

I have an entity "Document" with an one-to-one association to an entity called "File". In the database table of the File entity I store the content of a file. So if I load for example 20 Documents I do not want the associated Files to be loaded, because this leads to memory problems.

I do not understand the explanation

There is no foreign key on the inverse side, hence it is impossible to decide whether to proxy it or not.


In a one-to-many association there is no foreign key on the inverse side, too. Why not always load a proxy like in a one-to-many association?

Plus: There is no documentation about this, neither on http://docs.doctrine-project.org/en/latest/reference/association-mapping.html nor http://docs.doctrine-project.org/en/latest/reference/unitofwork-associations.html

Comment by Roman S. Borschel [ 10/Dec/12 ]

It is pretty simple, in a one-to-many association where the one-side is the inverse side, it holds a collection. The collection may be empty or not but there can always be a collection so it easy and correct to always put a proxy collection there.

If you have a single-valued side that is the inverse side, how can you decide whether to put a proxy object there or not? Without seeing the foreign key you have no way to distinguish between: There is no associated object (and thus putting a proxy object in place would by simply wrong) or there is one and of which type it is, if inheritance is involved (since putting a proxy of the wrong type in is also wrong).

This is as far as I recall, maybe Benjamin knows more on the current state.

Comment by Christian Stoller [ 10/Dec/12 ]

Okay, I see the problem. But it would be nice if this behaviour could be documented.

Isn't it possible to always put a special proxy object there and if it get's accessed via lazy loading and Doctrine detect's that there is no associated entity, then the proxy will be replaced by a NULL value?

Comment by Hernan Rajchert [ 26/Feb/13 ]

Hi, I've been faced with this issue some times. I tent to solve this by doing two unidirectional one-to-one. Then I deal with the non existing relationship using a method called getRelation that I defined in a BaseModel.
I have created this method because Doctrine filled up with a Proxy when I fetch the entity without its relationship (then accesing the object would throw an Exception), and filled up with null when the object was eagerly fetched (left join) but no relationship was found.
I think we could add this getRelation in the entitymanager or a trait after php 5.4.

Comment by Martin Štekl [ 10/Nov/13 ]

Hi,
I think that idea of special proxy object is not so bad. However if you do not want to create special proxy object and build some logic around it then why do you not want to satisfy at least one of two (currently unsupported) cases?
I mean the case in which the object type is used in inheritance. This case is easier to solve in my opinion (similar to @OneToMany) and usually wanted. It is better to support at least one possibility then none.

Comment by Filip Procházka [ 05/Mar/14 ]

I'm proposing a solution to this "Won't Fix" that I disagree with https://github.com/doctrine/doctrine2/pull/970

Comment by Doctrine Bot [ 23/Mar/14 ]

A related Github Pull-Request [GH-970] was closed:
https://github.com/doctrine/doctrine2/pull/970





[DDC-3015] [GH-974] [SLC] Resolve association cache entry Created: 07/Mar/14  Updated: 23/Mar/14  Resolved: 23/Mar/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of FabioBatSilva:

Url: https://github.com/doctrine/doctrine2/pull/974

Message:



 Comments   
Comment by Doctrine Bot [ 07/Mar/14 ]

A related Github Pull-Request [GH-974] was closed:
https://github.com/doctrine/doctrine2/pull/974





[DDC-3012] [GH-971] [SLC] Fix query association proxy Created: 05/Mar/14  Updated: 23/Mar/14  Resolved: 23/Mar/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of FabioBatSilva:

Url: https://github.com/doctrine/doctrine2/pull/971

Message:



 Comments   
Comment by Doctrine Bot [ 06/Mar/14 ]

A related Github Pull-Request [GH-971] was closed:
https://github.com/doctrine/doctrine2/pull/971





[DDC-3018] DQL “NEW” Operator and Literal type "String" Created: 09/Mar/14  Updated: 23/Mar/14  Resolved: 23/Mar/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: DQL
Affects Version/s: 2.4, Git Master, 2.5
Fix Version/s: 2.5, 2.4.3
Security Level: All

Type: Bug Priority: Major
Reporter: harleaux Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: dql, orm


 Description   

Hello all,

When i use the DQL operator "new" to build data transfert object with string literal expression as field in object constructor, the call to Query::getResult thrown an exception.

Condition :
The string literal expression must be the first parameter of the constructor.

Following DQL :

$query = $em->createQuery('SELECT NEW CustomerDTO('some scalar string', c.name, c.email) FROM Customer c');

$users = $query->getResult();

Thrown exception :

ContextErrorException: Notice: Undefined variable: fieldType in doctrine/orm/lib/Doctrine/ORM/Query/SqlWalker.php line 1527

That happens because in SqlWalker::walkNewObject on the AST\Literal switch case. There is no case for AST\Literal::STRING, so $fieldType isn't defined.

I have also noted if the scalar string isn't the first parameter, $fieldType take the type of previous foreach element.



 Comments   
Comment by Benjamin Eberlei [ 23/Mar/14 ]

Fixed and merged into 2.4 release branch





[DDC-3022] JOIN without association generates invalid SQL Created: 11/Mar/14  Updated: 23/Mar/14  Resolved: 23/Mar/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: DQL
Affects Version/s: Git Master, 2.4.2
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Matthieu Napoli Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: sql-walker


 Description   

I saw in the documentation than since Doctrine 2.4 we could join without associations, using fields.

However I tried it and it generates invalid SQL (I use master). Here is an example:

SELECT a
FROM Namespace\Article a
JOIN Namespace\Authorization authorization WITH a.id = authorization.entityId

Generates the following SQL:

SELECT a0_.id AS id0 FROM Article a0_ INNER JOIN Authorization a1_ AND (a0_.id = a1_.entityId)

As you can see, instead of "INNER JOIN ... ON ..." we have "INNER JOIN ... AND ..." which is invalid.

I can't say if it's a regression of 2.5, or already in 2.4. I can't test my project with 2.4 because I used embedded objects.



 Comments   
Comment by Marco Pivetta [ 11/Mar/14 ]

I wrote a test at https://github.com/doctrine/doctrine2/compare/hotfix;DDC-3022-wrong-arbitrary-join-sql and it doesn't look like the bug is there.

Check your mappings and verify that everything is correct, or alter the given test case to make it fail.

Comment by Matthieu Napoli [ 11/Mar/14 ]

Thank you for trying and sorry for wasting your time _ I had forgotten an empty discriminator map on the "Authorization" class. For my defense the error was kind of weird

It's all good, no bug here.





[DDC-3024] Proxy Notice if none of joined tables are primary Created: 11/Mar/14  Updated: 23/Mar/14  Resolved: 23/Mar/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4.2
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Nima Sadjadi Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: orm, proxy
Environment:

nix* server with php 5.3.x



 Description   

In case of ManyToOne/OneToMany if NONE of joined coloumns are primary it throws a proxy notice:
NOTICE: Undefined index: id in /vendor/doctrine/common/lib/Doctrine/Common/Proxy/AbstractProxyFactory.php on line 121
Can be replicated this by running:
$somethings = $em->getRepository('Entities\Something')->findBy(array('productId' => "4"));

Something entity is ManyToOne to another OneToMany entity, and this productId is primary on NONE of these two entities/tables.



 Comments   
Comment by Marco Pivetta [ 11/Mar/14 ]

As discussed on the mailing list, this issue requires a failing test case to be confirmed.

Comment by Nima Sadjadi [ 12/Mar/14 ]

I am trying to do so Marco, but I am stuck for $metadata thing I said in that thread, as soon as you advice how to fix that, I will be able to run a failing test.

Comment by Benjamin Eberlei [ 23/Mar/14 ]

not using the primary for the joined columns is not supported and the SchemaValidator already gives an error about that. Runtime checks are not possible here.





[DDC-3030] [GH-979] Bypass metadata cache in console commands Created: 15/Mar/14  Updated: 23/Mar/14  Resolved: 23/Mar/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: