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

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

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


 Description   

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



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

Hi, do you have any more information about this ?

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

Thanks

Comment by Karsten Dambekalns [ 11/Apr/11 ]

The issue is simple and logical.

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

Here is an example:

namespace Foo;

class Bar {

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

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

}

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

Comment by Benjamin Eberlei [ 11/Apr/11 ]

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

Comment by Karsten Dambekalns [ 11/Apr/11 ]

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

Comment by Andrey Kolyshkin [ 13/May/11 ]

Example (Entitymanager.php):

namespace Doctrine\ORM;

and

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

Result:
Doctrine\ORM\Doctrine\ORM\Configuration

Should be:

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

Or

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

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

Comment by Karsten Dambekalns [ 27/May/11 ]

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

Comment by Michael Ridgway [ 11/Jul/11 ]

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

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

Comment by Andrew Mackrodt [ 29/Sep/11 ]

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

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

Comment by Benjamin Eberlei [ 13/Dec/11 ]

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

Comment by Benjamin Eberlei [ 13/Dec/11 ]

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

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

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





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

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

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


 Description   

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

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

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


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

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

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

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





[DDC-1478] GH-175: added EntityRepository::getClassName() Created: 08/Nov/11  Updated: 03/Feb/14  Resolved: 13/Nov/11

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

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


 Description   

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

added EntityRepository::getClassName() to fullfill the ObjectRepository interface

see https://github.com/doctrine/common/pull/70



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

Merged

Comment by Doctrine Bot [ 03/Feb/14 ]

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





[DDC-1468] Exception verbose: Id in a mapped-superclass Created: 04/Nov/11  Updated: 20/Dec/13  Resolved: 19/Dec/11

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.1
Fix Version/s: 2.2

Type: Improvement Priority: Minor
Reporter: Francois Mazerolle Assignee: Fabio B. Silva
Resolution: Fixed Votes: 0
Labels: None


 Description   

Some exception could/should be more precise (I've lost a lot of time figuring out why I was having an error)

When you have an id field inside a mapped-superclass, you get the following exception:

[ErrorException]
Notice: Undefined index: IdealTech\OnlineSystem\GeoBundle\Entity\AbsAddress in /Users/fmazerolle/Sites/it/os/vendor/doctrine/lib/Doctrine/ORM/Mapping/Driver/AbstractFileDriver.php line 121

The exception should be more verbose and tell the real cause of the error.



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

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

Comment by Benjamin Eberlei [ 19/Dec/11 ]

Related Pull Request was closed: https://github.com/doctrine/doctrine2/pull/219

Comment by Guilherme Blanco [ 19/Dec/11 ]

Fixed in https://github.com/doctrine/doctrine2/commit/f6d9344d892e5e959b4474437258b02777b41eb1

Comment by Doctrine Bot [ 03/Dec/13 ]

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

Comment by Doctrine Bot [ 20/Dec/13 ]

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





[DDC-1561] GH-239: Fix $qb->expr() PHPDoc @return type. Created: 23/Dec/11  Updated: 20/Dec/13  Resolved: 28/Dec/11

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

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


 Description   

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

The autocompletion was missing so i was sad.

But hey, it's open source!



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

Fixed

Comment by Doctrine Bot [ 20/Dec/13 ]

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





[DDC-972] MySql MyISAM support Created: 07/Jan/11  Updated: 15/Sep/13  Resolved: 11/Sep/13

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

Type: Improvement Priority: Major
Reporter: nicolas isnardi Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 2
Labels: None
Environment:

All



 Description   

We can not set MySql Engine for MyISAM. MySqlPlatform has a _getCreateTableSQL where you can pass some options with the engine param.
Not able to set it up from yml, xml or annotation schema.



 Comments   
Comment by Cédric Tailly [ 19/May/11 ]

I have the same problem and I didn't find documentation to select the engine for a given table.

I tried to understand the code by myself and made modifications of my Doctrine v2.0.5, perhaps this is not the best one but here is a beginning of a solution :

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

@ ORM\Mapping\Driver\DoctrineAnnotations.php:100

final class Table extends Annotation

{ public $name; public $schema; public $indexes; public $uniqueConstraints; public $engine; }

@ ORM\Mapping\Driver\AnnotationDriver.php:144

$primaryTable = array(
'name' => $tableAnnot->name,
'schema' => $tableAnnot->schema,
'engine' => $tableAnnot->engine
);

@ ORM\Tools\SchemaTool.php:133

$table = $schema->createTable($class->getQuotedTableName($this->_platform));

if ( isset($class->table["engine"]) )
$table->addOption("engine",$class->table["engine"]);

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

...and to define for instance the MyISAM engine in annotations :

/**

  • @Entity
  • @Table(engine="MyISAM")
    */

Because there is no foreign key on MyISAM tables, there are still problems on the schema creation/update when Doctrine executes the corresponding "alter table" SQL commands.

Comment by gabriel sancho [ 12/Jul/12 ]

in Doctrine 2.2.2 will be

Doctrine/ORM/Tools/SchemaTool.php-149- /// PATCH ------------------------------------
Doctrine/ORM/Tools/SchemaTool.php-150- if ( isset($class->table["engine"]) )
Doctrine/ORM/Tools/SchemaTool.php-151- $table->addOption("engine",$class->table["engine"]);
Doctrine/ORM/Tools/SchemaTool.php-152- /// PATCH ------------------------------------

Doctrine/ORM/Mapping/ClassMetadataInfo.php-1719- /// PATCH ------------------------------------
Doctrine/ORM/Mapping/ClassMetadataInfo.php-1720- if (isset($table['engine']))

{ Doctrine/ORM/Mapping/ClassMetadataInfo.php-1721- $this->table['engine'] = $table['engine']; Doctrine/ORM/Mapping/ClassMetadataInfo.php-1722- }

Doctrine/ORM/Mapping/ClassMetadataInfo.php-1723- /// PATCH ------------------------------------

Doctrine/ORM/Mapping/Table.php-42- /// PATCH ------------------------------------
Doctrine/ORM/Mapping/Table.php-43- /** @var string */
Doctrine/ORM/Mapping/Table.php-44- public $engine;
Doctrine/ORM/Mapping/Table.php-45- /// PATCH ------------------------------------

Doctrine/ORM/Mapping/Driver/AnnotationDriver.php-181- /// PATCH ------------------------------------
Doctrine/ORM/Mapping/Driver/AnnotationDriver.php-182- $primaryTable['engine'] = $tableAnnot->engine;
Doctrine/ORM/Mapping/Driver/AnnotationDriver.php-183- /// PATCH ------------------------------------

i found a problem in ManyToMany relations, the intermediate table will be InnoDB

Comment by Benjamin Eberlei [ 13/Jul/12 ]

You can do all tables as MyISAM already through metadata using @Table(options=

{"engine": "MyISAM"}

) except Many-To-Many Join Tables. But you could create a listener to the "postSchemaGenerate" event and accept the schema instance there, modify everything accordingly.

Comment by Christophe Coevoet [ 13/Jul/12 ]

should we add the support of the options for the @JoinTable annotation ?

Comment by Benjamin Eberlei [ 13/Jul/12 ]

Yes, that is probably what this ticket boils down to

Comment by Benjamin Eberlei [ 11/Sep/13 ]

This was added in 2.2 or 2.3 with

@Table(options={"engine":"MyISAM"}) 




[DDC-1285] Select by multiple ids Created: 22/Jul/11  Updated: 11/Sep/13  Resolved: 11/Sep/13

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

Type: Improvement Priority: Major
Reporter: Serge Smertin Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 1
Labels: None


 Description   

How do you look at adding findByIds(array $ids) to EntityManager and UnitOfWork? This would allow fetching multiple entities from a database at one request and would be very useful for caching - there would be even some kind of IdentityMap kept in memcached or any other caching engine, that supports multiple id retrieval: i've been using sujhjhjch an architecture in multiple projects and it turned out to be very effective. There were two basic methods - findIdsByFilter(array $filter) and findEntitiesByIds(array $ids). The latter one had a caching proxy, replicating entities to a cache storage. If this idea proceeds - I'd be glad to cover it with more details.

This topic on StackOverflow could also help:
http://stackoverflow.com/questions/276709/design-pattern-for-memcached-data-caching



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

Updating fix version

Comment by Benjamin Eberlei [ 11/Sep/13 ]

This is implemented on the Repository since 2.1 or 2.2 with findBy(array('id' => array(1, 2, 3, 4, 5));





[DDC-952] Several features to batch eager selects more efficently Created: 27/Dec/10  Updated: 11/Sep/13  Resolved: 11/Sep/13

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

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

Sub-Tasks:
Key
Summary
Type
Status
Assignee
DDC-53 Introduce batching of eager loads Sub-task Resolved Benjamin Eberlei  
DDC-733 Implement a way of forcing a Persiste... Sub-task Resolved Benjamin Eberlei  
DDC-734 Possibility to fetch all outstanding ... Sub-task Closed Guilherme Blanco  
DDC-865 Passing an array as parameter Sub-task Resolved Benjamin Eberlei  
DDC-914 Use JOIN for Fetch=EAGER ManyToOne an... Sub-task Resolved Benjamin Eberlei  
DDC-963 @OneToOne inverse side executes queri... Sub-task Resolved Benjamin Eberlei  
DDC-1060 Use Hydrators inside Persisters Sub-task Resolved Benjamin Eberlei  

 Description   

This ticket aggregates several strategies to optimize batching of eager selects.



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

Requirements for batching of eager loads:

1. Since we are using an IN() query for this we can only support this feature for entities that have a single column primary key.
2. If we want to support composite keys we need to build it as WHERE ( (id1 = ? AND id2 = ?) OR (id1 = ? AND id2 = ?)) but this is currently not possible with the way how internally the $criteria array is used.

Comment by Benjamin Eberlei [ 31/Dec/10 ]

Next item to think about: What if an exception or event breaks the flow and "triggerEagerLoads()" is never called?





[DDC-687] Add New Entity Attribute "idGetter" to allow accessing the ID without triggering lazy-load Created: 12/Jul/10  Updated: 11/Sep/13  Resolved: 11/Sep/13

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

Type: New Feature Priority: Major
Reporter: Benjamin Eberlei Assignee: Roman S. Borschel
Resolution: Fixed Votes: 1
Labels: None


 Description   

Often people present us with the use-case that they want to access the ID of a proxy without loading it.

This has lead to several ugly solutions like mapping the ID to an object and as a foreign key field. There currently exists a simple solution for this:

$id = $em->getUnitOfWork()->getEntityIdentifier($entity->getRelatedProxy());

However we could add a new property here called "idGetter" that would take the name of a method.

During Proxy Generation then this method is created with magic functionality that:

1. In case of Single Primary Key returns the single value
2. In case of Composite Primary Key returns an array of the values in their UoW internal order
3. Throw an Exception if the method does not exist on the original object



 Comments   
Comment by Stefan Klug [ 25/Jan/11 ]

What about an @IdGetter annotation. A function instrumented like this would not trigger the lazy load within the proxy.

Something like

class Entity {
    /** @Id **/
    private $id;

    /** @IdGetter **/
    public function getId() {
       return $this->id;
    }
}

would then result in the proxy implementation

class EntityProxy extends Entity {
  
    public function getId() {
        if (!$this->__isInitialized__) {
            return $this->_identifier;
         } else {
             return parent::getId();
        }
    }
}

After reading the original post I realized that it proposed nearly the same thing. Nevertheless I'll leave it here for clarity. I still think that an annotation on a function would be better, than an annotation which gets the function name as a parameter.

Regards Stefan

Comment by Benjamin Eberlei [ 25/Jan/11 ]

$this->_identifier is an array.

Comment by Benjamin Eberlei [ 11/Sep/13 ]

This was implemented in 2.2 by detecting when this can be done on a getId() call automatically.





[DDC-2148] Many-to-many not working with interface Created: 16/Nov/12  Updated: 22/Nov/12  Resolved: 22/Nov/12

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: DQL
Affects Version/s: 2.3
Fix Version/s: 2.2

Type: Bug Priority: Major
Reporter: Moritz Kraft Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: dql
Environment:

Linux, PHP 5.3.10, Symfony 2.2



 Description   

First off, here's a pastie with all the code and mappings involved, and a stacktrace: http://pastie.org/5372087

Not sure if this a bug or not, but I think that according to the docs this should work - in a vendor bundle I have an entity defining a unidirectional many-to-many relation to an interface: the entity is Group and defines a many-to-many relation to a UserInterface, which is resolved correctly in the app configuration (as the many-to-one relations using it in the other entities of this vendor bundle work fine).

I'm going by these docs:

http://symfony.com/doc/master/cookbook/doctrine/resolve_target_entity.html

However, when adding a user to a group, I'm getting a weird error:

An exception occurred while executing 'INSERT INTO acme_group_user (group_id, user_id) VALUES (?, ?)' with params

{"1":2,"2":1,"3":2,"4":1}

:

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

For some reason it's adding 4 parameters to the statement instead of 2.

Oddly enough, the query generation works perfectly fine when I replace the interface in the mapping with the actual final entity. But that wasn't the point of the exercise... I need to use the interface there.

Also, in other entities in that GroupBundle which are referencing the UserInterface using a different relation type, i.e. many-to-one, the relations work perfectly fine.

The schema validates as well, using doctrine:schema:validate in the console.



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

"many-to-many TO a mapped superclass"? I don't think relations TO mapped superclasses are supported in any way... A mapped superclass should never appear in a `targetEntity` mapping.

Could you please re-formulate the description of the issue? There is no mapped superclass in your examples

Comment by Moritz Kraft [ 16/Nov/12 ]

You are of course right. Edited the issue description/title.

It is a blocker for us, btw., not minor - being able to use a many-to-many relation there is rather central to the code of our app. I'm not seeing a workaround, easy or otherwise.

Comment by Marco Pivetta [ 16/Nov/12 ]

Moritz Kraft yes, but it is not a blocker for the next release Will restore prio.

Comment by Moritz Kraft [ 16/Nov/12 ]

Ah right, yeah, that makes sense. Thank you!

Comment by Moritz Kraft [ 22/Nov/12 ]

Fixed in 1b5f051 - thanks Benjamin!

Comment by Moritz Kraft [ 22/Nov/12 ]

Fixed in 2.3 branch, backported to 2.2 as well





[DDC-1526] Unecessary queries with LEFT JOIN Created: 09/Dec/11  Updated: 23/Oct/12  Resolved: 28/Jan/12

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

Type: Bug Priority: Critical
Reporter: Pascal Burkhard Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

PHP 5.3.6


Attachments: Text File trace.txt     Text File trace.txt    
Issue Links:
Duplicate
is duplicated by DDC-1573 Simple relation hydratation not worki... Resolved

 Description   

After upgrading to 2.1.4 (from 2.1.2), the following dql started creating way more queries than necessary :
SELECT m, p, s, c, o
FROM FERMainBundle:Menu m
LEFT JOIN m.page p
LEFT JOIN m.section s
LEFT JOIN m.children c
LEFT JOIN s.position o
ORDER BY m.lft

Details to the code here:
http://pastie.textmate.org/private/z9gtgqe1odwenxcmudywqa
The model looks like that:
http://pastie.textmate.org/private/przxzfimsfyua02cxqcv9a

http://pastie.textmate.org/private/ob1jqiekv89e4xj9bq06q
First query is executed, it should in fact retrieve everything there is about the menu, but then it runs the second query for every menu element I have, generating a lot of queries that didn't occur before.



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

Can you profile where exactly the extra queries are executed using xdebug_start_trace? Directly during hydration or later in your code?

Comment by Pascal Burkhard [ 19/Dec/11 ]

xdebug trace start just before I query the database

Comment by Benjamin Eberlei [ 20/Dec/11 ]

Hi Pascal, sorry but this is not enough. I need this query until all the other entities (or at least one) are n+1 joined.

Comment by Pascal Burkhard [ 20/Dec/11 ]

Here the complete trace, started just before the first query. I'm sorry but I can't make heads or tails with that... I hope it can help you pinpoint the problem.

Please also note that I have update Doctrine ORM to 2.1.5 and there was a change in the number of "superfluous" queries done. I am now only left with additional queries to get the relations to "parent", cf the model ( http://pastie.textmate.org/private/przxzfimsfyua02cxqcv9a ).

Comment by Benjamin Eberlei [ 28/Dec/11 ]

Is the trace from before upgrade to 2.1.5 or after?

Comment by Pascal Burkhard [ 28/Dec/11 ]

The "complete" trace, i.e. the one that is 5.94 mb big is from after the upgrade to 2.1.5.

Comment by Benjamin Eberlei [ 29/Dec/11 ]

Can you disable the nested set extension? the other ticket uses it too and i want to rule out that its the extensions fault.

Comment by Pascal Burkhard [ 29/Dec/11 ]

Alright. I deactivated the Tree extension, but there are no changes in the number of queries.

Comment by Benjamin Eberlei [ 28/Jan/12 ]

I found the issue.

Comment by Benjamin Eberlei [ 28/Jan/12 ]

Fixed





[DDC-1479] GH-169: preFlush event and lifecycle callback Created: 08/Nov/11  Updated: 10/Jul/12  Resolved: 13/Nov/11

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

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


 Description   

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

For now, we have `@PrePersist`, `@PreUpdate` and `@PreRemove` callbacks. But it's not enough, cuz in some cases we need to run some entity method just before *every* `EntityManager#flush()` call (examples - translatable behavior and file uploading routines).

I've added and tested new `@PreFlush` event, which occurs during the start of the `EntityManager#flush()`, before any changeset gets calculated. This gives users ability to hook into flush process and prepare their entities to save even if they were not changed.



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

Merged into master

Comment by Benjamin Eberlei [ 09/Jul/12 ]

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

Comment by Benjamin Eberlei [ 10/Jul/12 ]

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





[DDC-1482] GH-160: Allow to unset one-to-one relation with generated class Created: 08/Nov/11  Updated: 07/Jun/12  Resolved: 13/Nov/11

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

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


 Description   

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

Added <variableDefault> on generated class.
This generate methods like:
```function setGroup(Group $group = null){
}
```

that allow to remove "Group" association if the relation is one-to-one.

Plus some indentation issue



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

Merged

Comment by Benjamin Eberlei [ 07/Jun/12 ]

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

Comment by Benjamin Eberlei [ 07/Jun/12 ]

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





[DDC-1481] GH-158: Collapsed cascade elements, if cascade-all. Created: 08/Nov/11  Updated: 06/Jun/12  Resolved: 18/Nov/11

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

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


 Description   

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

Collapsed cascade elements, if cascade-all.
(better readability for generated xml)



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

implemented

Comment by Benjamin Eberlei [ 06/Jun/12 ]

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





[DDC-1385] INDEX BY doesn't work for selects with scalars only Created: 21/Sep/11  Updated: 01/Apr/12  Resolved: 08/Nov/11

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

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


 Description   

By scalars-only-selects I mean this:

SELECT c.id, c.name FROM GLocalityBundle:Country c  INDEX by c.id 

The result won't be indexed by c.id, as opposites to this:

SELECT c FROM GLocalityBundle:Country c  INDEX by c.id 

Assuming that GLocalityBundle:Country has several hunders of fields, and you need only two of them, this is very disappointing

After diving in the code, due to rigorous separation of entities on objects and scalars, it looks practically impossible even to implement this feature
What is this? Bad design?



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

I agree it seems very complex to implement for the Object and ArrayHydrator, however it should be very easy for the getScalarResult() hydrator.

Even more I think there is a general bug with INDEX BY and scalars in Object and ArrayHydrator that has to be evaluated.

Comment by Benjamin Eberlei [ 31/Oct/11 ]

This PR will fix this issue https://github.com/doctrine/doctrine2/pull/151, it is scheduled for 2.2

Comment by Benjamin Eberlei [ 08/Nov/11 ]

This is fixed in master

Comment by Oleg Namaka [ 01/Apr/12 ]

This behavior has not changed in the latest 2.2.1. getArrayResult returns an indexed result. getScalarResult returns zero based result. Do I need to create a separate ticket for that issue?





[DDC-1503] Add support for executing custom SQL functions on custom types Created: 02/Jun/10  Updated: 09/Mar/12  Resolved: 21/Nov/11

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

Type: New Feature Priority: Minor
Reporter: Dylan Arnold Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 6
Labels: None

Attachments: File 022-doctrine-basic-entity-persister.diff     File 024-doctrine-many-to-many-persister.diff     File 025-doctrine-unit-of-work.diff     File 029-doctrine-query.diff     File doctrine-type.diff    
Issue Links:
Duplicate
is duplicated by DBAL-53 Missing convertToDatabase-calls when ... Resolved

 Description   

I have created a custom type called point but need a way to have a function called on columns of this type when fetching / updating / inserting entities.

For example:

Consider I have an entity which has a column called the_geom

This is associated with my custom type point

A basic select statement for this entity is as follows:

SELECT id, name, the_geom FROM points where id = 1

The problem is the_geom is encoded and on the PHP side I want it in human readable form. I would like a way to specify custom functions on SELECT / INSERT / UPDATE for columns of this custom type.

When selecting my entity I would like to execute the function ST_AsText(the_geom)

SELECT id, ST_AsText(the_geom) FROM points where id = 1

The same goes for updates and inserts. I would like to surround the column SQL with other custom functions, to encode my human readable text back to the encoded value for the DB.

Possibly this could be integrated into Doctrine\DBAL\Types\Type ?

// Modify the column SQL for insert
public function getSqlInsertColumn(....)
// Modify the column SQL for update
public function getSqlUpdateColumn(....)
// Modify the column SQL for select
public function getSqlSelectColumn(....)
// A possible example of getSqlSelectColumn(...)
public function getSqlSelectColumn($doctrineSql)
{
    // $doctrineSql == "p0_.the_geom"
    return 'ST_AsText(' . $doctrineSql . ')';
}


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

You can only fetch entities using the normalized value of any field, that means you have to find a common transformation that is saved in your entities and then converted on the fly.

There is a default converting method from database to PHP and back you could use, however this is only in one direction. You could define a class for the Point and convert from and to this Call in your Type. This way you could encapsualte all the converting logic in an object and your entities only use the object.

You can extend DQL to have additional queries, however when you select additional fields in DQL and apply a function to them, they are retrieved as scalar and not inside your entity. How to do this is detailed in the manual and the cookbook.

Comment by Benjamin Eberlei [ 04/Jun/10 ]

Closed, there are already extension points that help with this matter-

Comment by Dylan Arnold [ 04/Jun/10 ]

Hi Benjamin.

Thanks for your response.

I don't fully understand what you mean. As far as I can tell this is a specific use case that is not supported by doctrine.

What I have tried is creating an entity that contains a field named $point. This is of my custom type PointType which extends Doctrine\Dbal\Types\Type

In this method I intended to create my own Geometry\Point object by parsing a human readable value returned from the database and seamlessly converting to and from this value in convertToDatabaseValue($value, AbstractPlatform $platform) and convertToPHPValue($value, AbstractPlatform $platform)

The problem is that the column is in binary format and I need the database to decode it for me.

I also understand about extending DQL to use custom functions. If I went down this route, every time I fetch my entities, I would have to do an extra step to parse the scalar. Suddenly my domain logic is not encapsulated within my entity and I have a feeling this could end up being messy.

There is also another possibility as far as I can tell, using a NativeQuery, however this would mean that every time I fetch an entity I would have to do field mapping, and any time I didn't map the field to a function my entity would fail to decode the point and break, this route would also mean a lot of extra coding and care.

I am happy to accept that this use case may not be useful to a large portion of doctrine users and therefore may not be a justified addition to doctrine. I do however believe that this is a feature that would be nice to have, and others will miss it in the future, particularly in postgis integration.

Doctrine already has custom DQL and custom types. As a new user my opinion is that there is definitely some room for some advanced functionality in this area. However, you guys are the core devs, you understand the project and its internals so if this is a feature that should be left out then so be it. (I may just have to look into my own hack).

Kind regards

Comment by Benjamin Eberlei [ 12/Jul/10 ]

Re-opened, although this might possibly be a better ORM than DBAL extension. We have to re-evaluate this for 2.1

Comment by Benjamin Eberlei [ 20/Sep/10 ]

DBAL-53 highlightes a possible problem, how to handle foreign keys in this regard?

Comment by Benjamin Eberlei [ 24/Dec/10 ]

Idea: For each type, wrap the column in a possible conversion snippet:

class Type
{
    public function convertToDatabaseValueSQL($sqlExpr, $platform)
    {
        return $sqlExpr;
    }

    public function convertToPHPValueSQL($sqlExpr, $platform)
    {
        return $sqlExpr;
    }
}

Example:

class IPAddress extends Type
{
    public function convertToDatabaseValueSQL($sqlExpr, $platform)
    {
        return "INET_ATON($sqlExpr)";
    }

    public function convertToPHPValueSQL($sqlExpr, $platform)
    {
        return "INET_PTON($sqlExpr)";
    }
}

Conversion inside the ORM would take place at the following locations:

1. When generating SELECT SQL inside the persister, use the conversion in the SELECT clause.
2. When generating SELECT SQL from a DQL, use conversion in the SELECT clause.
3. When updating an entity inside the persister use this in the SET clause and WHERE clause for the ID.
4. When inserting an entity inside the persister use this in the VALUES clause.

Open questions:

1. Should conversion also be done for occurances in any other clauses other than SELECT?
2. Can we bear the performance impact of this on SQL generation.

Comment by Benjamin Eberlei [ 24/Dec/10 ]

Acttually thinking about it. It has to be everywhere when 3 is necessary (and DELETE WHERE also needs this) then of course the values should be converted for SELECT clauses WHERE also.

One Exception might be JOIN clauses WHERE its better to have:

a.foo = b.foo

vs

FUNC(a.foo) = FUNC(b.foo)
Comment by Benjamin Eberlei [ 10/Mar/11 ]

I think we can optimize the performance of this considerably in the ORM by adding a field option "requiresSQLConversion" that is only set if a boolean method "requiresSQLConversion()" on the type returns true. This method gets a default implementation in abstract type of:

public function requiresSQLConversion()
{
  return false;
}

Every complex type would need to overwrite this method.

Then inside ORM we would only need to check if (isset($field['requiresSQLConversion'])) to determine if we have to modify the SQL or not. Also caching structure would only grow by this option if the variable is actually true.

Comment by Lars Strojny [ 02/May/11 ]

As DBAL-53 has been closed as a duplicate of this one, I'm attaching our patches to make type conversion work

Comment by Benjamin Eberlei [ 15/May/11 ]

Thanks Lars, this is something else what i would implement though.

This ticket gets high priority for 2.2, i will implement and check in directly after 2.1 will be released end of next month.

Comment by Benjamin Morel [ 14/Oct/11 ]

Added a missing type hint in DBAL\Types\Type.php

Will this feature be implemented soon? convertToDatabaseValueSQL() and convertToPHPValueSQL() are not used anywhere yet...

Comment by Benjamin Eberlei [ 21/Nov/11 ]

Implemented.

Comment by Benjamin Morel [ 09/Mar/12 ]

What about the missing type hint on convertToPHPValueSQL() ?

Is there a reason for the inconsistency in these method declarations:

public function convertToDatabaseValueSQL($sqlExpr, AbstractPlatform $platform)
public function convertToPHPValueSQL($sqlExpr, $platform)





[DDC-1653] command line cache clear commands clear everything from caches including non Doctrine related caches Created: 15/Feb/12  Updated: 03/Mar/12  Resolved: 03/Mar/12

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

Type: Improvement Priority: Major
Reporter: Howard Ha Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

When I run doctrine orm:clear-cache:metadata I noticed that it clears everything within the cache, even items which have nothing to do with Doctrine at all.

In looking into the various driver implementations it seems that the AbstractCache->deleteAll() depends on getIds of each cache driver, yet the getIds of XcacheCache and MemcacheCache drivers seem to just get every single item within the cache.

This has several implications:

  1. clearing metadata cache actually clears query cache and any other Doctrine cache using the same cache driver
  2. clearing Doctrine cache of one project actually clears caches of every project using the same cache container
  3. clearing Doctrine cache clears every object cached within that container, leading to increased risk of cache stampeding

In looking at the stored cache data it seems possible to fix #2 by using the Namespace of that project when executing a cache clear. it also seems possible to use the cache driver's deleteByRegex() to solve #1 by deleting only items listed as metadata cache vs query cache. Fixing #1 and #2 automatically fixes concern #3

Or, as an alternative, I could suggest that deleteAll() in MetaDataCommand should be replaced by:

$cacheIds = $cacheDriver->deleteBySuffix('METADATA');


 Comments   
Comment by Howard Ha [ 02/Mar/12 ]

I think this issue might be resolved in 2.2 since the cache layer seems to have been rewritten.

Comment by Guilherme Blanco [ 03/Mar/12 ]

To address this issue we require the rewrite that was done in 2.2.
Closing as fixed.





[DDC-1641] [Tests] Wrong tearDown() in UnitOfWorkTest Created: 09/Feb/12  Updated: 10/Feb/12  Resolved: 10/Feb/12

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

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


 Description   

root@ubuntu-server-1110:/home/zerkms/src/doctrine2# phpunit
PHPUnit 3.6.10 by Sebastian Bergmann.

Configuration read from /home/zerkms/src/doctrine2/phpunit.xml.dist

.SSSSSS.........................EEEEEEEEEEEEEEEEEEEEEEEEEEEEE 61 / 1472 ( 4%)
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE.EEESE...SSSEEEEEEEEEEEEEE 122 / 1472 ( 8%)
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE 183 / 1472 ( 12%)
.EEEEEEESSESESEESESEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEFEEEEE 244 / 1472 ( 16%)
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEESE 305 / 1472 ( 20%)
SSSEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEFFFEEEEEEEEEEEEEEEEEE 366 / 1472 ( 24%)
EEEEEEEEEEESSSEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEESSSSSSSSS 427 / 1472 ( 29%)
SSSS...........SEEEEEEEEEEEEEEEEEEEEEEEEEESEEESEEEEEEEEEEEEEE 488 / 1472 ( 33%)
EEEEEEEEEEEEEEEEEEEEEEEEESEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE 549 / 1472 ( 37%)
EEEEEEEEEEEEEEEEEEEEEE.EEEEEEEEEEEEE.EEEEEEEEEEESSEEEEEEEEEEE 610 / 1472 ( 41%)
EEEEEEEEEEEEEEEEEEEEEEEEEE................................... 671 / 1472 ( 45%)
............................................................. 732 / 1472 ( 49%)
............................................................. 793 / 1472 ( 53%)
.............................................S............... 854 / 1472 ( 58%)
......S...................................................... 915 / 1472 ( 62%)
............................................................. 976 / 1472 ( 66%)
............................................................. 1037 / 1472 ( 70%)
............................................................. 1098 / 1472 ( 74%)
............................................................. 1159 / 1472 ( 78%)
............................................................. 1220 / 1472 ( 82%)
............................................................. 1281 / 1472 ( 87%)
............................................................. 1342 / 1472 ( 91%)
...........................S............S.................... 1403 / 1472 ( 95%)
.................................SSSSSSSS.PHP Fatal error: Class 'Doctrine\Tests\Mocks\EntityPersisterMock' not found in /home/zerkms/src/doctrine2/tests/Doctrine/Tests/ORM/UnitOfWorkTest.php on line 55

This (the fatal error) happens because of in ORM/Tools/SetupTest there is a condition in setUp() that marks test as skipped, but tearDown() is being invoked anyway (that is how phpunit works).

So tearDown() should run only in case if setUp() hasn't skipped the test, otherwise tearDown() deletes registered autoloaders

PS: other tests failed because I haven't set up any database



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

Fixed.





[DDC-1213] Make Bit comparsion available Created: 17/Jun/11  Updated: 09/Feb/12  Resolved: 19/Dec/11

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

Type: Improvement Priority: Major
Reporter: Ronald Marske Assignee: Fabio B. Silva
Resolution: Fixed Votes: 0
Labels: None
Environment:

MAC OSX 10.7



 Description   

When you go to compare Bit Values in MySQL Database you can do thiy by "&" or "|" If you do this with Doctrine 2 you got an exception like following:
Message: [Syntax Error] line 0, col 161: Error: Expected =, <, <=, <>, >, >=, != got '&'

So i fixed this problem for me:

Doctrine\ORM\Query\Parser:
Line 2633

    /**
     * ComparisonOperator ::= "=" | "<" | "<=" | "<>" | ">" | ">=" | "!=" | "&" | "|"
     *
     * @return string
     */
    public function ComparisonOperator()
    {
        switch ($this->_lexer->lookahead['value']) {
            case '=':
                $this->match(Lexer::T_EQUALS);

                return '=';

            case '<':
                $this->match(Lexer::T_LOWER_THAN);
                $operator = '<';

                if ($this->_lexer->isNextToken(Lexer::T_EQUALS)) {
                    $this->match(Lexer::T_EQUALS);
                    $operator .= '=';
                } else if ($this->_lexer->isNextToken(Lexer::T_GREATER_THAN)) {
                    $this->match(Lexer::T_GREATER_THAN);
                    $operator .= '>';
                }

                return $operator;

            case '>':
                $this->match(Lexer::T_GREATER_THAN);
                $operator = '>';

                if ($this->_lexer->isNextToken(Lexer::T_EQUALS)) {
                    $this->match(Lexer::T_EQUALS);
                    $operator .= '=';
                }

                return $operator;

            case '!':
                $this->match(Lexer::T_NEGATE);
                $this->match(Lexer::T_EQUALS);

                return '<>';
            /* Changes by SR-RM to make Bit Oprations available */
            case '&':
            	$this->match(LEXER::T_BIT_AND);
            	return '&';
            case '|':
            	$this->match(LEXER::T_BIT_OR);
            	return '|';
            /* Changes by SR-RM End */
            default:
                $this->syntaxError('=, <, <=, <>, >, >=, !=, &, |');
        }
    }

Doctrine\ORM\Query\Lexer:
Line 53

/* Changes SR-RM to make Bit Oprations available */
const T_BIT_AND             = 30;
const T_BIT_OR               = 31;
/* Changes by SR-RM End */

Line 193

/* Changes SR-RM to make Bit Oprations available */
case '&': return self::T_BIT_AND;
case '|': return self::T_BIT_OR;
/* Changes by SR-RM End */

So, maybe you gonna ad this in next Release

Thanks or your good Job



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

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

Comment by Benjamin Eberlei [ 19/Dec/11 ]

Related Pull Request was closed: https://github.com/doctrine/doctrine2/pull/230

Comment by Benjamin Eberlei [ 19/Dec/11 ]

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

Comment by Benjamin Eberlei [ 19/Dec/11 ]

Related Pull Request was closed: https://github.com/doctrine/doctrine2/pull/231

Comment by Benjamin Eberlei [ 19/Dec/11 ]

Fixed

Comment by Markus Fieber [ 09/Feb/12 ]

I do miss this patch in the recently checked out 2.2 branch. Is there any reason, it was skipped, even if the fix-version here is still 2.2?
I really miss this feature and was unable to get it to work by applying it manually. The parser seems to have troubles applying my parameters :\

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

Hi Markus

The bit comparisons was been added as DQL functions,
Can you explain your problem ?

Comment by Markus Fieber [ 09/Feb/12 ]

Hi Fabio, thank you for the fast reply and the great Doctrine anyway!

My problem is the following:
I have an @Entity called Picture with some columns and the following

	/** @Column(type = "integer", nullable = false)
	 * @var int */
	private $visibility;

Now I try to fetch entities from the database that satisfy some special bit mask in this visibility attribute by doing the following:

	/** @var $query \Doctrine\ORM\Query */
	$query = $this->entityManager->createQuery('SELECT e FROM Classes\Models\Event e JOIN e.pictures p WHERE p.visibility & :visibility = :visibility ORDER BY p.uploadTime DESC');
	$query->setParameter('visibility', \Classes\Session::instance()->getActualUsersRights());
	return $query->getResult();

The error reported is:

Fatal error:  Uncaught exception 'Doctrine\ORM\Query\QueryException' with message '[Syntax Error] line 0, col 78: Error: Expected end of string, got '='' in ...\Doctrine\ORM\Query\QueryException.php:42
Stack trace:
#0 ...\Doctrine\ORM\Query\Parser.php(380): Doctrine\ORM\Query\QueryException::syntaxError('line 0, col 78:...')
#1 ...\Doctrine\ORM\Query\Parser.php(745): Doctrine\ORM\Query\Parser->syntaxError('end of string')
#2 ...\Doctrine\ORM\Query\Parser.php(213): Doctrine\ORM\Query\Parser->QueryLanguage()
#3 ...\Doctrine\ORM\Query\Parser.php(288): Doctrine\ORM\Query\Parser->getAST()
#4 ...\Doctrine\ORM\Query.php(231): Doctrine\ORM\Query\Parser->parse()
#5 ...\Doctrine\ORM\Query.php(242): Doctrine\ORM\Query->_parse()
#6 in <b>...\Doctrine\ORM\Query\QueryException.php</b> on line <b>42</b><br />

Please note: I applied the above patch by hand to the Doctrine 2.2 code. Before that I got an "expected = got '&'" exception in the query.

Am I wrong, if I look through the code and try to find the suggested lines from Ronald there? They aren't in the downloadable package and even not in the SVN, I checked out this morning from http://svn.github.com/doctrine/doctrine2.git

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

Hi Markus

The "&" and "|" is not available for database compatibilities
You should use the DQL function BIT_AND or BIT_OR

WHERE BIT_AND( p.visibility, :visibility )
Comment by Markus Fieber [ 09/Feb/12 ]

Thanks a lot Fabio,

stupid me, sorry.

For completeness, I now use:

SELECT e FROM Classes\Models\Event e JOIN e.pictures p WHERE BIT_AND(p.visibility, :visibility) = :visibility ORDER BY p.uploadTime DESC

and seem to get past the critical part.

Now I can go on trying to get the project back to work with the new Doctrine 2.2
I know its worth the work





[DDC-1617] EntityGenerator does not create uniqueConstraints annotations Created: 24/Jan/12  Updated: 28/Jan/12  Resolved: 28/Jan/12

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

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


 Description   

I have add some uniqueConstraints in ClassMetadataInfo but the EntityGenerator does not create the annotations for this.


private function _generateTableAnnotation($metadata)
{
    $table = array();

    if (isset($metadata->table['schema'])) {
         $table[] = 'schema="' . $metadata->table['schema'] . '"';
    }

    if (isset($metadata->table['name'])) {
        $table[] = 'name="' . $metadata->table['name'] . '"';
    }

    return '@' . $this->_annotationsPrefix . 'Table(' . implode(', ', $table) . ')';
}



 Comments   
Comment by Benjamin Eberlei [ 28/Jan/12 ]

Fixed





[DDC-1620] Partial merge of PR261 Created: 25/Jan/12  Updated: 25/Jan/12  Resolved: 25/Jan/12

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Tools
Affects Version/s: 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.1.5, 2.2-BETA1, 2.2-BETA2, 2.2.0-RC1
Fix Version/s: 2.1.6, 2.2
Security Level: All

Type: Bug Priority: Blocker
Reporter: Miha Vrhovnik Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

The PR261 [1] has two commits, but only one (the first one) was merged to 2.1 and 2.2

[1] - https://github.com/doctrine/doctrine2/pull/261



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

fixed

Comment by Miha Vrhovnik [ 25/Jan/12 ]

Hm github is still saying that this is not in 2.2 branch....

Comment by Benjamin Eberlei [ 25/Jan/12 ]

Cherrypick

Comment by Benjamin Eberlei [ 25/Jan/12 ]

ah no, now its up. thanks





[DDC-1619] Missing QueryBuilder::distinct() method Created: 25/Jan/12  Updated: 25/Jan/12  Resolved: 25/Jan/12

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: 2.1.5, 2.2.0-RC1, Git Master
Fix Version/s: 2.1.6, 2.2
Security Level: All

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


 Description   

The QueryBuilder misses a way to make a query distinct.



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

Fixed





[DDC-1618] Query::Iterate() with fetch join exception but no associaiton selected Created: 24/Jan/12  Updated: 24/Jan/12  Resolved: 24/Jan/12

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: DQL, ORM
Affects Version/s: 2.1.5
Fix Version/s: 2.1.6, 2.2
Security Level: All

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


 Description   

Iterate with fetch join in class Application\Sonata\NewsBundle\Entity\Post using association tags not allowed.

SELECT o FROM Application\Sonata\NewsBundle\Entity\Post o LEFT JOIN o.tags s_tags LEFT JOIN o.author s_author WHERE ( o.id = :field_4f1f118cf04ff_id_0 OR o.id = :field_4f1f118cf04ff_id_1 OR o.id = :field_4f1f118cf04ff_id_2 )

The SqlWalker.php (line 742) does not check if the association is selected ...

The PR : https://github.com/doctrine/doctrine2/pull/271



 Comments   
Comment by Benjamin Eberlei [ 24/Jan/12 ]

Fixed





[DDC-1606] Added fix for collection->contains with many-to-many extra lazy fetchMode Created: 17/Jan/12  Updated: 22/Jan/12  Resolved: 17/Jan/12

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

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


 Description   

That case previously triggered a PHP error along the lines of:

Notice: Undefined index: 0000000062a3a7690000000033c91b26 in doctrine/lib/Doctrine/ORM/UnitOfWork.php line 2202
#0 doctrine/lib/Doctrine/ORM/Persisters/ManyToManyPersister.php(267): Doctrine\ORM\UnitOfWork->getEntityIdentifier(Object(Item))
#1 doctrine/lib/Doctrine/ORM/PersistentCollection.php(411): Doctrine\ORM\Persisters\ManyToManyPersister->contains(Object(Doctrine\ORM\PersistentCollection), Object(Item))
#2 Test.php(71): Doctrine\ORM\PersistentCollection->contains(Object(Item))

Associated PR: https://github.com/doctrine/doctrine2/pull/259



 Comments   
Comment by Guilherme Blanco [ 17/Jan/12 ]

Merged in https://github.com/doctrine/doctrine2/commit/c1012f79706491e9dbf6c8741225b62833c6d2ce





[DDC-1604] Implement Common Proxy Created: 16/Jan/12  Updated: 22/Jan/12  Resolved: 16/Jan/12

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.2-BETA1, 2.2-BETA2
Fix Version/s: 2.2.0-RC1, 2.2
Security Level: All

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


 Comments   
Comment by Benjamin Eberlei [ 16/Jan/12 ]

done





[DDC-1609] Weird testerror on PostgreSQL Created: 18/Jan/12  Updated: 22/Jan/12  Resolved: 18/Jan/12

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: 2.2-BETA1, 2.2-BETA2
Fix Version/s: 2.2.0-RC1, 2.2
Security Level: All

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


 Description   

https://github.com/doctrine/doctrine2/commit/3bb803fd697d92d661f5b8cea473f75f46c34857

Git Bisect found this commit to lead to the following error:

$ phpunit -c postgresql.phpunit.xml --filter DDC-742
PHPUnit 3.6.5 by Sebastian Bergmann.

Configuration read from /home/benny/code/php/wsnetbeans/doctrine2/postgresql.phpunit.xml

E

Time: 12 seconds, Memory: 36.00Mb

There was 1 error:

1) Doctrine\Tests\ORM\Functional\Ticket\DDC742Test::testIssue
Exception: [PHPUnit_Framework_Error_Notice] Undefined index: 0000000016f5d67f000000001fa7794e

With queries:
11. SQL: 'INSERT INTO comments (content) VALUES (?)' Params: 'baz'
10. SQL: 'INSERT INTO comments (content) VALUES (?)' Params: 'bar'
9. SQL: 'INSERT INTO comments (content) VALUES (?)' Params: 'foo'
8. SQL: 'ALTER TABLE user_comments ADD CONSTRAINT FK_BF13722AF8697D13 FOREIGN KEY (comment_id) REFERENCES comments (id) NOT DEFERRABLE INITIALLY IMMEDIATE' Params: 
7. SQL: 'ALTER TABLE user_comments ADD CONSTRAINT FK_BF13722AA76ED395 FOREIGN KEY (user_id) REFERENCES users (id) NOT DEFERRABLE INITIALLY IMMEDIATE' Params: 
6. SQL: 'CREATE TABLE comments (id SERIAL NOT NULL, content VARCHAR(100) NOT NULL, PRIMARY KEY(id))' Params: 
5. SQL: 'CREATE INDEX IDX_BF13722AF8697D13 ON user_comments (comment_id)' Params: 
4. SQL: 'CREATE INDEX IDX_BF13722AA76ED395 ON user_comments (user_id)' Params: 
3. SQL: 'CREATE TABLE user_comments (user_id INT NOT NULL, comment_id INT NOT NULL, PRIMARY KEY(user_id, comment_id))' Params: 
2. SQL: 'CREATE TABLE users (id SERIAL NOT NULL, title VARCHAR(100) NOT NULL, PRIMARY KEY(id))' Params: 

Trace:
/home/benny/code/php/wsnetbeans/doctrine2/lib/Doctrine/ORM/UnitOfWork.php:2171
/home/benny/code/php/wsnetbeans/doctrine2/lib/Doctrine/ORM/Persisters/ManyToManyPersister.php:113
/home/benny/code/php/wsnetbeans/doctrine2/lib/Doctrine/ORM/Persisters/ManyToManyPersister.php:95
/home/benny/code/php/wsnetbeans/doctrine2/lib/Doctrine/ORM/Persisters/AbstractCollectionPersister.php:130
/home/benny/code/php/wsnetbeans/doctrine2/lib/Doctrine/ORM/Persisters/AbstractCollectionPersister.php:108
/home/benny/code/php/wsnetbeans/doctrine2/lib/Doctrine/ORM/UnitOfWork.php:310
/home/benny/code/php/wsnetbeans/doctrine2/lib/Doctrine/ORM/EntityManager.php:334
/home/benny/code/php/wsnetbeans/doctrine2/tests/Doctrine/Tests/ORM/Functional/Ticket/DDC742Test.php:63


/home/benny/code/php/wsnetbeans/doctrine2/tests/Doctrine/Tests/OrmFunctionalTestCase.php:359


 Comments   
Comment by Benjamin Eberlei [ 18/Jan/12 ]

This error depends on the caching layer. Without APC/Memcache this test works for me, not with cache. But it only happens on PGSQL not on MySQL or SQLITE

Comment by Benjamin Eberlei [ 18/Jan/12 ]

It specifically depends on the Memcache driver, test works with APC

Comment by Benjamin Eberlei [ 18/Jan/12 ]

Fixed





[DDC-1612] Cannot call entityManager->flush($entity) with new entity Created: 19/Jan/12  Updated: 22/Jan/12  Resolved: 21/Jan/12

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.2-BETA1, 2.2-BETA2, Git Master
Fix Version/s: 2.2.0-RC1, 2.2
Security Level: All

Type: Bug Priority: Major
Reporter: Sascha-Oliver Prolic Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

Following works:
$entity = $em->find('Entity', 1);
$entity->setName('newName');
$em->persist($entity);
$em->flush($entity);

Following does NOT work:
$entity = new Entity();
$entity->setName('newName');
$em->persist($entity);
$em->flush($entity);



 Comments   
Comment by Benjamin Eberlei [ 21/Jan/12 ]

Fixed





[DDC-1603] Unique key name isn't correctly set Created: 16/Jan/12  Updated: 22/Jan/12  Resolved: 17/Jan/12

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Tools
Affects Version/s: 2.2-BETA2
Fix Version/s: 2.1.6, 2.2.0-RC1, 2.2, 2.3

Type: Bug Priority: Minor
Reporter: Thomas Tourlourat - Armetiz Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

Example :

<unique-constraints>
<unique-constraint columns="permalink" />
<unique-constraint columns="code" />
</unique-constraints>

This will create :
CREATE UNIQUE INDEX UNIQ_6C3BF144F286BC32 ON shows (permalink);
CREATE UNIQUE INDEX 1 ON shows (code);

instead of :
CREATE UNIQUE INDEX UNIQ_6C3BF144F286BC32 ON shows (permalink);
CREATE UNIQUE INDEX UNIQ_6C3BF14477153098 ON shows (code);

The problem comme from SchemaTool, and the first key is a valid result because of "==" instead of "===" inside Table.php.

I have create a PR on Github.



 Comments   
Comment by Thomas Tourlourat - Armetiz [ 16/Jan/12 ]

Here the PR for the ORM SchemaTool : https://github.com/doctrine/doctrine2/pull/261
Here the PR for the DBAL Table : https://github.com/doctrine/dbal/pull/94

Comment by Guilherme Blanco [ 17/Jan/12 ]

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

Comment by Benjamin Eberlei [ 21/Jan/12 ]

DBAL merged back into 2.2 and 2.1.x

Comment by Benjamin Eberlei [ 21/Jan/12 ]

and Merged into 2.2 and 2.1.x ORM





[DDC-1613] Add Pagination Tools Created: 22/Jan/12  Updated: 22/Jan/12  Resolved: 22/Jan/12

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

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


 Description   

We should add pagination tools to the Doctrine\ORM\Tools\Pagination namespace. There are already 3 libraries out there that share the same code-base:

We should merge the currently best one of this into the code soon, as the cost of maintaining them is very high and their code is pretty stable by now.



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

Implemented, using the KNP Code, the PAgerfanta tests and putting a set of functional tests on top.

Merged back into 2.2 aswell as the code can be considered stable and does not affect any other area of the code.





[DDC-1610] Associations loaded in 'loadClassMetadata' event are not well initialized inside ClassMetadata Created: 18/Jan/12  Updated: 21/Jan/12  Resolved: 21/Jan/12

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

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


 Description   

Reproduce
---------------

  • I have an entity
  • I'm loading an association (named 'myfield') inside a `LoadClassMetadata` event.

Error
------

Then i get this error : Notice: Undefined index: myfield in /vendor/doctrine/lib/Doctrine/ORM/UnitOfWork.php line 2473

Problem
-----------

It seems that here https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php#L294 we call the method 'wakeupReflection' before the loadClassMetadata event is dispatched.

A solution
-------------

I've created a patch (all tests pass) here https://github.com/gordonslondon/doctrine2/commit/0823cd54d0b2720f5e72aa9a29d16271904d99f0 that fixed the issue. Do you want a PR ?

Here's the PR : https://github.com/doctrine/doctrine2/pull/264



 Comments   
Comment by Benjamin Eberlei [ 21/Jan/12 ]

Fixed





[DDC-1608] Lazy load more restrict when consuming PersistentCollection trigger actions to *Persisters Created: 17/Jan/12  Updated: 18/Jan/12  Resolved: 18/Jan/12

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

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


 Description   

Since https://github.com/doctrine/doctrine2/pull/259 we identified an issue with the Persisters that are failing to check for entities that exist in UoW (managed and sched for insert) and are now being checked is they are part of Collection.
Also it missed some tests. It should be easy, just ->persist the entity then triggers Collection actions.



 Comments   
Comment by Guilherme Blanco [ 18/Jan/12 ]

Fixed in https://github.com/doctrine/doctrine2/commit/d39760ba49418f42f235e9befe223896f11de4bd

Comment by Benjamin Eberlei [ 18/Jan/12 ]

Merged back to 2.2





[DDC-1598] ProxyFactory makes assumptions on identifier getter code Created: 13/Jan/12  Updated: 16/Jan/12  Resolved: 16/Jan/12

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.5, 2.0.6, 2.0.7, 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.1.5, 2.2-BETA1, 2.2-BETA2, Git Master
Fix Version/s: 2.2, 2.3, 2.x
Security Level: All

Type: Bug Priority: Critical
Reporter: Marco Pivetta Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None


 Description   

As of
https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Proxy/ProxyFactory.php#L214
and
https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Proxy/ProxyFactory.php#L237
the current ProxyFactory isn't actually checking if the identifier getter has logic in it.
Current checks aren't enough/valid.

In my opinion the check should be matching following:

(public|protected)\s+function\s+getFieldname\s*(\s*)\s+

{\s*\$this\s*->Fieldname\s*;\s*}

Not really experienced with regex, but currently cannot come up with a more secure check.



 Comments   
Comment by Benjamin Eberlei [ 15/Jan/12 ]

Can you explain why you think this is necessary?

You are right an id method with logic could exist in 4 lines of code, but for what purpose?

Comment by Marco Pivetta [ 15/Jan/12 ]

First of all it is a question of concept. Doctrine shouldn't assume anything about entities outside of their fields. It already introduces a level of complication when we explain how to clone/serialize objects, which was very confusing.

Asking for the purpose of an identifier field getter method is in my opinion again an attempt of making assumptions over user's code...

What if the user wrote something like:

public function getIdentifierField1()

{ return $this->identifierField1? $this->_myInitializationStuff() : null; }

private function _myInitializationStuff()

{ //open files, check stuff, make things difficult for the D2 team :D }

For instance, opening file handlers, sockets, whatever... This is a case that would break the entity because of optimization introduced by the ProxyFactory. (not to mention when getIdentifierField1 does some conversion, like return $this->identifierField1 + self::OFFSET_REQUIRED_BY_WEBSERVICE;

I'm not arguing about the validity of this optimization, but that the checks are too lazy.

I've read something about moving the ProxyFactory to common and using code scanner tools, and the check should be about applying the optimization only when the form is

return $this->identifierField1;

That's why I put the example of the regex. That would probably not be as safe as using some reflection-based tool, but surely more than just checking if the code is <= 4 lines...

Comment by Marco Pivetta [ 15/Jan/12 ]

Also don't know what stuff like EAccelerator (known in this Jira as of it's fantastic idea about stripping comments) would make the check of the 4 lines like.

Comment by Benjamin Eberlei [ 16/Jan/12 ]

This argument is void i just seen

A method:

public function getIdentifierField1()
{
   return $this->identifierField1? $this->_myInitializationStuff() : null;
} 

Will only used when the id is not set anyways.

In any other case Ids are Immutable and changing them in your code would break a lot more than just this smart proxy method generation.

Comment by Marco Pivetta [ 16/Jan/12 ]

Nope, this code actually works only if the ID is set
I'm not talking about changing IDs, it's just that getters and setters don't always reflect the class attributes...

Comment by Marco Pivetta [ 16/Jan/12 ]

As of IRC there's 3 ways (for now) to get this solved:

  • Some code scanner/stronger checks (difficult/problems with private methods/slow)
  • Regex (as of description)
  • Adding configuration (per-entity or per-method. Probably too messy)
  • Documenting it as "magic" of proxies and let the users be aware of it




[DDC-1594] Merging serialized entity back to the UnitOfWork Created: 11/Jan/12  Updated: 15/Jan/12  Resolved: 15/Jan/12

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

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

Windows 7, Apache, PHP 5.3.8, Zend Framework



 Description   

(I'm using doctrine 2.1.4.)

I'm trying to merge an Entity back to the UnitOfWork.
The Entity is created from a serialized object (The deserialzed Entity is a valid Entity Object. The only difference
is that it is not managed by Doctrine yet) and I'm using the merge
method of the EntityManager to get it in managed state again.

This results in a call of the Method doMerge() in the UnitOfWork
class.
This method takes the id of my deserialized Entity, that I want to
merge, and looks if an Entity with that id is already in doctrine
cache. If that is the case my deserialized Entity is merged with the
one in the cache. So far so good. But I've got the Problem, that the
Entity, which is in cache, is not initialized yet. It is not initialized because
this Entity has a relation to another Entity that a used earlier in code.
It's there but in uninitialized stat, because I did not access it yet.
So when my deserialized Entity and the one from cache gets merged, some field are
uninitialized (the id field, for example).

I fixed the problem by adding this piece of code in line 1446 in the
UnitOfWork class:
if(! $managedCopy->_isInitialized_)

{ $managedCopy->__load(); }

 Comments   
Comment by Benjamin Eberlei [ 15/Jan/12 ]

Fixed and merged into 2.2 and 2.1





[DDC-1585] Doctrine2 doesn't check for the correct entity type on @ManyToOne relations Created: 07/Jan/12  Updated: 15/Jan/12  Resolved: 15/Jan/12

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

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

Issue Links:
Duplicate
duplicates DBAL-479 Doctrine2 schema-tool:update doesn't ... Resolved

 Description   

I made a mistake when creating a @ManyToOne entity:

/**

  • @ManyToOne(targetEntity="Entities\EntityA")
    */
    private $test;

However, I was setting Entities\EntityB into $test.

Doctrine2 doesn't check for this, resulting in a hard-to-find issue.



 Comments   
Comment by Guilherme Blanco [ 13/Jan/12 ]

Duplicated

Comment by Benjamin Eberlei [ 15/Jan/12 ]

This is not a duplicate, its a runtime issue in the code when setting the wrong target entity type.

Comment by Benjamin Eberlei [ 15/Jan/12 ]

Implemented an instanceof check.





[DDC-1601] Schema Validator wrong on entities with pk as fk Created: 15/Jan/12  Updated: 15/Jan/12  Resolved: 15/Jan/12

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

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


 Comments   
Comment by Benjamin Eberlei [ 15/Jan/12 ]

Fixed





[DDC-1588] There is no way to get the Query's result cache impl without going to EM Created: 08/Jan/12  Updated: 09/Jan/12  Resolved: 09/Jan/12

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

Type: Improvement Priority: Major
Reporter: Matti Niemelä Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

Ok, my problem is this:

I have created a Query object. Now I'd like to get it's result cache driver.

My options:
1) Ask QueryCacheProfile for the driver. I can, but it's never populated by default so I always get just NULL.
2) Ask Query with getResultCacheDriver(), but wait, I can't, that's now deprecated
3) Ask from EM's configuration the result cache driver. This always works.

I propose that either the QueryCacheProfile is always populated with the Query's default result cache impl unless specifically overridden for the QueryCacheProfile

OR

Make getResultCacheDriver() not deprecated. Like the other two related methods, they are not deprecated, why should this one. Calling this could populate the QueryCacheProfile for future use like all the other (get cache ttl, id) methods.

My problem with with option 3) is "leaving the context of my method and the Query" (mentally of course). Why should I have to go poke around in EM's configuration when the result cache IS (or is easily obtainable behind the scenes) in the query object anyways?



 Comments   
Comment by Benjamin Eberlei [ 08/Jan/12 ]

Weird, this code looks very strange. I will check and fix that before the 2.2 RC release.

Comment by Benjamin Eberlei [ 09/Jan/12 ]

The default result cache is now passed to any new query cache profile. The following API is now working as expected:

$query->useResultCache(true);
$cache = $query->getQueryCacheProfile()->getResultCacheDriver();
Comment by Matti Niemelä [ 09/Jan/12 ]

That's perfect! Thank you!





[DDC-1577] Remove static Reflection dependency from ClassMetadata Created: 03/Jan/12  Updated: 03/Jan/12  Resolved: 03/Jan/12

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

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

Issue Links:
Reference
relates to DCOM-93 Add Reflection Abstraction Resolved

 Description   

See DCOM-93 for more information






[DDC-1547] GH-228: Fixed testsuite Created: 19/Dec/11  Updated: 03/Jan/12  Resolved: 28/Dec/11

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

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


 Description   

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






[DDC-1554] GH-235: Allow ExporterDrivers that implement the exportClassMetadata() function to return false Created: 22/Dec/11  Updated: 03/Jan/12  Resolved: 28/Dec/11

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

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


 Description   

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

Allow ExporterDrivers that implement the exportClassMetadata() function to return FALSE when no content is available/needs to be written to a file by the AbstractExporter, preventing empty files to be generated foreach processed ClassMetadataInfo instance.

I'm currently generating Data Transfer Object class for my Entities, but not all Entities require it. Based on an Annotation I determine which DTO's will be generated and return FALSE otherwise. Currently this 'negative' return is not respected and a lot of empty files are created.






[DDC-1360] Reserved words escaping fails when using multiple reserved words Created: 03/Sep/11  Updated: 03/Jan/12  Resolved: 31/Dec/11

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

Type: Bug Priority: Blocker
Reporter: Elnur Abdurrakhimov Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None
Environment:

Linux, PostgreSQL



 Description   

Everything works fine when I use the @Table annotation like this: @Table(name="`user`"). But when the user table is in the user schema and I try to use the annotion in this way: @Table(name="`user`.`user`") — everything falls apart.

A quick look into the code showed that it checks if the table name starts with `, and if it does, it sets the quoted parameter to true and removes the ` characters on the both sides. So, if I quote the both words like @Table(name="`user`.`user`"), the table name becomes "user`.`user" and it, of course, fails. If I quote it just like @Table(name="`user.user`"), the table name becomes "user.user", which fails too.

If Doctrine allows to escape the reserved words, it should take into account this kind of usage as well.



 Comments   
Comment by Guilherme Blanco [ 05/Sep/11 ]

By now, it's currently impossible to do cross database joins in an easy way.
We have planned it through the schema support in @Table.

I'll be working on this support for 2.2, but until there, my only recommendation is to not use a keyword as a table name.

Cheers,

Comment by Elnur Abdurrakhimov [ 05/Sep/11 ]

It's not cross database; it's just schema.table in PostgreSQL. It works when not using reserved words, but fails with them.

Comment by Benjamin Eberlei [ 28/Oct/11 ]

How much of this ticket does your commit from some weeks ago cover guilherme?

Comment by Benjamin Eberlei [ 16/Nov/11 ]

Fixed for 2.2

Comment by Elnur Abdurrakhimov [ 21/Dec/11 ]

It still doesn't work. Tried on master.

Comment by Benjamin Eberlei [ 21/Dec/11 ]

what kind of error do you get?

Comment by Benjamin Eberlei [ 28/Dec/11 ]

could reproduce the problem with table names and sequence names.

Comment by Benjamin Eberlei [ 28/Dec/11 ]

Fixed.

Comment by Elnur Abdurrakhimov [ 29/Dec/11 ]

I've just got fresh clones of doctrine-doctrine2, doctrine-dbal and doctrine-common — all on their master branches.

My entity has this annotation:

@ORM\Table(name="`user`.`user`")

I'm getting the following exception:

SQLSTATE[42P01]: Undefined table: 7 ERROR: relation "user.user" 
does not exist LINE 1: ... is_private9,
u0_.created_at AS created_at10 FROM "user.user... 

So, it's translating `user`.`user` to "user.user", while it should be "user"."user".

Comment by Elnur Abdurrakhimov [ 29/Dec/11 ]

What changed is that earlier `user`.`user` was translated to "user`.`user", while now it's translated to "user.user", but should be to "user"."user".

I saw the commit related to this ticket (https://github.com/doctrine/doctrine2/commit/959a68694e5827a74ad5b8c8216996ffff6196ba) and I want to note that I'm getting this error not when creating a table, but when querying it. I don't use Doctrine for creating tables anyway — I do it via plain SQL.

Comment by Benjamin Eberlei [ 31/Dec/11 ]

I keep trying until i fixed this, now with a commit into DBAL: https://github.com/doctrine/dbal/commit/4cb8a99b65fb08e01fbc02cf9c0e07255e3f8463

Will be included in Beta 2

Comment by Elnur Abdurrakhimov [ 31/Dec/11 ]

Now `user`.user, `user`.`user` and `user.user` get escaped properly, ending up as "user"."user". Interestingly enough, even only the beginning tick like in `user.user ends up as "user"."user".

user.`user`, though, results in user.`user` — that is, nothing gets escaped. I don't think this is a big deal, because if I can escape both schema and table name parts, then I won't run into problems. I'm pointing this out in case it was intended to affect the escaping too.

Good job, thanks.





[DDC-551] Consider adding ability to specify additional join conditions on a @JoinTable / @JoinColumn Created: 28/Apr/10  Updated: 22/Dec/11  Resolved: 18/Dec/11

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

Type: Improvement Priority: Minor
Reporter: Marc Hodgins Assignee: Alexander
Resolution: Fixed Votes: 5
Labels: None

Issue Links:
Duplicate
is duplicated by DDC-1007 Add ability to filter a association Resolved
is duplicated by DDC-750 Named scopes (conditional columns and... Resolved
is duplicated by DDC-1092 CustomTreeWalkers For Entities Resolved
is duplicated by DDC-1083 Support for a @Filter annotation to c... Resolved

 Description   

Per discussion with beberlei and romanb in #doctrine-dev yesterday, opening this ticket as a "feature request" to support migrating legacy schemas with a special many-to-many mapping to Doctrine.

Consider the following schema:

CREATE TABLE categories (
    category_id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
    content_type ENUM('posts', 'videos'),
    /* ... */
    PRIMARY KEY (category_id)
) ENGINE=InnoDB;

CREATE TABLE content_category_association (
    content_id BIGINT UNSIGNED NOT NULL,
    category_id BIGINT UNSIGNED NOT NULL,
    content_type ENUM('posts', 'videos'),
    PRIMARY KEY (content_id, category_id, content_type),
    FOREIGN KEY (category_id, content_type) REFERENCES categories(category_id, content_type) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB;

CREATE TABLE posts (
    post_id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
    /* ... */
    PRIMARY KEY (post_id)
) ENGINE=InnoDB;

CREATE TABLE videos (
    video_id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
    /* ... */
) ENGINE=InnoDB;

There is a Many-To-Many relationship between each of the posts and videos table (via the content_category_association table) to the categories table. The difference from a standard many-to-many relationship is there is an extra column in the association table (content_type) which must be included in the join condition to return correct results. Since both the videos and posts table have their own autonumber primary keys, a join against the association table must include an extra condition (i.e. INNER JOIN ... ON ... AND content_category_association.content_type = 'posts').

Perhaps you could allow passing of additional properties to @JoinTable / joinColumns to specify the additional join condition .. i.e.:

/** @Entity */
class Video
{
  /**
   * @ManyToMany(targetEntity="Category")
   * @JoinTable(name="content_category_association",
   *      joinColumns={@JoinColumn(name="content_id", referencedColumnName="video_id")},
   *      inverseJoinColumns={@JoinColumn(name="category_id", referencedColumnName="video_id")},
   *      extraJoinTerms={@JoinTerm(content_type="video")}
   *      )
   */
  private $categories;

  // ...
}

/** @Entity */
class Category
{
    // ...
}

Certainly this schema is not ideal from a pure OO perspective. Class inheritance with a discriminator column may have been a better way to do this, thereby allowing a globally unique "content_id" for all types of content, negating the need for the extra column in the association table. However, it would nonetheless be helpful to have this additional capability within Doctrine to avoid having to re-factor such a legacy schema.



 Comments   
Comment by Yaroslav Zenin [ 25/Nov/10 ]

Would be great to get this functionality

Comment by Benjamin Eberlei [ 22/Jul/11 ]

Assigned to asm89

Comment by Benjamin Eberlei [ 22/Jul/11 ]

Scheduled for 2.2

Comment by Alexander [ 16/Aug/11 ]

I've been working on this ticket over here:
https://github.com/asm89/doctrine2/tree/DDC-551

Latest thing I added was the state of the collection of filters, because this is needed for parsing (and sometimes not parsing) the queries to generate SQL. I'd like some feedback about the state keeping. More information at the commit:
https://github.com/asm89/doctrine2/commit/2653d735e230d19b0fcb703800008f3abdb7a3ba

At this point the EntityManager keeps track of this state, but maybe it would be nice to have a separate FilterCollection keep track of the state/hashes etc?

Comment by Benjamin Eberlei [ 18/Dec/11 ]

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

Comment by Benjamin Eberlei [ 18/Dec/11 ]

Related Pull Request was closed: https://github.com/doctrine/doctrine2/pull/210

Comment by Benjamin Eberlei [ 18/Dec/11 ]

Related Pull Request was closed: https://github.com/doctrine/doctrine2/pull/224

Comment by Benjamin Eberlei [ 18/Dec/11 ]

Implemented

Comment by Benjamin Eberlei [ 18/Dec/11 ]

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

Comment by Benjamin Eberlei [ 18/Dec/11 ]

Related Pull Request was closed: https://github.com/doctrine/doctrine2/pull/225

Comment by Benjamin Eberlei [ 19/Dec/11 ]

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

Comment by Benjamin Eberlei [ 19/Dec/11 ]

Related Pull Request was closed: https://github.com/doctrine/doctrine2/pull/227

Comment by Glen Ainscow [ 19/Dec/11 ]

Alex mentioned on IRC that filters do not provide the functionality that the OP requires, so this issue should really re-opened, unless I'm missing something?

Comment by Benjamin Eberlei [ 22/Dec/11 ]

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





[DDC-1539] QueryException occurs when parentheses exist on the left-hand of comparison Created: 14/Dec/11  Updated: 20/Dec/11  Resolved: 20/Dec/11

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

Type: Bug Priority: Minor
Reporter: Koji Ando Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

When I executed the following DQL, I get an error.

 
> php scripts/doctrine.php orm:run-dql "select o from OrderDetail o where (o.price + o.tax) * o.count > 10000"

  [Doctrine\ORM\Query\QueryException]
  [Syntax Error] line 0, col 69: Error: Expected =, <, <=, <>, >, >=, !=, got ')'

When I swap the left-hand expression and right-hand one, no error occurs.

> php scripts/doctrine.php orm:run-dql "select o from OrderDetail o where 10000 < (o.price + o.tax) * o.count"

array
  empty


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

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

Comment by Guilherme Blanco [ 20/Dec/11 ]

Fixed in https://github.com/doctrine/doctrine2/commit/4bc014c6961be2e24b131d06d25c885fdf07bc3b

Comment by Benjamin Eberlei [ 20/Dec/11 ]

Related Pull Request was closed: https://github.com/doctrine/doctrine2/pull/233





[DDC-1548] One to one entity badly populated Created: 19/Dec/11  Updated: 19/Dec/11  Resolved: 19/Dec/11

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

Type: Bug Priority: Critical
Reporter: Asmir Mustafic Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None
Environment:

ubuntu php 5.3.8


Attachments: File 1548.php    

 Description   

One to one entity over populated



 Comments   
Comment by Asmir Mustafic [ 19/Dec/11 ]

I have created a test.

the bug may be in \Doctrine\ORM\Internal\Hydration\AbstractHydrator at line 246.

i think...

remove
if ( ! isset($rowData[$dqlAlias][$cache[$key]['fieldName']]) || $value !== null) {

and replace with :

if ( ! isset($rowData[$dqlAlias][$cache[$key]['fieldName']]) && $value !== null) {

this will fix the bug

Comment by Guilherme Blanco [ 19/Dec/11 ]

Fixed since this commit: https://github.com/doctrine/doctrine2/commit/68663fac4b5619643b8a140d6bbe7031e4fa2ad5

Thanks a lot for the report and patch! =D

Comment by Benjamin Eberlei [ 19/Dec/11 ]

Update fix version, this was merged into 2.1.5





[DDC-1545] Update on loaded association not detected upon flush() Created: 18/Dec/11  Updated: 19/Dec/11  Resolved: 19/Dec/11

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

Type: Bug Priority: Critical
Reporter: Bernhard Schussek Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

If an association is joined during fetching and then updated in-memory, the update is not detected during flushing. I made the following test cases:

Association is joined:

  • change NULL → entity: does not work
  • change entity → NULL: works
  • change entity1 → entity2: does not work

Assocation is not joined:

  • change NULL → entity: works
  • change entity → NULL: works
  • change entity1 → entity2: works


 Comments   
Comment by Bernhard Schussek [ 18/Dec/11 ]

See here for the test case: https://github.com/bschussek/doctrine-orm/tree/DDC-1545

Comment by Guilherme Blanco [ 19/Dec/11 ]

Increasing priority

Comment by Guilherme Blanco [ 19/Dec/11 ]

Issue fixed since this commit:

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

Thanks a lot for the bug reporting. It was the second time someone reported me this issue and I could not reproduce! =)

Comment by Benjamin Eberlei [ 19/Dec/11 ]

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

Comment by Benjamin Eberlei [ 19/Dec/11 ]

Related Pull Request was closed: https://github.com/doctrine/doctrine2/pull/229

Comment by Benjamin Eberlei [ 19/Dec/11 ]

Fixed properly now. Will be merged into 2.1.x

Comment by Benjamin Eberlei [ 19/Dec/11 ]

Update fix version, this was merged into 2.1.5





[DDC-217] Result cache should cache the SQL result and not the final objects Created: 19/Dec/09  Updated: 19/Dec/11  Resolved: 30/Oct/11

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

Type: Improvement Priority: Minor
Reporter: Roman S. Borschel Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 5
Labels: None

Issue Links:
Duplicate
is duplicated by DDC-1279 Shouldn't Cached Results Trigger Life... Resolved
Reference
is referenced by DDC-446 Cached resultset do not add Entities ... Resolved

 Description   

When fetching objects and using a result cache, it would probably be better to cache the SQL result array instead of the hydrated objects. That way, when grabbing from the cache managed entities can be returned. Also, caching is more efficient since an SQL result array does not need to be serialized/unserialized when storing in apc or memcached.



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

It also avoids unnecessary "proxy not initialized, can't serialize" exceptions.

Comment by Jonathan H. Wage [ 18/Mar/10 ]

If we make this change, the caching won't be "as" affective right since it will still have to go through the hydration process?

Comment by Benjamin Eberlei [ 18/Mar/10 ]

Correct, but its almost impossible to result cache entities because they are not allowed to have a single proxy entity at any depth of the object graph.

Maybe we should introduce another notion of SqlResultCache? The ResultCache is good and effective for all Array and Scalar hydration modes, however the SQL Result caching is more useful for Object Hydration.

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

Exactly. Yes it means hydration is always run but you really cant speak of "effective" when caching large object result sets because serialization & especially unserialization which then happens on every request will be pretty slow.

As Benjamin said, result caching is perfect for anything but objects so this ticket really only affects queries that use object hydration. Storing the raw sql result for these has the advantage that the objects retrieved from the cache are not detached and thus need not be merged and also you dont have issues with uninitialized proxies preventing serialization.

Comment by Jonathan H. Wage [ 20/Mar/10 ]

Is this also the cause of this issue? http://www.doctrine-project.org/jira/browse/DDC-446

Since we're unserializing some objects, does Doctrine know about them?

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

Yes, as already said, objects coming from the result cache are currently DETACHED. Thus the EM does not care about them. This is fine if you just want to display them but if you want to modify them and persist new changes, you need to merge() the ones you want to become MANAGED again into the EM.

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

It should also be noticed that if we make this change and the cached objects are managed after grabbing from the cache this can have a negative effect on flushing performance, if you only want the cached objects for read-only/display purposes. Maybe we should still provide both options, like Benjamin said.

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

Moved to 2.1 for now.

Comment by Daniel Cousineau [ 30/Nov/10 ]

I would like to see the ability to cache pre-hydration as I have already run into this issue.

Maybe the interface could be along similar syntaxes as turning on result caches

$query->useResultCache(true)
      ->setResultCacheLifetime(3600)
      ->setResultCachePreHydration(true); //Result cache should work pre-hydration, false caches 

However from my examinations the hydrators will have to be rewritten to accept an array instead of a pdo statement.

That would be my vote. If you don't have the resources to work on the ticket I can tackle it.

Comment by Benjamin Eberlei [ 01/Dec/10 ]

rewriting to use an array is not an option. this would require to call ->fetchAll() which is not wanted for the Iterate Result feature.

There has to be a better way to redefine the method signatures to allow both use-cases.

Comment by Benjamin Eberlei [ 01/Dec/10 ]

Ah btw, any help is appreciated. Just Fork doctrine2 over at Github and develop this feature in a new branch (git checkout -b DDC-217) and link it here or issue a pull request on Github.

Comment by Daniel Cousineau [ 01/Dec/10 ]

Forked here: https://github.com/dcousineau/doctrine2 though probably should pull it out into a local branch.

I went ahead and went down that route of altering hydrators to accept an array as well as a statement. This way uncached queries will work with the statement as it used to, but can also hydrate from an array.

As for the iterable hydrator you have a point but in this case you really can't cache it period, be it pre or post hydration (since to cache we have to serialize ALL the information).

What I have up is working(ish with the caveat that I backported the changes to an earlier tagged release for our application and tested using that), take a look and see if we like or don't like how I did it.

You'll notice I did split up _doExecute() for the query objects, because the DQL query object does so much analysis in the _doExecute() method which produces and attaches information (namely the result set mapping) that is depended on by the hydration process, I split it up into a "doPreExecute" function so that it can be called separately without actually executing the query.

Comment by Benjamin Eberlei [ 02/Dec/10 ]

Yes i know that the serialize thing won't work with the Iterator. My point was that the Iterator USES the Hydrator code and it should still support that use-case.

See the IterableResult class and make sure that its still working after your refactoring.

I don't like the instanceof check then iterate vs the forach over the array. I would rather find a solutio nthat works for both, but i cant find one now that doesnt involve findAll() (which is bad).

Comment by Daniel Cousineau [ 02/Dec/10 ]

I'll double check against the IterableResult and make sure it's compatible.

Beyond that, I don't know what I could other than the instance of check. I could extend the statement object and create a statement that takes a flat array so all the code remains the same (i'm passing a statement).

Comment by Benjamin Eberlei [ 24/Dec/10 ]

Assigning Guilherme

Comment by Przemek Sobstel [ 10/May/11 ]

I've made my own implementation for this:
https://github.com/sobstel/doctrine2/commit/f583625f791da22dec77dd7d6c83b813f0bcbdaa

There are no changes in specific hydrators and there is no fetchAll(). I've added 2 wrappers: one for cached result array, and one for uncached pdo statement. The former (CachedResultStatement) is actually ArrayIterator which just implements used methods (fetch & closeCursor => also specified in ResultStatementInterface). The latter is decorator for stmt, which just collects results on each call of fetch() (results are later available by calling getResult), and apart from this all calls are delegated to actual stmt object.

I've used (copied) following changes from Daniel https://github.com/dcousineau/doctrine2/commit/c23b5a902da79ffc472c0769b9258775baf3189e

Btw, what is your reasoning for not using fetchAll() anywhere?

Comment by Reio Piller [ 19/Jun/11 ]

maybe a dumb question but is it normal that result cache fetched entities associations are set to blank objects?

Comment by Bogdan Albei [ 22/Jul/11 ]

I've sent a pull request for the fix(https://github.com/bogdanalbei/doctrine2/commit/00d1aa2192b86e51872fbc833b2436354f6fe162) . The changes were tested under live conditions sice v2.0.

Comment by Benjamin Eberlei [ 17/Oct/11 ]

Workaround for this issue: https://gist.github.com/57e6b4deea566baac053

Also: This will be fixed in 2.2.

Comment by Benjamin Eberlei [ 22/Oct/11 ]

First step of this hit DBAL today https://github.com/doctrine/dbal/pull/69

Comment by Benjamin Eberlei [ 23/Oct/11 ]

DBAL code was heavily refactored and merged, the ORM PR is now open for discussion:

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

Comment by Benjamin Eberlei [ 30/Oct/11 ]

Merged into master

Comment by Benjamin Eberlei [ 19/Dec/11 ]

Related Pull Request was closed: https://github.com/doctrine/doctrine2/pull/87





[DDC-1546] another incorrect mapping not detected by orm:validate-schema Created: 18/Dec/11  Updated: 19/Dec/11  Resolved: 19/Dec/11

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers
Affects Version/s: 2.1.1
Fix Version/s: 2.2

Type: Bug Priority: Minor
Reporter: Tom Vogt Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

Linux Debian Squeeze, MySQL



 Description   

Several lines like this one:

<field name="upgrades" type="int" column="Upgrades"/>

Were not flagged by orm:validate-schema as incorrect. Updating a related entity revealed the problem ("int" not being a proper type) at runtime.

Bug: orm:validate-schema should throw an error on incorrect column type.



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

Keep it coming, very valuable

Comment by Benjamin Eberlei [ 19/Dec/11 ]

Fixed, but referenced with wrong ticket in master right now.





[DDC-1456] Sequence doesn't work correctly when sequence is defined second in a composite key Created: 26/Oct/11  Updated: 17/Dec/11  Resolved: 17/Dec/11

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

Type: Bug Priority: Minor
Reporter: Chris Colborne Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

Oracle



 Description   

When using a sequence in Oracle as part of a composite key and the sequence is defined second, Doctrine retrieves from the sequence correctly but incorrectly assigns to the first key (which in this case is not the correct column)

Example:

/Entity/ItemModel.php
/**
 * @Column(name="submission_id", type="integer")
 * @Id
 */
private $submissionId;

/**
 * @Column(name="model_id", type="integer")
 * @Id
 * @GeneratedValue(strategy="AUTO")
 * @SequenceGenerator(sequenceName="model_id_seq", initialValue=1, allocationSize=1)
 */
private $modelId;

Doctrine correctly retrieves the sequence, however it then attempts to set the first identifier field (in this case submission_id) instead of the sequence key.

The problem appears in /Doctrine/ORM/UnitOfWork.php line 613.
$class->indentifier is hard coded to item 0.

$this->entityIdentifiers[$oid] = array($class->identifier[0] => $idValue);

You can workaround this issue by defining the sequence first in the entity.



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

This is not allowed currently, there is a PR for custom id generators, but so long i am closing this as invalid.

Also i added an error exception which makes this kind of setup fail.





[DDC-1330] Doctrine CLI and additional things like Migrations Created: 14/Aug/11  Updated: 17/Dec/11  Resolved: 17/Dec/11

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

Type: Bug Priority: Minor
Reporter: Timo A. Hummel Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 1
Labels: None


 Description   

I'm currently trying out Migrations. However, it seems to me that it is not possible to easily add migrations to a system-wide installed Doctrine2 ORM.

This bug is probably 50% documentation issue and 50% code issue.

What I'm basically trying to do is to add the migrations project.

Problem One: The $cli object

The documentation for both migrations and ORM state about the $cli object. However, it is never explained how the $cli object is instanciated.

It isn't obvious that $cli is either defined by the doctrine command (=doctrine.php which comes with the sandbox and is eventually installed system-wide) or actually needs to be defined by the developer himself. It might be obvious when you read the complete manual first (like a book, which actually nobody does - at least not anybody I know), but this isn't helpful because the manuals are all reference manuals.

So the manuals need to be changed so that it actually explains where $cli comes from.

http://www.doctrine-project.org/docs/orm/2.1/en/reference/tools.html
http://www.doctrine-project.org/projects/migrations/2.0/docs/reference/introduction/en#introduction

Problem Two: Defining a custom doctrine.php file

As there's no code - at least not which I could have found easily - to add CLI commands to system's doctrine.php without modifying it, developers are forced to duplicate the code of doctrine.php and add their own CLI commands.

The problem could be easily avoided by allowing the users to define something like $additionalCommands in their cli-config.php which could then appended via $cli->addCommands() in the master doctrine.php file.



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

Added a part on setiing up the CLi into the ORM docs.





[DDC-1368] incorrect mapping not detected by orm:validate-schema Created: 08/Sep/11  Updated: 17/Dec/11  Resolved: 17/Dec/11

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

Type: Bug Priority: Minor
Reporter: Tom Vogt Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

Linux, Debian Lenny, PHP 5.3.8



 Description   

The following incorrect mapping was not detected by orm:validate-schema, instead running it resulted in:

$ doctrine orm:validate-schema
[Mapping] OK - The mapping files are correct.

<doctrine-mapping>
...
<one-to-many field="duchies" target-entity="Duchy" mapped-by="realm">
<order-by>
<order-by-field name="name" direction="ASC" />
</order-by>
</one-to-many>
...
</doctrine-mapping>

and the inverse side:

<doctrine-mapping>
<one-to-one field="realm" target-entity="Realm" inversed-by="duchies">
<join-column name="Realm" referenced-column-name="ID" />
</one-to-one>
</doctrine-mapping>

obviously, the inverse side should be many-to-one and not one-to-one. Interesting bugs in the code resulted. Obviously a coder mistake, but orm:validate-schema should have detected that the association has incompatible mappings.



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

Fixed





[DDC-1544] Interfaces as target entity + event to resolve them to an implementation Created: 17/Dec/11  Updated: 17/Dec/11  Resolved: 17/Dec/11

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

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


 Description   

Idea is:

/**
 * @ManyToOne(targetEntity="UserInterface")
 */

Would fire "onResolveTargetEntity" which is supposed to return details for resolving the interface to an actual implementation.



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

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

Comment by Benjamin Eberlei [ 17/Dec/11 ]

Related Pull Request was closed: https://github.com/doctrine/doctrine2/pull/222

Comment by Benjamin Eberlei [ 17/Dec/11 ]

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

Comment by Benjamin Eberlei [ 17/Dec/11 ]

Related Pull Request was closed: https://github.com/doctrine/doctrine2/pull/223





[DDC-1541] ClassMetadataBuilder has some name discrepancy in calls to AssociationBuilder methods Created: 16/Dec/11  Updated: 17/Dec/11  Resolved: 17/Dec/11

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

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


 Description   

ClassMetadataBuilder class has some methods defined that call methods on AssociationBuilder class by different names, specifically the (set) part . e.g.

ClassMetadataBuilder method addManyToOne, calls setInversedBy, but is defined in AssociationBuilder as inversedBy. This trows a call to undefined method.

Which one is it ?



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

Fixed.





[DDC-1524] NamedQueries annotation doesn't work with just one NamedQuery Created: 09/Dec/11  Updated: 17/Dec/11  Resolved: 17/Dec/11

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

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

Attachments: File AnnotationDriver.php    

 Description   

NamedQueries annotation doesn't work with just one NamedQuery

the problem is locale in the class Doctrine\ORM\Mapping\Driver\AnnotationDriver line 179.

Is needed validate if var $namedQueriesAnnot->value is an array before try perform foreach statement.

Please I'm sorry for my bad English.

Thank you



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

Why dont you define the named queries as array? just @NamedQuery(

{...}

) ?

Also please consider attaching a diff of your patch, not the whole changed class.

Comment by Benjamin Eberlei [ 17/Dec/11 ]

Added better validations.





[DDC-1536] GH-213: QueryBuilder::getQuery Created: 13/Dec/11  Updated: 14/Dec/11  Resolved: 14/Dec/11

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

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


 Description   

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

Hi there,
I'm wondering myself if the QueryBuilder::getQuery is a good method name.
Actually, a getMethodObject makes me think that I can use many times the getMethodObject and work with the same object.
e.g :

```php
$qb->getQuery()->useResultCache (true);
$qb->getQuery()->execute();
```
In my code, the problem is that getQuery return a new instance of Query each time that I call getQuery.
Furthermore, the getQuery method invoke a createQuery method.

So, maybe the QueryBuiler::getQuery can store a reference to the created Query instance, and if the QueryBuilder::getQuery is call many times without any change return the stored instance.
If the QueryBuilder::getQuery have to generate a new Query, throw an exception or something like that.

Because of a change to QueryBuilder::createQuery is a major change, I don't think that It could be the solution, but it's a reflexion around this.

What do you think about that ?



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

This includes a BC break.
Marking as won't fix.





[DDC-1537] GH-214: Fixed typo in the XmlDriver Created: 13/Dec/11  Updated: 14/Dec/11  Resolved: 14/Dec/11

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

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


 Description   

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



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

Merged





[DDC-1531] Documentation references no-longer available constant Lexer::T_ABS Created: 13/Dec/11  Updated: 14/Dec/11  Resolved: 14/Dec/11

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Documentation
Affects Version/s: Git Master
Fix Version/s: 2.2

Type: Documentation Priority: Major
Reporter: Erik Bernhardson Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

Line 645 of https://github.com/doctrine/orm-documentation/blob/master/en/reference/dql-doctrine-query-language.rst

Best i can tell this has been re-named to Lexar::T_IDENTIFIER by looking at other functions in the distribution



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

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





[DDC-979] ArrayHydrator::updateResultPointer() must be an array, string given Created: 12/Jan/11  Updated: 11/Dec/11  Resolved: 11/Dec/11

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

Type: Bug Priority: Major
Reporter: Van Hauwaert Bert Assignee: Guilherme Blanco
Resolution: Won't Fix Votes: 0
Labels: None
Environment:

MySQL - Ubuntu


Attachments: File DDC979Test.php    

 Description   

I have the following MySQL tables + data

CREATE TABLE `agent` (
  `agentID` bigint(20) NOT NULL AUTO_INCREMENT,
  `company` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`agentID`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8 COMMENT='module=agent';

CREATE TABLE `file` (
  `fileID` bigint(20) NOT NULL AUTO_INCREMENT,
  `filename` varchar(100) DEFAULT NULL,
  `mimetype` varchar(100) DEFAULT NULL,
  `extension` varchar(5) DEFAULT NULL,
  `path` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`fileID`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8 COMMENT='module=agent';

CREATE TABLE `agentFile` (
  `agentID` bigint(20) NOT NULL COMMENT 'orderBy=orderNr&order=asc',
  `fileID` bigint(20) NOT NULL,
  `orderNr` int(11) DEFAULT NULL,
  PRIMARY KEY (`agentID`,`fileID`),
  KEY `agentFileAgent` (`agentID`),
  KEY `agentFileFile` (`fileID`),
  CONSTRAINT `agentFileAgent` FOREIGN KEY (`agentID`) REFERENCES `agent` (`agentID`) ON DELETE CASCADE ON UPDATE NO ACTION,
  CONSTRAINT `agentFileFile` FOREIGN KEY (`fileID`) REFERENCES `file` (`fileID`) ON DELETE CASCADE ON UPDATE NO ACTION
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='module=agent';


INSERT INTO `agent` (agentID,company) VALUES (1,'Company 1');
INSERT INTO `agent` (agentID,company) VALUES (2,'Company 2');
INSERT INTO `file` (fileID,filename,mimetype,extension,path) VALUES (1,'logoCompany2',NULL,NULL,NULL);
INSERT INTO `agentFile` (agentID,fileID,orderNr) VALUES (2,1,0);

Everything works fine if I do the following:

$query = $em->createQuery('SELECT a, af, f FROM Agent_Model_Agent a LEFT JOIN a._agentFileRefAgent af WITH af._orderNr=0 LEFT JOIN af._file f');
$results = $query->getResult();

But I get an error when I replace getResult with getArrayResult.

$query = $em->createQuery('SELECT a, af, f FROM Agent_Model_Agent a LEFT JOIN a._agentFileRefAgent af WITH af._orderNr=0 LEFT JOIN af._file f');
$results = $query->getArrayResult();

Error:

Catchable fatal error: Argument 1 passed to Doctrine\ORM\Internal\Hydration\ArrayHydrator::updateResultPointer() must be an array, string given, called in /var/www/vhost/issue/htdocs/externals/Doctrine/lib/Doctrine/ORM/Internal/Hydration/ArrayHydrator.php on line 150 and defined in /var/www/vhost/issue/htdocs/externals/Doctrine/lib/Doctrine/ORM/Internal/Hydration/ArrayHydrator.php on line 207
0.2773	12011956	Doctrine\ORM\AbstractQuery->getArrayResult( )	../IndexController.php:18
0.2773	12012164	Doctrine\ORM\AbstractQuery->execute( )	../AbstractQuery.php:378
0.3262	12217064	Doctrine\ORM\Internal\Hydration\AbstractHydrator->hydrateAll( )	../AbstractQuery.php:527
0.3263	12199568	Doctrine\ORM\Internal\Hydration\ArrayHydrator->_hydrateAll( )	../AbstractHydrator.php:99
0.3276	12219368	Doctrine\ORM\Internal\Hydration\ArrayHydrator->_hydrateRow( )	../ArrayHydrator.php:62
0.3277	12223840	Doctrine\ORM\Internal\Hydration\ArrayHydrator->updateResultPointer( )	../ArrayHydrator.php:150


 Comments   
Comment by Guilherme Blanco [ 16/Aug/11 ]

Could you please include your Model mappings too?

Comment by Guilherme Blanco [ 11/Dec/11 ]

Hi,

This special situation is not really possible.
You are not allowed to create a cross-reference Entity without defining an own @Id.
The situation you exposed here is due to it. Issue was left open but now after some tests it can be closed. In 2.2-DEV we added a better explanation for your problem, I hope the message is clear enough for you:

Entity of type Doctrine\Tests\ORM\Functional\Ticket\DDC979AgentFile has identity through a foreign entity Doctrine\Tests\ORM\Functional\Ticket\DDC979Agent, however this entity has no identity itself. 
You have to call EntityManager#persist() on the related entity and make sure that an identifier was generated before trying to persist 'Doctrine\Tests\ORM\Functional\Ticket\DDC979AgentFile'. 
In case of Post Insert ID Generation (such as MySQL Auto-Increment or PostgreSQL SERIAL) this means you have to call EntityManager#flush() between both persist operations.

Marking the issue as won't fix.

Comment by Guilherme Blanco [ 11/Dec/11 ]

Added the testcase I have used.





[DDC-609] Refactor ComparisonExpression grammar rule Created: 24/May/10  Updated: 10/Dec/11  Resolved: 10/Dec/11

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

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


 Description   

ComparisonExpression has a lot of alternatives to choose from and it is simply difficult to make the decision without backtracking, only lookahead.



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

Done with current refactorings





[DDC-1523] Coalesce() does not work with functions Created: 09/Dec/11  Updated: 10/Dec/11  Resolved: 10/Dec/11

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

Type: Bug Priority: Major
Reporter: Martin Prebio Assignee: Guilherme Blanco
Resolution: Invalid Votes: 0
Labels: None


 Description   

I wanted to use COALESCE in DQL with a function (e.g. CURRENT_TIMESTAMP()). If I run this DQL, I receive a syntax error exception like this one:

montbook:marlow mprebio$ php scripts/doctrine.php orm:run-dql "select COALESCE(CURRENT_TIMESTAMP()) from Project\Entity\User user"

[Doctrine\ORM\Query\QueryException]
[Syntax Error] line 0, col 33: Error: Expected Doctrine\ORM\Query\Lexer::T_CLOSE_PARENTHESIS, got '('

I've traced this error to Doctrine\ORM\Parser::ScalarExpression() which tries to interpret the current_timestamp function as a SimpleArithmeticExpression or as a StateFieldPathExpression (first if). As far as I understand this part of the parser, the function call should lead to the if part with $this->_isFunction(). Therefore I added a "and !$this->_isFunction()" to the first if clause. After this change everything works as expected: The above query returns the current timestamp (many times because of the from since DQL needs a from part).

Reordering the ifs should work too.



 Comments   
Comment by Martin Prebio [ 09/Dec/11 ]

Also the documentation at http://www.doctrine-project.org/docs/orm/2.1/en/ only mentions COALESCE in the EBNF but not in the real documentation part. At first I thought that Doctrine doesn't support coalesce at all.

Comment by Guilherme Blanco [ 10/Dec/11 ]

COALESCE does not exist on 2.1.
COALESCE is a 2.2-DEV, so use latest master.

Marking as invalid, since we won't change 2.1 to support this.





[DDC-638] Extend SqlWalker Created: 14/Jun/10  Updated: 09/Dec/11  Resolved: 09/Dec/11

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

Type: Improvement Priority: Trivial
Reporter: Scott Morken Assignee: Guilherme Blanco
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

I needed to extend SqlWalker for a custom output walker and all the vars are private instead of protected. Easy fix if it is intended to be extendable and I was supposed to be extending SqlWalker.



 Comments   
Comment by Benjamin Eberlei [ 19/Jun/10 ]

Don't all the private variables have getter and setter methods to modify them?

Btw, can you explain your use-case a little bit more? This would greatly help to find solutions to the issue.

Comment by Scott Morken [ 21/Jun/10 ]

They do have getter and setter methods, but privates don't show up at all in a class that extends the base class. SqlWalker works great if it's not meant to be extended.

Sure, I was using HINT_CUSTOM_OUTPUT_WALKER to point to an extended version of SqlWalker to strip some joins off of a query (in the SqlWalker::walkFromClause() method) that I cloned from the base query I was using. Something like...
SELECT id FROM table
LEFT JOIN table1 table1.table_id = table.id
ORDER BY field1
I wanted just the ids without the joins for the cloned query so the easiest thing I could think of was to override SqlWalker with the HINT_CUSTOM_OUTPUT_WALKER and strip the joins in ::walkFromClause(). I was also thinking about removing the order by but it didn't seem to have much impact on performance, but if I had, it would have been the same way, although I think that one would be removable via a HINT_CUSTOM_TREE_WALKER? I didn't really look into that part. I know my use-case is pretty specific and won't apply to 99.9% of people out there.

There's a good chance I misunderstood how you guys wanted the HINT_CUSTOM_OUTPUT_WALKER to work, but it seemed to me like it would be easiest to use it to extend SqlWalker and that worked great once I changed the privates to protected

Comment by Roman S. Borschel [ 21/Jun/10 ]

@"... and that worked great once I changed the privates to protected"

Until the next refactoring This is heavily "moving" code and I don't think we want to take care of the backwards compatibility issues with making them protected. You were right in assuming that currently SQLWalker is not meant to be extended, implementing TreeWalker directly with a custom walker. I do see that it can be a valid use-case but the problem is that this will cause quite some burden on backwards compatibility because this code tends to change a lot.

Comment by Scott Morken [ 21/Jun/10 ]

Sounds good to me. As always, thanks!!

Comment by Guilherme Blanco [ 09/Dec/11 ]

As previously defined, SqlWalker is not meant to be extended.

If user wants to create a customized output, he must provide his own customOutputWalker entirely implemented.
SqlWalker is a place of heavy implementation, one of the core functionalities ans it tends to restrict a lot our possible fixes because internal API is always changing.

Cheers,





[DDC-1508] ClassMetadataBuilder only accepts ClassMetadata not *Info Created: 23/Nov/11  Updated: 09/Dec/11  Resolved: 09/Dec/11

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

Type: Bug Priority: Minor
Reporter: Benjamin Eberlei Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


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

Fixed since https://github.com/doctrine/doctrine2/commit/0febf0611439e05abbb1bf4b4e9668f7ad125c67





[DDC-1293] Update DQL function signature in documentation Created: 25/Jul/11  Updated: 09/Dec/11  Resolved: 09/Dec/11

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

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


 Description   

The documentation concerning the new DQL Date functions is outdated, as the 'unit' of the interval is not described.

 
DATE_ADD(date, days) - Add the number of days to a given date.
DATE_SUB(date, days) - Substract the number of days from a given date.

Should be

 
DATE_ADD(date, interval, unitOfInterval)

for example:

 
DATE_ADD(CURRENT_DATE(), 1, 'DAY');
DATE_SUB(CURRENT_DATE(), 4, 'MONTH');

UPDATE: it appears parameters are not injected properly when using the DATE functions:

 
$qb->where("x._lastMutationDateTime < DATE_ADD(CURRENT_DATE(),?1,'day')");
$qb->setParameter(1, 5);

Results in:

//DQL
SELECT x FROM Entity p WHERE x._lastMutationTimestamp < DATE_ADD(CURRENT_DATE(),?1,'day')
//SQL:
SELECT x0_.id AS id0, x0_.last_mutation_timestamp AS last_mutation_timestamp1
WHERE x0_.last_mutation_timestamp < DATE_ADD(CURRENT_DATE, INTERVAL 0 DAY)


 Comments   
Comment by Benjamin Eberlei [ 27/Aug/11 ]

Marked as bug

Comment by Guilherme Blanco [ 09/Dec/11 ]

This issue was already fixed, maybe docs should be regenerated.
Marking as fixed for now.





[DDC-1295] Sandbox Sample Code which shall go into cli-config.php and index.php for EntityManager working with yaml is wrong Created: 25/Jul/11  Updated: 09/Dec/11  Resolved: 09/Dec/11

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

Type: Documentation Priority: Major
Reporter: Sven Zahrend Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None
Environment:

LINUX doctrine2.git



 Description   

In http://www.doctrine-project.org/docs/orm/2.1/en/tutorials/getting-started-xml-edition.html
in Section: Obtaining the EntityManager
the Code:

//$driverImpl = new Doctrine\ORM\Mapping\Driver\XmlDriver(_DIR_."/config/mappings/xml");
$driverImpl = new Doctrine\ORM\Mapping\Driver\XmlDriver(_DIR_."/config/mappings/yml");
//$driverImpl = $config->newDefaultAnnotationDriver(_DIR_."/entities");

produces:

PHP Fatal error: Class 'Sandbox\Doctrine\ORM\Mapping\Driver\XmlDriver' not found in ..

Should be corrected to:
$driverImpl = new \Doctrine\ORM\Mapping\Driver\XmlDriver(_DIR_."/config/mappings/yml");

produces:

PHP Fatal error: Uncaught exception 'Doctrine\ORM\Mapping\MappingException' with message 'No mapping file found named 'Entities.User.dcm.xml' ..

Should be corrected to:
$driverImpl = new \Doctrine\ORM\Mapping\Driver\YamlDriver(_DIR_."/config/mappings/yml");

and finally, following the xml yaml Entities folder structure in the sandbox, should be corrected to:

$driverImpl = new \Doctrine\ORM\Mapping\Driver\YamlDriver(_DIR_."/yaml");

With this configuration I was able to create Entities from yaml through these commands:

  1. doctrine orm:generate-entities ./
  2. doctrine orm:schema-tool:create


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

This issue was already solved in 2.2....
The tutorial code changed due to the new support introduced in 2.2, so I'm marking as fixed and assigning to this middle point version.

Cheers,





[DDC-1057] The methods of ResultSetMapping should return the current object Created: 04/Mar/11  Updated: 07/Dec/11  Resolved: 07/Dec/11

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

Type: Improvement Priority: Minor
Reporter: Ota Mares Assignee: Fabio B. Silva
Resolution: Fixed Votes: 0
Labels: None


 Description   

The ResultSetMapping class methods should return the current object, so that a fluent interface is provided. Its just a minor issues but makes the class more pleasant to use.



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

Fixed since this commit https://github.com/doctrine/doctrine2/commit/33c5b639b04169f9520910da0d25508754d32b6b





[DDC-1170] XML Mapping : add attribute "column-definition" for tag "id" Created: 26/May/11  Updated: 05/Dec/11  Resolved: 05/Dec/11

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

Type: New Feature Priority: Minor
Reporter: Nicolas C Assignee: Fabio B. Silva
Resolution: Fixed Votes: 0
Labels: None
Environment:

Linux, Doctrine ORM 2.0.3 on Symfony2, MySQL.



 Description   

XML mapping :

<id name="id" type="integer">
      <generator strategy="IDENTITY"/>
</id>

Generate SQL :

id int auto_increment not null

It's not possible with XML mapping to have :

 id int UNSIGNED not null auto_increment

Because tag "id" doesn't support "column-definition" attribute.
We can have same problem for others types parameters.

I suggest this solution : in file <Doctrine/ORM/Mapping/Driver/XmlDriver.php>

// add this code to line 226 ( in the "Evaluate <id ...>" bloc after the array "mapping" )  :

if(isset($idElement['column-definition'])){
                $mapping['columnDefinition'] = (string)$idElement['column-definition'];
}

New XML mapping :

<id name="id" type="integer" column="id" column-definition="INT unsigned NOT NULL" >
      <generator strategy="IDENTITY"/>
</id>

Warning : "column-definition" must not contains "AUTO_INCREMENT" (added automaticly) :

<id name="id" type="integer" column="id" column-definition="INT unsigned NOT NULL AUTO_INCREMENT" >
      <generator strategy="IDENTITY"/>
</id>

With "AUTO_INCREMENT" in column-definition all foreign keys contain this parameter.



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

Fixed since this commit: https://github.com/doctrine/doctrine2/commit/eaec259186b7f19a22b7632f30ea4d1ee94705f2





[DDC-1472] WHERE <<function>> IN ... doesn't work Created: 06/Nov/11  Updated: 04/Dec/11  Resolved: 04/Dec/11

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

Type: Bug Priority: Minor
Reporter: Christoph Krämer Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

I have a query which is supposed to compare a result of a user defined function with a set of possible results
SELECT ... WHERE YEAR(w.date) IN (.......)

But I get the error:
[Syntax Error] line 0, col 49: Error: Expected Doctrine\ORM\Query\Lexer::T_IN, got '('

If I only compare the result of the function with a single value everything works as aspected:
SELECT ... WHERE YEAR(w.date) = 2011
.. works!

I also testet it with other functions like DATE_DIFF, etc. but always get the same error.



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

Fixed in master since this commit: https://github.com/doctrine/doctrine2/commit/0380d5ae580dcbefd63051028fc1ab78599fda6c





[DDC-1416] bug in simple test with sub query Created: 13/Oct/11  Updated: 04/Dec/11  Resolved: 04/Dec/11

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

Type: Bug Priority: Major
Reporter: waldo Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None
Environment:

Linux/Ubuntu 10.10 PHP 5.3.3-1ubuntu9.5



 Description   

For exemple :

$query = $em->createQuery("SELECT * FROM address WHERE :aValue IN (1, 2, 3, 4, 5, 6, 7, 8, 9, 10)");
$query->getQuery()->getSQL();

Doctrine throw that error : Doctrine\ORM\Query\QueryException: [Semantical Error] line 0, col xxx near ':aValue': Error: ':aValue' is not defined.

But in SQL this type of request is posible.



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

Fixed in trunk: https://github.com/doctrine/doctrine2/commit/0380d5ae580dcbefd63051028fc1ab78599fda6c





[DDC-1073] Refactor SqlWalker::walkGroupByItem not to use PathExpression anymore but accept strings (identification variable) aswell Created: 20/Mar/11  Updated: 04/Dec/11  Resolved: 04/Dec/11

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

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

Issue Links:
Reference
is referenced by DDC-1053 GROUP BY crashes Doctrine 2 Resolved

 Description   

Due to DDC-1053 the code in SqlWalker::walkGroupByClause and ::walkGroupByItems() is not as nice as it could be. This is because of the PathExpression type hint.



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

Issue was resolved by this commit: https://github.com/doctrine/doctrine2/commit/2642daa43851878688d01625f272ff5874cac7b2





[DDC-1457] Wrong return annotation for UnitOfWork::getEntityPersister() method Created: 26/Oct/11  Updated: 04/Dec/11  Resolved: 04/Dec/11

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

Type: Documentation Priority: Minor
Reporter: Aigars Gedroics Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

It is

@return Doctrine\ORM\Persisters\AbstractEntityPersister

should be (I suppose)

@return \Doctrine\ORM\Persisters\BasicEntityPersister

or

@return Persisters\BasicEntityPersister


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

Fixed in trunk

Commit ref: https://github.com/doctrine/doctrine2/commit/a26990c3e8693134a2789c4c7c57d6f053f01fcf





[DDC-1236] GROUP BY does not work with functions Created: 29/Jun/11  Updated: 02/Dec/11  Resolved: 02/Dec/11

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

Type: Improvement Priority: Major
Reporter: Andreas Hörnicke Assignee: Guilherme Blanco
Resolution: Fixed Votes: 4
Labels: None


 Description   

The following query fails with Cannot group by undefined identification variable (yes CAST-Function was added). Would be nice to have such a feature,

SELECT ...
FROM Task t
...
WHERE
  ...
GROUP BY
  CAST(t.scheduledDate as date)


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

This is documented in the EBNF of DQL that this not works.

Marked as improvement.

Comment by Wladimir Coka [ 18/Oct/11 ]

Is there any workaround?

Comment by Andreas Hörnicke [ 18/Oct/11 ]

Using a native query is a workaround.

Comment by Benjamin Eberlei [ 18/Oct/11 ]

There is another workaround that should work:

SELECT ...,   CAST(t.scheduledDate as date) AS castedDate
FROM Task t
...
WHERE
  ...
GROUP BY
castedDate
Comment by Wladimir Coka [ 18/Oct/11 ]

I tried this:

SELECT ... ,MONTH(t.fechaCreacion) as mes 
FROM Tramite t 
...
WHERE 
... 
GROUP BY 
mes 

But I get this error:

Message: [Semantical Error] line 0, col 202 near 'mes ': Error: 'mes' does not point to a Class.

Comment by Benjamin Eberlei [ 18/Oct/11 ]

Then only native query is a workaround for now

We work on this for 2.2

Comment by Wladimir Coka [ 18/Oct/11 ]

Ok I'll need to move my code to native query... Hope you can fix this with 2.2 or earlier ... Thanks

Comment by Alex Barnes [ 03/Nov/11 ]

BTW I have put in a fix and so far have had no issues.... but this should be considered hack as I'm not very familiar with the internal workings of Doctrine.

See doctrine-dev groups:
https://groups.google.com/d/topic/doctrine-dev/QZMMnYV4V_8/discussion

HTH

Alex

Comment by Guilherme Blanco [ 02/Dec/11 ]

Since this commit: https://github.com/doctrine/doctrine2/commit/2642daa43851878688d01625f272ff5874cac7b2
This issue is solved through the SelectExpression + Hidden + ResultVariable refer.

SELECT 
    ..., CAST(t.scheduledDate as date) AS HIDDEN groupDate
FROM Task t
    ...
WHERE
    ...
GROUP BY
    groupDate




[DDC-1517] find/getReference break on invalid or missing identifier fields Created: 01/Dec/11  Updated: 01/Dec/11  Resolved: 01/Dec/11

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

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





[DDC-1502] SQLite should eat prefixed tables (since they dont exist) Created: 21/Nov/11  Updated: 21/Nov/11  Resolved: 21/Nov/11

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

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


 Description   

People use schema or many databases, however SQLite does not support the foo.bar syntax, so there is no way to run the tests in sqlite memory against these setups.



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

Implemented





[DDC-1448] Add a base entity to allow users to skip writing boilerplate code Created: 22/Oct/11  Updated: 19/Nov/11  Resolved: 19/Nov/11

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

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


 Description   

For forward compatibility with https://gist.github.com/1034079 we want to add a "BaseEntity" into the core that handles boilerplate code through implementing "__call" and using the metadata to generate getter/setter/adder/is methods on the fly.



 Comments   
Comment by Alexander [ 30/Oct/11 ]

Had some discussion about this on IRC:

  • the BaseEntity shouldn't do __callStatic since there are already repositories that do stuff like this
  • for php 5.3 it would be shipped as a class that can be extended
  • maybe some task that generates the trait from the class or the other way around
Comment by Benjamin Eberlei [ 19/Nov/11 ]

Implemented in Doctrine\Common\Persistence\PersistentObject.

This can be generically used by all ObjectManagers.





[DDC-1442] SimpleObject hydratation mode with inheritance Created: 20/Oct/11  Updated: 18/Nov/11  Resolved: 18/Nov/11

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

Type: Bug Priority: Minor
Reporter: Thomas Tourlourat - Armetiz Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

SimpleObject hydratation mode with inheritance, it appear that it's not working.

The problem start in SimpleObjectHydrator.php line 129 when calling UnitOfWork->createEntity(NULL, Array, Array).



 Comments   
Comment by Benjamin Eberlei [ 20/Oct/11 ]

in what context are you using simpleobjecthydrator?

Comment by Thomas Tourlourat - Armetiz [ 20/Oct/11 ]

It was just for testing this feature.

I have build this queryBuilder :

$queryBuilder	= $entityManager->createQueryBuilder();
$queryBuilder->select ("user");
$queryBuilder->from ("Entity\User", "user");
$queryBuilder->where ("user.idUser = 916");
$queryBuilder->getQuery()->execute (array(), \Doctrine\ORM\AbstractQuery::HYDRATE_SIMPLEOBJECT);

Entity\User extends an other Entity.

Comment by Benjamin Eberlei [ 27/Oct/11 ]

Can you maybe show how the User and Other entity are mapped? It seems your discriminator map could contain a problem, i couldnt reproduce it with our Joined Table Inheritance test entities so far.

Comment by Alexander [ 08/Nov/11 ]

Lowered the priority of this issue until we receive more feedback.

Comment by Benjamin Eberlei [ 18/Nov/11 ]

This was fixed recently by throwing an error message telling the user that his discriminator mapping is wrong.





[DDC-1417] entity generator does not support nullable relationship Created: 13/Oct/11  Updated: 18/Nov/11  Resolved: 18/Nov/11

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Tools
Affects Version/s: 2.1.2
Fix Version/s: 2.2

Type: Bug Priority: Minor
Reporter: Marcel Dejean Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

With a nullable relationship, e.g.

  manyToOne:
    bar:
      targetEntity: Bar
      joinColumns:
        bar_id:
          referencedColumnName: id
          nullable: true

the setter generated for the relationship

   public function setBar(\Acme\FooBarBundle\Entity\Bar $bar)
    {
        $this->bar = $bar;
    }

can not take null as an argument.

It should generate

    public function setBar(\Acme\FooBarBundle\Entity\Bar $bar = null)
    {
        $this->bar = $bar;
    }


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

This was fixed in a recent PR.





[DDC-1430] GROUP BY $alias in Oracle Created: 18/Oct/11  Updated: 18/Nov/11  Resolved: 18/Nov/11

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

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

Linux 64bits + Oracle 11g



 Description   

When creating a query with the QueryBuilder, the groupBy with only the alias doesn't work as expected.

It creates the group by with the ID only, but Oracle need all the fields to work.

The ORA-00979: not a GROUP BY expression error is returned.

From my SlotRepository I do:

$query = $this->createQueryBuilder('s')
    ->select('s, COUNT(a.id) AS agendas_count')
    ->leftJoin('s.agenda_slots', 'l')
    ->leftJoin('l.agenda', 'a')
    ->groupBy('s')
;

The SQL generated is:

SELECT s0_.id AS id0, s0_.hour_start AS hour_start1, s0_.hour_end AS hour_end2, s0_.active AS active3, COUNT(a1_.id) AS sclr4 FROM slot s0_ LEFT JOIN agenda_slot a2_ ON s0_.id = a2_.slot_id LEFT JOIN agenda a1_ ON a2_.agenda_id = a1_.id GROUP BY s0_.id

The SQL expected is:

SELECT s0_.id AS id0, s0_.hour_start AS hour_start1, s0_.hour_end AS hour_end2, s0_.active AS active3, COUNT(a1_.id) AS sclr4 FROM slot s0_ LEFT JOIN agenda_slot a2_ ON s0_.id = a2_.slot_id LEFT JOIN agenda a1_ ON a2_.agenda_id = a1_.id GROUP BY s0_.id, s0_.hour_start, s0_.hour_end, s0_.active

As workaround I include all fields manually.

Thank you,
Juan Manuel



 Comments   
Comment by Juan M [ 15/Nov/11 ]

Fabio: If you have any questions or you can't reproduce the problem, let me know.

Comment by Fabio B. Silva [ 15/Nov/11 ]

Thanks Juan,

I think I understand your problem,
I created one PR with a possible solution in github

Comment by Benjamin Eberlei [ 15/Nov/11 ]

To add to this, although i merged the PR i am not sure if this is enough.

SELECT u FROM User u GROUP BY u

I think there will be a problem if User has foreign keys, because they appear in the SELECT clause, but not in the GROUP BY.

Comment by Fabio B. Silva [ 15/Nov/11 ]

Are you right Benjamin,

I'm testing with the following dql :


SELECT u FROM Doctrine\Tests\Models\CMS\CmsUser u GROUP BY u
SELECT c0_.id AS id0, c0_.status AS status1, c0_.username AS username2, c0_.name AS name3, c0_.email_id AS email_id4 FROM cms_users c0_ GROUP BY c0_.id, c0_.status, c0_.username, c0_.name


SELECT e FROM Doctrine\Tests\Models\CMS\CmsEmployee e GROUP BY e
SELECT c0_.id AS id0, c0_.name AS name1, c0_.spouse_id AS spouse_id2 FROM cms_employees c0_ GROUP BY c0_.id, c0_.name

What you thing about iterate Association Mappings to get foreign keys?

Comment by Benjamin Eberlei [ 15/Nov/11 ]

yes the code has to behave exactly like the select clause generation. Maybe even use that code (if thats possible).

Comment by Benjamin Eberlei [ 18/Nov/11 ]

fixed





[DDC-1447] <orphan-removal /> BC? Created: 22/Oct/11  Updated: 15/Nov/11  Resolved: 15/Nov/11

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

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


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

This is not a bc, <orphan-removal /> was invalid all along, <n-to-m orphan-removal="true/false" /> is defined in the XSD mapping.





[DDC-1452] ObjectHydrator bug: hydration of entity with self (cyclic) relation through ref entity Created: 24/Oct/11  Updated: 15/Nov/11  Resolved: 14/Nov/11

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.1, 2.1.1, 2.1.2
Fix Version/s: 2.2
Security Level: All

Type: Bug Priority: Critical
Reporter: Piotr Śliwa Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None

Attachments: File DDC1452Test.php     File DDC1452Test.php    

 Description   

ObjectHydrator has bug in hydrate entities with relation to entity of this same class throught reference entity. Example Model:

EntityA

  • id
  • title (string)
  • entitiesB (annotation: @ORM\OneToMany(targetEntity="EntityB", mappedBy="entityAFrom"))

EntityB

  • id
  • entityAFrom (annotation: @ORM\ManyToOne(targetEntity="EntityA", inversedBy="entitiesB"))
  • entityATo (annotation: @ORM\ManyToOne(targetEntity="EntityA"))
  • type (string)

Scenario:

Execution of dql query 'SELECT a, b, ba FROM EntityA AS a LEFT JOIN a.entitiesB AS b LEFT JOIN b.entityATo AS ba' with max results set to "1" and data in database:

EntityATable:
id | title
1 | a
2 | b

EntityBTable:
id | entityAFromId | entityAToId | type
1 | 1 | 2 | type

Resume:

I expected collection of EntityA object (size=1 becouse I set max results to 1) with hydrated entitiesB collection (size=1 becouse in db is only 1 record) and hydrated entityTo object. entitiesB property of entityTo object should be empty PersistCollection (ready to lazy load) but is null...

I can provide TestCase for this issue.



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

Attached a working testcase.

Please put it into tests/Doctrine/Tests/ORM/Functional/Ticket and run:

phpunit --group DDC-1452

Please make that test fail from your perspective, i think it reproduces your test-case exactly.

Comment by Piotr Śliwa [ 29/Oct/11 ]

Ok, I have fixed testcase to situation that I was talking about.

I have hardly debuged this issue, problem is in ObjectHydrator::_getEntity() method. This method delegates to UnitOfWork::createEntity() and passes $hints array. In $hints array, data about fetching associations is stored. In situation when one entity is joined throught two different associations (as in this testcase, first time DDC1452EntityA is used in from clause, second time in join clause) hydrator "minds" that objects from second association have have loaded association that is connecting entities of the same type. In testcase this is "entitiesB" association of "ba" aliased entity. That occurs, becouse $hints['fetched']['Namespace\DDC1452EntityA']['entitiesB'] has already been set on true while hydrating DDC1452EntityA objects from "FROM" clause. If in testcase had not been set limit for results, then this test would have to pass, becouse second object of DDC1452EntityA ($a2) would have to be load propertly as entity from "FROM" clause.

Comment by Benjamin Eberlei [ 29/Oct/11 ]

The explaination makes sense. I will dig into it.

Comment by Benjamin Eberlei [ 14/Nov/11 ]

This is fixed, but only in master. The code change necessary was pretty serious so i dont want to merge it into the stable branch without more people testing it.

Comment by Piotr Śliwa [ 15/Nov/11 ]

Great job, thanks!





[DDC-1492] Fatall error: Cannot use object as array in ORM\Internal\Hydration\ObjectHydrator.php on line 314 Created: 13/Nov/11  Updated: 15/Nov/11  Resolved: 15/Nov/11

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

Type: Bug Priority: Blocker
Reporter: Konstantin Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None
Environment:

Symfony2, Doctrine 2.1.1 (also bug present on 2.1.3-dev - latest revison of 2.1.x branch)



 Description   

My entities

event
eveht.event_area_id=event_area.id (1:1)
event_area.event_id=event.id (1:1)
event_area.area.id=area.id (one area has many event_area's)
area.parent_id=area_id (hierarchial)
event.author_id=user.id (one user has many events)

area - STI: District/City/Region/Country/etc.

SELECT
	r, ra, a, ap, au, DATE(r.eventTime) AS event_date
FROM OloloEventsBundle:Event r
	LEFT JOIN r.eventArea ra
		LEFT JOIN ra.area a
			LEFT JOIN a.parent ap
	INNER JOIN r.author au WHERE r.eventTime <= :r_eventtime AND ra.area IN(:ra_area)
GROUP BY r
ORDER BY event_date DESC

This DQL caused an error "Cannot use object of type District as array in ORM\Internal\Hydration\ObjectHydrator.php on line 314". When I'm removing `ap` friom fetching - it works. Mapping are correct - there are many other places where it works correctly.



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

On 2.1.1 line 314 is a "}". Can you restate the line and add a stack trace if possible (xdebug or phpunit can help there).

Comment by Konstantin [ 13/Nov/11 ]

Sorry, line was changed cause I've updated to 2.1.3-dev.

( ! ) Fatal error: Cannot use object of type Ololo\Bundle\TerritorialBundle\Entity\District as array in Z:\home\dev\Ololo\code\vendors\Doctrine\Orm\lib\Doctrine\ORM\Internal\Hydration\ObjectHydrator.php on line 308
Call Stack
#	Time	Memory	Function	Location
1	0.0006	333520	{main}( )	..\index_dev.php:0
2	0.0254	1435584	Symfony\Component\HttpKernel\Kernel->handle( )	..\index_dev.php:20
3	0.2454	3634168	Symfony\Bundle\FrameworkBundle\HttpKernel->handle( )	..\Kernel.php:171
4	0.2454	3634576	Symfony\Component\HttpKernel\HttpKernel->handle( )	..\HttpKernel.php:44
5	0.2454	3634576	Symfony\Component\HttpKernel\HttpKernel->handleRaw( )	..\HttpKernel.php:71
6	0.3589	5534264	call_user_func_array ( )	..\HttpKernel.php:117
7	0.3590	5534448	Ololo\Bundle\DistrictsBundle\Controller\DistrictController->EventsPastAction( )	..\HttpKernel.php:0
8	1.1606	13782464	Ololo\Bundle\EventsBundle\Entity\EventRepository->getPastEventsByAreasIds( )	..\DistrictController.php:145
9	1.1607	13783520	Ololo\Bundle\EventsBundle\Entity\EventRepository->getEventsSliceBySpecification( )	..\EventRepository.php:385
10	1.2010	14224216	Doctrine\ORM\AbstractQuery->getResult( )	..\EventRepository.php:477
11	1.2010	14224368	Doctrine\ORM\AbstractQuery->execute( )	..\AbstractQuery.php:392
12	3.3409	14781264	Doctrine\ORM\Internal\Hydration\AbstractHydrator->hydrateAll( )	..\AbstractQuery.php:594
13	3.3412	14785824	Doctrine\ORM\Internal\Hydration\ObjectHydrator->_hydrateAll( )	..\AbstractHydrator.php:99
14	3.3413	14798576	Doctrine\ORM\Internal\Hydration\ObjectHydrator->_hydrateRow( )	..\ObjectHydrator.php:140
                    $parentObject = $this->_resultPointers[$parentAlias][key($first)]; // trouble here, $this->_resultPointers[$parentAlias] is object of District
Comment by Guilherme Blanco [ 14/Nov/11 ]

Hi.

If you change this line:

$parentObject = $this->_resultPointers[$parentAlias][key($first)];

To this:

$parentObject = $first[key($first)];

Does it work for you?

Comment by Konstantin [ 14/Nov/11 ]

yes, with this line of code this query works.

Comment by Guilherme Blanco [ 15/Nov/11 ]

https://github.com/doctrine/doctrine2/commit/77e076f1fdbe24fdb2f5a1fb1842c0b9cb7d95a4

This issue was fixed in master.
I requested Benjamin to merge this with 2.1 branch.

Thanks





[DDC-1404] Named Queries not inherited in JOINED Inheritance Created: 06/Oct/11  Updated: 14/Nov/11  Resolved: 14/Nov/11

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

Type: Bug Priority: Minor
Reporter: Rafael Dohms Assignee: Fabio B. Silva
Resolution: Fixed Votes: 0
Labels: None


 Description   

When using the JOINED Inheritance (@ORM\InheritanceType("JOINED")) any Named Queries defined in the parent entity are not recognized by the repositories of the children.

So if we have ParentEntity as the parent and ChildEntity a class that extends ParentEntity in table inheritance also. Accessing the ChildEntityRepository and asking for a named query defined via annotation in ParentEntity results in "query does not exist"



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

Merged





[DDC-1476] Yaml Driver doesn't default field types to string Created: 08/Nov/11  Updated: 14/Nov/11  Resolved: 14/Nov/11

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

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

All



 Description   

Doctrine documentation states that a field default value is a string.
The annotation driver behaves so but the Yaml driver doesn't.

The Yaml driver requires that a field is set a type explicitly.

Why is this different among drivers and what is the actual default behaviour?



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

Merged





[DDC-1424] Make order in DQL SELECT clause matter for hydration Created: 16/Oct/11  Updated: 14/Nov/11  Resolved: 14/Nov/11

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

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

Issue Links:
Reference
is referenced by DDC-1096 "You may have observed that in a mixe... Resolved

 Description   

The order of the DQL Select clause should matter for the result hydration:

SELECT u.id, u, u.name FROM User u => result keys: id, 1, name
SELECT u.id, u.id FROM User u => result keys: id, or numerical hydration 0, 1
SELECT u.id, u AS user FROM User u => result keys: id, user


 Comments   
Comment by Guilherme Blanco [ 14/Nov/11 ]

Implemented!!!

https://github.com/doctrine/doctrine2/commit/81cc6d9da83d217ea62bd467053fd9885d1083cd





[DDC-1446] Evaluate to configure default "persist cascade" for all enties. Created: 22/Oct/11  Updated: 14/Nov/11  Resolved: 14/Nov/11

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

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


 Description   

.



 Comments   
Comment by Guilherme Blanco [ 14/Nov/11 ]

As we already discussed on IRC, this automation would open a can of worms. It cannot be implemented.





[DDC-1461] Possible Regression with OneToOne relation Created: 31/Oct/11  Updated: 13/Nov/11  Resolved: 13/Nov/11

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

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

Sub-Tasks:
Key
Summary
Type
Status
Assignee
DDC-1506 Possible Regression with OneToOne rel... Sub-task Open Benjamin Eberlei  

 Description   

I have the following relations:

namespace Model;

use Doctrine\ORM\Mapping as ORM;

/**
 * @ORM\Entity(repositoryClass="Model\Repository\UserRepository")
 * @ORM\ChangeTrackingPolicy("DEFERRED_EXPLICIT")
 * @ORM\HasLifecycleCallbacks
 * @ORM\Table(name="users")
 */
class User
{
    /**
     * @ORM\OneToOne(targetEntity="Model\TwitterAccount", orphanRemoval=true, fetch="EAGER", cascade = {"persist"}, inversedBy="user")
     * @var TwitterAccount
     */
    private $twitterAccount;
}

/**
 * @ORM\Entity(repositoryClass = "Model\Repository\TwitterAccountRepository")
 * @ORM\Table(name = "twitter_accounts")
 * @ORM\ChangeTrackingPolicy("DEFERRED_EXPLICIT")
 */
class TwitterAccount
{
    /**
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="AUTO")
     * @ORM\Column(type="integer")
     */
    private $id;

    /**
     * @ORM\OneToOne(targetEntity="Model\User", fetch="EAGER")
     */
    private $user;
}

now when I add a new account, the user-side is not updated with the id of the account, but the account is still saved to the database.

$twitterAccount = new TwitterAccount();
$user->setTwitterAccount($twitterAccount);
$em->persist($user);
$em->flush();

The twitterAccount_id of the users table is empty, but the new account is added to the "twitter_accounts" table with the correct user_id.



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

Do you know when this started to happen ?

Comment by Johannes Schmitt [ 31/Oct/11 ]

I have reverted some commits of the ORM, but it doesn't seem to have happened recently, or it is a combination of different changes in one of the repositories.

What's weird is that the error does not occur when the user is new, but only if it already exists. It seems like somehow the UOW does not detect that it has changed.

Comment by Benjamin Eberlei [ 13/Nov/11 ]

This is deferred explicit related it seems.

Comment by Benjamin Eberlei [ 13/Nov/11 ]

Verified

Comment by Benjamin Eberlei [ 13/Nov/11 ]

Hm no, it works for me.

See https://github.com/doctrine/doctrine2/commit/e8eda4aeae3a24c52a0b69d01946b93c5a9cba27 and reopen if you can make it fail.





[DDC-753] RepositoryClass for MappedSuperclass or other global set custom repository Created: 18/Aug/10  Updated: 13/Nov/11  Resolved: 13/Nov/11

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

Type: New Feature Priority: Major
Reporter: Patrik Votoček Assignee: Guilherme Blanco
Resolution: Fixed Votes: 1
Labels: None


 Description   

I need global repository class setter for all my entities. Because manualy set on all entity is not DRY.

My idea is two possibilities. First is param for MappedSuperclass:

/**
 * @MappedSuperclass(repositoryClass=MyRepository)
 */
class Foo {}

or config option (same as proxy dir/namespace)

$config = new \Doctrine\ORM\Configuration;
$config->setDefaultRepository('MyRepository');


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

Implemented





[DDC-720] Ability to call flush only for a given entity Created: 27/Jul/10  Updated: 13/Nov/11  Resolved: 13/Nov/11

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

Type: Improvement Priority: Major
Reporter: Amir Abiri Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 1
Labels: None

Attachments: Text File irc.txt    

 Description   

In a nutshell, this change would mean that flush() can optionally accept an entity as an argument. When that happens, the resulting changeset will be limited to that entity and any entity reachable from it.

The IRC transcript contains more details.



 Comments   
Comment by Benjamin Eberlei [ 22/Oct/11 ]

Rescheduled for 2.2

Comment by Benjamin Eberlei [ 22/Oct/11 ]

Code here, please review https://github.com/doctrine/doctrine2/pull/166

Comment by Benjamin Eberlei [ 13/Nov/11 ]

This was implemented and is in master.





[DDC-1490] Generated Ids with Sequence/Auto Increment Generators not always casted to int Created: 13/Nov/11  Updated: 13/Nov/11  Resolved: 13/Nov/11

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

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


 Description   

The Id Generators don't necessarily cast ids to integer values when generating them.



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

Fixed





[DDC-1491] Bug in SchemaValidator diffing join columns Created: 13/Nov/11  Updated: 13/Nov/11  Resolved: 13/Nov/11

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

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


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

Fixed in 2.2-dev as its only relevant in an error message displaying





[DDC-1458] Issue with tracking entity changes Created: 28/Oct/11  Updated: 11/Nov/11  Resolved: 10/Nov/11

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

Type: Bug Priority: Critical
Reporter: Maxim Assignee: Alexander
Resolution: Fixed Votes: 0
Labels: None
Environment:

linux/ubuntu, nginx, php-cgi, symfony framework



 Description   

Flushing at point #2 has no effect (outputs int(1)), flushing at point #1 works as expected (outputs int(5)).
this issue comes only when i trying to set boolean value on managed assotiated entity

upd. same issue with datetime properties

/**
 * @ORM\Entity
 */
class TestEntity
{
    /**
     * @ORM\Id
     * @ORM\Column(type="integer")
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;
    /**
     * @ORM\Column(type="integer")
     */
    protected $value;
    /**
     * @ORM\OneToOne(targetEntity="TestAdditionalEntity", inversedBy="entity", orphanRemoval="true", cascade={"persist", "remove"})
     */
    protected $additional;
}

/**
 * @ORM\Entity
 */
class TestAdditionalEntity
{
    /**
     * @ORM\Id
     * @ORM\Column(type="integer")
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;
    /**
     * @ORM\OneToOne(targetEntity="TestEntity", mappedBy="additional")
     */
    protected $entity;
    /**
     * @ORM\Column(type="boolean")
     */
    protected $bool;
    
    public function __construct()
    {
        $this->bool = false;
    }
}

$test = new \TestEntity();
$test->setValue(1);
$test->setAdditional(new \TestAdditionalEntity());

$em->persist($test);
$em->flush();
$em->clear();

$test = $em->getRepository('Bundle:TestEntity')->find(1);
$test->setValue(5);

// point #1
$test->getAdditional()->setBool(true);
// point #2

$em->flush();

var_dump($test->getValue());


 Comments   
Comment by Alexander [ 08/Nov/11 ]

Looking into this.

Comment by Benjamin Eberlei [ 09/Nov/11 ]

formatting

Comment by Alexander [ 10/Nov/11 ]

Fixed in master:
https://github.com/doctrine/doctrine2/pull/187

Comment by Benjamin Eberlei [ 11/Nov/11 ]

Merged into 2.1.x





ORA-00972: identifier is too long (DDC-1384)

[DDC-1427] Fix for columns Created: 17/Oct/11  Updated: 08/Nov/11  Resolved: 08/Nov/11

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

Type: Sub-task Priority: Major
Reporter: Benjamin Eberlei Assignee: Alexander
Resolution: Fixed Votes: 0
Labels: None


 Description   

Fix for generating sql with columns that are exactly MAX IDENTIFIER SIZE long.



 Comments   
Comment by Alexander [ 08/Nov/11 ]

Fixed over here:

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





[DDC-1455] Selecting association id (FK) without join Created: 26/Oct/11  Updated: 07/Nov/11  Resolved: 07/Nov/11

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

Type: New Feature Priority: Major
Reporter: Wladimir Coka Assignee: Guilherme Blanco
Resolution: Invalid Votes: 0
Labels: None


 Description   

It might be a missing feature or I might be doing something wrong. I need to select an association (FK) without the need of a join.

I'm trying something like this:

select i.client.id , count(i) as total 
from \Invoice i 
GROUP BY i.client

But I get this error:
Error: Expected Doctrine\ORM\Query\Lexer::T_FROM, got '.'



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

Try

SELECT i.client, count(i) AS total
Comment by Guilherme Blanco [ 07/Nov/11 ]

This is already supported in 2.2-DEV through IDENTITY() DQL function.

SELECT IDENTITY(i.client), count(i) as total 
  FROM \Invoice i 
 GROUP BY i.client




[DDC-1463] Inner join eagerly loaded entities if possible Created: 31/Oct/11  Updated: 31/Oct/11  Resolved: 31/Oct/11

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

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


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

Merged





[DDC-1439] Saving many to many association with composed keys. Created: 20/Oct/11  Updated: 31/Oct/11  Resolved: 31/Oct/11

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

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


 Description   

I have a problem with saving many to many realtion. My entities are.

calss Entity1 {
		
	/**
	 * @Id @column
	 */
	protected $key1;

	/**
	 * @Id @column
	 */
	protected $key2;
	
	/**
	 * @ManyToMany (targetEntity="Entity2")
	 * @JoinTable (name="Entity1Entity2",
	 *      joinColumns={@JoinColumn(name="key1", referencedColumnName="key1")},
	 *      inverseJoinColumns={@JoinColumn(name="key3", referencedColumnName="key3")}
	 *      )
	 */
	protected $entity2;
}

class Entity2 {
	
	/**
	 * @Id @column
         * @GeneratedValue(strategy="AUTO")
	 */
	protected $key3
}

So in the middle table that i keep the keys from the other 2 i need to save only key1 and key3. And key2 need to be ignored.
But when i try to save instead of saving the proper values it try to save the value for key2 instead of the value of key1 in the middle table.
After some debuging i found that in Doctrine\ORM\Persisters\ManyToManyPersister in the private function _collectJoinTableColumnParameters lies the problem.
Instead of taking the key by the name you are doing array_pop. And you are making a check for composite keys but you presume that bouth of the keys will be
in the middle table, but that is not the case for me.
The quick fix that i did was to remove the current check for isComposite and get the keys like we are in the isComposite case always.

Tanks in advance for the great work.

Have a nice day!



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

This kind of mapping is not supported right now, the CLI tool "orm:validate-schema" should throw a compile time error on it as well.

I am not sure if just changing that line is enough for this to work, or if there are other obstacles as well.

Comment by victor Velkov [ 28/Oct/11 ]

well that is the code so you can see what exactly i have removed

/**
     * Collects the parameters for inserting/deleting on the join table in the order
     * of the join table columns as specified in ManyToManyMapping#joinTableColumns.
     *
     * @param $coll
     * @param $element
     * @return array
     */
    private function _collectJoinTableColumnParameters(PersistentCollection $coll, $element)
    {
        $params = array();
        $mapping = $coll->getMapping();
        $isComposite = count($mapping['joinTableColumns']) > 2;

        $identifier1 = $this->_uow->getEntityIdentifier($coll->getOwner());
        $identifier2 = $this->_uow->getEntityIdentifier($element);

       // if ($isComposite) {
            $class1 = $this->_em->getClassMetadata(get_class($coll->getOwner()));
            $class2 = $coll->getTypeClass();
        //}

        foreach ($mapping['joinTableColumns'] as $joinTableColumn) {
            if (isset($mapping['relationToSourceKeyColumns'][$joinTableColumn])) {
                //if ($isComposite) {
                    if ($class1->containsForeignIdentifier) {
                        $params[] = $identifier1[$class1->getFieldForColumn($mapping['relationToSourceKeyColumns'][$joinTableColumn])];
                    } else {
                        $params[] = $identifier1[$class1->fieldNames[$mapping['relationToSourceKeyColumns'][$joinTableColumn]]];
                    }
//                } else {
//                    $params[] = array_pop($identifier1);
//                }
            } else {
                //if ($isComposite) {
                    if ($class2->containsForeignIdentifier) {
                        $params[] = $identifier2[$class2->getFieldForColumn($mapping['relationToTargetKeyColumns'][$joinTableColumn])];
                    } else {
                        $params[] = $identifier2[$class2->fieldNames[$mapping['relationToTargetKeyColumns'][$joinTableColumn]]];
                    }
//                } else {
//                    $params[] = array_pop($identifier2);
//                }
            }
        }

        return $params;
    }
Comment by Benjamin Eberlei [ 28/Oct/11 ]

i did find that already and also think its a good change to do sometihng along this lines (there is a better solution), however i dont knöow if that is even enough to get your use-case working across the whole ORM. We have zero test-cases for this kind of mapping, so i cannot guarantee you this works at all. This is why the orm:validate-schema gives you an error for this aswell (since some commits ago, this was missing earlier).

Comment by Benjamin Eberlei [ 31/Oct/11 ]

I checked the code again, this mapping is invalid. You have to define all id columns as join columns or otherwise the core will explode somewhere.

Since i cannot know and guarantee where it works and where it doesnt the SchemaValidator throws an exception about this problem. I added tests to master and 2.1.x that this mapping error is indeed given as an error.

Comment by Benjamin Eberlei [ 31/Oct/11 ]

sorry, i coudlnt fix it in 2.1.x, just in 2.2





[DDC-1384] ORA-00972: identifier is too long Created: 19/Sep/11  Updated: 30/Oct/11  Resolved: 30/Oct/11

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

Type: Bug Priority: Major
Reporter: Matheus Luis Ramos de Souza Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None

Sub-Tasks:
Key
Summary
Type
Status
Assignee
DDC-1427 Fix for columns Sub-task Resolved Alexander  
DDC-1428 Fix for tables Sub-task Resolved Alexander  

 Description   

Hi,

When the query is executed the follow problem occur:
ORA-00972:identifier is too long
The problem occur because a column name has 30 characters and the
Doctrine creates an alias with <column_name>+<position_in_select>
becoming 31 characters, in Oracle the max allowed characters in the name
is 30.
Is there any configuration that disable this mechanism?
How can I solve this issue?
Thanks!
Regards,

Matheus Souza.



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

This is tricky. No way for you to reduce the column length to < 30 chars? The problem with a fix for this would be that we would need to execute a bunch of functions for every database vendor and every column alias used in every SQL statement: quite some overhead

Comment by Matheus Luis Ramos de Souza [ 26/Sep/11 ]

I get it.
I don't know the implementation, but is there a possibilty to create a property that disable the "suffix field position" in alias, staying just <column_name>?

Tks!

Comment by Benjamin Eberlei [ 15/Oct/11 ]

The following workaround will get you around this problem until i find a better solution.

1. Create a MyOraclePlatform extends \Doctrine\DBAL\Platforms\OraclePlatform
2. Override the "getSQLResultCasing($string)" to do:

$val = parent::getSQLResultCasing($string);
return substr($val, -30);

This substrings every result alias to 30 chars.

Comment by Matheus Luis Ramos de Souza [ 17/Oct/11 ]

But how does the Doctrine will know about my implementation?
I will have to change the Driver too?

Thanks!

Comment by Benjamin Eberlei [ 17/Oct/11 ]

no, you can pass the "platform" into the DriverManager::create method as "platform" parameter for the $params AFAIK, relevant code is Doctrine\DBAL\Connection::__construct if you want to check it out.

Comment by Matheus Luis Ramos de Souza [ 17/Oct/11 ]

In some cases it works, but it doesn't work when the SqlWalker is invoked, I think that the problem is in walkSelectClause($selectClause) method in the else clause for this verification:

if ($class->isInheritanceTypeSingleTable() || $class->isInheritanceTypeJoined()) {
if ($class->isInheritanceTypeSingleTable() || $class->isInheritanceTypeJoined()) {
...
} else {
                // Add foreign key columns to SQL, if necessary
                if ($addMetaColumns) {
                    $sqlTableAlias = $this->getSqlTableAlias($class->table['name'], $dqlAlias);
                    foreach ($class->associationMappings as $assoc) {
                        if ($assoc['isOwningSide'] && $assoc['type'] & ClassMetadata::TO_ONE) {
                            foreach ($assoc['targetToSourceKeyColumns'] as $srcColumn) {
                                $columnAlias = $this->getSqlColumnAlias($srcColumn);
                                $sql .= ', ' . $sqlTableAlias . '.' . $srcColumn . ' AS ' . $columnAlias;
                                $columnAlias = $this->_platform->getSQLResultCasing($columnAlias);
                                $this->_rsm->addMetaResult($dqlAlias, $this->_platform->getSQLResultCasing($columnAlias), $srcColumn);
                            }
                        }
                    }
                }
            }
        }

the problem is in the follow lines, because the getSQLResultCasing has no effect in $sql variable that is returned:

$columnAlias = $this->getSqlColumnAlias($srcColumn);
$sql .= ', ' . $sqlTableAlias . '.' . $srcColumn . ' AS ' . $columnAlias;
$columnAlias = $this->_platform->getSQLResultCasing($columnAlias);

The correct would be this way, wouldn't be?

$columnAlias = $this->getSqlColumnAlias($srcColumn);
$columnAlias = $this->_platform->getSQLResultCasing($columnAlias);
$sql .= ', ' . $sqlTableAlias . '.' . $srcColumn . ' AS ' . $columnAlias;
  • In the version of Doctrine that I'm using, there is no DriverManager::create method, I'm using
    DriverManager::getConnection(array $params,Configuration $config = null,EventManager $eventManager = null) instead.

Tks!!

Comment by Benjamin Eberlei [ 17/Oct/11 ]

Narf, sorry that this doesn't work.

This is rather unreliable if this fails here, can we trust it in other places? I think i have to work on this by hard, its just very problematic to test this, it may be easy to miss a location.

Comment by Benjamin Eberlei [ 17/Oct/11 ]

we found a simple way to fix this, expect a patch for this soon!

Comment by Alexander [ 26/Oct/11 ]

The issue should be fixed with the code over here:
https://github.com/doctrine/doctrine2/pull/167

I haven't been able to test it on a real Oracle DB yet. Maybe you guys can give it a go?

Comment by Benjamin Eberlei [ 30/Oct/11 ]

Fixed, however will not be merged into 2.1.x because the patch is really large





[DDC-446] Cached resultset do not add Entities in UnitOfWork Created: 19/Mar/10  Updated: 30/Oct/11  Resolved: 30/Oct/11

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

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

Attachments: File DDC446Test.php    
Issue Links:
Reference
relates to DDC-217 Result cache should cache the SQL res... Resolved

 Description   

When using resultset cache, when you fetch for these object and attempt to manipulate them, they fail to work giving this message:

Notice:  Undefined index: 000000006f95482300000000384dffac in /srv/app/library/Doctrine/ORM/UnitOfWork.php on line 1901


 Comments   
Comment by Roman S. Borschel [ 20/Mar/10 ]

Objects coming from the result cache are all detached. The EM does not care about them unless you merge() them. But there should probably be a better exception instead of this notice. Please show the code that causes the notice.

PS: Result caching objects is inefficient.

Comment by Guilherme Blanco [ 20/Mar/10 ]

Test case attached.

This is a situation where it should work smoothly IMHO.

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

No, it should not work smoothly because $user is a detached object. It should throw an exception but the problem is that its hard to detect whether an object is detached in _doPersist.

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

You need to understand the difference between managed and detached. Its very important.

Comment by Guilherme Blanco [ 20/Mar/10 ]

Adding merge doesn't work too.... same error.

Juyst add $this->_em->merge($user); in line 52.

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

Of course it wouldnt because thats not how merge works. Merge returns a managed copy.

So you would do:

$managedUser = $this->_em->merge($user);

...

$article->setUser($managedUser);

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

http://www.doctrine-project.org/documentation/manual/2_0/en/working-with-objects:merging-entities

Comment by Benjamin Eberlei [ 30/Oct/11 ]

Implemented through DDC-217





Current event system is not flexible enough (DDC-1431)

[DDC-1449] Create postFlush event Created: 23/Oct/11  Updated: 23/Oct/11  Resolved: 23/Oct/11

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

Type: Sub-task Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

Create postFlush event



 Comments   
Comment by Benjamin Eberlei [ 23/Oct/11 ]

See https://github.com/doctrine/doctrine2/pull/168 - merged





[DDC-1437] Strange behavior with proxied classes,expected to get entity, but returned identifier. Created: 19/Oct/11  Updated: 19/Oct/11  Resolved: 19/Oct/11

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

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


 Description   

I have the following xml mapping:

 
User:
  <entity name="User" table="user">
    <id name="id" type="integer" column="id">
      <generator strategy="SEQUENCE"/>
    </id>
    <field name="name" type="string" column="name"/>
   </entity>

SuperUser:
  <entity name="SuperUser" table="superuser">

    <id name="user" type="integer" column="user_id" association-key="true"/>

    <one-to-one field="user" target-entity="User">
      <join-columns>
        <join-column name="user_id" referenced-column-name="id"/>
      </join-columns>
    </one-to-one>

  </entity>

From this mapping i have generated the php classes.

In my application, when the SuperUser class is proxied, SuperUser::getUser() method looks like this:

 
public function getUser(){

        if ($this->__isInitialized__ === false) {
            return $this->_identifier["user"];
        }
        $this->__load();
        return parent::getUser();
}

When i call $usperuser->getUser() the expected return value is the User class instance; but the current implementation returns only user id (contained in $this->_identifier["user"]).

In this behavior is also involved private function ProxyFactory::isShortIdentifierGetter($method, $class)

Some solutions proposed by me, can be:

  • remove this behavior
  • during proxy generation, add in this case a method called getUserId, and this method can return user id (but in this case, the behavior continues to be strange because is available only for proxied classes).

(sorry for my english)



 Comments   
Comment by Benjamin Eberlei [ 19/Oct/11 ]

very recent bug in master, i will fix it.

Comment by Benjamin Eberlei [ 19/Oct/11 ]

fixed in master





[DDC-1343] Github-PR-105 by domnikl: DDC-1278 - EntityManager::clear($entity) support Created: 21/Aug/11  Updated: 17/Oct/11  Resolved: 17/Oct/11

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

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


 Description   

domnikl created a pull request on Github:

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

added cascade detach operation only for entites with the same name when $entityName on clear() was specified. I am still unsure where to put my tests for that.



 Comments   
Comment by Guilherme Blanco [ 17/Oct/11 ]

Fixed in this commit https://github.com/doctrine/doctrine2/commit/22a04fd6de3ffa44cc3cd817d65cf112b1df7b53





[DDC-1278] EntityManager::clear($entity) support Created: 14/Jul/11  Updated: 16/Oct/11  Resolved: 16/Oct/11

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

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

Sub-Tasks:
Key
Summary
Type
Status
Assignee
DDC-2850 Allow cascaded clearing of Entities a... Sub-task Resolved Guilherme Blanco  

 Description   

It was originally planned that EntityManager::clear() would also support an optional argument - $entity -, which would remove only the reference to an existent entity (maybe also consider a new cascade to allow graph clearing) from UoW.
Currently, it's win or wall. You can't clear a specific portion of Entities.



 Comments   
Comment by Dominik Liebler [ 13/Aug/11 ]

I implemented this (https://github.com/doctrine/doctrine2/pull/104) but forgot to consider also cascade detach. What do you think about adding an additional parameter $entityName to both cascadeDetach() and doDetach()?

Comment by Benjamin Eberlei [ 16/Oct/11 ]

Merged into 2.2-master

Comment by Alexander [ 16/Oct/11 ]

By merging the new PR: https://github.com/doctrine/doctrine2/pull/105.





[DDC-1358] Native Query hydration ignores empty entity doublons Created: 02/Sep/11  Updated: 16/Oct/11  Resolved: 16/Oct/11

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

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

Debian 6, Symfony 2, Doctrine 2



 Description   

My case is the follwing :

In a range of dates, I want to know if an entity has been defined for each day. So the raw SQL result would looks like :

DATE              ID NAME
--------- ---------- -------------
19-SEP-11          4 [Entity Name]
20-SEP-11          1 [Entity Name]
21-SEP-11          2 [Entity Name]
22-SEP-11          3 [Entity Name]
23-SEP-11       NULL NULL
24-SEP-11       NULL NULL
25-SEP-11       NULL NULL
26-SEP-11       NULL NULL
27-SEP-11          7 [Entity Name]
28-SEP-11          6 [Entity Name]
29-SEP-11          5 [Entity Name]

11 rows selected.

The range calculation forced me to use Native Query, but I stumbled upon a strange behavior : the Result array showed less records than the raw SQL would provide. After some dirty debugging, I found out that during hydration, an array of previously hydrated object keys was stored ObjectHydrator->_identifierMap. The key of null elements (the gap in the SQL result above) is stored too. The problem is that when there is multiple empty elements, hydration only keeps one, and forget the others, thus reducing the overall size of the output result.

I've already come up with a quick n'dirty fix wich suits my current needs, but it would be better if this issue was addressed at a more global level.

Here's the one-liner fix :

Doctrine/ORM/Internal/Hydration/ObjectHydrator.php line 397 was :
                if ( ! isset($this->_identifierMap[$dqlAlias][$id[$dqlAlias]]) ) {
Doctrine/ORM/Internal/Hydration/ObjectHydrator.php line 397 now :
                if ( ! isset($this->_identifierMap[$dqlAlias][$id[$dqlAlias]]) || str_replace( '|', '', $id[$dqlAlias]) == '') {


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

Doesnt he still hydrate an empty object for this row then? Why are you even using the object hydrator? I rather tend to go and throw an exception if for a query using the ObjectHydrator $id[$dqlAlias] is empty, because frankly this is just not supported.

Comment by Benjamin Lorteau [ 04/Sep/11 ]

He does hydrate one empty object for the first line with empty ID, but he does not hydrate further empty object.

Thus, instead of having an array with the following objects :

 
Entity(id=4)
Entity(id=1)
Entity(id=2)
Entity(id=3)
Entity(id=)
Entity(id=)
Entity(id=)
Entity(id=)
Entity(id=7)
Entity(id=6)
Entity(id=5)

I got :

 
Entity(id=4)
Entity(id=1)
Entity(id=2)
Entity(id=3)
Entity(id=)
Entity(id=7)
Entity(id=6)
Entity(id=5)
Comment by Benjamin Eberlei [ 04/Sep/11 ]

Yes, but can you show me your DQL statement?

Comment by Benjamin Lorteau [ 05/Sep/11 ]

I'm using Native Query, so I guess it's not DQL, but here's the query (Oracle SQL)

SELECT *
FROM (
    SELECT to_date(:date_start,\'dd-mm-yyyy\') + rownum -1 as period_date
    FROM all_objects
    WHERE rownum <= to_date(:date_end,\'dd-mm-yyyy\') - to_date(:date_start,\'dd-mm-yyyy\')+1
)
LEFT JOIN entity ON period_date = entity_date',
Comment by Benjamin Eberlei [ 15/Oct/11 ]

For the Array- and ObjectHydrator the ID is a required result.

I am not sure how to proceed with this, i think the right behavior is to return null as the object when no id is found. What do you think?

Is the Date a scalar value of the result?

Comment by Benjamin Lorteau [ 15/Oct/11 ]

The expected results would be, in order of preference :

  • Entity without id set (like in my example above)
  • null value

And yes, the Date was an additional scalar value for which I needed the Native Query

Comment by Benjamin Eberlei [ 16/Oct/11 ]

Your example lacks details but, for case one. Did the queries return values for the non-id columns of this entity?

Comment by Benjamin Lorteau [ 16/Oct/11 ]

Sorry for the concision, I didn't wanted to flood my comment with unrelated data.

The fact is the queries returned values for the non-id columns when the ID was set, and null values when not. I will update my comment.

Comment by Benjamin Eberlei [ 16/Oct/11 ]

I will go with adding NULL values there. This is more consistent, since null represents a non-existent entity.

Fixed and merged back into 2.1.x





[DDC-744] invalid onDelete value inside of @JoinColumn annotation throws an exception instead of valueable error message Created: 11/Aug/10  Updated: 16/Oct/11  Resolved: 16/Oct/11

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

Type: Improvement Priority: Major
Reporter: Jan Obrátil Assignee: Guilherme Blanco
Resolution: Invalid Votes: 0
Labels: None


 Description   

Invalid onDelete value throws an exception in doctrine cli interface. It would be nice that developer can see what error occured and where fix it. Exception does not have any information about invalid onDelete value or file & line pointer to problem.



 Comments   
Comment by Guilherme Blanco [ 16/Oct/11 ]

We have the validate-schema command. This ticket is now invalid





[DDC-766] Parameter not used in OrmTestCase Created: 25/Aug/10  Updated: 16/Oct/11  Resolved: 16/Oct/11

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

Type: Improvement Priority: Minor
Reporter: Christian Heinrich Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

The param $eventManager in OrmTestCase::_getTestEntityManager is not used and should be removed.

(However, I'm not sure whether this would be a change to API and thus I don't do it myself but file this as an issue)



 Comments   
Comment by Guilherme Blanco [ 16/Oct/11 ]

Fixed in https://github.com/doctrine/doctrine2/commit/eeba947ea7f0f5f18672c368398f105a93e58545





[DDC-1161] DQL generate duplicate SQL Alias with CTI + oneToOne self referencing Created: 20/May/11  Updated: 16/Oct/11  Resolved: 16/Oct/11

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: DQL
Affects Version/s: 2.0.5, 2.1
Fix Version/s: 2.2
Security Level: All

Type: Bug Priority: Major
Reporter: Nicolas Badey Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None
Environment:

WAMP , PHP 5.3.5 , MySql 5.5.8
Symfony 2 Beta 1


Attachments: File Content.php     File Page.php    

 Description   

Hi,

I have a Entity "Content" whith several childs entities like "Page" , "Article" in Joined inheritance.
I make DQL directly on entity "Content", that work perfectly with the discriminator map for return/delete/update appropriates objects.
I use "Page" or "Article" entity only for make a new object and persist.

But now I have add a oneToOne self relation in "Content" :
Content#parent_id => Content#id , no cascade.

And now every DQL return :
SQLSTATE[42000]: Syntax error or access violation: 1066 Not unique table/alias: XX
And yes I see in generated SQL that Content's alias is not unique :

For DQL : SELECT c FROM Content WHERE c.status = 1

SQL Result :

SELECT n0_.id AS id0, n0_.name AS name1, n0_.title AS title2, n0_.author AS author3, n0_.author_update AS author_update4, n0_.status AS status5, n0_.type AS type6, n0_.weight AS weight7, n0_.create_on AS create_on8, n0_.update_on AS update_on9, n0_.url AS url10, n0_.zone AS zone11, n0_.children_sort AS children_sort12, n0_.children_sort_type AS children_sort_type13, n0_.path AS path14, n0_.level AS level15, n1_.meta AS meta16, n2_.content AS content17, n3_.description AS description18, n3_.keywords AS keywords19, n3_.gwt AS gwt20, n3_.analytics AS analytics21, n3_.xiti AS xiti22, n0_.class AS class23 FROM ncms_content n0_ LEFT JOIN ncms_page n1_ ON n0_.id = n1_.id LEFT JOIN ncms_article n2_ ON n0_.id = n2_.id LEFT JOIN ncms_content n0_ ON n0_.id = n0_.id LEFT JOIN ncms_content n0_ ON n0_.id = n0_.id LEFT JOIN ncms_content n0_ ON n0_.id = n0_.id LEFT JOIN ncms_content n0_ ON n0_.id = n0_.id LEFT JOIN ncms_content n0_ ON n0_.id = n0_.id LEFT JOIN ncms_website n3_ ON n0_.id = n3_.id LEFT JOIN ncms_content n0_ ON n0_.id = n0_.id WHERE n0_.status =1

=> SQLSTATE[42000]: Syntax error or access violation: 1066 Not unique table/alias: 'n0_'

But if I use getRepository like this :
$em->getRepository('Content')->findBy(array('status'=>1));
It works, and return appropriates objects.
And I can see that "Content" have several unique alias in the SQL query :

SELECT t0.id AS id1, t0.name AS name2, t0.title AS title3, t0.author AS author4, t0.author_update AS author_update5, t0.status AS status6, t0.type AS type7, t0.weight AS weight8, t0.create_on AS create_on9, t0.update_on AS update_on10, t0.url AS url11, t0.zone AS zone12, t0.children_sort AS children_sort13, t0.children_sort_type AS children_sort_type14, t0.path AS path15, t0.level AS level16, t0.parent_id AS parent_id17, t0.class, t18.meta AS meta19, t20.content AS content21, t27.description AS description28, t27.keywords AS keywords29, t27.gwt AS gwt30, t27.analytics AS analytics31, t27.xiti AS xiti32 FROM ncms_content t0 LEFT JOIN ncms_page t18 ON t0.id = t18.id LEFT JOIN ncms_article t20 ON t0.id = t20.id LEFT JOIN ncms_content t22 ON t0.id = t22.id LEFT JOIN ncms_content t23 ON t0.id = t23.id LEFT JOIN ncms_content t24 ON t0.id = t24.id LEFT JOIN ncms_content t25 ON t0.id = t25.id LEFT JOIN ncms_content t26 ON t0.id = t26.id LEFT JOIN ncms_website t27 ON t0.id = t27.id LEFT JOIN ncms_content t33 ON t0.id = t33.id WHERE t0.status =1

Regards,



 Comments   
Comment by Benjamin Eberlei [ 05/Jun/11 ]

Fixed formatting.

Comment by Benjamin Eberlei [ 05/Jun/11 ]

Can you upload the mapping files and php code? This looks very weird and i dont know where to start debugging from your description.

Comment by Nicolas Badey [ 06/Jun/11 ]

Done, Mapping and Entities (simplified).

I have a little question, how we can acces to the discriminator map in a DQL query or Entity's object ? Because we cannot mappe this field.

Comment by Guilherme Blanco [ 16/Oct/11 ]

Hi Nicholas,

In 2.2-DEV this issue seems to be addressed already.
We did an internal refactoring (that leads us to not merge into 2.1) that addressed this issue.

I added coverage to your issue with this commit and it works nicely: https://github.com/doctrine/doctrine2/commit/33bcf7ad6f67b8641983f51901d0e74cfde8446c

Marking the ticket as fixed in 2.2





[DDC-1422] Do not load entities when an identifier is retrieved from a proxy Created: 15/Oct/11  Updated: 15/Oct/11  Resolved: 15/Oct/11

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

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


 Comments   
Comment by Guilherme Blanco [ 15/Oct/11 ]

Fixed as of https://github.com/doctrine/doctrine2/commit/ba38f3e1e9d725224998af9fce42186b5ccb9641





[DDC-1383] Inheritance superclass object is created after merging entity referencing to discriminated entity Created: 19/Sep/11  Updated: 15/Oct/11  Resolved: 15/Oct/11

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

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

Ubuntu 11.04, MySQL 5.1.54-1ubuntu4, PHP 5.3.5-1ubuntu7.2


Attachments: File DDC1383Test.php    

 Description   

Problem is that after merging the object with a reference to some other entity with inheritance (is one of the superclass's discriminator map), the referenced object has wrong instance (it is Proxy object). It is instance of the superclass not the extended class.

In my test case I have joined inheritance model with only two entities to make things simple as possible.

First is the base entity (I have even marked it as abstract):

/**
 * @Entity
 * @InheritanceType("JOINED")
 * @DiscriminatorColumn(name="discr", type="integer")
 * @DiscriminatorMap({1 = "Entity"})
 */
abstract class AbstractEntity

and one entity which extends from the first one:

/**
 * @Entity
 */
class Entity extends AbstractEntity {
	/**
	 * @ManyToOne(targetEntity="AbstractEntity")
	 * @var AbstractEntity
	 */
	protected $reference;

In this scheme I've got 2 objects, first referencing to the second. They both are inserted in the database with no problems.

$child = new Entity();
$parent = new Entity();
$child->setReference($parent);

After the flush I try merging the child entity into the entity manager, the parent entity reference is not instance of Entity\Entity anymore.

You can see full test case in the archive attached.



 Comments   
Comment by Aigars Gedroics [ 26/Sep/11 ]

Attached standardized test case.

Comment by Benjamin Eberlei [ 15/Oct/11 ]

Fixed.





[DDC-1411] onCascade property gets wrong value when entities are generated Created: 10/Oct/11  Updated: 15/Oct/11  Resolved: 15/Oct/11

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

Type: Bug Priority: Major
Reporter: Vinícius Borriello Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

Unix/Apache/PHP 5.3/MySQL



 Description   

I'm using this cmd to generate entities "/path/to/php path/to/doctrine orm:generate-entities --generate-annotations="1" ~/some/path".

The CASCADE option for ONDELETE columns is being wrongly generated, the right would be: onDelete="CASCADE" but it is being generated as onDelete=true



 Comments   
Comment by Benjamin Eberlei [ 15/Oct/11 ]

Fixed





[DDC-209] Add the notion of read-only entities Created: 14/Dec/09  Updated: 15/Oct/11  Resolved: 15/Oct/11

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

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

Issue Links:
Dependency
is required for DDC-1386 getPartialReference() will result in ... Resolved
Sub-Tasks:
Key
Summary
Type
Status
Assignee
DDC-691 doctrine.readOnly query hint Sub-task Open Roman S. Borschel  
DDC-692 Read-only entities Sub-task Resolved Benjamin Eberlei  

 Description   

This may include:

  • a doctrine.readOnly query hint
  • a @ReadOnly annotation or xml/yaml descriptor element

Useful mainly for optimization purposes to tell doctrine to ignore such objects for any change tracking (except the initial creation/insert, of course).



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

DDC-692 might make it into 2.0. The query hint is definitely out of scope for that release.

Comment by Benjamin Eberlei [ 29/Mar/11 ]

Implemented DDC-692 for inclusion in 2.1, however move the query hint to 2.x





[DDC-1418] Integrate Simplified XML/YML Drivers from Symfony Created: 13/Oct/11  Updated: 13/Oct/11  Resolved: 13/Oct/11

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

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


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

Merged this stuff from Symfony, thanks!





[DDC-509] Documentation for Implementing Event Listeners is incomplete Created: 10/Apr/10  Updated: 11/Oct/11  Resolved: 11/Oct/11

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

Type: Improvement Priority: Major
Reporter: David Abdemoulaie Assignee: Guilherme Blanco
Resolution: Fixed Votes: 1
Labels: None


 Description   

See: http://www.doctrine-project.org/documentation/manual/2_0/en/events#implementing-event-listeners

I created it as Major due to the following statement "you have to follow this restrictions very carefully since operations in the wrong event may produce lots of different errors, such as inconsistent data and lost updates/persists/removes."

s/this/these/ as well



 Comments   
Comment by Guilherme Blanco [ 11/Oct/11 ]

Fixed





[DDC-1396] [APC Cache] "clear-cache" commands do not work with cli Created: 27/Sep/11  Updated: 03/Oct/11  Resolved: 03/Oct/11

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

Type: Bug Priority: Critical
Reporter: Jérôme Forêt Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None
Environment:

in php.ini
apc.enable_cli = 1



 Description   

Commands for clear-cache:result, clear-cache:query, clear-cache:metadata do not work with cli and APC Cache

Revert some correction not tested by guilhermeblanco by adding

if ($cacheDriver instanceof \Doctrine\Common\Cache\ApcCache)
{
    throw new \LogicException("Cannot clear APC Cache from Console, its shared in the Webserver memory and not accessible from the CLI.");
}


 Comments   
Comment by Guilherme Blanco [ 03/Oct/11 ]

Fixed in https://github.com/doctrine/doctrine2/commit/8efae0b232210b27200f2709e7fcb24c7f02c5de

Thanks for the report. =)





[DDC-1395] [Doctrine cache clear-result] - wrong function is used Created: 27/Sep/11  Updated: 03/Oct/11  Resolved: 03/Oct/11

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

Type: Bug Priority: Major
Reporter: Jérôme Forêt Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

lib\Doctrine\ORM\Tools\Console\Command\ClearCache\ResultCommand.php

Fixing

 
$cacheDriver = $em->getConfiguration()->getQueryCacheImpl();
by
$cacheDriver = $em->getConfiguration()->getResultCacheImpl();

Fixing

 
output->write('Clearing ALL Query cache entries' . PHP_EOL);
by
output->write('Clearing ALL Result cache entries' . PHP_EOL);


 Comments   
Comment by Guilherme Blanco [ 03/Oct/11 ]

Fixed in https://github.com/doctrine/doctrine2/commit/cd2805137056688fc0848f7fa76b479d681a3cb6





[DDC-1365] Use getQuotedTableName() consistently in all SQL Created: 06/Sep/11  Updated: 25/Sep/11  Resolved: 07/Sep/11

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

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


 Description   

Its missing in some of the persisters/sql walker code.



 Comments   
Comment by Guilherme Blanco [ 07/Sep/11 ]

Committed in https://github.com/doctrine/doctrine2/commit/e3d133af045815167bdbb0e47a496cc49c86fc23

Please merge in 2.1.





[DDC-1339] New DQL function: IDENTITY(SingleValuedAssociationPathExpression) Created: 19/Aug/11  Updated: 08/Sep/11  Resolved: 08/Sep/11

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

Type: New Feature Priority: Minor
Reporter: Guilherme Blanco Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

Suppose the association: User N:1 Group and user wants to be able to retrieve "users.group_id" without joining the Group entity.
This lead us to create a new DQL function:

SELECT IDENTITY(u.Group) AS group_id FROM User u WHERE u.id = ?0


 Comments   
Comment by Guilherme Blanco [ 08/Sep/11 ]

Implemented https://github.com/doctrine/doctrine2/commit/a7f3af8328b031a6f006eef1062554bf9f57e1df





[DDC-659] Programmatic PHP ClassMetadata Builder Created: 28/Jun/10  Updated: 04/Sep/11  Resolved: 04/Sep/11

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

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


 Description   

Currently using the two existing PHP Metadata Drivers you have a hard time writing the metadata against a plain ClassMetadata instance, because its already so optimiized in the datastruct. It would we cool if we had a class (Doctrine\ORM\Tools\ClassMetadataBuilder) which accepts a ClassMetadata instance in the constructor and has convenience methods to build up this instance.

This way you could use the PHPStatic Driver for example:

class MyEntity
{
  static public function loadClassMetadata(ClassMetadata $metadata)
  {
    $builder = new ClassMetadataBuilder($metadata);
    $builder->setTable('my_entity');
    // ...
  }
}


 Comments   
Comment by Benjamin Eberlei [ 08/Aug/10 ]

API Suggestion:

class ClassMetadataBuilder
{
    public function __construct(ClassMetadata $cm);
    public function markMappedSuperclass();

    public function setTable($name);
    public function addTableIndex($columns, $name);
    public function addTableUniqueConstraint($columns, $name);

    public function setJoinedTableInheritance();
    public function setSingleTableInheritance();
    public function setDiscriminatorColumn($name, $type);
    public function addDiscriminatorMapClass($name, $class);
    
    public function setChangeTrackingPolicyDeferredImplict();
    public function setChangeTrackingPolicyDeferredExplicit();
    public function setChangeTrackingPolicyNotify();

    public function addField($fieldName, $type, array $options = array());
    public function addVersionField($fieldName, $type, array $options = array());
    public function addPrimaryField($fieldName, $type, array $options = array());
    public function setSequenceGenerator($sequenceName, $allocationS