[DDC-274] Class and namespace naming inconsistency Created: 24/Jan/10  Updated: 31/Oct/10

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

Type: Improvement Priority: Critical
Reporter: Glen Ainscow Assignee: Roman S. Borschel
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.





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

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

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

Attachments: File DDC810Test.php    

 Description   

More information coming soon. Attaching a test case



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

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

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

@Jon: Any more information coming?

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

Comment by Benjamin Eberlei [ 29/Sep/10 ]

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

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

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

Comment by Benjamin Eberlei [ 03/Apr/11 ]

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





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

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

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





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

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

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


 Description   

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



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

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

Comment by Lars Strojny [ 07/Sep/10 ]

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





[DDC-1270] Incorrect QueryBuilder example Created: 11/Jul/11  Updated: 11/Jul/11

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

Type: Documentation Priority: Major
Reporter: Alex Bogomazov Assignee: Benjamin Eberlei
Resolution: Unresolved 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





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

Status: Open
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: Unresolved 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.





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

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

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





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

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

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


 Description   

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






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

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

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


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

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

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


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

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





[DDC-1235] Provide fluent interfaces in stub methods Created: 28/Jun/11  Updated: 29/Oct/12

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

Type: Improvement Priority: Major
Reporter: Andreas Hörnicke Assignee: Benjamin Eberlei
Resolution: Unresolved 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





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

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

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


 Description   

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

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

Just look at django, one command to update db:

./manage.py syncdb

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






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

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

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


 Description   

Read the IRC log:

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





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

Status: Open
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: Benjamin Eberlei
Resolution: Unresolved 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.






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

Status: Open
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: Benjamin Eberlei
Resolution: Unresolved 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.






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

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

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


 Description   

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

Mistakes:

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

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






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

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

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


 Description   

We should optimize code-generation somehow.



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

Descheduled to 2.x





[DDC-946] Evaluate optional use of igbinary for serialization Created: 22/Dec/10  Updated: 22/Dec/10

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

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


 Description   

Igbinary is supposed to be faster and better than serialize/unserialize(). We should check if its relevant for us (metadata and query caching for example):

https://github.com/phadej/igbinary



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

http://ilia.ws/archives/211-Igbinary,-The-great-serializer.html#extended





[DDC-1484] GH-162: ProxyFactory creates proxy's parent structure if it doesn't exist Created: 08/Nov/11  Updated: 26/Jun/12

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

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


 Description   

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

Wheeee, nested proxies can be generated without hassle!



 Comments   
Comment by Benjamin Eberlei [ 13/Nov/11 ]

Marked as improvement

Comment by Benjamin Eberlei [ 16/Jun/12 ]

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

Comment by Benjamin Eberlei [ 26/Jun/12 ]

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





[DDC-1459] Move DDC-331, DDC-448, DDC-493, DDC-513, DDC-698 Tests into SQLGeneration Testsuite Created: 29/Oct/11  Updated: 01/Aug/12

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

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





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

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

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


 Description   

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

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



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

Updating fix version





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

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

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


 Description   

Add test for DDC-1437






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

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

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


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

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

Comment by Guilherme Blanco [ 20/Dec/11 ]

Updating fix version





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

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

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


 Description   

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



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

Idea:

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

Comment by Guilherme Blanco [ 09/Dec/11 ]

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

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

Comment by Guilherme Blanco [ 20/Dec/11 ]

Updating fix version





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

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

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


 Description   

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






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

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

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


 Description   

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

{username}

:

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

Message:

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

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






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

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

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


 Description   

alOneh created a pull request on Github:

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






[DDC-2128] [GH-507] Now MetaDataFilter takess also regexp. For example whern you want to Created: 06/Nov/12  Updated: 06/Jan/13

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

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


 Description   

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

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

Message:

extract metadata if you would filter like this: --filter="Article"
would extract also for "ArticleItems" (article_items table). Now you
can use --filter="Article$" if you want only that table (articl)






[DDC-2102] Make optional SubselectFromClause Created: 25/Oct/12  Updated: 25/Oct/12

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

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


 Description   

Subselect ::= SimpleSelectClause [SubselectFromClause] [WhereClause] [GroupByClause] [HavingClause] [OrderByClause]






[DDC-2087] Select colum Hydration Created: 18/Oct/12  Updated: 18/Oct/12

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

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


 Description   

Simple way to select colum
for example I want select id's of entity's to save in cache or in other select query
Or i vant select one distinct field.

SELECT u.id FROM User as u

getResult give

array(
0=>array('id' => 1),
1=>array('id' => 2),
)

but how can take this

array(
0=> 1,
0=> 2,
)



 Comments   
Comment by Ivan Borzenkov [ 18/Oct/12 ]

for example

http://stackoverflow.com/questions/11327798/change-the-getresult-array-key-for-the-primary-key-value

this code would be good add in library
(and array key maybe too )





[DDC-2048] [GH-457] Fixes case when an entity has a relationship with a class with joined inheritance Created: 29/Sep/12  Updated: 29/Sep/12

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

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


 Description   

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

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

Message:






[DDC-2007] [GH-434] allowed to pass filter objects to the configurator Created: 31/Aug/12  Updated: 05/Sep/12

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

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


 Description   

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

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

Message:

If DDC-2004 gets approved.






[DDC-1999] Lazy loading doesn't get the field type when generating sql Created: 29/Aug/12  Updated: 29/Aug/12

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

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


 Description   

When calling with lazy loading the Sql generated doesn't convert the parameters according to their types. After debugging the problem I found that the problem is in the getType($field, $value) function in the BasicEntityPersister as it is it will never be able to return the filed type when called for lazy loading for oneToMany or ManyToMany. I put a quick fix for my self

 private function getType($field, $value)
    {

        switch (true) {
           //here we have original code
            default:

            	$type = null;
               // my fix starts here
            	$fieldParts = explode('.', $field);
            	if (count($fieldParts > 1)) {
	            	foreach ($this->_class->associationMappings as $mapping) {
						if (isset($mapping['joinColumnFieldNames'][$fieldParts[1]])) {
							$targetClass  = $this->_em->getClassMetadata($mapping['targetEntity']);

							if (isset($targetClass->fieldNames[$fieldParts[1]])) {
								$type = $targetClass->fieldMappings[$targetClass->fieldNames[$fieldParts[1]]]['type'];
							}

							break;
						}
	            	}
            	}
//my fix end here
        }

       //here we have original code

        return $type;
    }


i have only added that check in the default case of the switch. I am not sure if that is the most elegant way. I hope that helps and that it will be fixed soon. Thanks for the great work .



 Comments   
Comment by Benjamin Eberlei [ 29/Aug/12 ]

Fabio B. Silva Guilherme Blanco do we have a current best practice/policy regarding casting of join column types? There are some issues regarding it, this is another one.

Comment by Guilherme Blanco [ 29/Aug/12 ]

We avoid the manual breakdown of path expressions.
Also, in BasicEntityPersister it is done behind the scenes and can get into weird scenarios. Personally speaking, I don't see how we can easily fix this issue.





[DDC-2002] [GH-432] Add DBAL\TypeAwareObject type inference. Created: 29/Aug/12  Updated: 05/Sep/12

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

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


 Description   

This issue is created automatically through a Github pull request on behalf of Romain-Geissler:

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

Message:

DBAL allows you to define custom field types for your entities, and those are seamlessly converted from PHP to SQL value. However, you can't those custom types as parameters without type hinting it :

```php
$qb->select('e')
->from('Entity', 'e')
->where('e.customField = :customFieldValue')
->setParameter('customFieldValue',$customFieldValue,$customFieldDBALType);
//this third argument is for now compulsory
:
```

In my case, ``$customFieldValue`` is an object that won't work well if converted with the default string type. I added a new DBAL interface (see doctrine/dbal#193 ) and tweaked the parameter type inference so that custom values can advertise their DBAL type.

There is currently no way to dynamically override the parameter type inference logic, this is one design that allows it in some cases.



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

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





[DDC-1996] [GH-429] Ensure a parameter mapping entry exists for InstanceOf DQL expressions Created: 22/Aug/12  Updated: 22/Aug/12

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

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


 Description   

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

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

Message:

Hi,

This is a possible fix for http://www.doctrine-project.org/jira/browse/DDC-1995, in that it resolves the issue for me but I'm afraid I haven't had time to test it extensively with more complex queries than the use case I gave in that ticket.

Cheers,
Craig






[DDC-1971] [GH-419] Add ODM embedded-like functionality Created: 07/Aug/12  Updated: 14/Aug/12

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

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


 Description   

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

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

Message:

This PR adds ODM embedded-like functionality to the ORM.

Including the new @MappedAssociation annotation on a field having a one-to-one association adds a discriminator column to the table for storing the class name of a "mapped" entity.

This allows a class or mapped superclass with a one-to-one identifying association to be extended by additional entities without requiring any code changes (as is required with the discriminator map when using inheritance).

I apologize if this is the incorrect way to submit a feature request. Currently just the annotation driver has been updated, I wanted to get feedback before continuing with the remaining drivers. Models and tests are included.






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

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

Type: New Feature Priority: Major
Reporter: 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-1621] Add support for FROM Class1 a1 JOIN Class2 a2 WITH cond queries Created: 25/Jan/12  Updated: 30/Dec/12

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

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


 Description   

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



 Comments   
Comment by Alex [ 30/Nov/12 ]

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





[DDC-1590] Fix Inheritance in Code-Generation Created: 09/Jan/12  Updated: 10/Dec/12

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

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

Issue Links:
Dependency
is required for DDC-1579 MappedSuperClass and inheritance prob... Resolved

 Comments   
Comment by Lukas Domnick [ 10/Dec/12 ]

(I have no Link Privileges, but this one #DDC-1379 is a duplicate with more extent info.)





[DDC-1570] GH-243: Add ProxyFactoryInterface to allow custom proxy factories Created: 28/Dec/11  Updated: 28/Dec/11

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

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


 Description   

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

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

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






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

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

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


 Description   

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

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

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



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

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

You can just use this workaround yourself so long.





[DDC-1563] Result cache for repository queries Created: 25/Dec/11  Updated: 26/Aug/12

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

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


 Description   

Many related "standing data" tables are very static and seldom change. There should be a metadata config to enable result cache for ALL repository operations.

@entity(resultCache=@cache(ttl=3600))



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

This should directly support cache invalidation through a tag. Each repository gets a key with the current version. The version is one part ofthe actual cache datas key.

A new cache key version is generated:

1. When none is found during find operation
2. When any write operation is done.

For transaction consisteny the rollback operation in UoW needs to reset cache keys and only after a succesful commit operation the new cache key version should be set.

We may need begin, commit, rollback events in UoW for this.





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

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

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


 Description   

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



 Comments   
Comment by Alexander [ 22/Dec/11 ]

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





[DDC-1549] GH-232: Recursive check for entity identifiers and hashes Created: 20/Dec/11  Updated: 22/Mar/12

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

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


 Description   

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

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

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

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



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

Mark as improvement

Comment by Benjamin Eberlei [ 22/Mar/12 ]

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





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

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

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


 Description   

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

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



 Comments   
Comment by Alexander [ 22/Dec/11 ]

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

Comment by Marco Pivetta [ 22/Dec/11 ]

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

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

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





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

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

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


 Description   

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






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

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

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


 Description   

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

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

{"comment" = "test"}

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






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

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

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


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

Is broken. Error:

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

On a query like:

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


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

Updating fix version

Comment by Christian Raue [ 09/Jan/12 ]

It occurs even if the value is not HIDDEN.

Comment by Benjamin Eberlei [ 10/Jan/12 ]

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

Comment by Christian Raue [ 10/Jan/12 ]

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

Comment by Benjamin Eberlei [ 10/Jan/12 ]

Can you paste your DQL and SQL?

Comment by Christian Raue [ 10/Jan/12 ]

Code:

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

DQL:

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

SQL:

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

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

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

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

Comment by Christian Raue [ 21/Jan/12 ]

So we might just close this issue then?

Comment by Benjamin Eberlei [ 25/Jan/12 ]

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





[DDC-1938] [GH-406] [WIP] - DCOM-96 - Moving proxy generation and autoloading to common Created: 21/Jul/12  Updated: 26/Jan/13

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

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


 Description   

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

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

Message:

This PR is related to doctrine/common#168.

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



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

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

Comment by Benjamin Eberlei [ 26/Jan/13 ]

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





[DDC-1923] Type conversion error with oracle Created: 12/Jul/12  Updated: 12/Jul/12

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

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


 Description   

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






[DDC-1913] Updates for Fedora packaging Created: 07/Jul/12  Updated: 07/Jul/12

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

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

Fedora



 Description   

I am packaging the DoctrineDBAL PEAR package for Fedora and would like to have the following updates:

  • package.xml role for LICENSE changed from "data" to "doc"
  • package.xml role for UPGRADE* changed from "data" to "doc"
  • package.xml role for Doctrine/ORM/README.markdown changed from "data" to "doc"
  • add some content to Doctrine/ORM/README.markdown (when building RPM this file throws a warning because it is empty)
  • doctrine.bat should only be installed on Windows OS





[DDC-1899] [GH-385] set metadata for interface to be able to fetch entites by interface name Created: 29/Jun/12  Updated: 07/Jul/12

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

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


 Description   

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

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

Message:

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

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

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

or

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

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






[DDC-1860] Make usage of Composer for CLI optional Created: 09/Jun/12  Updated: 09/Jun/12

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

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


 Description   

There's two problems with current CLI implementation:

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



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

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





[DDC-1859] Implement console command to convert DQL into object running NativeQuery Created: 08/Jun/12  Updated: 08/Jun/12

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

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


 Description   

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






[DDC-1840] Create ParameterCollection indexed and implement it on AbstractQuery and QueryBuilder Created: 26/May/12  Updated: 20/Sep/12

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

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


 Description   

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



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

Not a bug





[DDC-1829] [GH-352] Add the posibility to add a custom Comparator for Schema tool Created: 21/May/12  Updated: 22/May/12

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

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


 Description   

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

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

Message:

See catacgc/dbal#153






[DDC-1820] [GH-348] [DDC-1819][WIP] Arbitrary object hydrator Created: 14/May/12  Updated: 27/May/12

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

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


 Description   

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

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

Message:

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

Other questions I have include:

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

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






[DDC-1813] Save column types in ClassMetadataInfo#columnTypes array instead of ClassMetadataInfo#fieldMappings['type'] Created: 06/May/12  Updated: 06/May/12

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

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


 Description   

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

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

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






[DDC-1814] Save quoted info in ClassmetadataInfo#quotedColumns instead of ClassmetadataInfo#fieldmappings['fieldname']['quoted'] Created: 06/May/12  Updated: 06/May/12

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

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


 Description   

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

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






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

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

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


 Description   

Give correct names to arguments

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

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

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






[DDC-1792] [GH-340] add public has() method to filter collection. Created: 19/Apr/12  Updated: 04/May/12

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

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


 Description   

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

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

Message:

Sorry if there is any reason why this is not implemented already.
This is useful when some feature, for example `soft-deleteable` filter may be optional.






[DDC-1787] Fix for JoinedSubclassPersister, multiple inserts with versioning throws an optimistic locking exception Created: 18/Apr/12  Updated: 18/Apr/12

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

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

Attachments: Text File JoinedSubclassPersister.php.patch    

 Description   

Attached is a small patch for a bug in the file JoinedSubclassPersister.php. When persisting multiple new entities that are subclasses of a baseclass (joined), and having the @Version attribute set, only for the last one a query is run to fetch the new value of the version field. The other one is tested with NULL, and throws an optimistic locking exception.






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

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

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


 Description   

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



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

There are four major issues with this:

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

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

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

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

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

Edit: Added #3

Comment by Craig Mason [ 18/Oct/12 ]

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

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

This is certainly not a patch - more guidance.

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

Comment by Craig Mason [ 25/Oct/12 ]

Updated, view all commits for this experimental branch here:

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

Comment by Craig Mason [ 29/Oct/12 ]

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

https://github.com/CraigMason/DoctrineSqlServerExtensions

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

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

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

Comment by Benjamin Eberlei [ 19/Jan/13 ]

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





[DDC-1760] [GH-324] simplified __call method Created: 03/Apr/12  Updated: 07/Apr/12

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

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


 Description   

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

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

Message:



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

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

Comment by Benjamin Eberlei [ 06/Apr/12 ]

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

Comment by Benjamin Eberlei [ 07/Apr/12 ]

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





[DDC-1750] [GH-319] [WIP] Added support to Multiple ID Generators Created: 01/Apr/12  Updated: 27/May/12

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

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


 Description   

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

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

Message:



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

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

Comment by Benjamin Eberlei [ 01/Apr/12 ]

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

Comment by Benjamin Eberlei [ 02/Apr/12 ]

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

Comment by Benjamin Eberlei [ 02/Apr/12 ]

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

Comment by Benjamin Eberlei [ 03/Apr/12 ]

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

Comment by Benjamin Eberlei [ 03/Apr/12 ]

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

Comment by Benjamin Eberlei [ 04/Apr/12 ]

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

Comment by Benjamin Eberlei [ 06/Apr/12 ]

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

Comment by Benjamin Eberlei [ 07/Apr/12 ]

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





[DDC-2305] [GH-584] QueryBuilder::addCriteria improvements Created: 19/Feb/13  Updated: 19/Feb/13

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

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


 Description   

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

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

Message:

1. Fix problem with different comparisons on the same field in QueryExpressonVisitor (now index value is added).
2. Add criteria field aliasing. Usually oject criteria has "filed = value" notation while DQL has "alias.field = value".
First level fields are added with alias, second+ level fields (object.field, parent.object.field) are truncated to the second level (object.field) without alias. Alias map can be implemented in future.



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

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





[DDC-2290] Infer custom Types from the field for query parameters Created: 08/Feb/13  Updated: 08/Feb/13

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

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


 Description   

When using a mapping Type that declares convertToDatabaseValue, the method is not always called in queries.

Example:

SELECT ... WHERE entity.field = ?1

(with entity.field being of custom type 'the_mapping_type')

Type::convertToDatabaseValue() is correctly called when using:

$query->setParameter('1', 'foo', 'the_mapping_type');

But it is not called when using:

$query->setParameter('1', 'foo');

which gives a query that returns invalid results.

Like other mapping types in this situation, there is no reason the type is not inferred automatically from the field.

I have written a failing test case in Doctrine\Tests\ORM\Functional\TypeValueSqlTest:

    public function testQueryParameterWithoutType()
    {
        $entity = new CustomTypeUpperCase();
        $entity->lowerCaseString = 'foo';

        $this->_em->persist($entity);
        $this->_em->flush();

        $id = $entity->id;

        $this->_em->clear();

        $query = $this->_em->createQuery('SELECT c.id from Doctrine\Tests\Models\CustomType\CustomTypeUpperCase c where c.lowerCaseString = ?1');
        $query->setParameter('1', 'foo');

        $result = $query->getResult();

        $this->assertCount(1, $result);
        $this->assertEquals($id, $result[0]['id']);
    }


 Comments   
Comment by Matthieu Napoli [ 08/Feb/13 ]

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

Comment by Matthieu Napoli [ 08/Feb/13 ]

The test is in this branch: https://github.com/myc-sense/doctrine2/tree/DDC-2290





[DDC-2275] [GH-568] Fixed plural variable names to singular when generating add or remove methods for entities Created: 04/Feb/13  Updated: 04/Feb/13

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

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


 Description   

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

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

Message:

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

Edited tests for EntityGenerator so that variable names are checked too






[DDC-2249] Default value sequence Created: 19/Jan/13  Updated: 19/Jan/13

Status: Open
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: Benjamin Eberlei
Resolution: Unresolved Votes: 0
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!






[DDC-2239] Allow dynamic modification of select queries (either filter the AST or query) Created: 11/Jan/13  Updated: 11/Jan/13

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

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


 Description   

I had built and used the following for doctrine 1: http://web.archive.org/web/20110705035547/http://www.doctrine-project.org/projects/orm/1.2/docs/cookbook/record-based-retrieval-security-template/en#record-based-retrieval-security-template

I'd like to build something similar for D2 based projects.

ocramius in IRC suggested a bug report/Improvement request. Figured that perhaps a custom event "dql_parse" or "ast_render" passing the AST or Query as a parameter.

I'm under a tight timeline and am willing to pay for aid/feature implementation.






[DDC-2219] computeChangeSets array_merging for associationMappings problem ? Created: 02/Jan/13  Updated: 07/Jan/13

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

Type: Documentation Priority: Major
Reporter: yohann.poli Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: unitofwork


 Description   

Is this normal that when i call "$changeset = $unitOfWork->getEntityChangeSet($myObject);", it only return changes of root Object, all changes in sub collection (OneToMany) are less (not merging in the changeset) ?

Is there an issue for that?



 Comments   
Comment by Marco Pivetta [ 02/Jan/13 ]

Changesets of collections are computed separately from those of entities.

Comment by yohann.poli [ 02/Jan/13 ]

Have to call the compute method for each collection of the entity ?

Comment by Benjamin Eberlei [ 06/Jan/13 ]

Yes you have to, but this kind of operation seems weird. What are you trying to achieve.

Comment by yohann.poli [ 07/Jan/13 ]

I manage a complex entity who have a collection entity (each entity in this collection have another collection entity) attributes and i need to now if the flush method has "really" execute an update.

For example if the level 3 entity is update, i have to know in the root entity all changes apply in child...





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

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

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

Attachments: File DDC2193Test.php    

 Description   

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

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

2、Error,cannot connect to the server

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

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

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


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

Hi

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

Could you provide more details please?

Cheers

Comment by dingdangjyz [ 13/Dec/12 ]

Doctrine\Common\Lexer.php

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

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

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

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

Hi

Could you try to add a failing test case please ?

Cheers

Comment by dingdangjyz [ 14/Dec/12 ]

xp php5.3.8 Apache

<?php

namespace Models\Entities;

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

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

@NamedNativeQueries query

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

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

Can't reproduce,

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

Cheers

Comment by Benjamin Eberlei [ 24/Dec/12 ]

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

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

Comment by dingdangjyz [ 31/Dec/12 ]

I'm sorry my English is too bad.

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





[DDC-2183] Second Level Cache improvements Created: 03/Dec/12  Updated: 03/Dec/12

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

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


 Description   

Hibernate has a second level cache feature that is much more advanced than Doctrines result cache.

With NoSQL in-memory databases such as Riak or MongoDB we could need a much more powerful cache to make Doctrine faaaaaasst. This ticket tracks the design and implementation of that feature.






[DDC-2170] Decorator base classes for query related objects Created: 26/Nov/12  Updated: 26/Nov/12

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

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


 Description   

Doctrine\ORM\Query should not be directly extendable but it would be nice to decorate query objects and add additional methods. Use cases are e.g. doctrine-fun (see https://github.com/lstrojny/doctrine-fun/blob/master/src/Doctrine/Fun/Query.php) or even cases where users want to add domain specific methods. As Doctrine\ORM\Query is final it is not so easy to decorate correctly. I would propose:

  • Add a new interfaces: Doctrine\ORM\QueryInterface that provides a contract for all methods Doctrine\ORM\Query provides
  • Add a decorator base class Doctrine\ORM\QueryDecorator as an extension point
  • Some for NativeQuery and QueryBuilder


 Comments   
Comment by Lars Strojny [ 26/Nov/12 ]

Related:





[DDC-2166] Improve Identifier hashing in IdentiyMap Created: 25/Nov/12  Updated: 25/Nov/12

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

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


 Description   

There are currently some drawbacks with identifier hashing:

  • They only work on one level for derived keys
  • The code is suspect to high performance requirements
  • Composite Keys might be suspect to weird bugs if they contain spaces.

There is a PR by goetas (https://github.com/doctrine/doctrine2/pull/232) that solves some issues, however adds a performance hit.

We should move the conditional logic of this code out and use a strategy pattern to improve both performance and robustness of this code.






[DDC-2154] Traits and Code Generation Created: 18/Nov/12  Updated: 18/Nov/12

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

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


 Description   

See https://github.com/doctrine/DoctrineBundle/issues/106#issuecomment-10479116






[DDC-1739] [GH-314] [WIP] Doctrine\Common metadata drivers reuse Created: 30/Mar/12  Updated: 07/Apr/12

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

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


 Description   

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

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

Message:

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

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

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

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

Tests are still failing.



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

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

Comment by Benjamin Eberlei [ 30/Mar/12 ]

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

Comment by Benjamin Eberlei [ 30/Mar/12 ]

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

Comment by Benjamin Eberlei [ 30/Mar/12 ]

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

Comment by Benjamin Eberlei [ 01/Apr/12 ]

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

Comment by Benjamin Eberlei [ 04/Apr/12 ]

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

Comment by Benjamin Eberlei [ 06/Apr/12 ]

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

Comment by Benjamin Eberlei [ 07/Apr/12 ]

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





[DDC-1723] Custom ID Generators Created: 22/Mar/12  Updated: 20/Sep/12

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

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


 Description   

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

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






[DDC-1681] loadRelated() - Method to efficiently load sets of related entities in "sub"-select strategies Created: 05/Mar/12  Updated: 05/Mar/12

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

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


 Description   

As per Request of Seldaek



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

Sample:

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

Would be the equivalent of:

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

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

Bonus points if you can loadRelated multiple relations at once.

Comment by Christophe Coevoet [ 05/Mar/12 ]

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

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

Comment by Jordi Boggiano [ 05/Mar/12 ]

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

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

Comment by Guilherme Blanco [ 05/Mar/12 ]

The one to be implemented would be:

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

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

Any other ideas, feel free to give me.





[DDC-213] Persist order of collections Created: 15/Dec/09  Updated: 16/Oct/12

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

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

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

 Description   

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



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

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

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

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

Comment by Benjamin Eberlei [ 22/May/10 ]

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

Changes are probably required in:

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

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

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

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

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

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

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

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

Comment by Benjamin Eberlei [ 30/Sep/10 ]

From a mailinglist entry, required check/changepoints:

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

Comment by Benjamin Eberlei [ 24/Dec/10 ]

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

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

Hi there,
I'm looking for this feature.

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

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

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

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

Waiting for advices, and solutions,

Thomas.

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

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

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

What do you think about it ?

Comment by Nicolas [ 29/Feb/12 ]

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

For exemple with user and group :

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

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

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

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

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

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

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

Thank a lot for your beautiful work.

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

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

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

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

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

Thomas.

Comment by Nicolas [ 29/Feb/12 ]

I don't think:

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

By example :

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

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

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

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

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

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

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

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

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

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

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

What do you think about it ?

Thomas;

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

Any news ?

Comment by Matthieu Napoli [ 16/Oct/12 ]

Hi, any news on this?

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

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

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





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

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

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


 Description   

The problem is this:

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

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

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

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

This causes an unacceptable amount of coupling.

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

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



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

Hi,

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

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

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

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

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

Comment by John Kleijn [ 14/May/10 ]

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

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

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

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

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

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

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

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

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

@RE: the UoW double flush:

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

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

So I see two possible ways to go here:

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

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

2) No effort, less code

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

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

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

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

Comment by John Kleijn [ 14/May/10 ]

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

$repo->start();

$repo->register($object);

$repo->commit();

Why?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Comment by John Kleijn [ 14/May/10 ]

> Scalar values are separate from objects.

Right. Bad example.

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

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

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

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





[DDC-585] Create a coding standards document Created: 13/May/10  Updated: 11/Feb/13

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

Type: Task 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?





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

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

Type: Task Priority: Major
Reporter: Roman S. Borschel Assignee: Roman S. Borschel
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.





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

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

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


 Description   

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



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

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

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

Comment by Benjamin Eberlei [ 02/Jan/11 ]

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

Comment by Benjamin Eberlei [ 05/Jun/11 ]

Changed to improvement





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

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

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

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

 Description   

Assuming:

Customer <onetoone> Cart

where Cart is the owning side.

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

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

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



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

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





[DDC-2321] DbDeploy Support Created: 27/Feb/13  Updated: 27/Feb/13

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

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


 Description   
  • DbDeploy Diff Generation
  • Schema Serialization
  • SchemaTool gets new event when diff is applied, then you can update a "stable" schema xml. On Generation new db deploy script, use current schema vs stable schema vom disc.





[DDC-2295] [GH-580] Second cache level POC Created: 14/Feb/13  Updated: 14/Mar/13

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

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


 Description   

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

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

Message:

Hi guys.

After a look into some implementations I end up with the following solution for the second level cache..

There is lot of work todo before merge it, but i'd like to get your thoughts before i go any further on this approach.
I hope my drafts are good enough to explain the idea :

      1. Cache strategies
  • READ_ONLY (DEFAULT) : ReadOnly cache can do reads, inserts and deletes, cannot perform updates or employ any locks.
  • NONSTRICT_READ_WRITE : Nonstrict Read Write Cache doesn’t employ any locks but can do reads, inserts , updates and deletes.
  • NONSTRICT_READ_WRITE : Read Write cache employs locks the entity before update/delete.
      1. classes / interfaces
  • *Region* :
    Defines a contract for accessing a entity/collection data cache. (Doesn’t employ any locks)
  • *ConcurrentRegion* :
    Defines contract for concurrently managed data region. (Locks the data before update/delete.)
  • *RegionAccess* :
    Defines a contract to access a cache region
  • *ConcurrentRegionAccess* :
    Defines contract for regions which hold concurrently managed data.
  • *CacheKey / EntityCacheKey / CollectionCacheKey/ QueryCacheKey*:
    Defines entity / collection key to be stored in the cache region.
  • *EntityEntryStructure / CollectionEntryStructure*
    Build cache entries and rebuild entities/colection from cache
  • *AccessProvider*
    Build RegionAccess based on entity / collection cache configuration

Collection Caching

The most common use case is to cache entities. But we can also cache relationships. 
A “collection cache” caches the primary keys of entities that are members of a collection (OneToMany/ManyToMany). 
and each element will be cached into its region.

Only identifiers will be cached for collection. When a collection is read from the second level cache it will create proxies based on the cached identifiers, if the application needs to access an element, Doctrine will go to the cache to load the element data.

      1. OPERATIONS
        1. INSERT :

*********************************************************************************************
UnitOfWork#commit
Connection#beginTransaction
Persister#executeInserts
Connection#commit
Persister#afterTransactionComplete
-> EntityRegionAccessStrategy#afterInsert
*********************************************************************************************
METHOD | READ-ONLY | NONSTRICT-READ-WRITE | READ-WRITE |
---------------------------------------------------------------------------------------------
afterInsert | add item to the cache | add item to the cache | add item to the cache |
---------------------------------------------------------------------------------------------

        1. UPDATE :

*********************************************************************************************
UnitOfWork#commit
Connection#beginTransaction
Persister#update
-> TransactionalRegionAccess#lockItem
-> execute
Connection#commit
Persister#afterTransactionComplete
-> RegionAccess#afterUpdate
-> TransactionalRegionAccess#unlockItem
*********************************************************************************************
METHOD | READ-ONLY | NONSTRICT-READ-WRITE | READ-WRITE |
---------------------------------------------------------------------------------------------
lockItem | | | lock item |
---------------------------------------------------------------------------------------------
afterUpdate | throws exception | update item cache | update item cache |
---------------------------------------------------------------------------------------------
unlockItem | | | unlock item |
---------------------------------------------------------------------------------------------

        1. DELETE :

*********************************************************************************************
UnitOfWork#commit
Connection#beginTransaction
Persister#delete
-> TransactionalRegionAccess#lockItem
-> execute
Connection#commit
Persister#afterTransactionComplete
-> RegionAccess#evict
*********************************************************************************************
METHOD | READ-ONLY | NONSTRICT-READ-WRITE | READ-WRITE |
---------------------------------------------------------------------------------------------
lockItem | | | lock item |
---------------------------------------------------------------------------------------------
evict | remove item cache | remove item cache | remove item cache |
---------------------------------------------------------------------------------------------

        1. USAGE :
```php
<?php

/**
 * @Entity
 * @Cache("NONSTRICT_READ_WRITE")
 */
class State
{
    /**
     * @Id
     * @GeneratedValue
     * @Column(type="integer")
     */
    protected $id;
    /**
     * @Column
     */
    protected $name;
    /**
     * @Cache()
     * @ManyToOne(targetEntity="Country")
     * @JoinColumn(name="country_id", referencedColumnName="id")
     */
    protected $country;
    /**
     * @Cache()
     * @OneToMany(targetEntity="City", mappedBy="state")
     */
    protected $cities;
}
```

```php
<?php

$em->persist(new State($name, $country));
$em->flush();                                // Put into cache

$em->clear();                                // Clear entity manager

$state   = $em->find('Entity\State', 1);     // Retreive item from cache
$country = $state->getCountry();             // Retreive item from cache
$cities  = $state->getCities();              // Load from database and put into cache

$state->setName("New Name");
$em->persist($state);
$em->flush();                                // Update item cache

$em->clear();                                // Clear entity manager

$em->find('Entity\State', 1)->getCities();   // Retreive from cache


$em->getCache()->containsEntity('Entity\State', $state->getId())  // Check if the cache exists
$em->getCache()->evictEntity('Entity\State', $state->getId());    // Remove an entity from cache
$em->getCache()->evictEntityRegion('Entity\State');               // Remove all entities from cache

$em->getCache()->containsCollection('Entity\State', 'cities', $state->getId());   // Check if the cache exists        
$em->getCache()->evictCollection('Entity\State', 'cities', $state->getId());      // Remove an entity collection from cache
$em->getCache()->evictCollectionRegion('Entity\State', 'cities');                 // Remove all collections from cache

```
        1. TODO :
  • handle many to many collection
  • handle inheritance
  • remove/add colection items on update
  • improve region tests
  • improve access strategy tests
  • implement xml / yml / php drivers
  • implement transaction region
  • implement transaction access strategy
  • .... ????





[DDC-2354] [GH-617] Wrong UnitOfWork::computeChangeSet() Created: 16/Mar/13  Updated: 16/Mar/13

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

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


 Description   

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

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

Message:

Sometimes some fields are Proxy when compute "changeSet". If it is Proxy, some listeners - example Gedmo sortable listener - belive the value has changed and this leads to chaos.

I check the $actualValue, if it is Proxy, the value didn't change.






[DDC-2351] Entity Listener vs. Event Listener Created: 15/Mar/13  Updated: 15/Mar/13

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

Type: Improvement Priority: Major
Reporter: Fabian Spillner Assignee: Fabio B. Silva
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Entity Listener and Event Listener don't get same events. An example is the onFlush event, which Entity Listener doesn't get. Why are both listeners receiving different events and not same events?

For consistency I'd like to see that both get same events - if I understand the purpose of Entity Listener correctly: it should be an alternative to Event Listener with same functionality but is bound to an entity.



 Comments   
Comment by Benjamin Eberlei [ 15/Mar/13 ]

onFlush and postFlush should be propagated to entity listeners as well





[DDC-2352] [GH-615] Update SqlWalker.php Created: 15/Mar/13  Updated: 15/Mar/13

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

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


 Description   

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

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

Message:

Always be sure that only a-z characters are used for table alias, otherwise use generic "t" for "table"






[DDC-2364] [GH-625] [DDC-2363] Duplicated record with orphanRemoval and proxy Created: 22/Mar/13  Updated: 22/Mar/13

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

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


 Description   

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

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

Message:

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






[DDC-2372] [GH-632] entity generator - ignore trait properties and methods Created: 26/Mar/13  Updated: 26/Mar/13

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

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


 Description   

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

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

Message:

Fixes:

DDC-1825
DDC-2154






[DDC-2210] PHP warning in ProxyFactory when renaming proxy file Created: 20/Dec/12  Updated: 28/Mar/13

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

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

Windows



 Description   

Getting a PHP Warning:

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

in ProxyFactory line 194.

I haven't more information in the warning.

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

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

This happens in dev environment, on a Windows machine.

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



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

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

We cannot fix this in Doctrine.

Comment by Matthieu Napoli [ 24/Dec/12 ]

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

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

Comment by Matthieu Napoli [ 27/Dec/12 ]

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

What can I do?

Thanks!

Comment by Matthieu Napoli [ 28/Feb/13 ]

Benjamin Eberlei ping: what can be done?

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

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

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

Comment by Marco Pivetta [ 28/Feb/13 ]

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

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

Comment by Matthieu Napoli [ 28/Feb/13 ]

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

Thanks for the feedback

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

Comment by Marco Pivetta [ 28/Feb/13 ]

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

Comment by Matthieu Napoli [ 28/Feb/13 ]

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

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

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

Comment by Marco Pivetta [ 28/Feb/13 ]

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

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

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

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

Comment by Matthieu Napoli [ 28/Feb/13 ]

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

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

Comment by Marco Pivetta [ 28/Feb/13 ]

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

Comment by Marco Pivetta [ 28/Feb/13 ]

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

Comment by Matthieu Napoli [ 28/Mar/13 ]

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





[DDC-2214] extra single quotation in sql when using EntityRepository::findBy Created: 26/Dec/12  Updated: 01/Apr/13

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

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

Attachments: File DDC2214Test.php    

 Description   

I'm using symfony 2.1 with mysql.

I have following code:

$related = 
$this->getDoctrine()->getRepository('MyWebBundle:LineRelated')
->findBy(array('line' => $lines), array('count' => 'DESC'), 20);

that generate the sql like this:

SELECT *
FROM line_related t0 
WHERE t0.line_id IN ('6059', 126352, '5677', '6058') 
ORDER BY t0.count DESC 
LIMIT 20

please notice that the sql has extra single quotation around the number 6059,5677 and 6058. which make the sql very slow.

I did a test, when using single quotation,the sql takes 300ms,when using without single quotation,the sql takes 1 ms.



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

Hi

Could you please attach your entities or a failing test case ?

Cheers

Comment by scourgen [ 27/Dec/12 ]

sure

LineRelated.php :

class LineRelated
{
    /**
     * @ORM\Id
     * @ORM\Column(type="integer")
     * @ORM\GeneratedValue(strategy="AUTO")
     */
     protected $id;

    /**
     * @ORM\ManyToOne(targetEntity="Line", inversedBy="line_related")
     * @ORM\JoinColumn(name="line_id", referencedColumnName="id",nullable=false)
     */
     protected $line;
     
    /**
     * @ORM\Column(name="line_id_related", type="integer")
     */
    protected $line_related;

    /**
     * @ORM\Column(type="smallint",nullable=false)
     */
     protected $count = 0;

###### get/set etc....... #######

Line.php

class Line
{
    /**
     * @ORM\Id
     * @ORM\Column(type="integer")
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;
########## blablabla #############

my action:

    public function right_line_relatedAction($line = null, $title='相关线路')
    {

        $lines = $l->getByUser($user, array());
//anyway,$lines is an array,It has several elements,each element is an instance of LineEntity.

        $related = $this->getDoctrine()->getRepository('MyWebBundle:LineRelated')->findBy(array('line' => $lines), array('count' => 'DESC'), 20);
//this findBy function generate the sql which is slow.

        return $related;
    }
Comment by Fabio B. Silva [ 27/Dec/12 ]

Hi,

How did you get this query string ?

Repository#findBy does not quote the values, It uses PDO:bindParam.
so the expected query string should be someting like :

WHERE t0.line_id IN (?, ? ,?) 

I tried to reproduce but in my tests the generated Query binds the parameters as "PDO::PARAM_INT".

I have added a test case.
Could you please can try to change it and make fails.

Cheers

Comment by scourgen [ 28/Dec/12 ]

reproduced :

SELECT t0.id AS id1, t0.line_id_related AS line_id_related2, t0.count AS count3, t0.line_id AS line_id4 FROM line_related t0 WHERE t0.line_id IN ('6059', 4851, '6068', 126352, '6060', '1000000') ORDER BY t0.count DESC LIMIT 20
Parameters: [['6059', 4851, '6068', 126352, '6060', '1000000']] 
[Hide runnable query]
Time: 234.53 ms [   Explain query ]

let me have a look on what's going on

Comment by scourgen [ 28/Dec/12 ]

interesting. I've dump(using ladybug_dump) the $lines,and I found out that when the element is a Proxies Object(Object(Proxies_GC_\My\WebBundle\Entity\Line)),then the id of that Object will be with quoted,when the elememt is an Real Entity,then It will be without quote.

for example,in my last comment, the parameters is [['6059', 4851, '6068', 126352, '6060', '1000000']]
the result of dumping $lines is :

array(6)
[0]: object(Proxies_CG_\Zuo\WebBundle\Entity\Line)
[1]: object(Zuo\WebBundle\Entity\Line)
[2]: object(Proxies_CG_\Zuo\WebBundle\Entity\Line)
[3]: object(Zuo\WebBundle\Entity\Line)
[4]: object(Proxies_CG_\Zuo\WebBundle\Entity\Line)
[5]: object(Proxies_CG_\Zuo\WebBundle\Entity\Line)

tell me if you need more information. thanks

Comment by Marco Pivetta [ 28/Dec/12 ]

This may be because

$_identifier

in proxies ( https://github.com/doctrine/doctrine2/blob/42e83a2716d19eada4f1cd49ece77d5f5229a239/lib/Doctrine/ORM/Proxy/ProxyFactory.php#L383 ) is not necessarily composed by integers. This could be fixed with DCOM-96. I'll add the tests to my development branch and will ping you back tomorrow

Comment by scourgen [ 28/Dec/12 ]

thanks

Comment by Marco Pivetta [ 06/Jan/13 ]

I see what is going on here... But this should not be a problem anyway, since they're bound anyway as "PDO::PARAM_INT", as Fabio B. Silva told you.

That's only a problem with the logger showing them as string. PDO will handle the conversion before the value hits the DB as far as I know.

Comment by scourgen [ 07/Jan/13 ]

I can understand your point,but what I don't really get is that the execute time of sql is very long,that explained the quote should be in the sql,not like what you said,that's only a problem with the logger.

Comment by Marco Pivetta [ 07/Jan/13 ]

scourgen can you profile the difference directly in CLI? What about checking the bound parameter type? Are those values bound as INTs in your case?

Comment by scourgen [ 07/Jan/13 ]

@ocramius I wish I could, but I was using doctrine2 with symfony2,So It looks like It will takes some time to simulating all environment and settings that could allow me to reproduced the problem.

but anyway,I will have a try and tell you what happen when I found something.

Comment by Marco Pivetta [ 07/Jan/13 ]

scourgen ok, awaiting your reply then

Comment by scourgen [ 07/Jan/13 ]

I've spent some time on playing with native doctrine2. It took me awhile to setup everything. but I just don't get that how to retrive data with its Proxy ojbect(for example Proxies_CG_\My\WebBundle\Entity\Line).

I mean the result of

$this->_em->getRepository("something")->findxxx()

always return an array of real object. I can't reproduced the situation(#comment-19186) that happens on symfony2+doctrine2.

anyway,I can make sure the problem is real exist,Because the execute time of that slow sql from the tool bar of symfony2 is same as I executed it at mysql cli. If the sql shows up on log with quote but running at mysql without quote,the execute time won't be same(actually It will be much more faster,in my case,20x times,from 2xxms to 10ms).

Comment by Marco Pivetta [ 07/Jan/13 ]

scourgen you can use

$em->getReference($className, $identifier)

(identifier being a key=>value array) to force proxies.

Give it a try

Comment by scourgen [ 08/Jan/13 ]

looks like I reproduced it.

    public function testIssue()
    {   
         $no_used=   $this->_em->getRepository(__NAMESPACE__. '\DDC2214Line')->findOneById(1);
        $lines=array(
            //$this->_em->getRepository(__NAMESPACE__. '\DDC2214Line')->findOneById(1),
            $this->_em->getReference(__NAMESPACE__. '\DDC2214Line',1),
            $this->_em->getReference(__NAMESPACE__. '\DDC2214Line','2'),
            $this->_em->getReference(__NAMESPACE__. '\DDC2214Line',3),
        );  
        $logger  = $this->_em->getConnection()->getConfiguration()->getSQLLogger();
        $ids     = array_map(function($r){
            return $r->id;
        }, $this->relatedList);

        //$related = $this->_em->getRepository(__NAMESPACE__ . '\DDC2214LineRelated')->findBy(array('line' => $lines), array('count' => 'DESC'), 20);
        $related = $this->_em->createQuery('select lr from '.__NAMESPACE__ . '\DDC2214LineRelated lr where lr.id in (:ids)')->setParameter('ids',$lines)->getResult();
            
        $query   = end($logger->queries);
//\Doctrine\Common\Util\Debug::dump($query['params']);

        $this->assertCount(3, $related);
        $this->assertEquals($ids, $query['params'][0]);
        $this->assertEquals(\Doctrine\DBAL\Connection::PARAM_INT_ARRAY, $query['types'][0]);
    }   
}

I use MySql Query log to see what's really happen in database(http://dev.mysql.com/doc/refman/5.5/en/query-log.html)

this is the log from table mysql.general_log

2013-01-08 12:23:44	[root] @ localhost [127.0.0.1]	59	0	Connect	root@localhost on doctrine_tests
2013-01-08 12:23:44	root[root] @ localhost [127.0.0.1]	59	0	Query	CREATE TABLE DDC2214Line (id INT AUTO_INCREMENT NOT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB
2013-01-08 12:23:44	root[root] @ localhost [127.0.0.1]	59	0	Query	CREATE TABLE DDC2214LineRelated (id INT AUTO_INCREMENT NOT NULL, line_id INT NOT NULL, count SMALLINT NOT NULL, line_id_related INT NOT NULL, INDEX IDX_D31307994D7B7542 (line_id), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB
2013-01-08 12:23:44	root[root] @ localhost [127.0.0.1]	59	0	Query	ALTER TABLE DDC2214LineRelated ADD CONSTRAINT FK_D31307994D7B7542 FOREIGN KEY (line_id) REFERENCES DDC2214Line (id)
2013-01-08 12:23:44	root[root] @ localhost [127.0.0.1]	59	0	Query	START TRANSACTION
2013-01-08 12:23:44	root[root] @ localhost [127.0.0.1]	59	0	Query	INSERT INTO DDC2214Line (id) VALUES (null)
2013-01-08 12:23:44	root[root] @ localhost [127.0.0.1]	59	0	Query	INSERT INTO DDC2214Line (id) VALUES (null)
2013-01-08 12:23:44	root[root] @ localhost [127.0.0.1]	59	0	Query	INSERT INTO DDC2214Line (id) VALUES (null)
2013-01-08 12:23:44	root[root] @ localhost [127.0.0.1]	59	0	Query	INSERT INTO DDC2214LineRelated (count, line_id_related, line_id) VALUES (1, 1, 1)
2013-01-08 12:23:44	root[root] @ localhost [127.0.0.1]	59	0	Query	INSERT INTO DDC2214LineRelated (count, line_id_related, line_id) VALUES (2, 2, 2)
2013-01-08 12:23:44	root[root] @ localhost [127.0.0.1]	59	0	Query	INSERT INTO DDC2214LineRelated (count, line_id_related, line_id) VALUES (3, 3, 3)
2013-01-08 12:23:44	root[root] @ localhost [127.0.0.1]	59	0	Query	COMMIT
2013-01-08 12:23:44	root[root] @ localhost [127.0.0.1]	59	0	Query	SELECT t0.id AS id1 FROM DDC2214Line t0 WHERE t0.id = 1 LIMIT 1
2013-01-08 12:23:44	root[root] @ localhost [127.0.0.1]	59	0	Query	SELECT d0_.id AS id0, d0_.count AS count1, d0_.line_id_related AS line_id_related2, d0_.line_id AS line_id3 FROM DDC2214LineRelated d0_ WHERE d0_.id IN (1, '2', 3)
2013-01-08 12:23:44	root[root] @ localhost [127.0.0.1]	59	0	Quit	

you can see,in database level,the second parameter of last query but two has quote ( (1, '2', 3) )

Comment by Benjamin Eberlei [ 25/Jan/13 ]

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

Comment by Benjamin Eberlei [ 26/Jan/13 ]

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





[DDC-2385] [GH-640] [Paginator]Add hidden field ordering for postgresql Created: 02/Apr/13  Updated: 02/Apr/13

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

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


 Description   

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

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

Message:

In postgresql environment, when some hidden fields are used in orderBy clause,
they're not property added because $rsm->scalarMappings don't have information about them.

This change fixes above.

I'm afraid I'm not sure which branch this will be merged, but anyway here's a patch.






[DDC-2390] Remove Parser and SQLWalker dependency on Query Created: 04/Apr/13  Updated: 04/Apr/13

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

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


 Description   

Query is too powerful to be available in Parser and SQLWalker, because it may lead to accessing data that changes on subsequent runs of a query that is cached.

Idea is to introduce a MetadataBag that contains only the values that are allowed to be accessed.






[DDC-2217] Return a lazy collection from PersistentCollection::match($criteria) Created: 31/Dec/12  Updated: 28/Mar/13

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

Type: Improvement Priority: Major
Reporter: Christophe Coevoet Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 4
Labels: None


 Description   

In 2.3, PersistentCollection::match() has been implemented by doing the query directly. But sometimes, the only meaningful information about the matched collection would be its length. In this case, it would be great to handle it in the same way than extra lazy collections are handled: the matched collection would be initialized lazily, and could do the count in an extra lazy way (if the original collection was extra lazy).
This would of course not change anything in the case where the original collection was already initialized.






[DDC-2374] [GH-634] [WIP] Value objects Created: 26/Mar/13  Updated: 14/Apr/13

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

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

Issue Links:
Reference
relates to DDC-93 It would be nice if we could have sup... Open

 Description   

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

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

Message:

This pull request takes a different approach than GH-265 to implement ValueObjects. Instead of changing most of the code in every layer, we just inline embedded object class metadata into an entities metadata and then use a reflection proxy that looks like "ReflectionProperty" to do the rewiring.

The idea is inspired from Symfony Forms 'property_path' option, where you can write and read values to different parts of an object graph.

This is a WIP, there have been no further tests made about the consequences of this approach. The implementation is up for discussion.






[DDC-2405] Changing strategy generates bad query. Created: 19/Apr/13  Updated: 21/Apr/13

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

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


 Description   

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

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

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

will trigger:

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

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

:

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



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

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

Comment by Van Rotemberg [ 21/Apr/13 ]

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

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

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

Comment by Marco Pivetta [ 21/Apr/13 ]

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

Comment by Van Rotemberg [ 21/Apr/13 ]

@marco pivetta

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

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

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





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

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

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

Windows 7, Apache 2.2, MSSQL Server, PHP 5.3.3



 Description   

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

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

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

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

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

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

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

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

Like $myRepo->find($identifier)

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



 Comments   
Comment by locs [ 23/Apr/13 ]

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





[DDC-2420] [GH-656] [DDC-2235] Fix for using a LEFT JOIN onto an entity with single table inheritance Created: 28/Apr/13  Updated: 28/Apr/13

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

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


 Description   

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

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

Message:

Possible fix for the bug DDC-2235. I'd love to hear some opinions on whether this is the right way to go about this issue. I'm not particularly familiar with the internals of doctrine so there may be a better solution.

------

The issue is when using DQL to perform a left join on an entity using single
table inheritance, doctrine tries to insert an `IN()` predicate into the `WHERE`
clause for all of the discriminator values. That makes sense and is valid, so
it would be wrong to remove that behaviour.

However when using a left join having an `IN()` in the main where clause makes
the `LEFT JOIN` pretty much useless, as it implicitly creates a `WHERE NOT NULL`
clause. This commit attempts to fix that by including an `OR IS NULL` in the
query if the join is a `LEFT JOIN`.

I've added some regression tests to ensure this bug never creeps back in. They fail on master (highlighting the bug) and pass after these commits have been applied. I've also included a couple of other queries as tests to be sure only this one case has been affected.






[DDC-2078] [GH-479] [WIP][Mapping] Ported some of the yaml driver to use Symfony config Created: 14/Oct/12  Updated: 01/May/13

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

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


 Description   

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

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

Message:

Looking for some input. How much validation and normailization should i push to the configuration ? Should i use default values so we can remove alot of lines from the driver ?

Is the way im allowing to extend the configuration good enough for Gedmo and others (untested)?






[DDC-2167] [GH-522] [DDC-2166] Refactor identity hash generation Created: 25/Nov/12  Updated: 01/May/13

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

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


 Description   

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

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

Message:

This work prepares for the merge of GH-232, allowing more complex and robust identifier hash generation.






[DDC-2316] [GH-588] ClassMetadataInfo: use reflection for creating new instance (on PHP >=5.4) Created: 23/Feb/13  Updated: 04/May/13

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

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


 Description   

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

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

Message:

On PHP >=5.4, use proper way for instantiating classes without invoking constructor.



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

Scheduling this for 3.0, when we move to php 5.4 or higher requirement





[DDC-2319] [GH-590] DQL Query: process ArrayCollection values to ease development Created: 25/Feb/13  Updated: 04/May/13

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

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


 Description   

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

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

Message:

I added some code to ease "where in" parameter binding.

As you know, when a where condition is added, the object itself can be passed as a parameter and it's id is automatically retrieved:

```php
$queryBuilder = $this
->where('model.category = :category')
->setParameter('category', $category)
;
```
Where `$category` is an object.

But it doesn't work for collections:
```php
$queryBuilder = $this
->where('model.category IN (:categories)')
->setParameter('categories', $categories)
;
```

Where categories is an `ArrayCollection` object (retrieved from a many to one relation for instance).

This doesn't work in the current version of Doctrine, and my PR solved that.

So far, the only solution is to do the following:

```php
$categoryIds = array();

foreach ($categories as $category)

{ $categoryIds[] = $category->getId(); }

$queryBuilder = $this
->where('model.category IN (:category_ids)')
->setParameter('category_ids', $categoryIds)
;
```

And this is pretty borring when you have to do it several times for several entities.

Note that I didn't add any unit test for this feature. Can you explain me where I should add the test?

Thanks!






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

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

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

Mysql 5.1.66 / Symfony 2.2.1



 Description   

For a parent class:

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

and simple Child1 & Child2 entities.

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

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

Enough for the context.
The symptoms:

$em->remove(instanceOfExternalEntity);

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

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

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



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

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

Comment by Bruno Jacquet [ 06/May/13 ]

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

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

Comment by Bruno Jacquet [ 06/May/13 ]

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

Comment by Bruno Jacquet [ 06/May/13 ]

Maybe using

cascade={"remove"}

, instead of

onDelete="CASCADE"

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





[DDC-2339] [GH-605] DDC-2338 Added failing test for composite foreign key persistance Created: 07/Mar/13  Updated: 09/May/13

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

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


 Description   

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

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

Message:

I've added this test regarding ticket DDC-2338



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

This is documented behavior and would just be an improvement





[DDC-2429] Association-Override Problem in XSD Mapping? Created: 05/May/13  Updated: 13/May/13

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

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Fabio B. Silva
Resolution: Unresolved Votes: 0
Labels: None


 Description   

From a mailinglist entry:

I use Doctrine 2.3 in Symfony 2.1.8

I'm using association-overrides in the XML format between several entities. Eclipse shows up several errors.

The first error message is shown in every Doctrine file when I declare the file format as such (for example: https://github.com/thewholelifetolearn/Social-Library/blob/master/src/SocialLibrary/ReadBundle/Resources/config/doctrine/GraphicNovel.orm.xml )

<?xml version="1.0" encoding="UTF-8"?>
<doctrine-mapping xmlns="http://doctrine-project.org/schemas/orm/doctrine-mapping"
                  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                  xsi:schemaLocation="http://doctrine-project.org/schemas/orm/doctrine-mapping
                  http://doctrine-project.org/schemas/orm/doctrine-mapping.xsd">

Eclipse shows this error :
White spaces are required between publicId and systemId

The error points to the "doctrine-mapping" line

The second error comes up when I change the doctype to (file example: https://gist.github.com/thewholelifetolearn/5462057 ):

<?xml version="1.0" encoding="UTF-8"?>
<doctrine-mapping xmlns="http://doctrine-project.org/schemas/orm/doctrine-mapping"
                  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                  xsi:schemaLocation="http://doctrine-project.org/schemas/orm/doctrine-mapping
                  https://raw.github.com/doctrine/doctrine2/master/doctrine-mapping.xsd">

But then this error is shown:
cvc-complex-type.2.4.b: The content of element 'association-overrides' is not complete. One of '

{"http://doctrine-project.org/schemas/orm/doctrine-mapping":association-override, WC[##other:"http://doctrine-project.org/schemas/orm/doctrine-mapping"]}

' is expected.

The error points on "<association-overrides>" in Novel.orm.xml (line 8)

Could someone explain me the errors that show up? The first error doesn't seem to disturb Symfony2 but the second messes around the console commands. But it still generates the database.






[DDC-2220] Add joins to Collection Filtering API Created: 03/Jan/13  Updated: 03/Jan/13

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

Type: Improvement Priority: Major
Reporter: Oleg Namaka Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 2
Labels: api, collection, filtering


 Description   

The recently added collection filtering API only goes half way in achieving a full fledged solution to filter huge collections. It still lacks joins. Look at the next two snippets:

    $criteria = Criteria::create()
        ->where(Criteria::expr()->eq('storeId', $store->getId()))
        ->andWhere(Criteria::expr()->eq('Category', 20))
        ->orderBy(array('popularity' => 'DESC'));
    return $this->BrandCategories->matching($criteria);

This piece of code works but what if there is a need to filter the BrandCategories collection by Categories with some extra criteria:

    $criteria = Criteria::create()
        ->where(Criteria::expr()->eq('storeId', $store->getId()))
        ->andWhere(Criteria::expr()->eq('Category', 20))
        ->andWhere(Criteria::expr()->eq('Category.name', 'Electronics'))
        ->orderBy(array('popularity' => 'DESC'));
    return $this->BrandCategories->matching($criteria);

That would not work.

Ideally we should have a possibility to join other entities, the Category entity in our case here:

    $criteria = Criteria::create()
        ->where(Criteria::expr()->eq('storeId', $store->getId()))
        ->andWhere(Criteria::expr()->eq('Category', 20))
        ->innerJoin(Criteria::expr()->field('Category', 'Category'))
        ->andWhere(Criteria::expr()->eq('Category.name', 'Electronics'))
        ->orderBy(array('popularity' => 'DESC'));
    return $this->BrandCategories->matching($criteria);

What do you think about it, does it make sense to add such functionality?






[DDC-2446] [GH-666] [DDC-2429] Fix xsd definition Created: 13/May/13  Updated: 13/May/13

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

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


 Description   

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

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

Message:

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






[DDC-2445] [GH-665] oo Add Null in ScalarExpression Created: 12/May/13  Updated: 12/May/13

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

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


 Description   

This issue is created automatically through a Github pull request on behalf of vahid-sohrabloo:

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

Message:






[DDC-2455] Setting classes in the entity manager Created: 16/May/13  Updated: 16/May/13

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

Type: Bug Priority: Major
Reporter: Petter Castro Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: entitymanager


 Description   

I am creating my own bundle in Sf2 which will be used for third libraries, but I need to provide some simple and complex queries from this.
For simple queries i have no problem because I set the repository with the class from the third library.
Something like this:

$this->repository = $this->em->getRepository($className);
$result = $this->repository
->createQueryBuilder("c")
->select('c, d, e')
->join("c.groups", "d")
->join("d.users", "e")
->where("e.id = :userId")
->setParameter("userId", $userId);

return $result->getQuery()->getResult();

But when I need complex queries i have to work with the Entity Manager instead of working with the Repository. So tables are named as MyBundle (Group), but not how the third library named (sf_group). As a consequence the SQL throws an error saying that my table does not exist.
This is how I am trying to retrieve:

$query = $this->em->createQuery("SELECT p FROM Groups p");

I sent the className as the entity to avoid this. Something like:

$query = $this->em->createQuery("SELECT p FROM ".$this->className." p");

However i need a lot of queries with JOINs, so i would have to change every entity name, which is not convenient.

What another way could I implemment this?

Thanks for your help.






[DDC-2456] [GH-669] Fixed generating column names for self referencing entity. Created: 17/May/13  Updated: 17/May/13

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

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


 Description   

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

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

Message:






[DDC-2461] [GH-673] Namespace based command names Created: 17/May/13  Updated: 17/May/13

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

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


 Description   

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

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

Message:

Symfony console supports auto completion:
``orm:generate:entities`` could called ``o:g:e``



 Comments   
Comment by Doctrine Bot [ 17/May/13 ]

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

Comment by Marco Pivetta [ 17/May/13 ]

BC break without advantages

Comment by Doctrine Bot [ 17/May/13 ]

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





[DDC-2460] [GH-672] Simplification example Created: 17/May/13  Updated: 17/May/13

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

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


 Description   

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

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

Message:

Remove doctrine class loader, one bootstrap file






[DDC-2463] [GH-675] Implementation for 'IsNot'-Comparison Created: 20/May/13  Updated: 20/May/13

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

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


 Description   

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

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

Message:

See PR (https://github.com/doctrine/collections/pull/11)

This is the required implementation for 'IsNotNull'-Filters in Collection-Filtering.






[DDC-2466] [GH-676] Update UnitOfWork.php Created: 22/May/13  Updated: 22/May/13

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

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


 Description   

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

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

Message:

Here, if a field (type date or datetime) is defined as id, I have an error because it's an object and not a string...

Can you please fix this bug ? Thank you.






[DDC-1283] Possible issue with PersistentCollection#getDelete/InsertDiff() Created: 21/Jul/11  Updated: 20/Sep/12

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

Type: Improvement Priority: Minor
Reporter: Glen Ainscow Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Using the following code, when you go from (1, 2) to (1), (2) is deleted as expected. However, if you go from (1, 2) to (2), (1) and (2) are deleted and (2) is then inserted. Is this the desired behaviour? (i.e. 2 extra queries)

$bracket->getTournamentLocations()->takeSnapshot();

$col = $bracket->getTournamentLocations()->unwrap();

$col->clear();

foreach ($form->getValue('tournamentLocations') as $id) {
    $col->add($em->getReference('Tournaments_Model_TournamentLocation', $id));
}

$bracket->getTournamentLocations()->setDirty(true);


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

First, you are using internal API therefore you are on your own anyways.

This is marked as improvment now, the functionality works, it may just be inefficient.

Comment by Guilherme Blanco [ 09/Dec/11 ]

Hi,

I'm marking issue as invalid because you're conceptually wrong.
What you're trying to do is telling that a collection of new entities is holded by a collection of Persistent entities.
The reference internally of PersistentCollection to ArrayCollection means a lot here.

Correct code would be you to regenerate the collection (a new ArrayCollection) and just assign it to setTournamentLocations($newCollection);

Does this explanation is enough for you?

Cheers,

Comment by Glen Ainscow [ 23/Dec/11 ]

Hi Guilherme,

If I do this:

$locations = new ArrayCollection();

foreach ($form->getValue('tournamentLocations') as $id) {
    $locations->add($em->getReference('Tournaments_Model_TournamentLocation', $id));
}

$bracket->setTournamentLocations($locations);

... then all the records are deleted, before adding the new records. This is inefficient and causes extra, unnecessary write operations.

Can't Doctrine perform diffs when persisting the collection, so that only the necessary deletes and inserts are executed?

Comment by Guilherme Blanco [ 13/Jan/12 ]

We could add it, but I don't think it worth the effort.
Main problem with this one is that we use C-level binary comparison to get the diff. That's what you entities/hash pointers are different.
We would have to write our own diff-comparator for both collections, which would probably slowdown the entire Doctrine.

I'd rather consider that it's not possible to be done at the moment, but I need much more investigation for that. This will be something that I'll probably only do when I look at this issue again with a lot of time (which is really hard to happen).

If you have some spare time, feel free to make some attempts.
Just don't forget to enable performance tests in Doctrine Unit Test suite.





[DDC-1123] Confusing error message when an ID is missing Created: 25/Apr/11  Updated: 15/Nov/11

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

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


 Description   

The error message you get when an entity is missing an ID when attempting to persist it is rather confusing.

"Entity of type Some\Entity\Name is missing an assigned ID."

This does not tell me anything at all. I had absolutely no idea what an assigned ID was. I totally randomly noticed that I had mistyped @GeneratedValue as @GenratedValue, and fixing it fixed the issue.

Perhaps the message makes sense if you're familiar with Doctrine 2 internals, but I think it should be changed to something more helpful, such as "Entity of type X is missing primary key".

Alternatively it could keep the same message, but it could suggest a possible error ("Does the entity have a primary key set?") or perhaps the documentation could include a reference to it to help debug.



 Comments   
Comment by Liju P M [ 15/Nov/11 ]

I too came across the same issue. The error message is not up to the mark here. In my case, mapping for primary key was missing the generator strategy,

<generator strategy="IDENTITY"/>

Thanks Jani Hartikainen for the hint.





[DDC-891] DDC-117: No sequence generation with composite foreign key Created: 25/Nov/10  Updated: 25/Nov/10

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

Type: New Feature Priority: Minor
Reporter: Timo A. Hummel Assignee: Roman S. Borschel
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Given the following entity definitions, Doctrine does not attempt to manage generated values. For example, in MySQL, it is perfectly possible to create a composite primary key and set auto_increment on one of these. See below the code for issues that occur.

User.php
/**
 * @Entity
 */
class User {
	/**
	 * @Id
	 * @Column(type="integer")
	 * @GeneratedValue(strategy="AUTO")
	 */
	private $id;
	
	/**
	 * @Column(type="string")
	 */
	private $name;
	
	/**
	 * @OneToMany(targetEntity="PhoneNumber",mappedBy="id",cascade={"all"})
	 */
	private $phoneNumbers;
	
	public function setName ($name) {
		$this->name = $name;
	}
}
PhoneNumber.php
/**
 * @Entity
 */
class PhoneNumber {
	/**
	 * @Id
	 * @Column(type="integer")
	 * @GeneratedValue(strategy="AUTO")
	 */
	private $id;
	
	/**
	 * @Id
	 * @ManyToOne(targetEntity="User",cascade={"all"})
	 */
	private $user;
	
	/**
	 * @Column(type="string")
	 */
	private $phonenumber;
	
	public function setUser (User $user) {
		$this->user = $user;
	}
	
	public function setPhoneNumber ($phoneNumber) {
		$this->phonenumber = $phoneNumber;
	}
}
Invokation
$albert = new User;
$albert->setName("albert");
$em->persist($albert);

$phoneAlbert1 = new PhoneNumber();
$phoneAlbert1->setUser($albert);
$phoneAlbert1->setPhoneNumber("albert home: 012345");
$em->persist($phoneAlbert1);

The first issue which occurs is that Doctrine does not generate the field "id" within PhoneNumber set to auto_increment.

The second issue which occurs is that Doctrine becomes confused when inserting a new record into PhoneNumber, because of the following INSERT INTO statement:

Insert Statement
INSERT INTO PhoneNumber (user_id, phonenumber) VALUES (?, ?)
array(1) {
  [1]=>
  string(19) "albert home: 012345"
}

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


 Comments   
Comment by Roman S. Borschel [ 25/Nov/10 ]

I don't think this will ever be possible.

Comment by Timo A. Hummel [ 25/Nov/10 ]

Is there a technical reason for that? I mean, with DDC-117 we are aiming for composite foreign keys, or is DDC-117 cancelled?

Comment by Benjamin Eberlei [ 25/Nov/10 ]

A composite key is ALWAYS of the type "ASSIGNED" and cannot be a combination of different id generation strategies.

You could however write a prePersist Listener that does this for you.

Comment by Timo A. Hummel [ 25/Nov/10 ]

Okay, maybe this is a feature for 3.0 or so. However, I'd suggest leaving this bug open as this is something which needs to be documented once DDC-117 becomes integrated within the main branch.

Additionally, Doctrine should complain about different ID generation strategies. Right now it silently ignores it.





[DDC-1423] Improving ReadOnly annotation by caching query results Created: 16/Oct/11  Updated: 16/Oct/11

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

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


 Description   

We should be able to tell Doctrine that we want the result of requests on ReadOnly marked Entities to be cached.

For instance:
$person->getMoodInformation();
$person->getCityInformation();

CityInformation are not likely to change so it would make sense to cache it and retrieve only MoodInformation (by using an annotation on the concerned Entity).

What would be even better is to tag which properies we want to hydrate from database and which properties we want to hydrate from cache.






[DDC-1409] Download common 404 Created: 10/Oct/11  Updated: 10/Oct/11

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

Type: Documentation Priority: Minor
Reporter: Thomas Tourlourat - Armetiz Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

404 on Common download link : http://www.doctrine-project.org/projects/common/download






[DDC-2103] Add support for using AliasResultVariable in WhereClause Created: 25/Oct/12  Updated: 25/Oct/12

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

Type: New Feature Priority: Minor
Reporter: Martin Hasoň Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

It would be nice if supported writing in DQL:

SELECT LOWER(a.name) AS name FROM User a WHERE name LIKE ?

The resulting sql:

SELECT LOWER(c0_.name) AS sclr0 FROM users c0_ WHERE LOWER(c0_.name) LIKE ?






[DDC-1889] generate persisters Created: 21/Jun/12  Updated: 22/Oct/12

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

Type: New Feature Priority: Minor
Reporter: Fabio B. Silva Assignee: Fabio B. Silva
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I'm not sure if this is really possible..

but to improve performance we should consider generate custom entity persisters.

Now entity persister are not cached,
if we generate it, we can create performance improvement in hidrators, avoiding checks and sql generation every time that an persister is called.



 Comments   
Comment by Benjamin Eberlei [ 21/Jun/12 ]

This should be relatively easy in the first step by ust generate the RSM and SQL statements in the constructor and extending from the default persister.





[DDC-1888] generate hydrators Created: 21/Jun/12  Updated: 21/Jun/12

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

Type: New Feature Priority: Minor
Reporter: Fabio B. Silva Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

To improve performance we should consider generate custom hydrators per entity or per rsm.

I think that will create a huge performance improvement, avoiding checks every time that an entity/result is hydrated.






[DDC-445] Evaluate possible ways in which stored procedures can be used Created: 19/Mar/10  Updated: 24/Dec/10

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

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

Issue Links:
Reference
relates to DDC-391 Allow to specifiy custom Entity and C... In Progress

 Description   

We should evaluate the current situation of stored procedure support as well as where we want to go with it / how far we want to support it, if at all.



 Comments   
Comment by Benjamin Eberlei [ 19/Mar/10 ]

I think this relates to the usage of Custom Persisters





[DDC-677] Allow DQL DELETE statements to work with join table fk constraints Created: 10/Jul/10  Updated: 10/Jul/10

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

Type: New Feature Priority: Minor
Reporter: Benjamin Eberlei Assignee: Roman S. Borschel
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Reference
is referenced by DDC-130 Cascading and @ManyToMany association... Resolved

 Description   

Currently DQL DELETE will break if any foreign key constraint restricts the delete.

Using the Metadata we can possibly detect these join table FK contstraints and delete them correctly.






[DDC-2459] ANSI compliant quote strategy. Created: 17/May/13  Updated: 17/May/13

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

Type: Improvement Priority: Minor
Reporter: Fabio B. Silva Assignee: Fabio B. Silva
Resolution: Unresolved Votes: 0
Labels: None


 Description   

In order to simplify and speed up the sql generation
an ANSI quote strategy would be useful.

The implementation would be something like :

<?php
class AnsiQuoteStrategy implements \Doctrine\ORM\Mapping\QuoteStrategy
{
    /**
     * {@inheritdoc}
     */
    public function getColumnName($fieldName, ClassMetadata $class, AbstractPlatform $platform)
    {
        return $class->fieldMappings[$fieldName]['columnName'];
    }

    /**
     * {@inheritdoc}
     */
    public function getTableName(ClassMetadata $class, AbstractPlatform $platform)
    {
        return $class->table['name'];
    }

    /**
     * {@inheritdoc}
     */
    public function getSequenceName(array $definition, ClassMetadata $class, AbstractPlatform $platform)
    {
        return $definition['sequenceName'];
    }

    /**
     * {@inheritdoc}
     */
    public function getJoinColumnName(array $joinColumn, ClassMetadata $class, AbstractPlatform $platform)
    {
        return $joinColumn['name'];
    }

    /**
     * {@inheritdoc}
     */
    public function getReferencedJoinColumnName(array $joinColumn, ClassMetadata $class, AbstractPlatform $platform)
    {
        return $joinColumn['referencedColumnName'];
    }

    /**
     * {@inheritdoc}
     */
    public function getJoinTableName(array $association, ClassMetadata $class, AbstractPlatform $platform)
    {
        return $association['joinTable']['name'];
    }

    /**
     * {@inheritdoc}
     */
    public function getIdentifierColumnNames(ClassMetadata $class, AbstractPlatform $platform)
    {
        return $class->identifier;
    }

    /**
     * {@inheritdoc}
     */
    public function getColumnAlias($columnName, $counter, AbstractPlatform $platform, ClassMetadata $class = null)
    {
        return $platform->getSQLResultCashing($columnName . $counter);
    }
}





[DDC-2462] [GH-674] Shortcut for force Created: 20/May/13  Updated: 20/May/13

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

Type: Improvement Priority: Minor
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 TorbenBr:

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

Message:






Generated at Wed May 22 00:22:00 UTC 2013 using JIRA 5.2.7#850-sha1:b2af0c8dc8537b36121c6a579fabbdf79fc919e5.