[DDC-3460] SchemaTool create unnecessry work by trying to set foreign keys on MyISAM tables Created: 20/Dec/14  Updated: 20/Dec/14

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

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


 Description   

When I run SchemaTool::getSchemaFromMetadata, it always adds foreign keys constraints for all association fields (in SchemaTool::gatherRelationJoinColumns). Since I've set the table's engine option to 'MyISAM', this is quite pointless, since they won't get created anyways.

When I run SchemaManager::createSchema, it does not detect any foreign keys, so the SchemaDiff from Comparator will contain a large number of (pointless) ADD CONSTRAINT FK_xxx FOREIGN KEY commands.

For the moment, I work around this by removing them in a ToolEvents::postGenerateSchemaTable listener, but shouldn't SchemaTool be able to detect this situation itself?






[DDC-3459] double inversed-by leads to incomprehensible error message Created: 20/Dec/14  Updated: 20/Dec/14

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

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


 Description   

When mapping a many-to-one relationship (in XML format), I made the mistake of having both sides be inversed-by (instead of one using mapped-by). This resulted in the following error message on doctrine:schema:update

Doctrine\ORM\ORMException: This behaviour is (currently) not supported by Doctrine 2 (uncaught exception) at /Volumes/User Data/Users/Tom/Sites/BM2/vendor/doctrine/orm/lib/Doctrine/ORM/ORMException.php line 217 while running console command `doctrine:schema:update`

This message could be more helpful. It doesn't tell me where the error is nor what the error is.






[DDC-3443] Doctrine Custom Type always converted as string, when not wanted Created: 09/Dec/14  Updated: 19/Dec/14  Resolved: 19/Dec/14

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

Type: Bug Priority: Major
Reporter: Romain Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 0
Labels: dql, postgresql
Environment:

Symfony2, PDO_PostgreSQL



 Description   

Hello,

trying to define a Custom Type in my Symfony2 application, I can't find how to write the convertToDatabaseValue function for working with native points in PostgreSQL (!= PostGIS extension).

Wished syntax :

'SELECT [...] FROM Addresses t0 WHERE t0.location = ?' with params ['(2.352,48.857)']

I use this convertToDatabaseValue function :

    public function convertToDatabaseValue($value, AbstractPlatform $platform) {
        if (!$value) return;

        return "'(".$value->getX().','.$value->getY().")'";
    }

DQL, creates this SQL query :

'SELECT [...] FROM Addresses t0 WHERE t0.location = ?' with params ["'(2.352,48.857)'"]

-> Double quotes are automatically added, the parameter is interpreted as string.

I don't know if it is a bug or if I am doing anything wrong ?

Thank you.



 Comments   
Comment by Marco Pivetta [ 10/Dec/14 ]

Please check http://doctrine-orm.readthedocs.org/en/latest/cookbook/advanced-field-value-conversion-using-custom-mapping-types.html and compare it with your codebase.

Comment by Romain [ 10/Dec/14 ]

As I understand, the function convertToDatabaseValue build the format from the value into "with params (############)"

But it does always put double quotes so that my value becomes a string.

convertToDatabaseValueSQL build the format before, at the placeholder and here, I don't want to change anything.

I tried also

getBindingType()

{ return \PDO::PARAM_NULL; }

Hoping that were going to remove the quotes, but it doesn't.

Any suggestion ?

Comment by Steve Müller [ 12/Dec/14 ]

Not sure but I think the double quotes are just added for the debug output. What would be the native SQL that you expect?
I think you will have to define \PDO::PARAM_STRING as binding type and remove the single quotes around your database value:

public function convertToDatabaseValue($value, AbstractPlatform $platform) {
    if (!$value) return;

    return "(".$value->getX().','.$value->getY().")";
}
Comment by Romain [ 19/Dec/14 ]

OK it is working without parenthesis ...

Thank you for your help .

Comment by Romain [ 19/Dec/14 ]

There were no problem, wrong syntax in my custom Typ ...





[DDC-2524] Wrong commit order with cascade remove and double association Created: 24/Jun/13  Updated: 19/Dec/14

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

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


 Description   

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

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

Associations are with cascade remove.

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

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



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

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

Comment by Matthieu Napoli [ 25/Jun/13 ]

The tests on Travis are failing as expected.

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

Here is the list of the queries executed for MySQL:

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

With queries:

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

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

Comment by Matthieu Napoli [ 25/Jun/13 ]

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

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

13 and 14 are in the wrong order.

Comment by Guilherme Blanco [ 03/Aug/13 ]

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

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

Comment by Matthieu Napoli [ 05/Aug/13 ]

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

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

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

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

Comment by Benjamin Eberlei [ 03/Jan/14 ]

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

Comment by Matthieu Napoli [ 15/Jan/14 ]

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

Comment by Benjamin Morel [ 04/Dec/14 ]

Just encountered what I believe to be the same bug, without any kind of circular dependency:

class A {
    /**
     * @ORM\OneToMany(targetEntity="B", mappedBy="a", indexBy="x", cascade={"all"}, orphanRemoval=true)
     */
    private $b;

    ...
}

class B {
    /*
     * @ORM\ManyToOne(targetEntity="A", inversedBy="b")
     * @ORM\JoinColumn(name="aid", referencedColumnName="id", nullable=false, onDelete="CASCADE")
     */
    private $a;

    ...
}

The following operations in A:

$this->b->clear();
$this->b->add(new B());

Result in the following SQL commands:

INSERT INTO B ...
DELETE FROM B ...

This is always the wrong commit order, and is doomed to fail when you have unique constraints in the B table.

Comment by Maxim Kapkaev [ 19/Dec/14 ]

Another situation without circular dependency:

class Entity
{
    /**
     * @ORM\OneToMany(targetEntity="Picture", mappedBy="entity", fetch="EXTRA_LAZY", cascade={"all"}, orphanRemoval=true)
     * @ORM\OrderBy({"position" = "ASC"})
     */
    protected $pictures = array();
} 

class Pictures {
    /**
     * @ORM\Column(type="string", length=1024, unique = true)
     */
    protected $file;
}
$hotel->setPictures($picturesArray);
$em->flush();
$hotel->getPictures()->clear();
$hotel->setPictures($somePictureUpdatedArray);
$em->flush();
Unique violation: 7 ERROR:  duplicate key value violates unique constraint "uniq_8f7c2fc08c9f3610"

Why we can't invoke entity deletions method (executeDeletions, UnitOfWork#commit) before executeInserts?
https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/UnitOfWork.php#L385-L388
There is another way?





[DDC-3458] [GH-1228] Fixed many small phpcs issues Created: 19/Dec/14  Updated: 19/Dec/14

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

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


 Description   

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

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

Message:

This pr fixes many small phpcs issues



 Comments   
Comment by Doctrine Bot [ 19/Dec/14 ]

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





[DDC-3379] [GH-1177] Ensure metadata cache is not ArrayCache in production Created: 08/Nov/14  Updated: 19/Dec/14  Resolved: 11/Nov/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: array-cache, cache, configuration, production-settings

Issue Links:
Reference
is referenced by DDC-3457 [GH-1227] Ensure query cache is not A... Open

 Description   

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

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

Message:

This PR adds a new check to Configuration::ensureProductionSettings(). It ensures that the metadata cache does not use ArrayCache in production.

The ArrayCache forgets everything at the end of each request, while the other bundled cache engines (Memcache, MongoDB, FileCache etc.) may keep entries for much longer. The metadata only changes when the source files are changed, so in production the metadata cache only needs to be cleared when new files are deployed, just like the generation of proxy classes.

It is possible to specify/modify metadata dynamically at runtime e.g. using the loadClassMetadata event so that the metadata changes without any changes to the source files, but I assume this is not a supported use-case (at least not without clearing the metadata cache manually). Agree?

The ArrayCache is the default cache engine added by e.g. Doctrine Bundle (for Symfony) and Doctrine ORM Service Provider (for Silex), so most developers are probably not aware of it. However, accessing the metadata at run-time has a significant performance impact (for some anecdotal evidence, see https://github.com/doctrine/common/pull/319#issuecomment-60945429), so a warning in ensureProductionSettings() is relevant.

The PR also fixes the units for ensureProductionSettings() that were previously not being run due to a missing "test" prefix on the ConfigurationTest::ensureProductionSettings method name.



 Comments   
Comment by Doctrine Bot [ 10/Nov/14 ]

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





[DDC-3457] [GH-1227] Ensure query cache is not ArrayCache in production Created: 19/Dec/14  Updated: 19/Dec/14

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

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

Issue Links:
Reference
relates to DDC-3379 [GH-1177] Ensure metadata cache is no... Resolved

 Description   

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

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

Message:

This PR applies the same check for the query cache that was done for the metadata cache in #1177 (as suggested by @stof).






[DDC-3456] [GH-1226] Update Travis badges to use the SVG version Created: 19/Dec/14  Updated: 19/Dec/14  Resolved: 19/Dec/14

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

Type: Documentation Priority: Trivial
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: badges, documentation, readme, travis


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 19/Dec/14 ]

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

Comment by Doctrine Bot [ 19/Dec/14 ]

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





[DDC-3203] "Orphan Removal" for ManyToMany and "Cascade remove" doesn't trigger "preRemove" callback on related entity Created: 01/Jul/14  Updated: 19/Dec/14

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

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

Latest ZendFramework2, latest ZF2 DoctrineModule and latest ZF2 DoctrineORMModule



 Description   

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

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

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

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

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

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



 Comments   
Comment by Oliver Hoff [ 19/Dec/14 ]

Orphan removal can not be supported for Many-To-Many relations, because the feature makes the assumption that the related entity is "privately owned" by the entity defining the orphan removal feature. In a Many-To-Many relation a related entity can be related to multiple entities and therefore is not privately owned by the relation defining entity.





[DDC-2592] [GH-748] Add hour to DATE_ADD and DATE_SUB Created: 06/Aug/13  Updated: 19/Dec/14  Resolved: 07/Aug/13

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

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


 Description   

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

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

Message:

Add hours support to DATE_ADD and DATE_SUB.

see https://github.com/doctrine/dbal/pull/354



 Comments   
Comment by Doctrine Bot [ 06/Aug/13 ]

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

Comment by Marco Pivetta [ 07/Aug/13 ]

Merged: https://github.com/doctrine/doctrine2/commit/34b855e253893dfb54068596e4849220d1ce9ec5

Comment by Doctrine Bot [ 19/Dec/14 ]

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





[DDC-3455] [GH-1225] Test for RuntimeException in AnnotationExporter::exportClassMetadata() Created: 19/Dec/14  Updated: 19/Dec/14

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

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


 Description   

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

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

Message:






[DDC-3451] [GH-1221] Very simple refactoring of the setup class Created: 16/Dec/14  Updated: 17/Dec/14  Resolved: 17/Dec/14

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

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


 Description   

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

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

Message:

Moved logic to instance methods.

This way, a project could depend on a Setup class instance (or extend it) and resolve it through a DI container.
To allow for BC, instance methods were renamed and a `__callStatic` magic method deals with finding them.
Tests were duplicated to test for static access and instance access.



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

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

Comment by Doctrine Bot [ 17/Dec/14 ]

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





[DDC-3454] [GH-1224] Updated setParameters function for not replace all parameters Created: 17/Dec/14  Updated: 17/Dec/14

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

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


 Description   

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

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

Message:

When you create QueryBuilder and you bind some parameters, if you use setParameters function after bind other parameters, previous parameters are removed(https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/QueryBuilder.php#L558). This would not be a problem if it was the same behaviour with the attribute $_parameterMappings (in ParserResult), but it's not the case, given that it keeps the number of parameters introduced, throwing an exception(https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Query.php#L293). To prevent this, I've made it initialize the setParameters with the existing ones.



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

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





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

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

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

Attachments: File DDC2838Test.php    
Issue Links:
Reference
is referenced by DCOM-249 Criteria are unable to locate getters... Open

 Description   

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

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

https://github.com/ptlis/DoctrineTestcase



 Comments   
Comment by Marco Pivetta [ 18/Aug/14 ]

We can't check out an entire project just to test a bug.

Please write an actual functional test case that can be integrated into the Doctrine ORM test suite.

Comment by brian ridley [ 20/Aug/14 ]

Hi,

i'm happy to do so - i'll take a look at this over the weekend.

Comment by Simon Paridon [ 12/Dec/14 ]

brian ridley: Any progress on this? This is currently an issue for us as well and hope to get fixed. I could look into converting it to a test for integration with the test suite if you don't have the time... but it might take a while since I have no experience with the requirements that should be met. (Plus, I am not sure how tightly coupled it is with your project)

Comment by Simon Paridon [ 17/Dec/14 ]

Hi Marco Pivetta, brian ridley,

I attached a functional Test that integrates with the test suite. Please let me know if I should issue a PR, and I'll do that this evening.





[DDC-3453] [GH-1223] Refactored construction of the EntityManager out to an EntityManagerFactory Created: 17/Dec/14  Updated: 17/Dec/14

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

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


 Description   

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

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

Message:

Added tests for the factory (needed to refactor the OrmTestCase so I could reuse mock config and mock connections).

This pattern is well established in Hibernate, I've been wondering why we don't have it in Doctrine.






[DDC-3452] [GH-1222] Embeddables in metadata builder Created: 17/Dec/14  Updated: 17/Dec/14

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

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


 Description   

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

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

Message:

Embeddables set the `$classMetadata->isEmbeddedClass = true` and sets `$classMetadata->isMappedSuperclass = false`, imitating the `switch` in xml / yml drivers.

Embeddeds have 2 methods, as other types have: `addEmbedded` is a one-off adder with fluent behavior, and `createEmbedded` returns an instance of `EmbeddedBuilder`. The class is very thin right now, but it's a good way to lay ground for improvements on embedded creation in the future.

This one is probably more useful than the last one, @Ocramius






[DDC-3450] Embeddables containing only nested embeddables are not hydrated properly Created: 16/Dec/14  Updated: 16/Dec/14

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

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


 Description   

I have the following object mapping:

Location (entity)

  • name <string>
  • bounds <Bounds>

Bounds (embeddable)

  • northeast <Coords>
  • southwest <Coords>

Coords (embeddable)

  • latitude <float>
  • longitude <float>

This setup works fine when persisting entities, the database schema is correct, etc. but when I fetch my `Location` entity afterwards the `bounds` property is wrong. It looks something like this. Calling `getBounds()` on `Location` returns something like:

Coords

  • latitude <float>
  • longitude <float>
  • northeast <Coords>
  • southwest <Coords>

As if the `Coords` embeddable has been transposed with the `Bounds` embeddable.

If I add another property to `Bounds` that isn't an embeddable (say a string) then it's hydrated correctly.



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

James Moss could you come up with a small test case in https://github.com/doctrine/doctrine2/tree/v2.4.7/tests/Doctrine/Tests/ORM/Functional/Ticket ?





[DDC-2589] [GH-746] Makes children of AbstractQuery non-final. Created: 05/Aug/13  Updated: 16/Dec/14  Resolved: 06/Aug/13

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

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


 Description   

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

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

Message:

b66d530540d18c60720e1843fc65ce7e0399a71c made these classes final, but there is no rationale for this change given in the commit log. Leaving this as final makes it impossible to mock and makes testing some areas of code difficult (or impossible).



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

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

Comment by Doctrine Bot [ 16/Dec/14 ]

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

Comment by Doctrine Bot [ 16/Dec/14 ]

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





[DDC-2587] [GH-744] Corrected PHP type for "decimal" mapping type Created: 03/Aug/13  Updated: 16/Dec/14  Resolved: 10/Aug/13

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

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


 Description   

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

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

Message:

"Basic Mapping" documentation says:
"decimal: Type that maps a SQL DECIMAL to a PHP string."



 Comments   
Comment by Doctrine Bot [ 10/Aug/13 ]

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

Comment by Doctrine Bot [ 16/Dec/14 ]

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

Comment by Doctrine Bot [ 16/Dec/14 ]

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





[DDC-3449] Single scalar Result and Hidden field Created: 15/Dec/14  Updated: 15/Dec/14

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

Type: Bug Priority: Minor
Reporter: Thomas Gallice Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I have try to get a single scalar result but my query contains a HIDDEN field. The result is the `NonUniqueResultException` exception.






[DDC-3448] @OrderBy on eager @OneToMany does not work Created: 13/Dec/14  Updated: 13/Dec/14

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

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


 Description   

generated code when eagerly fetching:

SELECT 
  t0.id AS id_8,
  t19.category_id AS category_id_23 
FROM 
  category t0 
  LEFT JOIN attribute_category t19 ON t19.category_id = t0.id 
WHERE 
  t0.id = ?

when fetching lazy the collection query has the ORDER BY clause






[DDC-2583] [GH-742] Cleaned up events.rst Created: 30/Jul/13  Updated: 13/Dec/14  Resolved: 25/Aug/13

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

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


 Description   

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

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

Message:

Was a mix-up between TestEventSubscriber and EventTest (e.g. the definition of TestEventSubscriber referenced TestEvent::preFoo, which did not exist). To clarify this I've renamed EventTest to TestEvent.

Tried to clarify the text in the Naming Convention section.

Added note that onClear is not a lifecycle callback.

Tried to clarify the definition of Lifecycle Callbacks.

Separated key/value descriptions into XML and YAML parts since the details are different

Added note in Implementing Event Listeners section that since 2.4 you do have access to EntityManager and UnitOfWork from lifecycle callbacks.

Added example about how to use the computed changeset to modify a primitive value in preUpdate section

Added naming convention example to Entity listeners class section

The other changes are typos and small fixes.



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

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

Comment by Marco Pivetta [ 25/Aug/13 ]

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

Comment by Doctrine Bot [ 13/Dec/14 ]

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





[DDC-2568] [GH-733] Update Parser.php Created: 24/Jul/13  Updated: 12/Dec/14  Resolved: 24/Jul/13

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

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


 Description   

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

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

Message:

Fix the docummentation for Parser::Literal()



 Comments   
Comment by Doctrine Bot [ 24/Jul/13 ]

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

Comment by Marco Pivetta [ 24/Jul/13 ]

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

Comment by Doctrine Bot [ 10/Dec/14 ]

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

Comment by Doctrine Bot [ 12/Dec/14 ]

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





[DDC-2562] [GH-730] To avoid "SpacingAfterParams" error with PHPCS Symfony2 coding standard Created: 22/Jul/13  Updated: 12/Dec/14  Resolved: 22/Jul/13

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

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


 Description   

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

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

Message:

Hello,
I added two blank lines in comments two avoid the following error with PHPCS Symfony2 coding standard :
Error Code: SpacingAfterParams
Error Description: Last parameter comment requires a blank new line after it.



 Comments   
Comment by Doctrine Bot [ 22/Jul/13 ]

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

Comment by Marco Pivetta [ 22/Jul/13 ]

Merged at https://github.com/doctrine/doctrine2/commit/8d2826c6334c705886d84768eb139b6be83bf386

Comment by Doctrine Bot [ 29/Nov/14 ]

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

Comment by Doctrine Bot [ 12/Dec/14 ]

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





[DDC-2582] [GH-741] Fixed DDC-1884. Created: 30/Jul/13  Updated: 12/Dec/14  Resolved: 08/Aug/13

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

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


 Description   

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

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

Message:

Fixed original failing test case provided in https://github.com/doctrine/doctrine2/pull/395 and highlighted as an issue in http://www.doctrine-project.org/jira/browse/DDC-1884



 Comments   
Comment by Doctrine Bot [ 30/Jul/13 ]

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

Comment by Doctrine Bot [ 30/Jul/13 ]

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

Comment by Fabio B. Silva [ 08/Aug/13 ]

Merged, For more details see : https://github.com/doctrine/doctrine2/pull/741

Comment by Doctrine Bot [ 18/Dec/13 ]

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

Comment by Doctrine Bot [ 12/Dec/14 ]

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

Comment by Doctrine Bot [ 12/Dec/14 ]

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





[DDC-3284] Yaml mapping. Comment on table and realtion Created: 29/Aug/14  Updated: 12/Dec/14

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

Type: Documentation Priority: Major
Reporter: Vladimir Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None
Environment:

Windows, XAMPP, PHP5.3, ZF2, Doctrine-ORM



 Description   

Is there any way to comment my tables and table relations with yml schema?
I can comment plain field like this

        prediction:
            type: text
            nullable: true
            length: null
            fixed: false
            options:                
                comment: 'program prediction'

But for relation:

        project:
            targetEntity: File\Entity\File
            cascade: {  }
            mappedBy: null
            inversedBy: null
            joinColumns:
                project:
                    referencedColumnName: id
            orphanRemoval: false
            options:                
                comment: 'File with project data'

Or for whole table:

Program\Entity\Program:
    type: entity
    table: program
    options:
        comment: 'State program table'

It doesn't work at all. When I perform migrations those comments are totally ignored. And I can't find any documentation for yml mapping table commenting



 Comments   
Comment by Steve Müller [ 29/Aug/14 ]

Commenting tables is a vendor specific feature and therefore not all database vendors support it. I think currently it is only possible to comment tables via mapping for MySQL. The mapping you provided for commenting tables should work however. See here: https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Mapping/Driver/YamlDriver.php#L247-L249
I'm not quite sure what you mean by commenting relations. Where would you expect Doctrine to add a comment to?

Comment by Vladimir [ 29/Aug/14 ]

I mean commenting a column that is a foreign key. Like 'project' column above that is a link to Files table and entity.

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

Unfortunately commenting columns part of an association mapping is not possible in ORM at the moment.

Comment by Martijn Zijlstra [ 09/Dec/14 ]

I tried doing this with annotations by adding a column annotation to the relation, but this effectively removed the relation alltogether. So no workaround yet.

Comment by Steve Müller [ 12/Dec/14 ]

Commenting foreign key columns is simply not supported yet via ORM mapping.





[DDC-2581] [GH-740] Synchronized support of FilterCollection with ODM by adding missing method Created: 30/Jul/13  Updated: 11/Dec/14  Resolved: 30/Jul/13

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

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


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 30/Jul/13 ]

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

Comment by Marco Pivetta [ 30/Jul/13 ]

Merged: https://github.com/doctrine/doctrine2/commit/0e010994a7588de868dc57b49d081a8a9a6e9b1d

Comment by Doctrine Bot [ 11/Dec/14 ]

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

Comment by Doctrine Bot [ 11/Dec/14 ]

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





[DDC-3441] Unidirectional ManyToOne Not Lazy Loading Created: 09/Dec/14  Updated: 11/Dec/14

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

Type: Bug Priority: Critical
Reporter: Marcus Fulbright Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: lazy-loading, proxy, public-properties, reflection

Issue Links:
Dependency
depends on DDC-3442 [GH-1217] @DDC3441 failing test cases... Open

 Description   

The Unidirectional ManyToOne association described in the docs does not lazy load correctly. The appropriate SQL will get executed, and the returned Proxy does pass type hinting for the correct class. However, the lazy loaded object always has the following properties:

  • _initializer_
  • _cloner_
  • _isInitialized_
  • lazyPropertiesDefaults

Any properties from the class definition do not show up. This is problematic when trying to get reflected properties and their values. Methods are correctly reflected.

Pull request for failing test case



 Comments   
Comment by Marcus Fulbright [ 09/Dec/14 ]

Let me know if anything else is needed.

Comment by Doctrine Bot [ 11/Dec/14 ]

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

Comment by Marco Pivetta [ 11/Dec/14 ]

Looks like a current ORM limitation (private properties lazy loading).

Related:





[DDC-3442] [GH-1217] @DDC3441 failing test cases for the ticket Created: 09/Dec/14  Updated: 11/Dec/14

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

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

Issue Links:
Dependency
is required for DDC-3441 Unidirectional ManyToOne Not Lazy Loa... Open

 Description   

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

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

Message:

Failing test cases for the ticket DDC-3441(http://www.doctrine-project.org/jira/browse/DDC-3441)



 Comments   
Comment by Marcus Fulbright [ 09/Dec/14 ]

I didn't realize a ticket would get automatically opened when I submitted a pull request. I already put relevant details for this in DDC-3441. This is a duplicate.

Comment by Doctrine Bot [ 11/Dec/14 ]

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





[DDC-3445] ERROR GENERATED VALUE (UUID) Created: 10/Dec/14  Updated: 11/Dec/14

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

Type: Bug Priority: Major
Reporter: MUHAMAD SURYA IKSANUDIN Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm, postgresql


 Description   

UUID is not working (missing ID and need to set manually)

/**
 * @ORM\Entity
 * @ORM\Table(name = "utl_role")
 */
class Role implements EntityInterface
{
    /**
     * @ORM\Id
     * @ORM\Column(name = "id", type = "guid")
     * @ORM\GeneratedValue(strategy = "UUID")
     **/
    protected $id;

===============================

i need to pass the id manually

$role->setId((new UuidGenerator())->generate($this->em, $role)); 

because the id is not set and error when i try to persist.

This error is arrive when i try to persist an entity i loop

================================

I use postgresql 9.3



 Comments   
Comment by Marco Pivetta [ 11/Dec/14 ]

Can you check this also against master (2.5-dev)?

Comment by MUHAMAD SURYA IKSANUDIN [ 11/Dec/14 ]

i think it same because the uuid generator is same

https://github.com/doctrine/doctrine2/blob/master/lib%2FDoctrine%2FORM%2FId%2FUuidGenerator.php#L42

in that code, i see the uuid is generated from database provider/platform, i suggest to use code base generator like

https://github.com/ramsey/uuid/blob/master/src%2FUuid.php

it just my suggestion

thanks





[DDC-2295] [GH-580] Second cache level POC Created: 14/Feb/13  Updated: 10/Dec/14  Resolved: 16/Dec/13

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

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


 Description   

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

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

Message:

Hi guys.

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

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

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

Collection Caching

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

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

      1. OPERATIONS
        1. INSERT :

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

        1. UPDATE :

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

        1. DELETE :

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

        1. USAGE :
```php
<?php

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

```php
<?php

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

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

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

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

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

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


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

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

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


 Comments   
Comment by Doctrine Bot [ 01/Oct/13 ]

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

Comment by Sergii Shymko [ 21/Nov/13 ]

Is the proposed solution going to allow to cache scalar properties of entities of specific type?

The behavior I'm looking for is the following:

  • Certain entity fields are explicitly marked as cached via annotation or something
  • Regardless of how a partially loaded entity is acquired (EM, repository, DQL), those fields are populated with the cached data
  • Getters for those fields simply return assigned values, not causing the full entity load, similarly to identifier fields
Comment by Marco Pivetta [ 22/Nov/13 ]

Sergii Shymko no, that is not covered. That would require a major overhaul in code generation tools and it would introduce major rewrites of the internal components. It's not covered here and is not really related with implementing the L2 Cache.

Comment by Pavel Sokolov [ 10/Dec/14 ]

When this will be merged to main Doctrine branch?

Comment by Marco Pivetta [ 10/Dec/14 ]

This was already merged in https://github.com/doctrine/doctrine2/issues/808

Comment by Pavel Sokolov [ 10/Dec/14 ]

I have tried to add Cache Annotation with Doctrine ORM 2.4.6:

/**

  • @ORM\Table(name="users")
  • @ORM\Cache()
    */

but I got error:

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

Is this cache implementation included in base Doctrine 2 ORM configuration?

Comment by Marco Pivetta [ 10/Dec/14 ]

This feature will land in 2.5, not 2.4.





[DDC-3447] Identifier Generation Strategy "UUID" is missing Created: 10/Dec/14  Updated: 10/Dec/14

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

Type: Documentation Priority: Minor
Reporter: David Fuhr Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: GeneratedValue


 Description   

The listing of the Identifier Generation Strategies as http://doctrine-orm.readthedocs.org/en/latest/reference/basic-mapping.html#identifier-generation-strategies misses the UUID.

The annotation reference contains the value for UUID http://doctrine-orm.readthedocs.org/en/latest/reference/annotations-reference.html#annref-generatedvalue

So it should be added at the "Identifier Generation Strategies"






[DDC-3446] [GH-1219] Comparison like/notlike support Created: 10/Dec/14  Updated: 10/Dec/14

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

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


 Description   

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

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

Message:

Support `Comparison::LIKE` and `Comparison::NOTLIKE` additionally to doctrine/collections#50

as alternative for #1150






[DDC-2580] [GH-739] Fix DDC-2579 Created: 29/Jul/13  Updated: 10/Dec/14  Resolved: 30/Jul/13

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

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


 Description   

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

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

Message:

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



 Comments   
Comment by Doctrine Bot [ 29/Jul/13 ]

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

Comment by Fabio B. Silva [ 30/Jul/13 ]

Merged : https://github.com/doctrine/doctrine2/commit/7055ccbf9bc9bd72b184734bcbeb72e682bf642b

Comment by Doctrine Bot [ 10/Dec/14 ]

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





[DDC-3439] [GH-1216] test XML export driver, the field options, for #1214 Created: 08/Dec/14  Updated: 10/Dec/14  Resolved: 10/Dec/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: export-xml, xml


 Description   

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

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

Message:

test for #1214



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

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

Comment by Doctrine Bot [ 10/Dec/14 ]

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

Comment by Doctrine Bot [ 10/Dec/14 ]

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





[DDC-3444] [GH-1218] Failing test case for cascading refresh Created: 09/Dec/14  Updated: 09/Dec/14

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

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


 Description   

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

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

Message:






[DDC-3438] [GH-1215] Don't make this class Final Created: 08/Dec/14  Updated: 09/Dec/14  Resolved: 08/Dec/14

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

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


 Description   

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

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

Message:

Why: It makes testing painful

https://github.com/phpspec/prophecy/issues/102



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

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

Comment by Doctrine Bot [ 09/Dec/14 ]

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





[DDC-2578] [GH-738] Modified Hydrators to be per-query instances instead of a singleton-like approach Created: 29/Jul/13  Updated: 09/Dec/14  Resolved: 30/Jul/13

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

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


 Description   

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

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

Message:

This fixes an old issue we have where we have a Query that triggers an entity-specific postLoad event which attempts to do another Query.
In this situation, developer will face an "Attempt to call method on a null object" error on PHP.



 Comments   
Comment by Doctrine Bot [ 29/Jul/13 ]

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

Comment by Fabio B. Silva [ 30/Jul/13 ]

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

Comment by Benjamin Eberlei [ 10/Aug/13 ]

Merged into 2.4 branch

Comment by Doctrine Bot [ 09/Dec/14 ]

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

Comment by Doctrine Bot [ 09/Dec/14 ]

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





[DDC-1987] Cascading "refresh" does not work on lazy loaded associations Created: 17/Aug/12  Updated: 09/Dec/14  Resolved: 31/Mar/13

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

Type: Bug Priority: Major
Reporter: Sascha Beining Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates DDC-2143 $em->refresh($entity) doesn't refresh... Resolved

 Description   

If the cascade option for an association includes the "refresh" keyword, the associated entites are only refreshed, if the collection is not lazy loaded.

The problem is that first the "parent" entity is reloaded, so the associations PersistentCollection is replaced with a new one that has not been initialized yet. And then in cascadeRefresh, the code explicitly avoids initializing that collection, so there will never be any entities in the wrapped ArrayCollection that the operation may cascade to.

I can see at least two possible solutions for this problem. One would be to swap the order of the operations, so that the cascading happens first. This would cascade based on the current object model state (pre-refresh), so entities that had been detached would not be refreshed.

The other would be to remember which collections had already been loaded, and to initialize the corresponding new collections before performing the cascading. That would cascade based on the refreshed state, so in this case, entities that had been newly attached would not be refreshed.

My current use-case would work with the first one, but I guess there will be some use-cases that would require the second one... :-/



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

Tricky issue. I share your analysis and ask myself if there is really a use-case for 2. If you ask for a refresh of the current state, that obviously means the current associations. Hence cascading first would be the solution here.

The problem is that the entities are still in memory and a consecutive access of the "new" collection returns them in their non-refreshed state.

You could help with solving this issue, can you create a TestCase like the ones in tests/Doctrine/Tests/ORM/Functional/Ticket/* and attach it here? It would be best against master, but ok if you do it against 2.1.7.

Comment by Marco Pivetta [ 23/Jan/13 ]

Sascha Beining 2.1 is not supported anymore. Can you verify if this behaviour is still reproducible in 2.3?

Comment by Alexander [ 10/Feb/13 ]

ping!

Comment by Benjamin Eberlei [ 31/Mar/13 ]

closing in favor of DDC-2143

Comment by Martijn Dwars [ 09/Dec/14 ]

I'm experiencing the same issue in 2.4.6. Should I create a new issue for this?

Comment by Marco Pivetta [ 09/Dec/14 ]

This issue was resolved as invalid: please design a test case before opening a new issue.





[DDC-3436] [GH-1212] [DDC-3108] Fix regression where join aliases were no longer accessible in Criteria expressions Created: 06/Dec/14  Updated: 08/Dec/14

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

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


 Description   

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

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

Message:

The solution to issue DDC-2764 was to blanket prefix all the fields with the root alias. The result was then impossible to use fields from multiple FROM tables or a JOIN.

This patch injects all available aliases into the comparison, if a field uses one of the aliases it will pass without modification. If it is an unknown alias it will prefix the first rootAlias listed using the same functionality as the deprecated getRootAlias() function.

Also improves the ORDER BY on Criteria expressions, again introduced by DDC-2764 using the above functionality, this was out of scope of bug DDC-3108.

Added unit tests to test new functionality.



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

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





[DDC-2765] [GH-830] [DDC-2764] Prefix criteria orderBy with rootAlias Created: 29/Oct/13  Updated: 08/Dec/14  Resolved: 02/Jan/14

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

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


 Description   

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

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

Message:

This fixes DDC-2764 by prefixing the QueryBuilder rootAlias to sortBy criteria.



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

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

Comment by Doctrine Bot [ 08/Dec/14 ]

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





[DDC-3440] <Inheritance SINGLE_TABLE> Entity merge not working with parent entity Created: 08/Dec/14  Updated: 08/Dec/14  Resolved: 08/Dec/14

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

Type: Bug Priority: Major
Reporter: Brian Nguyen Assignee: Marco Pivetta
Resolution: Cannot Reproduce Votes: 0
Labels: None


 Description   

I have problem when try to merge the ProfilePersonEntity, all the fields in ProfilePersonEntity was merged, but all another fields of parent class cannot.
I worked fine (wonderful) when i loaded with find(entity id), the DB data mapped 100% to the entity.

Please check the code below

ProfileEntity.php
======================================================================
/**

  • @Entity
  • @Table(name="PROFILE")
  • @InheritanceType("SINGLE_TABLE")
  • @DiscriminatorColumn(name="type", type="string")
  • @DiscriminatorMap( { * "Profile" = "ProfileEntity", * "ProfilePerson" = "ProfilePersonEntity", * "ProfileCompany" = "ProfileCompanyEntity" * }

    )
    */
    class ProfileEntity extends LockableEntity

    { /** * @Column(name="TYPE", type="string", length=15) */ private $type; /** * @Column(name="NAME", type="string", length=45) */ private $name; ... }

ProfilePersonEntity.php
======================================================================
/**

  • @Entity
    */
    class ProfilePersonEntity extends ProfileEntity { /** * @Column(name="LAST_NAME", type="string", length=45) */ private $lastName; ... }

LockableEntity.php
======================================================================
/** @MappedSuperclass */
class LockableEntity extends BaseEntity

{ /** @Column(name="LOCKED", type="string", nullable=true, length=45) */ private $lockOwner; ... }

BaseEntity.php
======================================================================
/**

  • @MappedSuperclass
  • @HasLifecycleCallbacks
    */
    class BaseEntity extends AbstractEntity { /** * @Id * @GeneratedValue * @Column(name="ID", type="integer") */ private $id; /** * @Version * @Column(name="VERSION", type="integer") */ private $version; ... }

...
$this->entityManager->merge($entity);
$this->entityManager->flush();
...



 Comments   
Comment by Marco Pivetta [ 08/Dec/14 ]

Cannot reproduce: missing reproducible test case.





[DDC-3425] [GH-1202] Checks key exists rather than isset Created: 03/Dec/14  Updated: 08/Dec/14  Resolved: 08/Dec/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: column-options, null, schema, table-options


 Description   

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

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

Message:

If the default value is set to `null`, `isset` will return `false` even though the key is actually there for a reason.



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

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

Comment by Doctrine Bot [ 08/Dec/14 ]

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





[DDC-3431] [GH-1207] Embedded classes reflection new instance creation with internal PHP classes Created: 05/Dec/14  Updated: 08/Dec/14  Resolved: 05/Dec/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: embeddables, instantiator, internal-php-classes, reflection

Issue Links:
Reference
is referenced by DDC-3437 [GH-1213] fix instantiation of embedd... Resolved

 Description   

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

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

Message:



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

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

Comment by Doctrine Bot [ 05/Dec/14 ]

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





[DDC-3437] [GH-1213] fix instantiation of embedded object in ReflectionEmbeddedProperty Created: 06/Dec/14  Updated: 08/Dec/14  Resolved: 08/Dec/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: abstract-class, embeddables, inheritance, reflection

Issue Links:
Reference
relates to DDC-3431 [GH-1207] Embedded classes reflection... Resolved

 Description   

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

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

Message:

Recently, ReflectionEmbeddedProperty was updated to extend ReflectionProperty. This broke any embeddable that extends an abstract class. That's because if a property is defined in the abstract class, <code>$this->class</code> is alway the abstract class and thus cannot be instantiated. The <code>$class</code> parameter that is passed into the constructor needs to be stored, and that class should be instantiated, not the the property's declaring class.



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

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

Comment by Doctrine Bot [ 08/Dec/14 ]

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





[DDC-2577] [GH-737] Skip not mapped public properties in SchemaValidator Created: 28/Jul/13  Updated: 05/Dec/14  Resolved: 10/Aug/13

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

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


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 10/Aug/13 ]

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

Comment by Doctrine Bot [ 05/Dec/14 ]

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





[DDC-2576] [GH-736] Skip not mapped public properties in SchemaValidator Created: 28/Jul/13  Updated: 05/Dec/14  Resolved: 30/Jul/13

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

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


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 28/Jul/13 ]

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

Comment by Fabio B. Silva [ 30/Jul/13 ]

Closed

Comment by Doctrine Bot [ 05/Dec/14 ]

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





[DDC-3427] Doctrine\ORM\Mapping\ClassMetadataFactory explicitly accepts EntityManager Created: 04/Dec/14  Updated: 05/Dec/14  Resolved: 05/Dec/14

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

Type: Bug Priority: Major
Reporter: Frank Wallen Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: orm
Environment:

Symfony2


Issue Links:
Dependency
depends on DDC-3432 [GH-1208] DDC-3427 - class metadata f... Resolved

 Description   

The setEntityManager only accepts instances of EntityManager thus blocking any objects extending EntityManager. It should expect EntityManagerInstance.






[DDC-3432] [GH-1208] DDC-3427 - class metadata factory should accept `EntityManagerInterface` instances Created: 05/Dec/14  Updated: 05/Dec/14  Resolved: 05/Dec/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: classmetadatafactory, entitymanager, entitymanagerinterface

Issue Links:
Dependency
is required for DDC-3427 Doctrine\ORM\Mapping\ClassMetadataFac... Resolved

 Description   

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

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

Message:

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



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

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

Comment by Doctrine Bot [ 05/Dec/14 ]

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





[DDC-3434] LimitSubqueryOutputWalker does not retain correct ORDER BY expression fields when dealing with HIDDEN sort fields Created: 05/Dec/14  Updated: 05/Dec/14  Resolved: 05/Dec/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: DQL, Tools
Affects Version/s: 2.4.4, 2.4.5, 2.4.6
Fix Version/s: 2.5, 2.4.7
Security Level: All

Type: Bug Priority: Major
Reporter: Marco Pivetta Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: dql, limitsubqueryoutputwalker, paginator

Issue Links:
Dependency
depends on DDC-3435 [GH-1211] DDC-3434 - paginator ignore... Resolved
Reference
relates to DDC-3336 Undefined property: Doctrine\ORM\Quer... Resolved
relates to DDC-1958 pager produces wrong results on postg... Resolved

 Description   

As per discussion in DDC-3336, the Doctrine\ORM\Tools\Pagination\LimitSubqueryOutputWalker does not retain the correct fields in the ORDER BY condition when one of the selected fields is marked as HIDDEN.

As an example, take a DQL query like:

SELECT a, a.name AS HIDDEN ord FROM Doctrine\Tests\ORM\Tools\Pagination\Author a ORDER BY ord DESC

This will result in an SQL query like:

SELECT DISTINCT id_0 FROM (SELECT a0_.id AS id_0, a0_.name AS name_1, a0_.name AS name_2 FROM Author a0_ ORDER BY name_2 DESC) dctrn_result

Removing the HIDDEN modifier will cause the query to produce the correct SQL:

SELECT DISTINCT id_0, name_2 FROM (SELECT a0_.id AS id_0, a0_.name AS name_1, a0_.name AS name_2 FROM Author a0_ ORDER BY name_2 DESC) dctrn_result ORDER BY name_2 DESC


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

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





[DDC-3435] [GH-1211] DDC-3434 - paginator ignores `HIDDEN` fields in `ORDER BY` query Created: 05/Dec/14  Updated: 05/Dec/14  Resolved: 05/Dec/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: DQL, Tools
Affects Version/s: 2.4.4, 2.4.5, 2.4.6
Fix Version/s: 2.5, 2.4.7
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: dql, limitsubqueryoutputwalker, paginator

Issue Links:
Dependency
is required for DDC-3434 LimitSubqueryOutputWalker does not re... Resolved

 Description   

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

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

Message:

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



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

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

Comment by Doctrine Bot [ 05/Dec/14 ]

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





[DDC-3336] Undefined property: Doctrine\ORM\Query\AST\SimpleArithmeticExpression::$field Created: 04/Oct/14  Updated: 05/Dec/14  Resolved: 05/Dec/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: DQL, Tools
Affects Version/s: 2.4.4, 2.4.5, 2.4.6
Fix Version/s: 2.5, 2.4.7
Security Level: All

Type: Bug Priority: Critical
Reporter: Glen Ainscow Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: ast, dql, limitsubqueryoutputwalker, paginator

Issue Links:
Dependency
depends on DDC-3433 [GH-1210] DDC-3336 - undefined proper... Resolved
Reference
relates to DDC-1958 pager produces wrong results on postg... Resolved
is referenced by DDC-3434 LimitSubqueryOutputWalker does not re... Resolved

 Description   

I upgraded from 2.4.1 to 2.4.4, and now I'm seeing this notice here & there:

Undefined property: Doctrine\ORM\Query\AST\SimpleArithmeticExpression::$field in /*/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/Pagination/LimitSubqueryOutputWalker.php on line 200

This seems to be in a method with the description "Generates new SQL for Postgresql or Oracle if necessary." ... but we're on MySQL (Percona).



 Comments   
Comment by Glen Ainscow [ 05/Oct/14 ]

Changed this to critical. It's also screwing up ordering, for example:

SELECT tp, p, CASE WHEN tp.memberTo IS NULL THEN 1 ELSE 0 END AS HIDDEN ord FROM Tournaments_Model_TeamPlayer tp INNER JOIN tp.player p LEFT JOIN p.user u WHERE tp.team = ?1 ORDER BY ord DESC, tp.memberFrom ASC

The paginator doesn't order the data correctly unless I remove the 2nd order by (tp.memberFrom ASC). The generated SQL from the QB/DQL is correct, so the paginator must be messing something up.

See: http://www.doctrine-project.org/jira/browse/DDC-1958?focusedCommentId=24010&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-24010

Comment by Marco Pivetta [ 13/Oct/14 ]

Need a test case in order to verify the issue

Comment by Glen Ainscow [ 26/Oct/14 ]

Okay, try this:

        $qb->from('Team', 't')
              ->select('t')
              ->orderBy('(1-1000)*1', 'DESC')
              ->getQuery()
              ->getResult();

This is simplified, the actual query works with field values, like this:

        ->orderBy('(((t.eloRating-1000)*t.reliability) + 1000)', 'DESC')

This causes the first issue.

Comment by Glen Ainscow [ 26/Oct/14 ]

The second issue is explained by Guilherme Santos.

Comment by Marco Pivetta [ 05/Dec/14 ]

The first comment goes to a new issue.

Comment by Marco Pivetta [ 05/Dec/14 ]

Moved that issue to DDC-3434

Comment by Doctrine Bot [ 05/Dec/14 ]

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

Comment by Doctrine Bot [ 05/Dec/14 ]

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





[DDC-2573] [GH-735] Fix proxy performance test Created: 26/Jul/13  Updated: 05/Dec/14  Resolved: 27/Jul/13

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

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


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 27/Jul/13 ]

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

Comment by Marco Pivetta [ 27/Jul/13 ]

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

Comment by Doctrine Bot [ 05/Dec/14 ]

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

Comment by Doctrine Bot [ 05/Dec/14 ]

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





[DDC-3433] [GH-1210] DDC-3336 - undefined property with paginator walker and scalar expression in ORDER BY clause Created: 05/Dec/14  Updated: 05/Dec/14  Resolved: 05/Dec/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: DQL, Tools
Affects Version/s: 2.4.4, 2.4.5, 2.4.6
Fix Version/s: 2.5, 2.4.7
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: ast, dql, limitsubqueryoutputwalker, paginator

Issue Links:
Dependency
is required for DDC-3336 Undefined property: Doctrine\ORM\Quer... Resolved

 Description   

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

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

Message:

Ping @glen-84

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



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

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





[DDC-1958] pager produces wrong results on postgresql Created: 30/Jul/12  Updated: 05/Dec/14  Resolved: 12/Nov/12

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

Type: Bug Priority: Major
Reporter: Miha Vrhovnik Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 1
Labels: paginator
Environment:
  • Postgres 9.1, 9.2
  • PHP 5.4

Issue Links:
Reference
is referenced by DDC-3336 Undefined property: Doctrine\ORM\Quer... Resolved
is referenced by DDC-3434 LimitSubqueryOutputWalker does not re... Resolved
Sub-Tasks:
Key
Summary
Type
Status
Assignee
DDC-2593 Same bug occurs in MariaDB 5.5 Sub-task Resolved Marco Pivetta  
DDC-2729 Same bug affects SQLServer2008Platform Sub-task Open Benjamin Eberlei  

 Description   

The query build by pager to get the subset of PKs to fetch produces wrong results on potgresql (and probably any database), that conforms to the SQL standard. The standard says, that if you wish to have the results in specific order, then you have to specify that by using an ORDER BY clause. If such a clause is not present the database can return the results in whatever order it sees fit.

Testcase fixtures:

CREATE TABLE test (
    id integer,
    name text
);

INSERT INTO test VALUES (1, 'c');
INSERT INTO test VALUES (2, 'a');
INSERT INTO test VALUES (3, 'e');
INSERT INTO test VALUES (4, 'b');
INSERT INTO test VALUES (5, 'd');
INSERT INTO test VALUES (6, 'a');
INSERT INTO test VALUES (7, 'g');
INSERT INTO test VALUES (8, 'h');
INSERT INTO test VALUES (9, 'e');
INSERT INTO test VALUES (10, 'j');

Passing f.e.

$qb = $this->repository
    ->createQueryBuilder('t')
    ->select('t')
    ->setFirstResult(0)
    ->setMaxResults(5)
    ->addOrderBy('t.name', 'ASC')

to pager produces SQL like this modified for readability

SELECT DISTINCT id FROM (
    SELECT id, name FROM test ORDER BY name
  ) dctrn_result
  LIMIT 5 OFFSET 0

Now there is nothing wrong with this modified query per se, but there is no ORDER BY clause in the outer query so according to the standard the DB can choose whatever order it seems fit. Now mysql chooses the same order, but postgresql does not and it's probably not the only DB doing so.

If you are interested in the results, this is the output I'm seeing:

  • postgresql: 8,4,1,5,3
  • mysql : 2,6,4,1,5

I and my coworker came to the standard compliant solution it was also tested on the dataset above on both postgresql and mysql and it produced equal results. We have found only one corner case this won't work and IMHO that can't be fixed. The problem is when you do a sort on a field from a table that is in 1:n relation to the main table.. e.g tables posts and tags, where one post can have a multiple tags and you want your results sorted by a tag.

Recipe for a correct query is:

  • remember the ORDER BY fields from original query and then remove them
  • wrap the original query with a DISTINCT query, but add the fields from ORDER BY to the SELECT part of that query and add the whole ORDER BY to the end of it, also add the PK to the order by clause, and add the LIMIT clause
  • wrap the resulting query into another query and select just the id.

so if I take the example from above the SQL should look like this:

SELECT id FROM (
  SELECT DISTINCT id, name FROM (
    SELECT id, name FROM test
  ) dctrn_result_inner
  ORDER BY name, id LIMIT 5 OFFSET 0
) dctrn_result


 Comments   
Comment by Jean-Philippe THEVENOUX [ 08/Nov/12 ]

I reproduce same problem with Postgres 7.4, Doctrine 2.3 whereas with doctrine 2.2, all is fine
Hope there'll a fix in next doctrine version

Comment by Raymond Kolbe [ 09/Apr/13 ]

http://www.doctrine-project.org/jira/browse/DDC-1800 This relates.

I just published a PR for an Oracle fix, but your solution appears to work for Oracle as well (issue is the same).

Comment by Bojidar Hristov [ 06/Aug/13 ]

Same bug occurs in MariaDB 5.5.

I commented out check for PostgreSQL and it works fine. Can you fix it for MariaDB too? Thanks

Comment by Guilherme Santos [ 21/Aug/14 ]

I make a ORDER BY with a HIDDEN field and this still happen to me! Like this:
$qb->addSelect('CASE WHEN p.description LIKE :description THEN 0 ELSE 1 END HIDDEN relevance')->addOrderBy('relevance');

This order by is ignored causing the same error!

In this line https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Query/SqlWalker.php#L1310
you don't add to ResultSetMapping so when you verifying in function preserveSqlOrdering the field doesn't exists!

Comment by Liam O'Boyle [ 16/Sep/14 ]

I've just been bitten by the "corner case" described above, "the problem is when you do a sort on a field from a table that is in 1:n relation to the main table.. e.g tables posts and tags, where one post can have a multiple tags and you want your results sorted by a tag.".

This is a pretty significant bug, as the end result is that data that should come back from the query doesn't. While there probably isn't a good universal workaround, the MySQL behaviour before this was already correct because the outer query was returning the ids in the same order as the internal query (even though it isn't required to by the standard). Is it possible to avoid having this apply to MySQL so that it doesn't introduce an additional bug in an attempt to fix an issue that doesn't apply to that platform anyway?

Comment by Miha Vrhovnik [ 16/Sep/14 ]

@Liam As you can se above the same applies to mariadb and if you look at the issues on the githubs doctrine project page you'll see that there is the same problem with newer mysql releases. AS I've written above. this corner case cannot be solved.

Comment by Liam O'Boyle [ 16/Sep/14 ]

Thanks Miha. I couldn't find this on the github page so didn't realise that it was affecting some newer MySQL releases (it didn't seem to affect mine, 5.5). If that's the case, then as you point out it can't even be fixed for MySQL.

Perhaps the lack of support could be more explicit instead? If you attempt to use the paginator with two FROM tables then a RuntimeException is thrown, if we did the same when the ORDER BY conditions applied to tables joined via a 1:m relationship then at least users would know that things were going wrong rather than getting strangely unpredictable results.





[DDC-2561] [GH-729] add missing hint about lifecycle callback Created: 22/Jul/13  Updated: 04/Dec/14  Resolved: 10/Aug/13

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

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


 Description   

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

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

Message:

the hint that this event is not also a lifecycle callback was missing for two of the event types.



 Comments   
Comment by Doctrine Bot [ 10/Aug/13 ]

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

Comment by Doctrine Bot [ 04/Dec/14 ]

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





[DDC-3430] [GH-1206] matching should not change critera Created: 04/Dec/14  Updated: 04/Dec/14

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

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


 Description   

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

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

Message:

The matching should behave like in ArrayCollection, where it is not changed.
The criteria should be cloned so that it could be used for more than one matching operation.






[DDC-3417] [GH-1195] Correction Events.rs - Entity Listeners Resolver Created: 27/Nov/14  Updated: 04/Dec/14  Resolved: 04/Dec/14

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

Type: Documentation Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: configuration, entitymanager, listener, resolve-target-entities, resolver, tools

Issue Links:
Reference
relates to DDC-3412 [GH-1193] Fix allow 'implementing you... Resolved

 Description   

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

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

Message:

Configuring the Entity Listener Resolver can only be done before Entity Manager is initialized as described here https://github.com/doctrine/doctrine2/pull/1193



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

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

Comment by Doctrine Bot [ 04/Dec/14 ]

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

Comment by Doctrine Bot [ 04/Dec/14 ]

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





[DDC-3412] [GH-1193] Fix allow 'implementing your own resolver' to work. Created: 25/Nov/14  Updated: 04/Dec/14  Resolved: 26/Nov/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: configuration, entitymanager, listener, resolver

Issue Links:
Reference
is referenced by DDC-3417 [GH-1195] Correction Events.rs - Enti... Resolved

 Description   

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

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

Message:

When the ListenersInvoker class is initialized, the Entity Listener Resolver is instantiated within the constructor and stored as a property onto the ListenersInvoker class; this doesn't work. When a User implements and set his or her own Entity Listener Resolver, it is ignored because because the Entity Listener Resolver has already been stored onto the class.

Instead of calling getEntityListenerResolver within the constructor, getEntityListenerResolver is called when resolving the User's EntityListenerResolver.



 Comments   
Comment by Doctrine Bot [ 26/Nov/14 ]

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

Comment by Doctrine Bot [ 26/Nov/14 ]

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

Comment by Marco Pivetta [ 26/Nov/14 ]

The listeners resolver is not supposed to be swapped out at runtime.

Comment by Doctrine Bot [ 26/Nov/14 ]

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

Comment by Doctrine Bot [ 04/Dec/14 ]

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





[DDC-3428] [GH-1204] Fix sequence-generator in MetaData exporter for XML Driver. Created: 04/Dec/14  Updated: 04/Dec/14  Resolved: 04/Dec/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: convert-mapping, export-xml, mapping, xml


 Description   

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

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

Message:

Make XMLExporter writes sequence-generator if a definition about it exists.



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

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

Comment by Doctrine Bot [ 04/Dec/14 ]

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





[DDC-3429] [GH-1205] Hotfix - #1200 symfony 2.7 deprecation fixes Created: 04/Dec/14  Updated: 04/Dec/14  Resolved: 04/Dec/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: console, symfony, yaml

Issue Links:
Reference
relates to DDC-3422 [GH-1200] Fix Yaml::parse() errors Resolved

 Description   

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

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

Message:

See #1200



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

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

Comment by Doctrine Bot [ 04/Dec/14 ]

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





[DDC-3422] [GH-1200] Fix Yaml::parse() errors Created: 30/Nov/14  Updated: 04/Dec/14  Resolved: 04/Dec/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Incomplete Votes: 0
Labels: console, yaml

Issue Links:
Reference
is referenced by DDC-3429 [GH-1205] Hotfix - #1200 symfony 2.7 ... Resolved

 Description   

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

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

Message:

Of course this might be just a temporary fix for:

"The ability to pass file names to Yaml::parse() was deprecated in 2.7 and will be removed in 3.0. Please, pass the contents of the file instead."



 Comments   
Comment by Doctrine Bot [ 01/Dec/14 ]

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

Comment by Doctrine Bot [ 04/Dec/14 ]

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





[DDC-3424] Class Table Inheritance - wrong table order on insert with more than one level of inheritance Created: 02/Dec/14  Updated: 04/Dec/14

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

Type: Bug Priority: Major
Reporter: mohammed Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: ORM
Environment:

Mysql



 Description   

when i use class table inheritance with multiple levels in doctrine :
Account<=User<=Dealer
(Dealer inherits from User, User from Account)
Account has the discriminator column and mapping.
when i persist a new Dealer entity I get a foreign key error because there is no row in the User table.
So the order in which the insert statements are executed:
1) Insert into Account
2) Insert into Dealer (which causes the error)
3) insert into User
Can someone help me thanks in advance.



 Comments   
Comment by Marco Pivetta [ 02/Dec/14 ]

Is this also valid for 2.4.x and master? 2.3.3 is a very old version.

Additionally, could you come up with a small reproduction test case? You can check the ones at https://github.com/doctrine/doctrine2/tree/v2.4.6/tests/Doctrine/Tests/ORM/Functional/Ticket for reference

Comment by mohammed [ 03/Dec/14 ]

This is also valid for 2.4.x and master
this is the test case https://github.com/rogerghost/doctrine2/blob/patch-1/tests/Doctrine/Tests/ORM/Persisters/DDC3424Test.php





[DDC-3426] [GH-1203] DDC3424Test.php Created: 03/Dec/14  Updated: 03/Dec/14  Resolved: 03/Dec/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Incomplete Votes: 0
Labels: None


 Description   

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

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

Message:

the problem consists in the insert's ordre



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

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

Comment by Doctrine Bot [ 03/Dec/14 ]

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

Comment by Steve Müller [ 03/Dec/14 ]

Closed by the contributor.





[DDC-2565] [GH-731] [DDC-2564] - PersistentCollection - initialize coll Created: 22/Jul/13  Updated: 02/Dec/14  Resolved: 23/Jul/13

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

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


 Description   

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

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

Message:

Initialize coll (the persisted collection) when using methods in the Doctrine\Common\Collection\Collection interface.



 Comments   
Comment by Austin Morris [ 22/Jul/13 ]

This is a duplicate of DDC-2564.

Comment by Marco Pivetta [ 23/Jul/13 ]

Duplicate of DDC-2564

Comment by Doctrine Bot [ 31/Jul/13 ]

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

Comment by Doctrine Bot [ 02/Dec/14 ]

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





[DDC-2559] [GH-728] Color message like the update tools Created: 19/Jul/13  Updated: 02/Dec/14  Resolved: 22/Jul/13

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

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


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 22/Jul/13 ]

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

Comment by Marco Pivetta [ 22/Jul/13 ]

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

Comment by Doctrine Bot [ 26/Nov/14 ]

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

Comment by Doctrine Bot [ 02/Dec/14 ]

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





[DDC-3181] Class Table Inheritance - wrong table order on insert with more than one level of inheritance Created: 20/Jun/14  Updated: 02/Dec/14

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

Type: Bug Priority: Major
Reporter: M. de Lange Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: orm
Environment:

oracle



 Description   

note: this issue seems the same as DDC-732

When using class table inheritance with multiple levels i.e.:
Object -> SolidObject -> Building -> House
(House inherits from Building, Building from SolidObject, SolidObject from Object)

Object has the discriminator column and mapping. When persisting a new House entity I get a foreign key error because there is no row in the Building table.

I searched in the Code and found the problem. In the class "Doctrine\ORM\Persisters\JoinedSubclassPersister" in function "executeInserts()" around line 146 the array $subTableStmts is first declared and then filled with insert statements. The statement of the House-table is first added, and then the parent-tables (except the root-table "Object", since that one is executed first).

So the order in which the insert statements are executed is:
1 Insert into Object ...
2 Insert into House ... (which causes the error)
3 insert into Building ...
4 Insert into SolidObject

I edited the source to insert into the parent-tables (first SolidObject, then Building) before inserting into the table that belongs to the class that is persisted (House). And this works



 Comments   
Comment by mohammed [ 26/Nov/14 ]

hello, can you please send me the modified lines or just share with me the whole method executeInserts.
thanks in advance





[DDC-1825] generate entities with traits Created: 18/May/12  Updated: 01/Dec/14

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

Type: Improvement Priority: Major
Reporter: Matthias Breddin Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 5
Labels: None
Environment:

php 5.4.3, symfony2.1-dev
php 5.5.12, symfony 2.5



 Description   

When a trait with included setters and getters is used and generate entities is called, doctrine add another set of getters and setters to the "main" entity where the trait is used.



 Comments   
Comment by Martin Aarhof [ 01/May/14 ]
/**
 * @ORM\Entity
 */
class Product {
    use Traits\Created;

    /**
     * @var integer
     *
     * @ORM\Column(name="id", type="integer")
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    private $id;

    /**
     * @var string
     *
     * @ORM\Column(name="name", type="string", length=255)
     */
    private $name;

    /**
     * Set name
     *
     * @param string $name
     * @return Attribute
     */
    public function setName($name)
    {
        $this->name = $name;

        return $this;
    }

    /**
     * Get name
     *
     * @return string 
     */
    public function getName()
    {
        return $this->name;
    }

}
Trait Created {
    /**
     * @var \DateTime $created
     *
     * @Gedmo\Timestampable(on="create")
     * @ORM\Column(type="datetime")
     */
    private $created;

    /**
     * @return \DateTime
     */
    public function getCreated()
    {
        return $this->created;
    }
}

Now when I run php app/console doctrine:generate:entities it copies everything from the trait and into the entity, so the entity now looks like

/**
 * @ORM\Entity
 */
class Product {
    use Traits\Created;

    /**
     * @var integer
     *
     * @ORM\Column(name="id", type="integer")
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    private $id;

    /**
     * @var string
     *
     * @ORM\Column(name="name", type="string", length=255)
     */
    private $name;

    /**
     * Set name
     *
     * @param string $name
     * @return Attribute
     */
    public function setName($name)
    {
        $this->name = $name;

        return $this;
    }

    /**
     * Get name
     *
     * @return string 
     */
    public function getName()
    {
        return $this->name;
    }

    /**
     * @var \DateTime $created
     *
     * @Gedmo\Timestampable(on="create")
     * @ORM\Column(type="datetime")
     */
    private $created;

    /**
     * @return \DateTime
     */
    public function getCreated()
    {
        return $this->created;
    }

}

And ofcourse invalidates the entity because it now has two methods of the getCreated and two of private $created

Comment by Wilgert Velinga [ 01/Dec/14 ]

Unfortunately I am also suffering from this bug. Is there anything I can do to help resolve it?





[DDC-3174] Query Cache not correct working when using SQLFilter Created: 17/Jun/14  Updated: 01/Dec/14

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

Type: Bug Priority: Major
Reporter: Benno Eggnauer Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: cache, sqlfilter


 Description   

We have an SQLFilter to filter on entities with a specific Trait implemented. The filter is very easy:

$res = $targetTableAlias . '.agency_id = ' . $this->getCurrentAgencyId();

On our system we have the query cache enabled, this works as long the "AgencyId" doesn't change. When the ID changes, the query cache seems to return the wrong (old cache) query.



 Comments   
Comment by Marco Pivetta [ 17/Jun/14 ]

I'm not sure if this case should be contemplated by the ORM. Filters are low-level and supposed to be stateless (services).

Comment by Benno Eggnauer [ 17/Jun/14 ]

OK, we can disable the query cache for this case. But then should at least the documentation be updated, which explicitly mentions to use filter for locales, which are also not stateless: http://doctrine-orm.readthedocs.org/en/latest/reference/filters.html#example-filter-class

Also in the query cache chapter: http://doctrine-orm.readthedocs.org/en/latest/reference/caching.html#query-cache

It is highly recommended that in a production environment you cache the transformation of a DQL query to its SQL counterpart. It doesn’t make sense to do this parsing multiple times as it doesn’t change unless you alter the DQL query.

Comment by Marco Pivetta [ 17/Jun/14 ]

Benno Eggnauer can you eventually provide a pull request?

Comment by James Blizzard [ 01/Dec/14 ]

I would just like to say that we're having exactly the same issue. I'd love some method (official or not) of having filters being taken into account in this situation.





[DDC-3423] Column Ordering when creating tables using doctrine:schema:update Created: 01/Dec/14  Updated: 01/Dec/14

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

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


 Description   

When you have a Base class (annotated with @MappedSuperClass) having some columns, say, createdById, createdDateTime and child entities deriving from the BaseClass, the ordering of the SQL when running doctrine:schema:update looks like

createdById
createdDateTime
id
field1
field2

i.e. the columns of the Base class come up first and then that of the children. It looks odd when you write a SQL to insert into these tables because the default ordering is not what you expect (Which would be derived class columns first and then base class).

I looked into ClassMetadataFactory that adds the fields to the classmetadata and figured if we could move the following
$this->addInheritedFields($class, $parent);
$this->addInheritedRelations($class, $parent);

to after the point where the local fields are added to the classmetadata, this problem is solved.

It might be even better if we have an annotation to specify the Ordering of columns but nevertheless this will help in cases where the base class columns appear after the derived class columns.

Note: Did look into columnDefinition annotation to specify a "AFTER <column>", but that cannot be used during CREATE TABLE, only for ALTER TABLE and that too, its mysql specific.






[DDC-3230] Bug in clear cache Created: 25/Jul/14  Updated: 30/Nov/14

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

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

Windows 7 64bits
PHP 5.5.4 32 bits
pdo_sql_srv 3.0.2 for php 5.5 32 bits
symfony 2.5
gedmo deletable @ dev-master
Redis 2.8.12
PHPRedis php_redis-2.2.5-5.5-nts-vc11-x86
IIS 7.5



 Description   

1. Redis is used for cache/meta/result caching.
2. Entity has property $deleted with gedmo deletable on it.
3. Removing property $deleted (and all related annotations)
4. Symfony commands:

php app/console doctrine:cache:clear-metadata
php app/console doctrine:cache:clear-query
php app/console doctrine:cache:clear-result
php app/console cache:clear --env=prod --no-debug <-- error on this command

5. [ReflectionException]
Property Entity::$deleted does not exist

Trace:

#0 \vendor\doctrine\orm\lib\Doctrine\ORM\Mapping\ClassMetadataInfo.php(989)
#1 \vendor\doctrine\orm\lib\Doctrine\ORM\Mapping\ClassMetadataFactory.php(571)
#2 \vendor\doctrine\common\lib\Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory.php(210) <-- CacheRedis driver called here
#3 \vendor\doctrine\common\lib\Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory.php(114)
#4 \vendor\symfony\symfony\src\Symfony\Bridge\Doctrine\CacheWarmer\ProxyCacheWarmer.php(69)
#5 \vendor\symfony\symfony\src\Symfony\Component\HttpKernel\CacheWarmer\CacheWarmerAggregate.php(48)
#6 \app\bootstrap.php.cache(2513)
#7 \app\bootstrap.php.cache(2284)
#8 \vendor\symfony\symfony\src\Symfony\Bundle\FrameworkBundle\Command\CacheClearCommand.php(128)
#9 \vendor\symfony\symfony\src\Symfony\Bundle\FrameworkBundle\Command\CacheClearCommand.php(90)
#10 \vendor\symfony\symfony\src\Symfony\Component\Console\Command\Command.php(252)
#11 \vendor\symfony\symfony\src\Symfony\Component\Console\Application.php(894)
#12 \vendor\symfony\symfony\src\Symfony\Component\Console\Application.php(193)
#13 \vendor\symfony\symfony\src\Symfony\Bundle\FrameworkBundle\Console\Application.php(96)
#14 \vendor\symfony\symfony\src\Symfony\Component\Console\Application.php(124)
#15 \app\console(27)

Why do i think this is a Doctrine bug and not a Symfony bug? Because

php app/console doctrine:cache:clear-metadata
php app/console doctrine:cache:clear-query
php app/console doctrine:cache:clear-result

have been called successfully so RedisCache should not return cache with $this->fieldMappings containing key "deleted"



 Comments   
Comment by Erik Verheij [ 30/Nov/14 ]

As a workaround I figured out that when you add the --flush flag it works as expected. You can read some documentation about what's going in this file; https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Tools/Console/Command/ClearCache/MetadataCommand.php#L44.

orm:clear-cache:metadata --flush





[DDC-3420] [GH-1198] Tables for buttons. Created: 28/Nov/14  Updated: 28/Nov/14  Resolved: 28/Nov/14

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

Type: Documentation Priority: Trivial
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: badges


 Description   

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

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

Message:






[DDC-3404] [GH-1188] Fixed counting exception Created: 20/Nov/14  Updated: 28/Nov/14  Resolved: 27/Nov/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: DQL, Tools
Affects Version/s: 2.4.6
Fix Version/s: 2.5, 2.4.7
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: count, paginator, parameters


 Description   

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

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

Message:

Fixed "Invalid parameter number: number of bound variables does not match number of tokens " exception during execution count on Query where select part of query contains :parameters.



 Comments   
Comment by Doctrine Bot [ 27/Nov/14 ]

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

Comment by Doctrine Bot [ 27/Nov/14 ]

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





[DDC-3421] [GH-1199] minor typo Created: 28/Nov/14  Updated: 28/Nov/14  Resolved: 28/Nov/14

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

Type: Documentation Priority: Trivial
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: dql, typo


 Description   

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

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

Message:

Fixed case in DQL query in docs.



 Comments   
Comment by Doctrine Bot [ 28/Nov/14 ]

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

Comment by Doctrine Bot [ 28/Nov/14 ]

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





[DDC-3418] Indexes not inherited from mapped superclass Created: 27/Nov/14  Updated: 27/Nov/14  Resolved: 27/Nov/14

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

Type: Improvement Priority: Minor
Reporter: Dustin Thomson Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: ddl, index, inheritance, mappedsuperclass, mapping

Issue Links:
Duplicate
duplicates DDC-3419 [GH-1196] Inherit indexes from mapped... Resolved
Reference
relates to OXM-2 Mapped-superclass, indexes not gathered Open
relates to DDC-3273 EntityGenerator writes @ORM\Table ann... Open

 Description   

Index definitions on mapped super classes are not inherited by their sub-classes.
I realize this makes the definition of the mapped super-class look a bit weird as it requires it to have a @Table element which isn't strictly valid since there is no corresponding table in the database.
However, it would be nice to set indices on the mapped superclass where the fields are actually defined as this increased comprehension and reduces maintenance.



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

Handled in DDC-3419





[DDC-3419] [GH-1196] Inherit indexes from mapped superclass Created: 27/Nov/14  Updated: 27/Nov/14  Resolved: 27/Nov/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: ddl, index, inheritance, mappedsuperclass, mapping

Issue Links:
Duplicate
is duplicated by DDC-3418 Indexes not inherited from mapped sup... Resolved

 Description   

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

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

Message:

Patch to allow entities to inherit indexes from their mapped superclasses.

More info here:
http://www.doctrine-project.org/jira/browse/DDC-3418



 Comments   
Comment by Doctrine Bot [ 27/Nov/14 ]

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

Comment by Doctrine Bot [ 27/Nov/14 ]

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





[DDC-3273] EntityGenerator writes @ORM\Table annotation for mapped superclass Created: 26/Aug/14  Updated: 27/Nov/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: Tools
Affects Version/s: 2.4.4, 2.4.5, 2.4.6
Fix Version/s: None
Security Level: All

Type: Bug Priority: Minor
Reporter: Jakab Adam Balazs Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: generation, orm, tools
Environment:

not relevant


Issue Links:
Reference
is referenced by DDC-3418 Indexes not inherited from mapped sup... Resolved

 Description   

file /doctrine/orm/lib/Doctrine/ORM/Tools/EntityGenerator.php method: generateTableAnnotation returns @ORM\Table annotation even for mapped superclass entities. Since classes with annotation @ORM\MappedSuperclass are only to be extended and will NOT have a database table associated to them they should not have '@ORM\Table' annotation at all.
It would be enough to wrap the method body with `if ($metadata->isMappedSuperclass)

{ ... }

`.






[DDC-3413] Types are always ignored when performing a one to many statement Created: 26/Nov/14  Updated: 27/Nov/14

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

Type: Bug Priority: Major
Reporter: Edouard COLE Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: persister


 Description   

BasicEntityPersister#getOneToManyStatement() is building an array named $criteria. This array is built this way:

$criteria[$tableAlias . "." . $targetKeyColumn] = ...;

This means this array is indexed by keys looking like that:

t0.fieldName

But the function BasicEntityPersister#expandParameters() is used in this function, and this function is NOT able to handle SQL field name as keys, but PHP attributes, because it uses BasicEntityPersister#getType() which is doing this:

case (isset($this->class->fieldMappings[$field])):
case (isset($this->class->associationMappings[$field])):

I think the $criteria array should be used to call BasicEntityPersister#getSelectSQL(), but another array should be passed to expandParameters. Here is a potential fix:

$cleanCriteria[$owningAssoc['fieldName']] = $criteria[$tableAlias . "." . $targetKeyColumn] = ...;

And $cleanCriteria should be passed to expandParameters.



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

Edouard COLE I suggest you to open a pull request with a failing test case, otherwise this issue is hard to follow/understand.





[DDC-3416] using getArrayResult and foreach with reference get a string at the end Created: 26/Nov/14  Updated: 26/Nov/14

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

Type: Bug Priority: Minor
Reporter: sysko Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

doctrine2 alone, not inside symfony or any framework



 Description   

This bug is quite weird so let me explain it

I have 2 Entity

Category (language independant information)

CategoryDescription (language dependant category 1 -> N categoryDescription)

when i do

        $categories = $this->createQueryBuilder('Entity\Category')
            ->select('c')
            ->distinct()
            ->from('Entity\Category', 'c')
            ->getQuery()
            ->getArrayResult();
        ;

        foreach ($categories as &$category) {
            var_dump($category);
            $plop = $category['id'];
        }

I will get the last element of the array as a string instead of an array
and that string being the value of the column "name" of the last CategoryDescription in my database

using a normal foreach without reference does not trigger the bug
using getResult also does not trigger the bug

if needed and someone guide me I can try to furnish a "minimal code" to reproduce the issue






[DDC-490] Cannot use ORDER BY xxx ASC NULLS LAST / ORDER BY field = value DESC syntax Created: 01/Apr/10  Updated: 26/Nov/14  Resolved: 26/Jul/10

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

Type: Improvement Priority: Minor
Reporter: Michael Zach Assignee: Guilherme Blanco
Resolution: Fixed Votes: 1
Labels: None
Environment:

Debian 5.0, PostgreSQL 8.4.2


Attachments: Text File nulls.patch     File SortableNullsWalker.php    

 Description   

It is at the time of this writing not possible to use something like:

$qb = $em->createQueryBuilder()
			->select('p')
			->from('Domain\Person', 'p')
			->where('p.id = 1')
			->orderBy('p.firstname', 'ASC NULLS LAST');

or

$qb = $em->createQueryBuilder()
			->select('p')
			->from('Webges\Domain\Core\Person\Person', 'p')
			->where('p.id = 1')
			->orderBy('p.firstname', '= ?');

which is perfectly valid syntax in PostgreSQL and also standard according to: http://troels.arvin.dk/db/rdbms/#select-order_by

Question is: will this be implemented in the near future / do any plans exist to support this at all?

Currently the only way is to use a native query with a custom ResultSetMapping

I do understand that not all database systems implement this, but an improvement in this direction would be a nice feature.



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

We wont add this into the Core DQL, but you can add it yourself using a Custom SQL Walker instead of the default one and some sort of query hint or similiar, you would then extend the EntityManager and have createQuery return your own Query class that always uses the Custom Sql Walker.

There will be a Cookbook Entry on how to do something similar soonish, since this also affects Oracle Platform this would really make a nice DoctrineExtensions namespaced component. Can we interest you in such an endavour?

Comment by Michael Zach [ 01/Apr/10 ]

Actually I just finished a simple patch to allow this in Core, but surely it could fit into an extension as well - keep me posted and I'll look into it.

Modified / extended Doctrine\ORM\Query\AST\OrderByItem, Doctrine\ORM\Query\SqlWalker, Doctrine\ORM\Query\Lexer, Doctrine\ORM\Query\Parser as a proof of concept.

I suppose it is considered good practice to extend the Doctrine\ORM\Query\Lexer as well when adding custom values for said extension?

Any hints beforehand appreciated.

Comment by Benjamin Eberlei [ 01/Apr/10 ]

I just realized you posting this here it might be impossible to do in the custom walker, since you also need to change the parser. Roman any thoughts?

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

I'm not sure. I don't think I would like adding this to the core right now as it seems a bit like bloat that only few people would use. Is this null ordering really a serious issue in practice? (I'm asking because I've never encountered it yet).

Hibernate has a similar request since 2005 (still open): http://opensource.atlassian.com/projects/hibernate/browse/HHH-465

The JPA specs say nothing about that topic. These two things make me wonder about the importance of this problem, of course they may simply have overlooked it.

If this null ordering is "essential" why not automatically pick a default (i.e. nulls last, which seems to be the default by the majority of databases) and enforce that on all order clauses. Bad idea?

Also, can the null ordering be configured in other ways, i.e. on the database side?

Comment by Michael Zach [ 02/Apr/10 ]

From what I've seen (at least in PostgreSQL), it cannot be configured on the DB side in general, but PG uses defaults for ASC / DESC - DESC is sorted NULLS FIRST, ASC is sorted NULLS LAST ( see: http://www.postgresql.org/docs/8.4/interactive/queries-order.html )

One way to solve this would be to use indexes with a default ordering (which kind of is the discussed DB configured ordering) - see: http://www.postgresql.org/docs/8.4/static/indexes-ordering.html

I could make an extension as suggested by Benjamin, although for this the Doctrine\ORM\Query\Lexer would at least need to change it's

private function _checkLiteral($identifier)

from

$name = 'Doctrine\ORM\Query\Lexer::T_' . strtoupper($identifier);

to

$name = get_class($this) . '::T_' . strtoupper($identifier);

in order to reduce duplicate code - sure, I could re-implement the functions behaviour, but this doesn't look like good OOP practice to me.

The gain of an extension would be to not only allow NULLS FIRST/LAST, but could be extended to allow

ORDER BY a + b, c
ORDER BY random()

constructs without the need to use a nativeQuery.

What do you guys think?

Comment by Benjamin Eberlei [ 02/Apr/10 ]

It could be added via QueryHints without changes to the parser and lexer, say:

    $query = $entityManager->createQuery("SELECT ... ORDER BY e.foo ASC, e.bar DESC")
    $query->setQueryHint(Query::HINT_CUSTOM_OUTPUT_WALKER, 'DoctrineExtensions\Query\SortableNullsWalker');
    $query->setQueryHint("sortableNulls.fields", array(
        "foo" => SortableNulls::NULLS_FIRST,
        "bar" => SortableNulls::NULLS_LAST,
    ));
    $results = $query->getResult();

See the latest commit with a cookbook recipe on how to write your own SQL Walker:

http://trac.doctrine-project.org/browser/docs/trunk/cookbook/en/dql-custom-walkers.txt?rev=7523

Comment by Michael Zach [ 02/Apr/10 ]

Benjamin, is it possible that this is coming in an upcoming svn commit? Currently, only a $query->setHint() implementation is available which does not call an own implementation class (DoctrineExtensions\Query\SortableNullsWalker).

The class consists of the two constants suggested by your last code example (didn't see a need to write an own class when it's only used in the walker, but can be changed) and the overwritten method "public function walkOrderByItem($orderByItem)".

Neither $query->getSql() nor $query->getResult() calls aforementioned custom walker, so I wonder if it's broken in the current svn trunk (rev. 7523) or if it's a new feature.

Comment by Benjamin Eberlei [ 02/Apr/10 ]

Hm, i used this already, it should work, the customWalker should be constructed in the Doctrine\ORM\Query\Parser::parse()

Comment by Michael Zach [ 02/Apr/10 ]

Proof of concept implementation - needs to to additional checks

Usage example can be found in class docblock

Comment by Michael Zach [ 02/Apr/10 ]

Changed attached file to an updated version, also adding patch against rev7523 to support in directly in Doctrine (if anyone is interested). Still proof of concept - feedback welcome.

Comment by Aigars Gedroics [ 21/Jul/10 ]

Is it possible to make similar SQL Walker for the 2nd problem for "ORDER BY p.id = 1" to work?

Comment by Guilherme Blanco [ 26/Jul/10 ]

I committed support to extensibility under Lexer.
Except that, nothing else can be done that is related to this ticket.

Although NULL FIRST/LAST is SQL Standard, it is not support across all RDBMS, and cannot be adapted between them. So we consider this support as "impossible" and forget about it.
But since you made a vlid request related to extensiblity of Lexer, this is one of the expected changes I was planning to do later on Doctrine. So I decided to commit it now.

Cheers,

Comment by Marc Drolet [ 20/Jun/12 ]

here is my implementaiton of the custom walker to do the trick for mysql, oracle and postgresql.

<?php
namespace DoctrineExtensions\CustomWalker;

use Doctrine\ORM\Query\SqlWalker;

/**

  • SortableNullsWalker
    */
    class SortableNullsWalker extends SqlWalker
    {
    const NULLS_FIRST = 'NULLS FIRST';
    const NULLS_LAST = 'NULLS LAST';

public function walkOrderByClause($orderByClause)
{
$sql = parent::walkOrderByClause($orderByClause);

if ($nullFields = $this->getQuery()->getHint('SortableNullsWalker.fields'))
{
if (is_array($nullFields))
{
$platform = $this->getConnection()>getDatabasePlatform()>getName();
switch ($platform)
{
case 'mysql':
// for mysql the nulls last is represented with - before the field name
foreach ($nullFields as $field => $sorting)
{
/**

  • NULLs are considered lower than any non-NULL value,
  • except if a - (minus) character is added before
  • the column name and ASC is changed to DESC, or DESC to ASC;
  • this minus-before-column-name feature seems undocumented.
    */
    if ('NULLS LAST' === $sorting) { $sql = preg_replace('/\s+([a-z])(\.' . $field . ') (ASC|DESC)?\s*/i', " -$1 $2 $3 ", $sql); }

    }
    break;
    case 'oracle':
    case 'postgresql':
    foreach ($nullFields as $field => $sorting)

    { $sql = preg_replace('/(\.' . $field . ') (ASC|DESC)?\s*/i', "$1 $2 " . $sorting, $sql); }

    break;
    default:
    // I don't know for other supported platforms.
    break;
    }
    }
    }

return $sql;
}
}

and I use it this way:
$query->setHint(Doctrine\ORM\Query::HINT_CUSTOM_OUTPUT_WALKER, 'DoctrineExtensions\CustomWalker\SortableNullsWalker')
->setHint('SortableNullsWalker.fields',
array(
'last_updated_date' => DoctrineExtensions\CustomWalker\SortableNullsWalker::NULLS_LAST,
)
);

hope this help

Comment by Israel Carberry [ 26/Nov/14 ]

Using Symfony 2.5.7 and Doctrine\ORM 2.5.0-DEV, the following changes seem to make the SortableNullsWalker work. This cleared up the errors I was getting, and the Symfony profiler shows the executable query I built using this class ending with ORDER BY b0_.example_date DESC NULLS LAST

--- old/SortableNullsWalker.php
+++ new/SortableNullsWalker.php
@@ -3,6 +3,7 @@
 namespace Webges\DoctrineExtensions\Query;
 
 use Doctrine\ORM\Query;
+use Doctrine\ORM\Query\AST\PathExpression;
 
 /**
  * The SortableNullsWalker is a TreeWalker that walks over a DQL AST and constructs
@@ -40,15 +41,11 @@
        if (is_array($hint) && count($hint)) {
            // check for a state field
            if (
-               $expr instanceof Query\AST\PathExpression &&
-               $expr->type == Query\AST\PathExpression::TYPE_STATE_FIELD
+               $expr instanceof PathExpression &&
+               $expr->type == PathExpression::TYPE_STATE_FIELD
            ) {
-               $parts = $expr->parts;
-               $fieldName = array_pop($parts);
-               $dqlAlias = $expr->identificationVariable . ( ! empty($parts) ? '.' . implode('.', $parts) : '');
-
                $search = $this->walkPathExpression($expr) . ' ' . $type;
-               $index  = $dqlAlias . '.' . $fieldName;
+               $index  = $expr->identificationVariable . '.' . $expr->field;
                $sql = str_replace($search, $search . ' ' . $hint[$index], $sql);
            }
        }




[DDC-3414] Joining on a table with inheritance produces badly formed ON clause Created: 26/Nov/14  Updated: 26/Nov/14

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

Type: Bug Priority: Major
Reporter: Lewis Wright Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: inheritance, joins, orm, querybuilder


 Description   

When I join on a table that uses class table inheritance, Doctrine automatically joins on the parent table, but it does it before the ON clause.

So for example, writing this DQL:

SELECT uc, c FROM MyModel\Customer c LEFT JOIN MyModel\Customer uc WITH uc.customer = c

produces:

SELECT 
 # Snipped
FROM 
  customer c0_ 
  LEFT JOIN user_customer u2_ 
  INNER JOIN base_user b1_ ON u2_.id = b1_.id ON (u2_.customer_id = c0_.id)

This syntax for the ON clause looks wrong, and fails in SQLite, so I can only assume it's the result of a bug?



 Comments   
Comment by Marco Pivetta [ 26/Nov/14 ]

Please compare the DQL you wrote by hand with the one generated by the QueryBuilder

Comment by Lewis Wright [ 26/Nov/14 ]

The issue appears not to be with just the query builder, but with the DQL version too (see the updated bug report). Would it help if I made a bare-bones doctrine application demoing the problem?

Actually, what would probably be more helpful is if I added a test to the test suite for this bug. I'll see what I can do.

Comment by Marco Pivetta [ 26/Nov/14 ]

We'd need a functional test to add to the test suite, not a demo app. Sending a pull-request with a failing test case will expose the problem immediately.

Comment by Lewis Wright [ 26/Nov/14 ]

Apologies, I should have read the contribute readme first before submitting the ticket. I've created a pull request here with the failing SQLite tests:

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

I did put this ticket number as the PR subject, but the bot seems to have created another issue here:
http://www.doctrine-project.org/jira/browse/DDC-3415





[DDC-3415] [GH-1194] [DDC-3414] Add test for "Joining on a table with inheritance produces badly formed ON clause" Created: 26/Nov/14  Updated: 26/Nov/14

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

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


 Description   

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

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

Message:

Add a test for a bug report. The test is only simple with no assertions, since the SQL generated by Doctrine is invalid and generates an exception in SQLite.






[DDC-3346] findOneBy returns an object with partial collection for the properties with mapping oneToMany/Fetch Eager Created: 10/Oct/14  Updated: 25/Nov/14

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

Type: Bug Priority: Critical
Reporter: Adrien Russo Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None


 Description   

findOneBy returns an object with partial collection for the properties with mapping oneToMany/Fetch Eager. This bug appear only for entities without inheritance.

Mapping
       
Test\Bar:
    type: entity
    table: bar
    fields:
        code:
            type: string
    oneToMany:
        posts:
            targetEntity: Test\Post
            fetch: EAGER
            mappedBy: bar
            cascade: ['all']
    
Test\Post:
    type: entity
    table: post
    fields:
        content:
            type: text
    manyToOne:
        bar:
            targetEntity: Test\Bar
            cascade: []
            joinColumn:
                name: bar_id
                referencedColumnName: id
Data
    
$bar = new \Test\Bar('foo');
$bar->addPost(
  new Test\Post('toto')
);
$bar->addPost(
  new Test\Post('tata')
);
 
$bar->getPosts()->count(); #value is 2
$manager->persist($bar);
$manager->flush();
FindOneBy with fetch eager
$bar = $repository->findOneBy(['code' => 'foo']);
$bar->getPosts()->count(); #value is 1
FindOneBy with fetch Lazy
$bar = $repository->findOneBy(['code' => 'foo']);
$bar->getPosts()->count(); #value is 2

I think this bug is due to the LIMIT 1 clause happening on findOneBy which also applies on joins generated here.

For instance, the generated SQL statement generated might look like

Sql Statement
SELECT
	t0. ID AS id_1,
	t0.code AS code_2,
	t1. ID AS id_3,
	t1.content AS content_4,
	t1.bar_id AS bar_id_5
FROM
	bar t0
LEFT JOIN post t1 ON t1.bar_id = t0. ID
WHERE
	t0. code = 'foo'
LIMIT 1





[DDC-3401] __load should not mark proxied entity as initialized when initialization fails Created: 19/Nov/14  Updated: 25/Nov/14  Resolved: 25/Nov/14

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

Type: Bug Priority: Major
Reporter: Oleg Namaka Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: lazy-loading, proxy


 Description   

Imagine this situation:

   //$entity2 is instance of \Doctrine\ORM\Proxy\Proxy which fails to load
    try {
       $entity2 = $entity->getEntity2();
   } catch (\Doctrine\ORM\EntityNotFoundException $e) {
       //the exception is caught
       // $entity2 is marked as initialized but its data is missing
   }

Then somewhere else in code:

 //$entity2 is instance of \Doctrine\ORM\Proxy\Proxy which fails to load
    try {
       $entity2 = $entity->getEntity2();
   } catch (\Doctrine\ORM\EntityNotFoundException $e) {
       //the exception is not caught since $entity2 is already initialized
   }
   foreach ($entity3->getSomeCollection() as $element) {
   // breaks since all internal data is missing

The fix to \Doctrine\Common\Persistence\Proxy::__load should look something like this:

        if (!$this->__isInitialized__ && $this->_entityPersister) {
//            $this->__isInitialized__ = true; --> this line is moved down below

            if (method_exists($this, "__wakeup")) {
                // call this after __isInitialized__to avoid infinite recursion
                // but before loading to emulate what ClassMetadata::newInstance()
                // provides.
                $this->__wakeup();
            }

            if ($this->_entityPersister->load($this->_identifier, $this) === null) {
                throw new \Doctrine\ORM\EntityNotFoundException();
            }
            unset($this->_entityPersister, $this->_identifier);
            $this->__isInitialized__ = true;
        }


 Comments   
Comment by Marco Pivetta [ 19/Nov/14 ]

The initialization flag has to be moved to the top, as initialization can recurse otherwise.

If you can abstract this into a test case, then I'll gladly try working on it.

Comment by Marco Pivetta [ 19/Nov/14 ]

Does the issue also affect 2.4?

Comment by Oleg Namaka [ 24/Nov/14 ]

@Marco, I do not know about 2.4 since I do not have it installed.

Regarding your first comment:

The initialization flag has to be moved to the top, as initialization can recurse otherwise.

In this case you can either introduce an independent flag to mitigate this problem or you can re-set the flag back to false in the following block right before an exception is thrown:

if ($this->_entityPersister->load($this->_identifier, $this) === null) {
    $this->__isInitialized__ = false;
    throw new \Doctrine\ORM\EntityNotFoundException();
}
Comment by Marco Pivetta [ 24/Nov/14 ]

I don't think that we are going to patch 2.3 anymore, so I suggest upgrading to 2.4, as this issue may likely have been fixed.

Consider that the entire proxy layer has been re-written: https://github.com/doctrine/doctrine2/blob/88ce68e733a02b84eb229c8447409b2ed5cf71ac/lib/Doctrine/ORM/Proxy/ProxyFactory.php#L175

Comment by Oleg Namaka [ 25/Nov/14 ]

@Marco, I installed 2.4 as you suggested but it seems that the issue is not fixed in it either. Look at a proxy __load generated in 2.4:

/** @private */
    public function __load()
    {
        if (!$this->__isInitialized__ && $this->_entityPersister) {
            $this->__isInitialized__ = true;

            if (method_exists($this, "__wakeup")) {
                // call this after __isInitialized__to avoid infinite recursion
                // but before loading to emulate what ClassMetadata::newInstance()
                // provides.
                $this->__wakeup();
            }

            if ($this->_entityPersister->load($this->_identifier, $this) === null) {
                throw new \Doctrine\ORM\EntityNotFoundException();
            }
            unset($this->_entityPersister, $this->_identifier);
        }
    } 

It looks identical to Proxy::__load generated in 2.3

Comment by Oleg Namaka [ 25/Nov/14 ]

@Marco, please disregard my previous comment as incorrect. This issue probably is fixed as a new proxy looks totally different. I will confirm it later today.

Comment by Marco Pivetta [ 25/Nov/14 ]

Marking as resolved in 2.4, won't fix for 2.3





[DDC-3411] [GH-1192] Fixed a very minor typo Created: 25/Nov/14  Updated: 25/Nov/14  Resolved: 25/Nov/14

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

Type: Documentation Priority: Trivial
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:



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

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

Comment by Steve Müller [ 25/Nov/14 ]

Fixed as of https://github.com/doctrine/doctrine2/commit/bf5003f25e45e6f044f070c876e4401087dff004

Comment by Doctrine Bot [ 25/Nov/14 ]

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





[DDC-3410] Allow Query Builder to specify the joins of Join Inheritance entities Created: 25/Nov/14  Updated: 25/Nov/14

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

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


 Description   

Possibly a duplicate of DDC-16 in essence; resolving this would probably resolve that issue.

Summary
When you SELECT an entity which is a superclass using Joined Inheritance, Doctrine automatically adds it's own JOINs of the superclass or subclass tables.
These automatic JOINs that are introduced can't be used in DQL/builder, so you can't do anything with them (further joins on their associations for eager loading, WHERE queries, etc).
Allow me to specify my own Joins between the superclass and subclass so I can perform further queries deeper in the associations.

Main culprit:
https://github.com/doctrine/doctrine2/blob/2.4/lib/Doctrine/ORM/Query/SqlWalker.php#L341

Long version
Superclass "Activity" uses the Joined inheritance type with a discriminator column. There are various activities such as ActivityDocument, ActivityTask, etc.
These sub-class activities have associations to other entities; ActivityDocument associates to a Document entity, and Document then associates to User.

For the query, I want to fetch all Activity where the Activities document/task is associated to a given user. If I wanted to do this in raw SQL it would look something like this:

SELECT a.*, ad.*, d.*, at.*, t.*
FROM Activity a
LEFT JOIN ActivityDocument ad ON ad.id = a.id
LEFT JOIN Document d ON d.id = ad.document_id
LEFT JOIN ActivityTask at ON at.id = a.id
LEFT JOIN Task t ON t.id = at.task_id
WHERE
t.user_id = 1 OR d.user_id = 1

Doctrine supports the joined inheritance type, so I want it to fetch the subclasses and also eagerly load the downstream Document or Task entity that's associated with them, and be able to execute clauses on the data.

I can only get half way there:

$builder
    ->select('a')
    ->from('Activity', 'a')
    ->leftJoin('ActivityDocument', 'ad', Query\Expr\Join::WITH, 'a.id = ad.id')
    ->leftJoin('ad.document', 'ad_d')
    ->orWhere('ad_d.user = :user')
    ->leftJoin('ActivityTask', 'at', Query\Expr\Join::WITH, 'a.id = at.id')
    ->leftJoin('at.task', 'at_t')
    ->orWhere('at_t.user = :user')
    ->setParameter('user', $user);

In the above I've fudged the joined inheritance association using ->leftJoin() in order to execute the deep WHERE portion, however because we're doing our own join between two entities, the association between Activity and ActivityDocument is lost.

The entities returned by this query are instances of ActivityDocument and ActivityTask; the hydrated subclasses are returned when we SELECT from Activity, and ActivityDocument and ActivityTask are LEFT JOINed automatically by Doctrine because the Activity entity is recognised as using Joined Inheritance, but there's no way to latch onto these generated LEFT JOINs.
https://github.com/doctrine/doctrine2/blob/2.4/lib/Doctrine/ORM/Query/SqlWalker.php#L376

Note that adding "ad", "at" or "at_d" or "at_t" to the select does not solve this.

A workaround for this specific scenario is this:

$builder->select('ad', 'at', 'ad_d', 'at_t')

This fetch ActivityDocument and ActivityTask specifically, plus their associations. Unfortunately because it is across multiple to-level entities, it causes null rows to be returned in the result set.

Effectively this goes the other way, and adds joins from ActivityDocument to Activity in order to provide the correct hydration of ActivityDocument.
https://github.com/doctrine/doctrine2/blob/2.4/lib/Doctrine/ORM/Query/SqlWalker.php#L348

Note that you still cannot use an alias for Activity because the builder was not the one to specify that relation.

What I want to be able to do
Allow me to define the join across the Join Inheritance entities, so I can use the alias for the superclass/subclass in the query builder!

Rather than DDC-16's idea of "casting" to a class, just let me define the join myself. Obviously this is more a "joined class" than a "joined field" , so extra notation may be required.
A painfully ugly example of this syntax could be something like:

$builder->join('Activity->ActivityDocument', 'ad')

This could then establish the Join as some form of JoinAssociation rather than a RangeVariableDeclaration.

The bigger problem is that SqlWalker::_generateClassTableInheritanceJoins doesn't have scope over any of the joins in the query, and thus can't inspect any relations that have been established in the query builder, and use those instead of generating its own.

Unfortunately I don't know the internals of Doctrine to be of any more use.

Why
Joined Inheritance is a powerful feature, but without being able to use associations across the superclass and subclass it actually creates an annoying dead-end in queries.

There is no good workaround for this issue. If you fetch a Join Inheritance entity you can only examine one side of the inheritance without performing another query.






[DDC-2557] [GH-725] Fix for problem with WHERE CASE LIKE Created: 17/Jul/13  Updated: 24/Nov/14  Resolved: 18/Jul/13

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

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


 Description   

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

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

Message:

See details described here: https://groups.google.com/forum/#!topic/doctrine-user/EbVMYOPnHPs

Still missing: NOT LIKE and others....



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

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

Comment by Doctrine Bot [ 24/Nov/14 ]

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

Comment by Doctrine Bot [ 24/Nov/14 ]

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





[DDC-3409] [GH-1191] [2.4] Documenting interface methods (based on entity manager) Created: 23/Nov/14  Updated: 23/Nov/14  Resolved: 23/Nov/14

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

Type: Documentation Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: entitymanagerinterface

Issue Links:
Dependency
depends on DDC-2846 [GH-870] Documenting interface method... Resolved

 Description   

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

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

Message:

This PR follows #870 and my [comments](https://github.com/doctrine/doctrine2/pull/870#commitcomment-5702280) on it.

I think these changes are MUST for the stable release. Especially when Doctrine is used together with such high quality framework like Symfony.



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

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

Comment by Doctrine Bot [ 23/Nov/14 ]

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





[DDC-2846] [GH-870] Documenting interface methods (based on entity manager) Created: 10/Dec/13  Updated: 23/Nov/14  Resolved: 10/Dec/13

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

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

Issue Links:
Dependency
is required for DDC-3409 [GH-1191] [2.4] Documenting interface... Resolved

 Description   

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

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

Message:



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

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

Comment by Marco Pivetta [ 10/Dec/13 ]

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





[DDC-3406] Proxy returns string instead of object Created: 21/Nov/14  Updated: 21/Nov/14

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

Type: Bug Priority: Major
Reporter: Martin Keckeis Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm, proxy


 Description   

I get an string in one case instead of an entity or proxy.

User -> Address -> Plant -> Hierarchy

User OneToOne Address
Address ManyToOne Plant
Plant OneToOne Hierarchy

(all are fetched as eager loading)

See PR with a test case here
https://github.com/doctrine/doctrine2/pull/1189

Reference
https://github.com/doctrine/DoctrineORMModule/issues/355



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

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





[DDC-3405] Join Query Related Created: 21/Nov/14  Updated: 21/Nov/14  Resolved: 21/Nov/14

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

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


 Description   

Hi,

I am new in doctrine. i Used doctrine in zend framwork 2. I tried to join user and group but i cannot do it.can u please tell whole process of join 2 table and join query



 Comments   
Comment by Oliver Hoff [ 21/Nov/14 ]

usage questions belong to the user mailing list http://groups.google.com/group/doctrine-user

Comment by Marco Pivetta [ 21/Nov/14 ]

Not an issue





[DDC-3407] add possibility to prevent some entitiy methods from being proxied Created: 21/Nov/14  Updated: 21/Nov/14

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

Type: New Feature Priority: Trivial
Reporter: Oliver Hoff Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This is for optimization of lazy loading, when using entity methods that operate only on identifier values.

This issue is partially addressed via:
https://github.com/doctrine/doctrine2/commit/ba38f3e1e9d725224998af9fce42186b5ccb9641

But it makes assumptions about a certain code style, that is for an "id" identifier property the getter is named "getId". but some code styles prefer "getID".

It would be nice to have an annotation like @ORM\SkipProxy (or equivalents for xml/yaml) to mark a method that should not be proxied.



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

I wouldn't implement it that way. I'm actually building something (non-trivial) at https://github.com/Ocramius/ProxyManager/pull/192 and https://github.com/Ocramius/ProxyManager/issues/159, but it will take some time to get there, and also to get doctrine to use that component to generate proxy classes.





[DDC-3408] [GH-1190] Document that AUTOGENERATE_ constants are allowed Created: 21/Nov/14  Updated: 21/Nov/14  Resolved: 21/Nov/14

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

Type: Documentation Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: autogeneration, documentation, proxy


 Description   

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

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

Message:

As of Doctrine Common 2.4, there are four strategies for generating proxy classes. Previously there were just two. This is supported by Doctrine ORM (implemented in bee74f898da0474b4bad44d41df84f1807036880 and 88754622419524bf92cfc18f9ab7fac148c35924), but the change is not fully reflected in the documentation and variable names used in Doctrine ORM.

This PR updates the documentation and variable names.



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

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





[DDC-3400] Wrong result using php-cli Created: 19/Nov/14  Updated: 20/Nov/14

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

Type: Bug Priority: Major
Reporter: Damir Abdijevic Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: cache, cli, dql, environment, orm
Environment:

Windows 7, Debian GNU/Linux 7 PHP 5.5.15



 Description   

Same query produces different results. With apache module everything works like expected. With php-cli the join condition to i18n table is ignored and calling getCountries() returns all and not only that entity that is matched by join condition.

        $qb = $this->_em->createQueryBuilder()
                        ->select('t', 'i18n')
                        ->from($this->_entityName, 't')
                        ->innerJoin('t.countries', 'i18n')
                        ->where('i18n.locale = :localeId')
                        ->setParameter('localeId', $localeId);

Country Entity:

namespace MyApp\Model\Entity;

use Doctrine\ORM\Mapping as ORM;
use Doctrine\Common\Collections\ArrayCollection;

/**
 * Country entity
 *
 * @ORM\Entity(repositoryClass="MyApp\Model\Repository\Country")
 * @ORM\Table(name="country")
 *
 */
class Country
{
    /**
     * @var int
     * @ORM\Id
     * @ORM\Column(type="integer", name="id")
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;

    /**
     * @var string
     * @ORM\Column(type="string", name="name", length=32, unique=true)
     */
    protected $name;

    /**
     * @var int
     * @ORM\Column(type="integer", name="sort", unique=true)
     */
    protected $sort;

    /**
     * @var ArrayCollection
     * @ORM\OneToMany(targetEntity="ProductDescription\Model\Entity\CountryI18n", mappedBy="country", cascade={"all"})
     */
    protected $countries;


    /**
     * Constructor
     *
     * @return Country
     */
    public function __construct()
    {
        $this->countries = new ArrayCollection();
    }

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

    /**
     * Setter for $this->id
     *
     * @param int $id entity id
     *
     * @return void
     */
    public function setId($id)
    {
        $this->id = (int) $id;
    }

    /**
     * Getter for $this->sort
     *
     * @return int
     */
    public function getSort()
    {
        return $this->sort;
    }

    /**
     * Setter for $this->sort
     *
     * @param int $sort sort order
     *
     * @return void
     */
    public function setSort($sort)
    {
        $this->sort = (int) $sort;
    }

    /**
     * Getter for $this->name
     *
     * @return string
     */
    public function getName()
    {
        return $this->name;
    }

    /**
     * Setter for $this->name
     *
     * @param string $name language name in german
     *
     * @return void
     */
    public function setName($name)
    {
        $this->name = (string) $name;
    }

   /**
    * Get collection from i18n table
    *
    * @return ArrayCollection
    */
    public function getCountries()
    {
        return $this->countries;
    }

    /**
     * Proxy method. So we have working with all entities same method
     * to getting i18n data.
     *
     * @return ArrayCollection
     */
    public function getI18n()
    {
        return $this->getCountries();
    }

CountryI18nEntity:

namespace MyApp\Model\Entity;

use Doctrine\ORM\Mapping as ORM;

/**
 * CountryI18n entity
 *
 * @ORM\Entity
 * @ORM\Table(name="country_i18n", uniqueConstraints={@ORM\UniqueConstraint(name="idx_UNIQUE_country_id_locale_id", columns={"country_id", "locale_id"})})
 */
class CountryI18n
{
    /**
     * @var int
     * @ORM\Id
     * @ORM\Column(type="integer", name="id")
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;

    /**
     * @ORM\ManyToOne(targetEntity="ProductDescription\Model\Entity\Country", inversedBy="countries")
     * @ORM\JoinColumn(name="country_id", referencedColumnName="id")
     */
    protected $country;

    /**
     * @ORM\ManyToOne(targetEntity="ProductDescription\Model\Entity\Language", inversedBy="countries")
     * @ORM\JoinColumn(name="locale_id", referencedColumnName="id")
     */
    protected $locale;

    /**
     * @var string
     * @ORM\Column(type="string", name="name", length=255)
     */
    protected $name;


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

    /**
     * Setter for $this->id
     *
     * @param int $id id of row primary key
     *
     * @return void
     */
    public function setId($id)
    {
        $this->id = (int) $id;
    }

    /**
     * Getter for $this->country
     *
     * @return Country
     */
    public function getCountry()
    {
        return $this->country;
    }

    /**
     * Setter for $this->country
     *
     * @param Country $country country entity to set
     *
     * @return void
     */
    public function setCountry(Country $country)
    {
        $this->country = $country;
    }

    /**
     * Getter for $this->locale
     *
     * @return Language
     */
    public function getLocale()
    {
        return $this->locale;
    }

    /**
     * Setter for $this->locale
     *
     * @param Language $locale language entity to set as locale
     *
     * @return void
     */
    public function setLocale(Language $locale)
    {
        $this->locale = $locale;
    }

    /**
     * Getter for $this->name
     *
     * @return string
     */
    public function getName()
    {
        return $this->name;
    }

    /**
     * Setter for $this->name
     *
     * @param string $name translation name
     *
     * @return void
     */
    public function setName($name)
    {
        $this->name = (string) $name;
    }

}


 Comments   
Comment by Marco Pivetta [ 19/Nov/14 ]

Looks like a caching issue. The amount of information provided is insufficient as it is. I'd suggest verifying if the generated SQL is the same, and checking that all caches were cleared both in CLI and in WEB sapis.

Comment by Damir Abdijevic [ 20/Nov/14 ]

O.k. here some further information.

No caching like Xcache or APC is enabled. PHP 5.5 integrated opcache ist not enabled. All Doctrine caches are set to Array. The sql queries are in both cases exactly the same:

sql
SELECT c0_.id AS id0, c0_.name AS name1, c0_.sort AS sort2, c1_.id AS id3, c1_.name AS name4, c1_.country_id AS country_id5, c1_.locale_id AS locale_id6 FROM country c0_ INNER JOIN country_i18n c1_ ON c0_.id = c1_.country_id WHERE c1_.locale_id = ?

/* locale_id = 2 */

The sql result is correct

Running the console script a ZF2 Initializer runs before that performs this query builder query:

QueryBuilder

$qb = $this->_em->createQueryBuilder()
                            ->select('t', 'i18n', 'l')
                            ->from($this->_entityName, 't')
                            ->innerJoin('t.countries', 'i18n')
                            ->innerJoin('i18n.locale', 'l');

That results in following SQL:

sql
SELECT c0_.id AS id0, c0_.name AS name1, c0_.sort AS sort2, c1_.id AS id3, c1_.name AS name4, l2_.id AS id5, l2_.name AS name6, l2_.full_name AS full_name7, l2_.locale AS locale8, c1_.country_id AS country_id9, c1_.locale_id AS locale_id10, l2_.country_id AS country_id11 FROM country c0_ INNER JOIN country_i18n c1_ ON c0_.id = c1_.country_id INNER JOIN language l2_ ON c1_.locale_id = l2_.id
Comment by Marco Pivetta [ 20/Nov/14 ]

What happens if you run those SQL statements via CLI (dbal:run-sql) or WEB? Same results?

Comment by Damir Abdijevic [ 20/Nov/14 ]

The sql result is correct. Can I attach it to the ticket? I have exported it to csv.

Comment by Marco Pivetta [ 20/Nov/14 ]

If the same results are produced on CLI and WEB APIs then I suggest trying to insulate the issue in a functional test to be run in both context. You probably have a different ORM bootstrap for CLI and WEB.

Attaching a CSV for same results makes no real difference here.

Comment by Damir Abdijevic [ 20/Nov/14 ]

No, I didn't want to attach two times the same result. Wanted to attach it one time to show that those entitites that are wrong in the result doesn't appear in the sql result at all. I don't have different bootstraps. After a few short tests I think it is an error in th ArrayCache mechanism. The difference was that using Apache one initializer was not called. Calling this initializer in both cases leads now to wrong results in CLI and WEB API.

When the second query is not executed everything is fine. But when the second longer query runs and selects all i18n entities and after it the first query runs then the issue appears.





[DDC-3403] [GH-1187] Fixed counting exception. Created: 20/Nov/14  Updated: 20/Nov/14  Resolved: 20/Nov/14

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

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


 Description   

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

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

Message:

Fixed "Invalid parameter number: number of bound variables does not match number of tokens " exception during execution count on Query where select part of query contains :parameters.



 Comments   
Comment by Doctrine Bot [ 20/Nov/14 ]

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

Comment by Doctrine Bot [ 20/Nov/14 ]

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





[DDC-2989] ORM should allow custom index names for foreign associations. Created: 07/Feb/14  Updated: 20/Nov/14

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

Type: Bug Priority: Minor
Reporter: Jonathon Suggs Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm, schematool

Issue Links:
Duplicate
is duplicated by DBAL-1047 doctrine:schema:update ignores index ... Resolved
Reference
relates to DBAL-234 Index names are not synchronized by C... Resolved
relates to DBAL-566 Schema Comparator does not identify r... Resolved
is referenced by DDC-2990 [GH-956] Foreign association index names Open

 Description   

Now that the DBAL allows/checks for renamed indexes, the ORM implementation needs to be enhanced to allow custom naming of the indexes for foreign associations.



 Comments   
Comment by Jonathon Suggs [ 07/Feb/14 ]

Here is a full example
https://github.com/jsuggs/schema-issue

I think this mainly has to do with the doctrine auto-generated indexes.

Comment by Marco Pivetta [ 15/Feb/14 ]

IIRC, index names cannot currently be assigned, and are computed automatically - that's why the ORM is behaving like that.

I don't think this needs a fix right now - lowering priority

Comment by Steve Müller [ 15/Feb/14 ]

Jonathon Suggs I also could not reproduce this bug in DBAL. I wonder if that is related to foreign key declarations (ORM relations) only. In fact, you cannot define index names for relations (foreign keys) in ORM at the moment. Therefore ORM always generates index names automatically. If you use custom names for those indexes in your online schema, the comparator will surely output the index renaming statement. I guess defining the index at table level in your mapping manually won't help here either.
Whatsoever I think this is an ORM only issue. If you manually changed your index names "online", you will now get some index rename statements when using the schema tool. Other users explicitly requested this feature. Schemas not in sync have to be upgraded, I guess. So IMO this is rather a "won't fix" in DBAL. However there is a possible improvement to ORM for being able to define index names for foreign keys. The whole topic is rather tricky concerning the comparator. Imagine you have (for whatever reason) multiple indexes with different names that span the exact same columns. How would you expect the comparator to output changes here? Which indexes should be renamed, which shouldn't?

Comment by Jonathon Suggs [ 18/Feb/14 ]

I guess I get it, but its kinda a big deal and I'll have to old off upgrading as a result. I personally find this more of a regression due to the unintended consequences. The schema diff is now 100% useless (to me) as I rename all of my indexes to a more semantic name.

My off the cuff thought on ORM index naming is that you expand the naming strategy to include support for the indexes. Given the full set of criteria you should be able to come up with some sort of semantic naming and only on namespace collision to you "fallback" to a hash of the columns (solves your issues and mine).

Comment by Jonathon Suggs [ 19/Feb/14 ]

To state differently, I (personally) value the schema diff tool much more than custom index (re)naming since the (overall) ability to use custom index names is not complete (due to the ORM issues Steve outlined above).

If the support to (re)name foreign key indexes can't go out in parallel to this, I'd like to offer a middle ground of making the index renaming configurable (ie ability to opt-out of functionality).

Sorry to be negative towards a new feature, but its really an inconvenience for me, and I suspect others since Strate also expressed concerns in the PR.

Let me know how I can be of help in working towards a resolution.

Comment by Benjamin Eberlei [ 19/Feb/14 ]

Jonathon Suggs What do you mean with "just upgraded"? Which to which version? The index renaming and coverage feature is very old already, not sure what is happening. Do you define an index for a relation column?

Comment by Steve Müller [ 19/Feb/14 ]

Benjamin Eberlei This definitely has to do with the comparator now comparing index names also.
Jonathon Suggs Can you please confirm my assumption that this problem is only related to relations and their foreign key indexes? Also can you confirm that it only affects those foreign key indexes which you gave a custom name? Can you please check that?
I don't see any reasonable solution in DBAL for this. The real solution IMO would be to allow custom names in ORM mappings for foreign key realation indexes.

Comment by Jonathon Suggs [ 19/Feb/14 ]

Sorry for the confusion.

Here is the PR that introduced the functionality in question.
https://github.com/doctrine/dbal/pull/473

Benjamin, I had just upgraded DBAL to the latest 2.5 master. This is only indirectly related to the ORM functionality as the ORM SchemaTool uses the DBAL Comparator to generate is schema diff.
Steve, yes this is only related to relations and foreign key indexes that were given a custom name. I documented the use case/scenario here: https://github.com/jsuggs/schema-issue

Steve, I see three potential solutions (in my personal order of preference).
1) Expand the NamingStrategy to allow it to handle the default names of foreign key relation indexes
2) As you suggested, allow for ORM mappings to specify foreign key relation indexes
3) Add a configuration directive that essentially allows for you to ignore renamed indexes (ie. fallback to the previous behavior, prior to PR 473).

I realize that #1 would be a bit more work, but I think offers enhanced functionality. #2 is a good, but would require additional annotations/mappings. #3 is probably the least dev effort but just doesn't feel right (to me).

Again, I don't want to seem critical of the dev effort, but its an unintended consequence that will keep me from being able to upgrade DBAL to 2.5.

Comment by Steve Müller [ 19/Feb/14 ]

Jonathon Suggs You are right the comparator is somewhat responsible for the "unnecesarry" schema diffs it now creates. However its functionality is completely working IMO. Try creating and comparing your schema example on DBAL level only (without utilizing ORM). You will see that it works. I see and understand that those index name updates are annoying but they are not WRONG. If you have a mapping for a relation with an unnamed index and rename this index in your online schema manually, I would even expect the schema tool to generate this diff. Because this is the whole point of the index rename feature. The problem we have here is that there currently is no way in ORM to define the index name on association mappings. There the following happens in your example when comparing the online and offline schema with the schema tool:

(abbreviated to the important steps, chronological order)

1. Collect mapping information and evaluate offline schema
1.1. Schema tool collects relation SQL for Bar -> Foo association and adds an unnamed index "IDX_76FF8CAA8E48560F" to table "bar"
1.2. Schema tool collects custom indexes defined in the mapping for "bar", detects the custom index "IDX_MANY_TO_ONE", tries to add it to the table "bar, but discards it because there is already another index "IDX_76FF8CAA8E48560F" fulfilling the exact same columns (this is how DBAL works ever since to avoid duplicate indexes)

2. Reverse-engineer online schema from database
2.1 Fetch all defined indexes for table "bar" -> adds "idx_many_to_one" to table "bar"

3. Comapre evaluated online schema to evaluated offline schema
3.1 Compare index "idx_many_to_one" (online schema) to index "IDX_76FF8CAA8E48560F" (offline schema) -> suggest index rename from "idx_many_to_one" to "IDX_76FF8CAA8E48560F" because the mapping is your definition and takes precedence.

Just to clarify what happens under the hood and that it is an ORM issue, not DBAL!

Comment by Jonathon Suggs [ 19/Feb/14 ]

Here is a first shot at basic support for allowing the mapping of the index name.
https://github.com/jsuggs/doctrine2/compare/foreign-association-index-names

Comment by Steve Müller [ 19/Feb/14 ]

Jonathon Suggs I have worked on a PR for this already using the exact same approach you just mentioned. However I am not quite sure about ManyToMany yet (because you would have to be able to define both index names there) and also I talked to Benjamin Eberlei and he does not seem to be happy with this approach. So I stopped work on this for the moment.

Comment by Steve Müller [ 19/Feb/14 ]

Moved this to ORM issues.

Comment by Jonathon Suggs [ 19/Feb/14 ]

Steve I both agree and disagree.

I think my underlying issue is your step 1.1. The ORM creates the index named "IDX_76FF8CAA8E48560F" and there is NO extension point for being able to override that behavior. FWIW, I've never been fond of the way that the ORM uses the AbstractAsset::_generateIdentifierName for generating the index and foreign key.

So I definitely agree that its is an ORM issue not DBAL issue . However, as I stated previously, until the ORM is updated/patched to allow for index naming, this (in my opinion) is a regression despite it working the way it currently does (correct or not).

I can close out this issue and open one for ORM. Do you have a old branch and/or ORM ticket that I can reference?

Thanks for engaging in the dialog! I hope to be of assistance in helping come up with a solution that gets everyone happy.

Comment by Steve Müller [ 19/Feb/14 ]

Jonathon Suggs Thanks for updating the description and thanks for assisting on this issue. We will find a solution for this before the final release of 2.5. If we cannot find a good solution until then we might also consider reverting the index renaming feature on DBAL (but I would like to avoid that). I will discuss this issue with the other core devs again and see what we can come up with.

Comment by Jonathon Suggs [ 19/Feb/14 ]

No problem, here is the start of a PR to maybe address the index names
https://github.com/doctrine/doctrine2/pull/956





[DDC-3394] UOW CreateEntity failure with zerofill columns Created: 17/Nov/14  Updated: 19/Nov/14  Resolved: 18/Nov/14

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

Type: Bug Priority: Major
Reporter: Thorry Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: DDC-1238
Environment:

PHP 5.4.4-14+deb7u8 (CLI) MySQL Server 5.5.35-0+wheezy1 MySQL Client 5.5.35 Debian Wheezy


Issue Links:
Reference
relates to DDC-3387 [GH-1182] #1086 identifier type in pr... Open

 Description   

In the CreateEntity function of the UnitOfWork in the following commit:

https://github.com/doctrine/doctrine2/commit/2858b8290fc63ca96a31ef173c9cf128ec18bfe7

This line will fail (under a specific set of circumstances) when zerofill identity columns are used:

($unmanagedProxy = $hints[Query::HINT_REFRESH_ENTITY]) !== $entity

Within one object the identifier will be stored as a string (eg "0000001"), in the other the identifier will be stored as a int (eg 1). The following line of code will return true:

$this->isIdentifierEquals($unmanagedProxy, $entity)

This will lead the UnitOfWork to assume the proxy is invalid, resetting the identifier. This object is then returned which can cause very weird things to happen.

If needed I can provide a code sample which clearly shows the problem in action. I came upon this problem when coding against an old database with zerofill columns, since a schema change in this database is unlikely to happen I hope someone can think of a fix.



 Comments   
Comment by Marco Pivetta [ 17/Nov/14 ]

Can you please check if the problem is reproducible with https://github.com/doctrine/doctrine2/pull/1182 applied? ( DDC-3387 )

Comment by Thorry [ 18/Nov/14 ]

Thank you for your super fast response!

I'm afraid the problem is still there with the patch you referred to in place.

I will dig further into the code, the place I mentioned is the place the failure occurs, however I do not think that's the place the failure originates from. It has something to do with the way the entity gets stored in memory.

Comment by Thorry [ 18/Nov/14 ]

This bug was already fixed by guilhermeblanco in this commit.

Comment by Thorry [ 18/Nov/14 ]

Bug was already fixed in dev.

Comment by Christophe Coevoet [ 18/Nov/14 ]

The "Fix version" should be 2.5, not 3.0 (the master branch is the dev version for 2.5)

Comment by Thorry [ 18/Nov/14 ]

Really? Is there a release date for 2.5? 3.0 is scheduled for December isn't it?

Comment by Marco Pivetta [ 18/Nov/14 ]

There is no scheduled release date for 2.5, as we can't get a decent (regular) amount of time assigned to the project right now.

Comment by Christophe Coevoet [ 19/Nov/14 ]

And what we wanted to schedule for December was 2.5, not 3.0. There is no date at all for 3.0, given that the work on it has not even started (and won't start in the foreseeable future given that core developers don't have enough time for such major task currently)

Comment by Thorry [ 19/Nov/14 ]

The 3.0 release date is stated here: http://www.doctrine-project.org/jira/browse/DDC/?selectedTab=com.atlassian.jira.jira-projects-plugin:roadmap-panel

Comment by Marco Pivetta [ 19/Nov/14 ]

Yeah, let me clear that.





[DDC-3391] RFC Allow adding extra metadata attributes Created: 13/Nov/14  Updated: 19/Nov/14

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

Type: Improvement Priority: Minor
Reporter: Gonzalo Vilaseca Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: drivers, metadata


 Description   

What I'd like to propose is a way of having custom metadata in ClassMetadata.

So the current problem is this: I want to add custom tags to doctrine metadata files, and then get this tags on a loadClassMetadata listener in order to modify the mapping.
Currently the only workaround is parsing this custom tags in the loadClassMetadata listener, going through all the files again.

I was thinking of having a new 'extra' array field in ClassMetadata, every time a driver parses a configuration, throw a new event with the read configuration (being xml, yaml...etc.). A custom listener will parse it looking for the custom tags and return an array that will be added to the 'extra' array field in ClassMetadata.

Then, on the loadClassMetadata listener we retrieve this 'extra' configuration information, and modify the mapping as we want.

Does this make sense?



 Comments   
Comment by Gonzalo Vilaseca [ 14/Nov/14 ]

Ideally instead of the 'extra' array field, it would be nice to easily extend Metadata class so that the new values are filled in the new extended Metadata class.

Comment by Christophe Coevoet [ 14/Nov/14 ]

This would be even worse. If the recommended way for extensions is to extend the Doctrine Metadata object to add their field, it means you can only use 1 extension at a time (because you cannot use the extended class of both extensions at the same time for the same object).
This is why it is much better for other libraries to store their own metadata in their own object instead of trying to put it inside the Doctrine ones.

I'm not even sure putting custom tags inside the Doctrine mapping file is the best solution. It may be better to use a separate metadata file for the mapping of the other library (just like you use a different mapping file for the Symfony validation mapping even if it applies to the same class than the Doctrine mapping for instance)

Comment by Gonzalo Vilaseca [ 14/Nov/14 ]

You're right regarding the metadata.

As for the separate files, validation in Symfony is not doctrine specific, that's why it's in a separate file. If you have a look at some doctrine extensions like ``Prezent translable`` or ``Doctrine2 behavioral extensions``, the natural location for the custom tags are the Doctrine mapping files as they are specific to doctrine, by looking at just one file you see the whole picture.

Yes, you could have your own mapping files, but then you would need to do some Symfony magic to be able to load them, and this is what would be nice to avoid.

I think of it as a way to easily extend doctrine mapping capabilities, in a 'plugin' way.

I'm currently working on a i18n bundle for Symfony, the tags I add in doctrine mapping files create associations between entities and their translations: I've had to create quite a few compiler passes for my current project to work as desired, and I see no way of abstracting this in a general way, it will need to be application specific. If I could hook into the Doctrine workflow and get those tags to populate my metadata class, that would be great, simple and reusable.

Comment by Gonzalo Vilaseca [ 19/Nov/14 ]

I've come out with another use case:
I need some custom metadata when the repository is instantiated, AFAIK there is no way of doing this right now, or is there?

Comment by Marco Pivetta [ 19/Nov/14 ]

You'd use a different metadata factory for that, specific to your use-case.
Mixing ORM mappings with the rest will just cause more coupling between the ORM and the userland use-case.





[DDC-3399] indexBy expects db field names insteadof model property names Created: 19/Nov/14  Updated: 19/Nov/14

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

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


 Description   

The following example does work:

Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
/**
 * @ORM\Entity
 */
class Order {

	use IDTrait;

	/**
	 * @ORM\OneToMany(
	 * 		targetEntity="OrderCategory",
	 * 		mappedBy="order",
	 * 		indexBy="my_category_id",
	 * 		fetch="EAGER",
	 * 		cascade={"all"},
	 * 		orphanRemoval=true
	 * )
	 * @var Collection
	 */
	private $categories;

}

/**
 * @ORM\Entity
 */
class OrderCategory {

	/**
	 * @ORM\ManyToOne(targetEntity="Order", inversedBy="categories")
	 * @ORM\JoinColumn(name="order_id", referencedColumnName="id", onDelete="CASCADE")
	 * @ORM\Id
	 * @var Order
	 */
	private $order;

	/**
	 * @ORM\ManyToOne(targetEntity="Category")
	 * @ORM\JoinColumn(name="my_category_id", referencedColumnName="id", onDelete="RESTRICT")
	 * @ORM\Id
	 * @var Category
	 */
	private $category;

}

If you use indexBy="category", it does not work. Why are the object property names used for referencing in most of the mapping, but for indexBy you have to use the db field name? It is nowhere mentioned in the docs.
I didnt test this with non-association properties as indexBy.






[DDC-3397] [GH-1186] Add a EntityRepository#createQuery() method Created: 18/Nov/14  Updated: 18/Nov/14  Resolved: 18/Nov/14

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

Type: New Feature Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: createquery, custom-repository, dql, repository


 Description   

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

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

Message:

This is usefull when you don't want to use a query builder in a custom repository.



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

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





[DDC-3398] PersistentCollection doesn't check that Entity is managed before scheduling orphan removal Created: 18/Nov/14  Updated: 18/Nov/14

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

Type: Bug Priority: Major
Reporter: Nicholas Dobie Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orphanRemoval


 Description   

I am adding and removing a non-persisted entity to a PersistentCollection before flushing. The collections field is an OneToMany relation with orphanRemoval. When the entity is removed it is automatically scheduled for orphanRemoval but is never checked if it is actually a managed entity before being scheduled which causes an exception. After it has been scheduled there is no way to unschedule it other than completely clearing the UnitOfWork.



 Comments   
Comment by Marco Pivetta [ 18/Nov/14 ]

Does this affect also later versions?





[DDC-3386] Multiple Level Discriminator Mapping Created: 11/Nov/14  Updated: 18/Nov/14

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

Type: Bug Priority: Minor
Reporter: Patrick Rose Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: inheritance, mapping, orm
Environment:

Linux, PHP 5.5.9



 Description   

We currently have a situation where we're required to have up to 4 levels of discriminator mappings, and we're finding that Doctrine will insert into our root entity table, and the leaf entity table correctly. However, the tables in between are not being set at all.

The hierarchy is below:

Deal -> EcommerceDeal
Deal -> EcommerceDeal -> ItemSpecific
Deal -> EcommerceDeal -> ItemSpecific -> ItemSpecificScheduled
Deal -> EcommerceDeal -> DealSet -> SetCombo
Deal -> EcommerceDeal -> DealSet -> SetMoreForLess

When inserting an ItemSpecific entity, I found that the Deal and ItemSpecific tables were filled but the EcommerceDeal was not.

There's not much documentation about trees that are slightly more complicated than the Employee, Person, Admin example in the docs so there's a chance I've misunderstood how to build the tables correctly.

Currently we only have one discriminator column on the Deal table. Should we instead be setting up several columns that are nullable and setting new discriminator columns further down the tree?

EDIT: All classes are Class Table Inheritance, in case that is unclear



 Comments   
Comment by Patrick Rose [ 11/Nov/14 ]

The thing that always confuses me while I'm working on this is the fact that I can select from the Database fine. I've got dummy data in each table and Doctrine is clever enough to select all the correct fields from the correct tables so I'm unsure whether I've made a mistake or if Doctrine has a bug.

Comment by Marco Pivetta [ 11/Nov/14 ]

This looks like normal ORM behavior to me, not really requiring any change. What's the reason for inserts on the other tables?

Comment by Patrick Rose [ 12/Nov/14 ]

We have data that's the same across all Ecommerce Deal types (things like the start time, end time etc). I'd expect to be able to set all the values on (say) an ItemSpecific deal and Doctrine to insert the generic data in the EcommerceDeal table.

Comment by Patrick Rose [ 12/Nov/14 ]

It turns out that Doctrine does support this out of the box. A predecessor had overriden the JoinedSubclassPersister with the sole purpose being to comment out the section relating to discriminator columns.

Comment by Patrick Rose [ 12/Nov/14 ]

Problem is with an overridden method not in the Doctrine core.

Comment by Marco Pivetta [ 13/Nov/14 ]

Patrick Rose do you mean that your version (local file) of the JoinedSubclassPersister was monkey-patched?

Comment by Patrick Rose [ 13/Nov/14 ]

Undoing monkey patch does not fully fix issue

Comment by Patrick Rose [ 13/Nov/14 ]

Marco: We'd overridden a whole bunch of classes to do various things, but I've got no idea what those were (these happened at least 6 months before I joined).

The JoinedSubclassPersister was overridden and just commented out two lines

$tableAlias = ($this->class->rootEntityName == $this->class->name) ? $baseTableAlias : $this->getSQLTableAlias($this->class->rootEntityName);
$columnList[] = $tableAlias . '.' . $discrColumn;

From speaking to people, it seems that the point of using that was to allow the discriminator columns to be on the incorrect tables.

However, even with undoing this, I've just tried to create a ComboDeal and it inserted into the root table and the leaf table but none of the other tables. However it looks like ItemSpecific entities are fine. I'll just retry creation of each entity type and get back to you.

Comment by Patrick Rose [ 13/Nov/14 ]

Just finished doing that. I can create EcommerceDeal entities, and ItemSpecific entities and they'll insert into the correct tables (so the EcommerceDeal entity saves into the EcommerceDeal and Deal tables, and the ItemSpecific entity saves into the ItemSpecific, EcommerceDeal and Deal tables).

The rest only insert into the Deal table and the table relating to that class.

Comment by Patrick Rose [ 18/Nov/14 ]

Is there an update on how we can resolve this?

Comment by Patrick Rose [ 18/Nov/14 ]

We've spent a day looking through and trying to work out what seems to be happening and seem to have a resolution.

It appears that the method of getting the parents was only getting those which weren't transient (and thus were entities), which in our case wasn't working since then Doctrine complains about duplicate column definitions. After overriding the getParentClass to allow us to be explicit we got it to work.





[DDC-3396] In Doctrine\ORM\Query\SqlWalker tableAliasMap and tableAliasCountershould be exposed Created: 17/Nov/14  Updated: 17/Nov/14

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

Type: Improvement Priority: Minor
Reporter: Ioan Badila Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: sql-walker


 Description   

I see that Doctrine\ORM\Query\SqlWalker::tableAliasMap and tableAliasCounter are private properties but this doesn't scale well with public Doctrine\ORM\Query\SqlWalker::getSQLTableAlias($tableName, $dqlAlias = '')

public function getSQLTableAlias($tableName, $dqlAlias = '')
{
$tableName .= ($dqlAlias) ? '@[' . $dqlAlias . ']' : '';

if ( ! isset($this->tableAliasMap[$tableName]))

{ $this->tableAliasMap[$tableName] = strtolower(substr($tableName, 0, 1)) . $this->tableAliasCounter++ . '_'; }

return $this->tableAliasMap[$tableName];
}

For me, getSQLTableAlias() is useful in my custom walker but I can't actually use it without exposing tableAliasMap and tableAliasCounter.






[DDC-3395] matching(Criteria::create()->orderBy()) is sorting in case insensitive manner Created: 17/Nov/14  Updated: 17/Nov/14

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

Type: Bug Priority: Minor
Reporter: Dona Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: case-sensitivity, collation, collection, criteria, sorting


 Description   

for example if we have two strings "IT" and "innovation" after sort by ASC , "IT" is coming before "Innovation".
I was expecting the arrayCollection to do a natural sort.



 Comments   
Comment by Marco Pivetta [ 17/Nov/14 ]

Dona this behavior may change depending on server-side collation anyway.





[DDC-3387] [GH-1182] #1086 identifier type in proxies Created: 11/Nov/14  Updated: 17/Nov/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: hydration, jti, persister, sti

Issue Links:
Dependency
is required for DDC-3223 Failing test (get id return string type) Open
Reference
is referenced by DDC-3394 UOW CreateEntity failure with zerofil... Resolved

 Description   

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

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

Message:

See #1086. This fix simply ensures that the column type for identifiers of proxies of STI/JTI are kept consistent with the DBAL types they are mapped to.

May be related/colliding with #1178

Ping @jaspernbrouwer






[DDC-3393] Cannot extend existing internal functions Created: 17/Nov/14  Updated: 17/Nov/14  Resolved: 17/Nov/14

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

Type: Bug Priority: Minor
Reporter: Rob Spick Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

On the MySQL platform, i want to use DATE_SUB with more than just DAY and MONTH, so I write a function and give it the identifier of date_sub however this is not allowed?

Why are we not able to extend the functions, surely if we're writing the function we know the platform that we're extending it on and the other platform specific functions will fail at parsing due to an unsupported type.

I don't want to have to prefix my code with MY_DATE_SUB only for an additional type to be supported at a later date, that would just lead to inconsistencies in my code.



 Comments   
Comment by Marco Pivetta [ 17/Nov/14 ]

Overriding DQL functions may have terrible and unforeseen consequences when dealing with any codebase. If you have a specific use-case, use a specific DQL function, but do not try overriding an existing one that may be used in ways that you are not aware of.





[DDC-3392] Add a way to use a custom instantiator in ClassMetadataInfo Created: 13/Nov/14  Updated: 13/Nov/14  Resolved: 13/Nov/14

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

Type: Improvement Priority: Minor
Reporter: Rekamlefat Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: inheritance, orm


 Description   

Hi,

In my project, I'm using a home made container of dependencies, that I use sometimes in my entities. I found very useful to use EntityListeners and EntityResolver to be able, on PostLoad event, to inject dependencies into the models.

Thinking of that, should it be a good idea to implement some custom instantiators that could do this, using the model's constructor?

Here's a quick example:

class MyInstantiator implements \Doctrine\Instantiator\InstantiatorInterface {

    private $container;

    public function __construct($container) {
        $this->container = $container;
    }

    public function instantiate($className) {
        // return a new model instance, with it's dependencies
        return $this->container->get($classname);
    }

}

// set default instantiator in entity manager
// container = your dependencies container
$entityManager->setDefaultInstantiator(new MyInstantiator($container));

Now in ClassMetadataInfo class, the instantiator cannot be overridden. Check these lines below. Instantiator is private and created via [new] in constructor and in wakeup method. Do we need to override ClassMetadataInfo to achieve this?

DoctrineORMMappingClassMetadataInfo.php
class ClassMetadataInfo implements ClassMetadata
{
    ...

    /**
     * @var \Doctrine\Instantiator\InstantiatorInterface|null
     */
    private $instantiator;

    /**
     * Initializes a new ClassMetadata instance that will hold the object-relational mapping
     * metadata of the class with the given name.
     *
     * @param string              $entityName     The name of the entity class the new instance is used for.
     * @param NamingStrategy|null $namingStrategy
     */
    public function __construct($entityName, NamingStrategy $namingStrategy = null)
    {
        $this->name = $entityName;
        $this->rootEntityName = $entityName;
        $this->namingStrategy = $namingStrategy ?: new DefaultNamingStrategy();
        $this->instantiator   = new Instantiator();
    }

    // ...

    /**
     * Restores some state that can not be serialized/unserialized.
     *
     * @param \Doctrine\Common\Persistence\Mapping\ReflectionService $reflService
     *
     * @return void
     */
    public function wakeupReflection($reflService)
    {
        // Restore ReflectionClass and properties
        $this->reflClass    = $reflService->getClass($this->name);
        $this->instantiator = $this->instantiator ?: new Instantiator();

        // ...
    }
    // ...
}

Thanks,



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

This is exactly the type of dependency that you DO NOT want in an entity.

Don't do this, it's discouraged and it will likely cause only headaches.

Marking as Won't Fix.

Comment by Rekamlefat [ 13/Nov/14 ]

Thanks for your feedback. I'm playing with this design pattern since a few days only, so I'm not quite confident about what is or isn't "good".

So your approach is to add a listener to the entity and manage all dependencies in the listener class? Can we say that's a best practice, or even a rule, to not ask for any dependency in any method of any entity?

Have a nice evening

Comment by Marco Pivetta [ 13/Nov/14 ]

So your approach is to add a listener to the entity and manage all dependencies in the listener class?

The idea is to NOT have dependencies in entities at all. It is arguably not necessarily an absolute, but it's a good practice to let entities only be aware of their siblings.

See also http://misko.hevery.com/2008/09/30/to-new-or-not-to-new/





[DDC-3366] [GH-1170] Added prev to collections Created: 26/Oct/14  Updated: 13/Nov/14  Resolved: 13/Nov/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Can't Fix Votes: 0
Labels: collection, interface, iterator


 Description   

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

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

Message:

Added prev() to array collections. This is needed when you want to cycle through the array in reverse order.



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

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

Comment by Doctrine Bot [ 13/Nov/14 ]

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

Comment by Marco Pivetta [ 13/Nov/14 ]

Can't be done in 2.x





[DDC-2894] on-update cascade for one-to-one association Created: 08/Jan/14  Updated: 13/Nov/14

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

Type: Bug Priority: Minor
Reporter: I. S. Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: orm, schematool, xml


 Description   

I'm trying to use on-update cascade in a one-to-one association but it ends in on-update restrict when I update the database tables.
I'm using XML Definition an my definition for this specific association looks like this:

<one-to-one field="scope" target-entity="Application\Entity\Scope">
<join-column name="scope_id" referenced-column-name="id" nullable="false" on-delete="CASCADE" on-update="CASCADE" />
<cascade>
<cascade-persist />
<cascade-remove />
</cascade>
</one-to-one>

This works pretty well when I use on-update="CASCADE" in a many-to-one association, but one-to-one just ignores it.
When I change the database manually everything works well, but the next update from command line will override it.



 Comments   
Comment by Pradeep Krishnan [ 12/Nov/14 ]

Any updates on this one?

Comment by Marco Pivetta [ 13/Nov/14 ]

We don't support on-update anymore, as identifiers should be immutable.





[DDC-2230] Changes from DDC-1690 trigger a bug in entity merging Created: 09/Jan/13  Updated: 12/Nov/14  Resolved: 26/Feb/13

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

Type: Bug Priority: Critical
Reporter: Patrick Schwisow Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

Following the changes for DDC-1690, I encountered a serious bug in how EntityManager::merge(...) functions for entities that use NOTIFY change tracking. It's related to interaction between lazy loading and calls to addPropertyChangedListener().

Scenario:

  • EntityA has a One-To-One, lazy-load association to EntityB
  • EntityB implements NotifyPropertyChanged and uses change tracking policy "NOTIFY"

Steps to reproduce:

  1. $instanceA = $em->find('EntityA', $id)
  2. $em->clear()
  3. $instanceA = $em->merge($instanceA)
  4. $instanceA->getB() will return a proxy for B that is marked as initialized by contains no data

Workaround: Mark EntityB::addPropertyChangedListener(...) as 'final', so it doesn't get proxied and lazy loading is not triggered.



 Comments   
Comment by Patrick Schwisow [ 09/Jan/13 ]

Also, the returned proxy from $instanceA->getB() is in the entityStates array but not in the identity map

Comment by Marco Pivetta [ 23/Jan/13 ]

Looks like this one is related to DDC-1734

Comment by Marco Pivetta [ 23/Feb/13 ]

I implemented a fix at https://github.com/Ocramius/doctrine2/compare/hotfix;DDC-2230

Please let me know if that branch works for you: I will open a PR tomorrow.

Comment by Benjamin Eberlei [ 23/Feb/13 ]

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

Comment by Benjamin Eberlei [ 26/Feb/13 ]

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

Comment by Doctrine Bot [ 29/Apr/14 ]

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

Comment by Doctrine Bot [ 12/Nov/14 ]

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





[DDC-1942] problem with serialize/merging entities with aggregation Created: 24/Jul/12  Updated: 12/Nov/14  Resolved: 27/Feb/13

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

Type: Bug Priority: Major
Reporter: gabriel sancho Assignee: Marco Pivetta
Resolution: Duplicate Votes: 3
Labels: merge, serialize
Environment:

linux, php 5.4.4, apache 2.2.22, mysql 5.5


Attachments: Text File project_debug.log    

 Description   

i have these two entities:

namespace nuevo_paquete;

class Clase_01{
	/**
	* @Id
	* @Column(name="id",type="integer",nullable=false)
	* @GeneratedValue
	*/
	protected $id;
        
        /**
	* @ManyToOne(targetEntity="\paquete_02\Clase_03", inversedBy="clase_01", fetch="EXTRA_LAZY", cascade={"detach","merge"})
	* @JoinColumn(name="clase_03", referencedColumnName="id")
	*/
	protected $clase_03;

        /**
	* @ManyToOne(targetEntity="\paquete_02\Clase_03", inversedBy="clase_01_1", fetch="EXTRA_LAZY", cascade={"detach","merge"})
	* @JoinColumn(name="clase_03_1", referencedColumnName="id")
	*/
	protected $clase_03_1;
}
namespace paquete_02;
class Clase_03{
   /**
	* @Id
	* @Column(name="id",type="integer",nullable=false)
	* @GeneratedValue
	*/
	protected $id;

        /**
	* @OneToMany(targetEntity="\nuevo_paquete\Clase_01", mappedBy="clase_03", fetch="EXTRA_LAZY", cascade={"detach"})
	*/
	protected $clase_01;
	
	/**
	* @OneToMany(targetEntity="\nuevo_paquete\Clase_01", mappedBy="clase_03_1", fetch="EXTRA_LAZY", cascade={"detach"})
	*/
	protected $clase_01_1;
}

Clase_01 have two aggregation association with Clase_03

Clase_01 ------> Clase_03

-----> Clase_03_1

when serialize an object of class Clase_01 and then unserialize, i lost the reference to the object of class Clase_03
but i can see Clase_03_1

ej:

$aux_orm = $em->find('nuevo_paquete\Clase_01', 1);
$em->detach($aux_orm);
$aux_s = serialize($aux_orm);
$aux_orm = unserialize($aux_s);

$aux_orm = $em->merge($aux_orm);
echo '['.$aux_orm->getId().']'; // [1]
echo '['.$aux_orm->getClase_03()->getId().']'; // [] expected : [1]
echo '['.$aux_orm->getClase_03_1()->getId().']'; // [1]

when i call get_clase_03() before detach the object, i can see the object Clase_03
ej:

$aux_orm = $em->find('nuevo_paquete\Clase_01', 1);
$aux_orm->getClase_03()->getId();

$em->detach($aux_orm);
$aux_s = serialize($aux_orm);
$aux_orm = unserialize($aux_s);

$aux_orm = $em->merge($aux_orm);
echo '['.$aux_orm->getId().']'; // [1]
echo '['.$aux_orm->getClase_03()->getId().']'; // [1]
echo '['.$aux_orm->getClase_03_1()->getId().']'; // [1]


 Comments   
Comment by gabriel sancho [ 24/Jul/12 ]

if i call $em->find() i still not able to view the object

//----------------------------------------
$aux_orm = $em->find('nuevo_paquete\Clase_01', 1);
$em->detach($aux_orm);
$aux_s = serialize($aux_orm);
$aux_orm = unserialize($aux_s);

$aux_orm = $em->merge($aux_orm);
echo '['.$aux_orm->getId().']'; // [1]
echo '['.$aux_orm->getClase_03()->getId().']'; // [] expected : [1]
echo '['.$aux_orm->getClase_03_1()->getId().']'; // [1]

$aux_orm = $em->find('nuevo_paquete\Clase_01', 1);
echo '['.$aux_orm->getId().']'; // [1]
echo '['.$aux_orm->getClase_03()->getId().']'; // still empty [] expected : [1]

//----------------------------------------
and if i have another register referencing the same object of class_03, i can't view
ej:

$aux_orm = $em->find('nuevo_paquete\Clase_01', 2);
echo '['.$aux_orm->getId().']'; // [2]
echo '['.$aux_orm->getClase_03()->getId().']'; // still empty [] expected : [1]
Comment by Marquez Alejandra [ 24/Jul/12 ]

i have the same problem

Comment by Benjamin Eberlei [ 29/Jul/12 ]

formatted code

Comment by Benjamin Eberlei [ 29/Jul/12 ]

Can you paste a var_dump() of class1 after you call detach and before serialize and then another one after you called unserialize? Also a var_dump of the serialized string $aux_s

Comment by gabriel sancho [ 30/Jul/12 ]

var_dump in attached file

Comment by gabriel sancho [ 11/Sep/12 ]

i found that if the class has more than two levels have the same problem
by ex. i have to do

// class1 -> register id 1
// class2 -> register id 1
// class3 -> null, don't exist
$class2 = $class1->getClass2();
$class3 = $class2->getClass3();
$class3->getId();

otherwise doctrine insert new registers in database for class3
after unserialize

Comment by gonzalo [ 11/Sep/12 ]

I have same problems

Comment by gabriel sancho [ 11/Sep/12 ]

if i declare in the entity annotation fetch="EAGER" works fine

Comment by Valentin Claras [ 11/Dec/12 ]

I have the same problem.

From what I saw, if I use fetch: EAGER, all my distinct entities are merged indeed, but if a specific entity (instance) is in two different collections, only one collection will have this instance.

So, any news about this bug ?

Comment by Valentin Claras [ 13/Dec/12 ]

I'm still trying to get my stuff works, and I'm now pretty sure that as soon as an object have to be merge more than once in a row (because of cascade associations), it end up being only in one collection, and lost for other entities.

I hope this could help.

Comment by Marco Pivetta [ 23/Jan/13 ]

I think this one is also related with DDC-1734 (noticed a lot of un-initialized objects).

gabriel sancho can you please try initializing ALL of these related objects prior to detaching/serializing and repeat your checks?

Comment by gabriel sancho [ 24/Jan/13 ]

How do I have to initialize the objects?

Comment by Marco Pivetta [ 24/Jan/13 ]

gabriel sancho by calling any method that is not `getId` on them.
This will initialize them

Comment by Marco Pivetta [ 23/Feb/13 ]

gabriel sancho news on this one? Managed to verify it?

Comment by Marco Pivetta [ 23/Feb/13 ]

This may be a duplicate of DDC-2306

Comment by Benjamin Eberlei [ 26/Feb/13 ]

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

Comment by Marco Pivetta [ 27/Feb/13 ]

This issue is valid only before the fix introduced at DDC-2306. Duplicate confirmed

Comment by Doctrine Bot [ 29/Apr/14 ]

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

Comment by Doctrine Bot [ 12/Nov/14 ]

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





[DDC-3368] [GH-1172] Don't initialize detached proxies when merging them. Created: 02/Nov/14  Updated: 12/Nov/14

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

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


 Description   

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

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

Message:

Ticket DDC-1392 fixed an issue where uninitialized proxies could not be merged
because the merge routine couldn't get the identifier from them. The soution
was to initialize the proxy.
Ticket DDC-1734 fixed the merging of unserialized uninitialized proxies by
resetting their internals, so these proxies were able to initialize, as required
by the fix for DDC-1392.

Somehow, in the meanwhile, the fix for DDC-1392 is not needed anymore:
reverting the patch will not break the associated test (but it does break the
test for DDC-1734). This means it is not needed anymore to initialize the proxy
when merging.

Uninitialized proxies that get merged should not be loaded at all. Since they
are not initialized, the entity data for sure hasn't changed, so it can be
safely ignored. Actually, the only thing the data is needed for while merging,
is to copy it into the managed entity, but that one is already supposed to be
up to date. By not initializing the proxy, a potential database roundtrip is
saved, and the fix for DDC-1734 is not needed anymore.

Besides optimizing the merge, this patch also solves an issue with merging.
Currently, when a detached uninitialized proxy is merged while there is already a
corresponding managed entity (proxy or not), the ORM returns a blank entity
instead of returning the already managed entity. This patch makes sure that
already existing managed entities are re-used.



 Comments   
Comment by Doctrine Bot [ 12/Nov/14 ]

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





[DDC-3390] [GH-1185] add a new method that return the mapped properties Created: 12/Nov/14  Updated: 12/Nov/14

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

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


 Description   

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

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

Message:

There are some implementations that use the doctrine metadata to get the properties of a entity (DoctrineObject), and it currently uses the getFieldNames and getAssociationNames methods to retrieve and merge it.

Since the embeddables feature was added, that method will return more than one metadata for each embeddable property, and then the hydrator can never find the appropriate setter for that property.

This method allows some implementation to retrieve all mapped fields from an entity, something that can't be done using get_class_vars for example.

Of course this implementation could be done in the hydrator, but i don't think it is its responsibility to filter and merge data received from the ClassMetadata. Since you have methods to retrieve the metadata formatted as the database structure, you should also have methods to retrieve the information to the other side, in object structure.






[DDC-2338] Entity with composite foreign keys identifiers should be persisted after related entities without exception Created: 07/Mar/13  Updated: 12/Nov/14  Resolved: 12/Nov/14

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

Type: Improvement Priority: Minor
Reporter: Alessandro Tagliapietra Assignee: Marco Pivetta
Resolution: Can't Fix Votes: 0
Labels: autoincrement, commitorder, identifier, identity, orm, sequence, unitofwork
Environment:

Mac OSX 10.8, php 5.4.11, doctrine git master version


Issue Links:
Dependency
depends on DDC-2339 [GH-605] DDC-2338 Added failing test ... Resolved
Reference
relates to DDC-3389 [GH-1184] Postgres SERIAL is not a po... Resolved

 Description   

I've seen that when you create an entity with a composite foreign key as identifier it cannot be flushed until the related entities are already flushed to the database and not just persisted.

It would be nice to let the user flush all the entities together and just INSERT first the related entities to get the ID and then use that to INSERT the entity with composite foreign keys.

I'm going to create a pull request with the failing test.



<
 Comments