[DDC-3808] [GH-1448] Fix some docblock return types and namespaces Created: 03/Jul/15  Updated: 03/Jul/15

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 dave1010:

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

Message:






[DDC-1310] Datetime fields merge bug Created: 01/Aug/11  Updated: 03/Jul/15  Resolved: 06/Aug/11

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

Type: Bug Priority: Minor
Reporter: Somogyi László Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None
Environment:

Win7, PHP 5.3.6



 Description   

Merge compares Datetime objects by ===; so if you assign a new datetime object to a datetime field (which contains the same date in the db already), then merge will issue an UPDATE on that field (because the objects hashes don't match for ===). The expected behavior is to assume it is unchanged, so no update.

Solution: Datetime objects should be compared by == (or by $dt->format('something') maybe)

Easy to reproduce:

Example.php
<?php
/** @Entity */
class EgEntity {
  /** @Id */
  private $id;
  /** @Column(type="datetime")
  private meeting;
  //other fields...

  public function setId($id) {
    $this->id = (int)$id;
  }

  public function setMeeting(Datetime $dt) {
    $this->meeting = $dt;
  }
}
$a = new EgEntity();
$a->setId(1);
$a->setMeeting(new Datetime('2011-08-01'));
$em->merge($a); //this will issue an UPDATE even if id 1 is 2011-08-01 already
?>


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

That is expected behavior, objects are compared by reference, otherwise we couldn't implement a generic comparison mechanism for all types based on objects and the code would get confusing and slow (this conversion/comparison loops are some of the most called code in Doctrine 2)

Comment by Jamal Youssefi [ 03/Jul/15 ]

Have you find a solution?

I use doctrine2 on symfony2 and have the following error when i try to merge a DateTime object:
"The class 'DateTime' was not found in the chain configured namespaces ...."

Comment by Somogyi László [ 03/Jul/15 ]

Hi Jamal.

No solution for my problem, but yours look different.
I tried my example class (fixed to a working one, and for symfony 2: https://gist.github.com/slaci/f49271638b77c30993b7) and this works:

    /**
     * @Route("/", name="homepage")
     */
    public function indexAction()
    {
        $eg = new \AppBundle\Entity\EgEntity();
        $eg->setId(1);
        $eg->setMeeting(new \DateTime('2015-07-03 10:00:00'));

        $em = $this->getDoctrine()->getManager();
        $em->merge($eg);
        $em->flush();
   }

This stuff runs without error, and always runs the update query (which was the topic of this issue many years ago and sad it's still not fixed).

You are using another DateTime class from a custom namespace, not the builtin \DateTime, or i don't know, but this should work when used correctly.





[DDC-3807] [GH-1447] Fix second level caching for queries with multiple joins Created: 03/Jul/15  Updated: 03/Jul/15

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 krispypen:

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

Message:

The $metadata of the main entity is not always the metadata you need here, for example when you do join A with B and then B with C. For the second join it was using the metadata from A.






[DDC-2780] IS [NOT] NULL conditions with JOINs Created: 06/Nov/13  Updated: 02/Jul/15

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

Type: Bug Priority: Major
Reporter: Marek Štípek Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

<?php
When trying to apply a [NOT] NULL condition on LEFT JOINed association. It ends with an error.

"Cannot add having condition on a non result variable."

$queryBuilder
->leftJoin('r.players', 'players', 'WITH', 'players = :player')
->where('players IS NULL');

It was working 3 month ago. But then, this commit broke it.

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

Or in other words if this is not a bug. How to test if the collection does not contain let's say a user with ID 5 (AND XX OR YY) with DQL/queryBuilder API? IN SQL I would just simply LEFT JOIN it with ON condition and then i would test it for existence using IS NULL in WHERE condition. How to do this using DQL when the pasted example ends with an error?



 Comments   
Comment by Marek Štípek [ 30/Mar/14 ]

OK. players.id IS NULL (but it's uglier)

Comment by Sullivan SENECHAL [ 14/Apr/15 ]

`r.players IS NULL` works too.

But I don't understand why this will be not fixed. I agree, it's uglier.

Comment by Marek Štípek [ 02/Jul/15 ]

I am checking the activity and it looks It was me who changed it to "Won't fix". If it's true then it was an accident. Sorry if I'm wrong.





[DDC-3806] Add example on how to connect listener to entity implementing NotifyPropertyChanged Created: 02/Jul/15  Updated: 02/Jul/15

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

Type: Documentation Priority: Minor
Reporter: Wouter Wiltenburg Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: event, listener


 Description   

I am implementing the notify `ChangeTracking` policy according to:

http://doctrine-orm.readthedocs.org/en/latest/cookbook/implementing-the-notify-changetracking-policy.html

And chapter 17.3. Notify:

http://doctrine-orm.readthedocs.org/en/latest/reference/change-tracking-policies.html#notify

But an example on where to best connect the listener to the entity implementing the NotifyPropertyChanged interface is missing. It would be great to add some best practices on how and where to add the listeners.






[DDC-3805] [GH-1445] Allow access to Query#getResultSetMapping Created: 01/Jul/15  Updated: 01/Jul/15

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

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


 Description   

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

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

Message:

Hi,

I've recently came across an issue which would require modifying the result set mapping of a query made with query builder.

I would like to SUM a field with a *custom type*, which is stored as an int, but is normally converted to a custom value object.

When using an aggregation function, the returned result is a simple int.

Is there any reason the `Query#getResultSetMapping` has to be protected?

Is there any danger if I do this?
```php
$rsm = $query->getResultSetMapping();
$rsm->addScalarResult('sclr_2', 'dailySpendLimit', 'bigMoney2Precision');

$query->setResultSetMapping($rsm);
```

Related: https://github.com/doctrine/doctrine2/commit/ea14bcff4a2a78bf774e8847b6645dca112f9757

Thanks!






[DDC-3804] [GH-1444] Missing opening tags added in one of the tutorials Created: 01/Jul/15  Updated: 01/Jul/15

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 cezarykluczynski:

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

Message:

This commit adds opening tags to one of the tutorials, so code can be properly highlighted on http://doctrine-orm.readthedocs.org/en/latest/tutorials/override-field-association-mappings-in-subclasses.html






[DDC-3803] [GH-1425] Also export default value for fieldMapping Created: 30/Jun/15  Updated: 30/Jun/15

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


 Description   

Also export default value for fieldMapping.

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

I've added some test cases but on some platforms phpunit failed because composer is out of date.






[DDC-3802] [GH-1443] Unsigned Created: 30/Jun/15  Updated: 30/Jun/15

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 meeuw:

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

Message:

unsigned isn't in $fieldMapping but in $fieldMapping['options']['unsigned']






[DDC-3801] [GH-1442] Corrected bad class reference in "Adding own commands" Created: 30/Jun/15  Updated: 30/Jun/15

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 elazar:

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

Message:






[DDC-3800] [GH-1441] [QUERY] "INSTANCE OF" now behaves correctly with subclasses Created: 29/Jun/15  Updated: 29/Jun/15

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: 1
Labels: None


 Description   

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

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

Message:

There was a bug in the "INSTANCE OF" operator as described in
https://groups.google.com/forum/#!topic/doctrine-user/B8raq8CNMgg

"INSTANCE OF" was not taking into account subclasses.
It was merely translating the class to its discriminator.
This is not correct since the class can have subtypes and those
are, indeed, still instance of the superclass.
Also, classes may not have a discriminator (e.g. abstract classes).

This commit also provide useful tests to avoid regression.






[DDC-3799] Unexpected outcome when using prePersist event and ID GeneratedValue strategy is set to NONE Created: 29/Jun/15  Updated: 29/Jun/15

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

Type: Documentation Priority: Minor
Reporter: yanick Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Setup: I have an entity that uses natural ids (GeneratedValue strategy is set to none). The entity also has life cycle callbacks for prePersist and preUpdate.

Expectation: The UnitOfWork would throw an EntityNotFoundException if I attempt to merge an untracked entity that does not exist in the database. I can catch the exception and call persist. All life cycle callbacks would be executed.

Outcome: No exception is thrown. The UOW creates a new instance of the the incoming object using only the ID. Persist is called on the newly created object and prePersist executes against the empty object. Finally the incoming entity is merged, which overwrites any properties that are managed by prePersist.

I was able to work around this by setting the GeneratedValue strategy to "Custom" and CustomIDGenerator to the AssignedGenerator.






[DDC-3798] Allow Collections to be used transparently with Array-Types Created: 29/Jun/15  Updated: 29/Jun/15

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

Type: Improvement Priority: Minor
Reporter: Robert Schönthal Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm


 Description   

Currently its not possible to use Collection with Array-Types transparently:

Entity.php
Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
class Entity
{
    /**
     * @var string[]|Collection
     *
     * @ORM\Column(type="json_array")
     */
    private $aliases = [];

    public function __construct()
    {
        $this->aliases  = new ArrayCollection();
    }
}

if i add Values to the Collection and persist the Entity the aliases are empty.
I need Lifecycle Listener which converts between ArrayCollection and array like this:

Entity.php
Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
    /**
     * @ORM\PrePersist
     */
    public function prePersist()
    {
        $this->aliases = $this->aliases->toArray();
    }

it would be good to have an automatic conversion! Should be fairly easy, i could write a PR if your interessted in...or am i missing a hidden piece?






[DDC-3797] IDENTITY function does not hydrate custom types Created: 26/Jun/15  Updated: 26/Jun/15

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


 Description   

The function IDENTITY does not hydrate customs types. I've a OrganizationId type, but when a execute the following DQL I got an error, because Doctrine tries to pass an integer as argument of my object constructor instead of an OrganizationId instance.

<mapped-superclass name="Campaign">
        <id name="id" column="id" type="campaign_id" />
        <id name="organization" column="organization_id" association-key="true" />
        <many-to-one field="organization" target-entity="Organization">
            <join-column name="organization_id" referenced-column-name="id" on-delete="CASCADE" on-update="CASCADE" />
        </many-to-one>
    </mapped-superclass>
SELECT NEW CampaignDTO(c.id, IDENTITY(c.organization), c.name) FROM Campaign c

Result:

Catchable Fatal Error: Argument 2 passed to Campaign::__construct() must be an instance of OrganizationId, integer given





[DDC-3796] SELECT NEW does not work with composite keys Created: 26/Jun/15  Updated: 26/Jun/15

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


 Description   

I'm getting an error trying to instantiate a DTO using a column that is used as ID and foreign key.

<mapped-superclass name="Campaign">
        <id name="id" column="id" type="campaign_id" />
        <id name="organization" column="organization_id" association-key="true" />
        <field name="name" column="name" type="string" length="255" />
        <many-to-one field="organization" target-entity="Organization">
            <join-column name="organization_id" referenced-column-name="id" on-delete="CASCADE" on-update="CASCADE" />
        </many-to-one>
    </mapped-superclass>
SELECT NEW CampaignDTO(c.id, c.organization, c.name) FROM Campaign c

Result:

[Semantical Error] line 0, col 54 near 'organization,': Error: Invalid PathExpression. Must be a StateFieldPathExpression.





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

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

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

Attachments: File DDC2838Test.php    
Issue Links:
Reference
is referenced by DCOM-275 Collections\Expr\ClosureExpressionVis... Open
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.

Comment by Florian Preusner [ 26/Dec/14 ]

+1

Comment by Simon Paridon [ 26/Jun/15 ]

My idea to solve this would go like this:

  • Add a new class ObjectCollection in Common that implements Collection and Selectable, but requires class metadata.
  • Whenever creating an ArrayCollection with entities / other objects, create an ObjectCollection instead.

The only thing that's causing me a headache is that ideally, there should be code sharing in some form between the matching() implementations of ObjectCollection and PersistentCollection, because both will use class metadata. Maybe this can be achieved somehow using a trait?

If you like the idea, I could look into it further.





[DDC-3795] [GH-1439] One to one unique index mapping bug Created: 26/Jun/15  Updated: 26/Jun/15

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 baerrach:

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

Message:

As per request on google groups.

My original problem was that schema:validate is telling me the database is not up to date and the only SQL it wants to run is DROP INDEX and CREATE INDEX on what is already there.

To write some tests to see why, I started hacking OrmFunctionalTestCase to give me back the class metadata for the model set in use. And while I was doing that I DRYed up the test setup to avoid duplication. But the ValueConversionType stopped working because they DROP TABLES when no other tests do. I think the drop tables was necessary because they use the same entities across some of the different test classes so when the entites were setup the would fail because the table already existed - which is the problem I bumped into.

I've got the code working by sharing the schema creation setup and not dropping tables, but because of this OneToOne mapping issue the tests fail because the unique index name already exists in the name space.

I've pushed the code changes to https://github.com/baerrach/doctrine2/tree/one-to-one-unique-index-mapping-bug so you can see what I am talking about.

Its done in three stages:

b0ce47d Remove tearDownAfterClass() and DROP TABLES

4b5cd37 DRY test setup for entities and modelSets

f7efac6 Fix OneToOne unique constraint mapping

You can run the ValueConversionType to see the failures, and resolution, in action.

phpunit -d memory_limit=-1 tests/Doctrine/Tests/ORM/Functional/ValueConversionType/






[DDC-3794] Cannot set default value on a @joinColumn Created: 25/Jun/15  Updated: 25/Jun/15

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

Type: Bug Priority: Major
Reporter: Ben Meynell Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: joins, schema, schemadiff, validator
Environment:

Symfony 2.3; Ubuntu 14.04



 Description   

The @Column allows for options={"default":1}).

However, @joinColumn does not support options={"default":1}).

The implication of this is that a default value can never be set for new database schemas and for existing schemas that have DEFAULT '1' included in its column definition a schema mismatch will occur when running doctrine:schema:validate.

Since there is no way to define a default on the entity-level there is no way to reconcile the mismatch. Instead, the default value just be removed from the database schema and be enforced on the application level.






[DDC-3720] Doctrine - Invalid column name 'sclr0' Created: 29/Apr/15  Updated: 25/Jun/15

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

Type: Task Priority: Major
Reporter: Belita Colares Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: querybuilder


 Description   

My query doesn't work when i use ->setMaxResult with orderBy SUM.

My dataBase is MSSQL SERVER 2008 R2

$query = $entity->createQueryBuilder('t')
                        ->select('SUM(t.price) AS test')
                        ->setMaxResults(10)
 ->orderBy('test', 'ASC')->getQuery()->getResult();

when i use only
'->select('t.price AS test') ->setMaxResults(10) ->orderBy('test', 'ASC');' doesn't work too

Invalid column name 'sclr0'.
but when i comment this method setMaxResult() my query works fine.

Please help-me, I sorry my english.






[DDC-3793] Unit Of Work - Proxy injected collections 'PersistentCollections' Created: 24/Jun/15  Updated: 24/Jun/15  Resolved: 24/Jun/15

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

Type: Improvement Priority: Major
Reporter: Leonel Franchelli Assignee: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: PersistentCollection, UnitOfWork
Environment:

Symfony 2.7 , Doctrine 2.5.0


Attachments: PNG File Selection_008.png     PNG File Selection_009.png     PNG File Selection_010.png    
Issue Links:
Duplicate
duplicates DDC-391 Allow to specifiy custom Entity and C... In Progress
duplicates DDC-80 Allow custom collections Resolved

 Description   

Hi all , i was looking to extend ArrayCollection i did it, but i notice something very very unusual, when an entity is loaded from the DB the unit of work most precisely on the method 'createEntity' it injects PersistentCollection object in the collections of all the entities, why you do that ?

Is there any way to inject my own subclass of PersistentCollection to the proxy objects ? Of course i know that i have to also extend PersistentCollection and create a CustomPersistentCollection

Sry for my english



 Comments   
Comment by Marco Pivetta [ 24/Jun/15 ]

Custom persistent collections are not yet supported.

See DDC-80 and DDC-391

Comment by Leonel Franchelli [ 24/Jun/15 ]

Thx for answering so quickly , well i just hope in some future version you add this feature eventually





[DDC-80] Allow custom collections Created: 30/Oct/09  Updated: 24/Jun/15  Resolved: 02/Jan/11

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

Type: Improvement Priority: Minor
Reporter: Ville Väänänen Assignee: Roman S. Borschel
Resolution: Won't Fix Votes: 1
Labels: None

Issue Links:
Duplicate
is duplicated by DDC-3793 Unit Of Work - Proxy injected collect... Resolved
Reference
relates to DDC-546 New fetch mode EXTRA_LAZY for collect... Resolved

 Description   

There should be a configuration option which specifies the class-name of the collection that will be created. The specified collection should implement the \Doctrine\Common\Collections\Collection interface. A custom collection would be needed if one want's to have some sort of aggregate functions, like 'getSum()' or 'getWeight()' for example.



 Comments   
Comment by Roman S. Borschel [ 30/Oct/09 ]

You can already use any Collection implementation you like as long as you program to the interface after the entity has become managed (or detached). This is from the manual:

"Collection-valued persistent fields and properties must be defined in terms of the Doctrine\Common\Collections\Collection interface. The collection implementation type may be used by the application to initialize fields or properties before the entity is made persistent. Once the entity becomes managed (or detached), subsequent access must be through the interface type."

The only thing that could probably be enhanced is to instantiate custom collection types when reconstituting entities from the database. But remember, even then you must program to the interface, not the concrete implementation, therefore, what you have in mind might not work. Collection implementations are wrapped in a PersistentCollection during runtime for change-tracking/lazy-load. A PersistentCollection supports the Collection interface only.

I have thought about implementing __call in PersistentCollection to forward unknown method calls to the wrapped instance. However I'm not sure I like that. Doctrine would be unaware of any changes that are made to the collection in those methods, making them rather fragile.

I hope you get the picture

Comment by Christian Heinrich [ 07/May/10 ]

I'm currently browsing through some open tickets and I think we could mark this one as invalid / won't fix, as the wrapping is a major feature.

Comment by Benjamin Eberlei [ 01/Jul/10 ]

I think this two go hand in hand, if we do the EXTRA_LAZY stuff we could also do this one here.

Comment by Benjamin Eberlei [ 01/Jul/10 ]

Ok, slightly modified, you can specifiy which persistent collection implementation you want to use for your entities.

Comment by Benjamin Eberlei [ 02/Jan/11 ]

This is not necessary anymore with EXTRA_LAZY collections, closing. Allowing to specifiy own collections wouldn't help since most often you also need to touch other parts (UnitOfWork Persisters) so its better for code-maintenance to just not allow this.





[DDC-391] Allow to specifiy custom Entity and Collection Persister classes Created: 06/Mar/10  Updated: 24/Jun/15

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

Type: New Feature Priority: Minor
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 9
Labels: None

Issue Links:
Duplicate
is duplicated by DDC-3793 Unit Of Work - Proxy injected collect... Resolved
Reference
is referenced by DDC-2637 [GH-769] Add Custom Persisters Open
is referenced by DDC-699 ProxyFactory: allow to overwrite $_pr... Resolved
is referenced by DDC-445 Evaluate possible ways in which store... Resolved

 Description   

It should be allowed to overwrite the default persisters for collections and entities. This should go along the lines of Hibernate which allows to set the custom implementations like:

XML:

<entity persister="persisterClass" />
<OneToMany persister="persisterClass" />

Annotation

/**
 * @Entity(persister="persisterClass")
 * @OneToMany(persister="persisterClass")
 */


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

Rescheduling for beta3.

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

Pushing back to beta4.

Comment by Roman S. Borschel [ 12/Jul/10 ]

Moved to 2.1 due to lack of time for any larger new features for 2.0.

Comment by Benjamin Eberlei [ 13/Oct/10 ]

implemented this in a feature branch for now, it really doesnt touch any other runtime code so maybe we can still merge this before RC1

http://github.com/doctrine/doctrine2/tree/OverridePersisters

Comment by Gediminas Morkevicius [ 25/Feb/11 ]

Is this forgotten? you should merge it since it does not affect any other parts of ORM, this is a great feature

Comment by Benjamin Eberlei [ 26/Feb/11 ]

This has not been forgotten, but the Persister is due for a heavy refactoring for 2.2 probably, when we will make it use the SQL Query object that we are working on.

So I cannot merge this, because the API will probably break big time.

Comment by Jonas Wouters [ 16/Mar/11 ]

Does that mean we will not see this feature before 2.2?

Comment by Benjamin Eberlei [ 16/Mar/11 ]

Yes, that is correct. I dont want to add it as experimental/undocumented feature because people will take it for granted and make us responsible for possible bc breaks.

I will update the target version accordingly.

Sorry for disappointing you, but this feature is fundamentally important at the core of the library. That means we have to get it right and not rush into it.

Comment by Gediminas Morkevicius [ 17/Mar/11 ]

Just as I thought that first you will want to make a query builder object for all persisters. since now they use plain sql. Thanks for all your work on this

Comment by Adam Brodziak [ 11/Jan/12 ]

I might be mistaken, but AFAICS mentioned Persister heavy refactoring did not made through to 2.2 version. Is there any plan to have it in 2.3 or at any later stage?

Comment by Guilherme Blanco [ 13/Jan/12 ]

@Adam I refactored all Persisters optimizing their code, but I could not complete the move from SQL string generation to Doctrine\DBAL\Query.
We missed it, yes. I may reschedule for 2.3

Comment by Thomas Rothe [ 05/Sep/12 ]

Why is it still missing in 2.3? I would require this for an extension that uses its own overridden entity persister and using a custom persister is the solution that you guys recomend for not overriding the entity manager.

Comment by sebastiaan stok [ 23/Sep/12 ]

Any change seeing this soon? I really need this for a security feature.

What is making this so hard? just adding an setEntityPersister($entityName, $object) should do the trick.
I don't need any fancy stuff, just a way to limit the fields in the SELECT list.

Edit: OK, I'm shot I CAN NOT overwrite the entity manager as the UnitOfWork is private!
Got any other idea?

Comment by Stefan Kögel [ 24/Sep/12 ]

Any chance you could add this quickly? I need this feature urgently to complete an extension using a custom persister. Thanks in advance.

Comment by Lennart Weijl [ 09/Jul/13 ]

What's the status on this issue?





[DDC-445] Evaluate possible ways in which stored procedures can be used Created: 19/Mar/10  Updated: 24/Jun/15  Resolved: 24/Jun/15

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

Type: Improvement Priority: Minor
Reporter: Roman S. Borschel Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 1
Labels: None

Issue Links:
Reference
relates to DDC-391 Allow to specifiy custom Entity and C... In Progress

 Description   

We should evaluate the current situation of stored procedure support as well as where we want to go with it / how far we want to support it, if at all.



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

I think this relates to the usage of Custom Persisters

Comment by Marco Pivetta [ 24/Jun/15 ]

Stored procedures are absolutely a no-go in terms of interop. Closing as won't fix.





[DDC-2763] Inheritance. CTI & STI. Improve lazy load associated entity, when target entity in association mapping is not last leaf in class hierarchy. Created: 27/Oct/13  Updated: 24/Jun/15

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

Type: Improvement Priority: Major
Reporter: Artur Eshenbrener Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 4
Labels: inheritance


 Description   

If we look inside documentation, we can see this:

There is a general performance consideration with Class Table Inheritance: If the target-entity of a many-to-one or one-to-one association is a CTI entity, it is preferable for performance reasons that it be a leaf entity in the inheritance hierarchy, (ie. have no subclasses). Otherwise Doctrine CANNOT create proxy instances of this entity and will ALWAYS load the entity eagerly.

I think it can be improved, if we will load only discriminator column value for resolve target class name, instead of loading whole entity. When we perform query from root entity, dicriminator value is already present in fetched database row.
What do you think?



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

Queries to fetch the discriminator column cannot be avoided (that's a limitation we can't workaround as far as I know).

What can be improved is avoiding instantiation of the joined results, and instead keep a proxy and a copy of the data for deferred hydration. That would allow avoiding recursive queries which are seen quite often when referencing the root of a STI/JTI

Comment by Artur Eshenbrener [ 27/Oct/13 ]

Queries to fetch the discriminator column cannot be avoided (that's a limitation we can't workaround as far as I know).

Of course, but fetching the discriminator value will produce less overhead than loading whole entity (with recursive loading joined entities). And, when you querying from root entity (with mapped sicriminator column), discriminator value already present in db result row (no need to extra query for dicriminator value).

What can be improved is avoiding instantiation of the joined results, and instead keep a proxy and a copy of the data for deferred hydration. That would allow avoiding recursive queries which are seen quite often when referencing the root of a STI/JTI

The result of my proposal will ability to get proxy class without loading whole entity.

Comment by Luca Bo [ 24/Jun/15 ]

IMHO useful proposal!





[DDC-3792] Broken link to api docs in documentation Created: 24/Jun/15  Updated: 24/Jun/15

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

Type: Documentation Priority: Trivial
Reporter: Felipe Figueroa Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: documentation
Environment:

Online documentation



 Description   

Links to API docs from doctrine documentation are broken in its latest version.

For example, in second level cache section, under cache region the link to API Doc points to http://www.doctrine-project.org/api/orm/2.5/class-Doctrine.ORM.Cache.Region.html/ which doesn't exist.

Actually, it doesn't seem to be an API doc section for version 2.5 whatsoever.






[DDC-3784] [GH-1434] convertToDatabaseValueSQL with $columnName Created: 21/Jun/15  Updated: 24/Jun/15

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 mihai-stancu:

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

Message:

Goal:

I want to be able to atomically increment a property such that $stock->setQuantityDelta(2); will render into an SQL such as UPDATE stock SET quantity = quantity+? WHERE id = ?;.

I would like to accomplish this without using DQL every time it is necessary hence I implemented a custom Doctrine2 type which can accomplish this – with support from this PR.

Changes:

\Doctrine\ORM\Persisters\BasicEntityPersister::updateTable now passes the column name to Doctrine\DBAL\Types\Type::convertToDatabaseValueSQL (PR) to be used by the concrete type instance (ex.: mihai-stancu/doctrine-types-extra:\MS\Doctrine\DBAL\Types\DeltaType).



 Comments   
Comment by Doctrine Bot [ 24/Jun/15 ]

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





[DDC-3791] Creating a sequence results in an error using Postgres: sequences' name must be quoted Created: 23/Jun/15  Updated: 23/Jun/15

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

Type: Bug Priority: Critical
Reporter: Marcos Passos Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Postgres' sequences must be quoted. The following snippet results in a error:

$schemaManager->createSequence(new Sequence('123_foo'));

Error:

SQLSTATE[42601]: Syntax error: 7 ERROR: syntax error at or near "123"
LINE 1: CREATE SEQUENCE 123_foo INCREMENT BY 1 MINVALUE 1





[DDC-3790] [GH-1438] added failing test illustrating Paginator's issue with value object ids Created: 23/Jun/15  Updated: 23/Jun/15

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 dadamssg:

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

Message:

The Paginator does not handle entities with value objects for id's. I've create a failing test illustrating this.

[The accompanying issue](http://www.doctrine-project.org/jira/browse/DDC-3789)






[DDC-3789] Paginator does not convert entity ids if they are value objects Created: 23/Jun/15  Updated: 23/Jun/15

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

Type: Bug Priority: Critical
Reporter: David Adams Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

If an entity uses a custom value object and DBAL type for its id, the value object is used as query parameters instead of the converted value.

Here is where $ids contains an array of value objects. This eventually gets set as parameter for the query here.

This leads to an exception like this:

An exception occurred while executing 'SELECT a0_.id AS ID_0, a0_.created_at AS CREATED_AT_1, a0_.updated_at AS UPDATED_AT_2, a0_.name AS NAME_3, a0_.primary_image_id AS PRIMARY_IMAGE_ID_4, a0_.category_id AS CATEGORY_ID_5, a0_.created_by_id AS CREATED_BY_ID_6 FROM assets a0_ WHERE a0_.created_by_id = ? AND a0_.category_id = ? AND a0_.id IN (?, ?, ?)' with params [\"9369f64a-a978-4c5c-b403-baef2576285f\", \"2f8d4a66-47af-4b14-9a3d-54c1debd084c\", {}, {}, {}]:\n\nWarning: oci_bind_by_name(): Invalid variable used for bind

The 3 empty parameters are how my value objects are being wrongly represented.

I've fixed a similar issue in this pull request but I don't know how to go about fixing this in the Paginator.

One solution could be to only allow value objects for id's if the value object class has a __toString() method and another line gets added after the id objects are retrieved:

Paginator.php
    /**
     * {@inheritdoc}
     */
    public function getIterator()
    {
        // existing code

        $ids = array_map('current', $subQuery->getScalarResult());
        $ids = array_map('strval', $ids);

        // existing code
    }





[DDC-451] Add GUID/UUID Id Generator Created: 20/Mar/10  Updated: 23/Jun/15  Resolved: 12/Mar/12

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

Type: New Feature Priority: Minor
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 3
Labels: None

Issue Links:
Reference
is referenced by DDC-3788 [GH-1437] [2.3] Updated docs for basi... Open

 Description   

We should add an IdGenerator that facilitates the DB Vendors UUID()/GUID() generation facilities.

Although these IdGenerators take more space compared to other Generators there are use-cases which can be only solved with this kind of Id Generator.



 Comments   
Comment by Guilherme Blanco [ 20/Mar/10 ]

Here is a basic GUID generator.

class Guid
{
    /**
     * Generate a GUID
     *
     * @return string
     */
    public static function generate()
    {
        $cpuname     = getenv('COMPUTERNAME');
        $address     = isset($_SERVER['SERVER_ADDR']) ? @$_SERVER['SERVER_ADDR'] : uniqid(hash("md5", time()), true) . time();
        $address     = (trim($cpuname) == '' ? crypt(uniqid(rand(), true)) : $cpuname) . '/' . $address;
        $milisecs        = microtime();
        $randomLong  = (rand(0, 1))? '-':'';
        $randomLong .= rand(1000, 9999).rand(1000, 9999).rand(1000, 9999).rand(100, 999).rand(100, 999);
        
        $string = $address . ':' . $milisecs . ':' . $randomLong;
        $hashString = strtoupper(md5($string));
        
        return substr($hashString, 0, 8).'-'.substr($hashString, 8, 4).'-'.substr($hashString, 12, 4).'-'.substr($hashString, 16, 4).'-'.substr($hashString, 20);
    }
    
    
    /**
     * Verifies if a string is a valid Guid generated acording to this class
     *
     * @param string $guid Guid to be analyzed
     * @return boolean
     */
    public static function match($guid)
    {
        
        $match = preg_match("/^([A-F0-9]{8}-[A-F0-9]{4}-[A-F0-9]{4}-[A-F0-9]{4}-[A-F0-9]{12})$/", $guid);
        
        return $match;
    }
}
Comment by Andy Aja deh [ 12/May/10 ]

I agree, there are some application features that can only be done with GUID.

Comment by Steffen Vogel [ 25/Jul/10 ]

Oh, thats a quite simple implementation of a UUID/GUID generator.

I would prefer something like this:
http://github.com/volkszaehler/volkszaehler.org/blob/master/backend/lib/Util/UUID.php

Its a RFC2144 compatible implementation for UUIDs

Comment by Aigars Gedroics [ 27/Jul/11 ]

Here is complete code how to do this - http://ranskills.wordpress.com/2011/05/26/how-to-add-a-custom-id-generation-strategy-to-doctrine-2-0/.

Comment by Maarten de Keizer [ 23/Nov/11 ]

A couple of months ago I created 2 pull requests for this feature (https://github.com/doctrine/doctrine2/pull/127 and https://github.com/doctrine/dbal/pull/58). It would be nice if the feature is in the next Doctrine release.

Comment by Benjamin Eberlei [ 12/Mar/12 ]

Implemented

Comment by Benjamin Eberlei [ 12/Mar/12 ]

Details: This works with Database provided GUID functionality only for now, the UUID Generator uses the AbstractPlatform#getGuidSqlExpression() function and a SELECT clause to fetch a new guid. A next step might be to add a Platform#supportsGuidGeneration() flag and otherwise fallback to a PHP based generation.

The Id generator in the ORM is pre insert, which makes this very awesome

Comment by Marijn Huizendveld [ 07/Aug/12 ]

There is a nice implementation out there with proper UUID generation and a DBAL datatype.

Comment by Benjamin Eberlei [ 07/Aug/12 ]

starting with 2.3 there are custom id generators and you can do whatever you want. There is also a UUID/GUID type in 2.3 that is using the appropriate vendor database functions to generate those values.

Comment by Menno Holtkamp [ 13/Aug/12 ]

There is also a UUID/GUID type in 2.3 that is using the appropriate vendor database functions to generate those values.

So how would one be able to use this UUID/GUID? Would it be required for the column to be tagged as a @Id and @GeneratedValue with GUID strategy? I would like to have a random string generated which does not act as @Id within Doctrine... The text quoted suggests that it should work out of the box by setting the column type to 'guid', which it does not (2.3.0-RC1).

Simply setting the column type to 'guid' does not trigger the database to generate an ID when INSERTing a row...

Comment by Marco Pivetta [ 13/Aug/12 ]

I'm not sure about PHP's case sensitivity, but as of https://github.com/doctrine/doctrine2/blob/00a5f185444fb5d7c84e445d9ea6d6a68e087f98/lib/Doctrine/ORM/Mapping/Driver/AnnotationDriver.php#L310 I think you should try with "UUID" (uppercase)

Comment by Menno Holtkamp [ 13/Aug/12 ]

Marco, it is indeed 'UUID', but this seems not to kick in when there is no @Id annotation used. I want to use it to come up with an identifier for an Order. It is not a primary key at database level or something like that. I was just wondering whether this new functionality can be used like that. I get the feeling it is not intended to be used like this:

/**
 * Unique Order identifier that acts as reference for an Order even when multiple databases are involved
 * 
 * @var string
 * @ORM\Column(name="order_identifier", type="string", unique=true)
 * @ORM\GeneratedValue(strategy="UUID")
 */
protected $_orderIdentifier;
Comment by Benjamin Eberlei [ 13/Aug/12 ]

Well it is an ID generator. So it has to be with @Id.

Comment by Menno Holtkamp [ 13/Aug/12 ]

Well, yes, that was my question and that is now answered, thanks.

It would be nice though to have UUID generation functionality available for non-database specific IDs as well. For instance for:

  • user account activation tokens
  • payment references
  • invoice reference, etc.

This is now something that has to be implemented at the applciation level. But since we have these generators available, why not re-use it. By adding a @Id annotation, it becomes part of a composite key, which is not the purpose. Maybe I'll dive into the code and see whether this is possible.

Comment by Benjamin Eberlei [ 13/Aug/12 ]

it is available, just take a look at the code.

Comment by Menno Holtkamp [ 13/Aug/12 ]

Well it is an ID generator. So it has to be with @Id.

it is available, just take a look at the code.

Mmm, now I am confused, I think we are mis-communicating.

Maybe using less text and more descriptive examples:

  • is it possible to use Database GUID functionality
    • without using the @Id annotations, to generate values for Entity properties that are not a primary key?
    • note that this Entity unique reference would exist next to a property that does have the @Id annotation

Attempt 1:

/**
 * The Order ID used at database level, which does NOT have any meaning within our domain, solely at database level
 *
 * @var integer
 * @ORM\Column(name="id", type="integer")
 * @ORM\Id
 * @ORM\GeneratedValue(strategy="IDENTITY")
 * @ORM\SequenceGenerator(sequenceName="orders_id_seq")
 */
protected $_id;

/**
 * The Order reference used at domain level, which DOES have meaning in our domain
 * Typically used to report in emails, printed on Invoices, etc
 *
 * @var string
 * @ORM\Column(name="order_identifier", type="guid")
 */
protected $_orderIdentifier;

Attempt 2:

/**
 * The Order ID used at database level, which does NOT have meaning within our domain, solely at database level
 *
 * @var integer
 * @ORM\Column(name="id", type="integer")
 * @ORM\Id
 * @ORM\GeneratedValue(strategy="IDENTITY")
 * @ORM\SequenceGenerator(sequenceName="orders_id_seq")
 */
protected $_id;

/**
 * The Order reference used at domain level, which DOES have meaning in our domain
 * Typically used to report in emails, printed on Invoices, etc
 *
 * @var string
 * @ORM\Column(name="order_identifier", type="string", unique=true)
 * @ORM\GeneratedValue(strategy="UUID")
 */
protected $_orderIdentifier;

Based on Benjamin's first answer I guess that this is not possible. Point is, the second answer indicates that it is possible . What is it?

Also note that in Attempt 2, the @GeneratedValue annotation on the second property interferes with the ID generation of the Entity defined at the first property. This is probably to realize composite keys, but can result in unexpected behavior since it replaces the way the primary key is generated?

Comment by Benjamin Eberlei [ 13/Aug/12 ]

Well @GeneratedValue Only works with @Id as I said. But there are low level APIs that you can look up in the UuidGenerator Strategy to use for something like this.





[DDC-3788] [GH-1437] [2.3] Updated docs for basic mapping Created: 23/Jun/15  Updated: 23/Jun/15

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

Type: Documentation Priority: Trivial
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: documentation, generator-strategy, identifier, orm

Issue Links:
Reference
relates to DDC-451 Add GUID/UUID Id Generator Resolved

 Description   

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

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

Message:

Added note about UUID identifier generator strategy, which was added in 2.3 version at @0a835609fabd9ef600127c4cacfbcc776d31d981.



 Comments   
Comment by Phansys [ 23/Jun/15 ]

Added GUID/UUID Id Generator.





[DDC-3787] [GH-1436] allow ManyToManyPersister to handle identification types Created: 23/Jun/15  Updated: 23/Jun/15

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 dadamssg:

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

Message:

This is my updated pull request which includes a test....but the test passes even without the fix. I'm not sure how to write a test which illustrates PDO throwing an exception without a database.

[Issue for pull request](http://www.doctrine-project.org/jira/browse/DDC-3785)






[DDC-3786] [GH-1435] allow ManyToManyPersister to handle identification types Created: 23/Jun/15  Updated: 23/Jun/15

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 dadamssg:

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

Message:



 Comments   
Comment by Doctrine Bot [ 23/Jun/15 ]

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





[DDC-3785] DBAL types are ignored in the ManyToManyPersister Created: 23/Jun/15  Updated: 23/Jun/15

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

Type: Bug Priority: Critical
Reporter: David Adams Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

If you're using custom DBAL types for id's, they are ignored and the value object is passed directly to be bound to the query.

For example, I have an Asset that has many Attributes. My asset's id is an AssetId object. I've created a custom DBAL type for AssetId. Whenever doctrine attempts to cleanse the Asset from orphaned Attributes an exception is thrown:

An exception occurred while executing 'DELETE FROM asset_attributes WHERE asset_id = ?' with params [{}]: Warning: oci_bind_by_name(): Invalid variable used for bind

The ManyToManyPersister::delete() method does not pass along any $types to the Connection::executeUpdate() method. The executeUpdate() method checks if there are types and if there are none, does not pass the params to the _bindTypedValues() method, which I think is the problem. The params(AssetId) get passed directly to the $stmt->execute($params) method call.

I believe the ManyToManyPersister::delete() method needs to look like this. This seems to work.

ManyToManyPersister.php
    /**
     * {@inheritdoc}
     */
    public function delete(PersistentCollection $collection)
    {
        $mapping = $collection->getMapping();

        if ( ! $mapping['isOwningSide']) {
            return; // ignore inverse side
        }
        $types = [];
        $class = $this->em->getClassMetadata($mapping['sourceEntity']);

        foreach ($mapping['joinTable']['joinColumns'] as $joinColumn) {
            $types[] = PersisterHelper::getTypeOfColumn($joinColumn['referencedColumnName'], $class, $this->em);
        }

        $this->conn->executeUpdate($this->getDeleteSQL($collection), $this->getDeleteSQLParameters($collection), $types);
    }





[DDC-3783] [GH-1433] Check for non-cacheable entities on metadata level, not at runtime Created: 20/Jun/15  Updated: 20/Jun/15

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 goetas:

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

Message:

This PR moves the check for non-cacheable entities from "runtime" to metadata definition.

If an entity has an association key as part of its PK, and this association key is not configured to be stored into SLC, an exception it thrown.

The previous approach was checking this constraint at "runtime" (right before saving the value), this PR moves this check at metadata level into (`_validateAndCompleteAssociationMapping` method).






[DDC-3782] onDelete="..." Change Not Recognized Created: 19/Jun/15  Updated: 19/Jun/15

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

Type: Bug Priority: Major
Reporter: Ben Meynell Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: ondelete
Environment:

Ubuntu 14.04; Symfony 2.3



 Description   

Steps to Reproduce

  • DB column is DEFAULT NULL and has a constraint of ON DELETE CASCADE.
  • DB and Entity schema are in sync.
  • Entity field definition is changed from onDelete="CASCADE" to onDelete="SET NULL".
  • doctrine:migrations:diff and doctrine:schema:validate do not recognize the change.





[DDC-3781] Fix Optimistic Locking Scenarios for Versioned Entities in Bidirectional Relationships Created: 18/Jun/15  Updated: 19/Jun/15

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

Type: Improvement Priority: Major
Reporter: Bill Schaller Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: locking, persistence, versioned

Issue Links:
Reference
is referenced by DDC-3681 [GH-1378] Feature to force-increment ... Closed

 Description   

As described in PR #1378, some scenarios involving a parent-child bidirectional relationship may incorrectly result in the parent's version not being incremented while the child's is.

An example: Versioned entity PurchaseOrder has a collection-valued association to versioned entity PurchaseOrderItem. Considering this as a business use-case, if the state of a PurchaseOrderItem changes during another transaction accessing the parent PurchaseOrder, the state of the PurchaseOrder can be considered to have changed as well. However, in the current ORM implementation, the PurchaseOrder is not considered to have changed, allowing transactions modifying it to proceed concurrently with transactions modifying its children, possibly resulting in inconsistent state.

The solution proposed in the referenced PR is unsuitable. Versioning should be transparent to userland code, and should be managed solely by the persistence layer - the EntityManager.

I think in this instance, we can look to the JPA spec as a good reference on how to handle this:

The version attribute is updated by the persistence provider runtime when the object is written to the database. All non-relationship fields and properties and all relationships owned by the entity are included in version checks (35).

(35) This includes owned relationship maintained in join tables.

JPA 2.1 spec

From what I understand of the implementation in Hibernate, version updates on the owning side of relationships propagate to the inverse side of bidirectional relationships if both sides are versioned entities.

So in the case of the example, if only a PurchaseOrderItem is changed and persisted, both the parent PurchaseOrder's version and the PurchaseOrderItem's version would be updated.

I am not certain what level of effort this would require, but I think changes would be required in UnitOfWork, BasicEntityPersister, and JoinedSubclassPersister.

As for performance effects, I think the performance impact will be minimal in most cases, as most scenarios will only add a single additional update statement. In cases where version updates propagate to multiple entities on inverse sides of relationship, each additional relation that meets the criteria will add an additional update statement.

If the persister is required to fetch the related entity before incrementing the version, it will add additional overhead to queries affecting related versioned entities. Therefore the documentation would need to discuss the potential performance impact, and recommend application of versioning and entity relationships with care.

A possible enhancement would be the addition of an @OptimisticLock(propagate=false) annotation for inverse-side properties, which would prevent propagation of version updates from related entities.



 Comments   
Comment by Doctrine Bot [ 18/Jun/15 ]

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

Comment by Darien Hager [ 19/Jun/15 ]

First, I'd like to toss another scenario on the pile: Consider an entity like, uhm, FavoritePurchaseOrders.

It refers to an owning User, references a set of PurchaseOrder items, and contains some statistics like "total price" or "earliest due-date".

This is different from the PurchaseOrder->PurchaseOrderItem relationship, because it probably uses a link-table and probably does not own/cascade-persist to PurchaseOrder items, since you generally favorite things which already exist. While it refers to a User, its version doesn't need to get updated if the owner is modified or reassigned, since it contains no user-specific information.

Secondly, should there be preFlush/postFlush events for entities whose versions are being altered, even if no other immediate values are changing? This probably relates to whether entities must be loaded in order to bump their versions.





[DDC-3681] [GH-1378] Feature to force-increment entity version Created: 09/Apr/15  Updated: 18/Jun/15  Resolved: 18/Jun/15

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

Type: New Feature Priority: Minor
Reporter: Doctrine Bot Assignee: Bill Schaller
Resolution: Won't Fix Votes: 0
Labels: persister, unitofwork, versioned

Issue Links:
Dependency
depends on DDC-3683 [GH-1380] Fix issue with second-level... Open
Duplicate
is duplicated by DDC-3640 Force version increment via mapped pr... Resolved
Reference
relates to DDC-3781 Fix Optimistic Locking Scenarios for ... Awaiting Feedback

 Description   

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

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

Message:

Submitting for feedback and experimentation.

The major use-case for this involves using certain entities as the versioned-gatekeepers for changes that don't directly live on the same entity. For example, using the version of a `PurchaseOrder` to control changes to any of its child `PurchaseOrderLineItem` objects.



 Comments   
Comment by Doctrine Bot [ 18/May/15 ]

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

Comment by Doctrine Bot [ 18/May/15 ]

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

Comment by Bill Schaller [ 18/Jun/15 ]

This PR is not a suitable solution for the problem and is being closed. Please see DDC-3781 for a discussion of the issue and proposed solution.

Comment by Doctrine Bot [ 18/Jun/15 ]

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





[DDC-3778] [GH-1430] "INSTANCE OF" example doesn't match description. Created: 18/Jun/15  Updated: 18/Jun/15  Resolved: 18/Jun/15

Status: Closed
Project: Doctrine 2 - ORM
Component/s: Documentation
Affects Version/s: 2.5
Fix Version/s: 2.5.1, 2.6.0
Security Level: All

Type: Bug Priority: Minor
Reporter: Doctrine Bot Assignee: Bill Schaller
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of michael-lavaveshkul:

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

Message:

Just did a small change. The DQL is supposed to
> [Query] for the staffs without getting any technicians

As it's currently written, it would select all ``Staff`` and the ``INSTANCE OF`` check would only test if they're ``Staff``.



 Comments   
Comment by Doctrine Bot [ 18/Jun/15 ]

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

Comment by Doctrine Bot [ 18/Jun/15 ]

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

Comment by Bill Schaller [ 18/Jun/15 ]

Backported to 2.5





[DDC-3779] [GH-1432] Change named native query message Created: 18/Jun/15  Updated: 18/Jun/15

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 coladict:

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

Message:

Since the feature is not implemented, it should throw that message, instead of the other one.
Once reading the queries into the `_attributes['namedNativeQueries']` array has been implemented, the message should be removed.



 Comments   
Comment by Doctrine Bot [ 18/Jun/15 ]

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





[DDC-3780] YmlDriver causing deprecated calls in Symfony 2.7 Created: 18/Jun/15  Updated: 18/Jun/15  Resolved: 18/Jun/15

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

Type: Improvement Priority: Minor
Reporter: Ziad Jammal Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

The 'YamlDriver' in 'Doctrine\ORM\Mapping\Driver' still uses Yaml:parse($file), which is causing deprecated logs in Symfony 2.7 branch.



 Comments   
Comment by Marco Pivetta [ 18/Jun/15 ]

This is already fixed in ORM 2.5.x





[DDC-3777] BigInt Ids from SequenceGenerator cast to int Created: 16/Jun/15  Updated: 16/Jun/15

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

Type: Bug Priority: Major
Reporter: Jeffrey Zullo Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: identifier, orm, sequence-generator


 Description   

Introduced by commit 5aeabcb445acf DDC-1490.

I have an entity with the following annotation:

/**
 * @Id
 * @Column(type="bigint", precision = 15, name="id")
 * @GeneratedValue(strategy="SEQUENCE")
 * @SequenceGenerator(sequenceName="my_sequence_name")
 */

If the "my_sequence_name" sequence is at a value greater than the php int max for 32-bit php (2147483647), the id generated by the SequenceGenerator is capped at 2147483647.

For example, "my_sequence_name" is currently at 4744708191. Attempting to save a new entity using this sequence generates 2147483647 as the id every time, even though the sequence value keeps increasing as expected.

This is caused by cast to int introduced to SequenceGenerator in commit 5aeabcb445acf.



 Comments   
Comment by Jeffrey Zullo [ 16/Jun/15 ]

Note: This is an issue for 32 bit php. I'm sure it would be an issue for 64 bit php as well, but my sequence hasn't overflowed that upper bound yet.





[DDC-3330] Bad Pagination - rows with sorted collection Created: 29/Sep/14  Updated: 16/Jun/15  Resolved: 16/Jun/15

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

Type: Bug Priority: Minor
Reporter: Thomas Lallement Assignee: Bill Schaller
Resolution: Fixed Votes: 0
Labels: paginator, tests
Environment:

Ubuntu 12.04, PHP 5.5.3


Attachments: File DDC3330Test.php    

 Description   

I use the Doctrine Paginator to be able to have a correct pagination with collection.
I followed the documentation here:
http://doctrine-orm.readthedocs.org/en/latest/tutorials/pagination.html

It works well in most cases but there is a problem when ordering on a property of the entity + on an other property of the collection.

See the failing unit test I joined to this ticket.



 Comments   
Comment by Bill Schaller [ 16/Jun/15 ]

Closed PR via manual merge





[DDC-3733] [GH-1406] add default value for GeneratedValue Created: 12/May/15  Updated: 16/Jun/15  Resolved: 16/Jun/15

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: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

The "strategy" attribute on the GeneratedValue annotation is actually not required but optional. It works fine when the attribute is not specified.

The default value for this attribute is AUTO.



 Comments   
Comment by Doctrine Bot [ 16/Jun/15 ]

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





[DDC-3738] [GH-1409] Added PHPDoc return type false of next method in Hydration/IterableResult Created: 15/May/15  Updated: 16/Jun/15  Resolved: 16/Jun/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.6.0
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 haeber:

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

Message:

Because hydrateRow can return false, too. The PHPDoc return type of the next method has return false in addition to array.



 Comments   
Comment by Doctrine Bot [ 16/Jun/15 ]

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





[DDC-3741] [GH-1411] Allow null to be passed to setHydrationCacheProfile Created: 20/May/15  Updated: 16/Jun/15  Resolved: 16/Jun/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.6.0
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 icambridge:

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

Message:

Currently null can be passed and is set as default, however if you do this you get an exception. This allows null to be passed and set.

There is an if statement later on to see if $this->_hydrationCacheProfile is null so it seems logical you can set it to be null.



 Comments   
Comment by Doctrine Bot [ 16/Jun/15 ]

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





[DDC-3744] [GH-1412] Added RANDOM() function to DQL Created: 22/May/15  Updated: 16/Jun/15

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

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


 Description   

This issue is created automatically through a Github pull request on behalf of cverges-ch:

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

Message:

Corresponds with generic platform support for a random number generator mechanism typically implemented by most DBMS.

See pull request at https://github.com/doctrine/dbal/pull/865

Use of RAND(), random(), DBMS_RANDOM.VALUE, or whatever the platform provides as a random number generator can be essential to some business logic. This adds generic platform support for this mechanism and introduces a new DQL keyword "RANDOM()".

DBAL: https://github.com/doctrine/dbal/pull/865
DQL: https://github.com/doctrine/doctrine2/pull/1412



 Comments   
Comment by Doctrine Bot [ 16/Jun/15 ]

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





[DDC-3748] [GH-1413] Added to_char function to convert other types to chars (/strings). Created: 27/May/15  Updated: 16/Jun/15  Resolved: 16/Jun/15

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

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


 Description   

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

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

Message:

Been missing the TO_CHAR function, which - under some circumstances - is needed in platforms like Oracle, e. g. to compare char and non-char fields. Have added it - hope, it is OK this way!






[DDC-3756] [GH-1416] [2.5][Bug] Fix ConvertDoctrine1Schema->getMetadata Created: 05/Jun/15  Updated: 16/Jun/15  Resolved: 16/Jun/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.5.1, 2.6.0
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 Restless-ET:

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

Message:

This bug was introduced at #1205 while resolving #1200.



 Comments   
Comment by Doctrine Bot [ 16/Jun/15 ]

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





[DDC-3760] [GH-1418] Remove (useless?) call to parser::getLexer() Created: 08/Jun/15  Updated: 16/Jun/15  Resolved: 16/Jun/15

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: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

The `$lexer` variable is not used, the method `parser::getLexer()` is just a dumb getter and do nothing, so in my opinion, the call to `parser::getLexer()` is useless in this context.

Can you confirm?



 Comments   
Comment by Doctrine Bot [ 16/Jun/15 ]

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





[DDC-3382] [GH-1419] With orphanRemoval, cannot delete and re-add entity Created: 10/Nov/14  Updated: 16/Jun/15  Resolved: 10/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: Christian Schmidt Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None

Issue Links:
Duplicate
is duplicated by DDC-3765 [GH-1419] [DDC-3382] Allow orphan rem... Open

 Description   

I have a one-to-many relation with orphanRemoval=true.

If I remove an entity from the related collection and add it back, the entity is removed from the database.

$employee = $company->getEmployees()->first();
$company->getEmployees()->removeElement($employee);
$company->getEmployees()->add($employee);

$em->persist($company);
$em->flush();
// Now $employee is deleted from the database.

The expected behaviour is to leave the entity in the database, because it was present in the PersistentCollection when $em->persist() was called.



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

This is expected behavior, and won't be changed for now.

Comment by Dmitriy Shashkin [ 10/Feb/15 ]

Is there any specific reason for this decision? Spent some time debugging because of this and I must say that such oddities are rather frustrating.

Comment by Marco Pivetta [ 10/Feb/15 ]

Dmitriy Shashkin we currently don't have an operation opposite to orphanRemoval

Comment by Christian Schmidt [ 11/Jun/15 ]

I have made a PR with the suggested change. It is a very small fix, so I hope you will reconsider this suggestion in the light of this.

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

Comment by Doctrine Bot [ 16/Jun/15 ]

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





[DDC-3765] [GH-1419] [DDC-3382] Allow orphan removal to be cancelled Created: 11/Jun/15  Updated: 16/Jun/15

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:
Duplicate
duplicates DDC-3382 [GH-1419] With orphanRemoval, cannot ... Resolved

 Description   

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

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

Message:

I have a one-to-many relation with orphanRemoval=true.
If I remove an entity from the related collection and add it back, the entity is removed from the database.

```PHP
$employee = $company->getEmployees()->first();
$company->getEmployees()->removeElement($employee);
$company->getEmployees()->add($employee);

$em->persist($company);
$em->flush();
// Now $employee is deleted from the database.
```

The expected behaviour is to leave the entity in the database, because it was present in the PersistentCollection when $em->persist() was called.

This has previously been suggested in DDC-3382(http://www.doctrine-project.org/jira/browse/DDC-3382), but it was rejected. This PR shows how small a change it is, so I hope the suggestion will be reconsidered in the light of this.



 Comments   
Comment by Doctrine Bot [ 16/Jun/15 ]

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





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

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:

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 16/Jun/15 ]

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





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

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 16/Jun/15 ]

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





[DDC-3690] PersistentCollection uses private property Created: 14/Apr/15  Updated: 16/Jun/15  Resolved: 16/Jun/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Lazy Loading, ORM
Affects Version/s: 2.5
Fix Version/s: 2.5.1
Security Level: All

Type: Bug Priority: Blocker
Reporter: Roel Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: collection, persistent-collection, release


 Description   

1. PersistentCollection in Doctrine 2.5 makes uses of the $initialized property defined in the AbstractLazyCollection of doctrine\collection (https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/PersistentCollection.php#L113)
2. Doctrine 2.5 depends on version ~1.2 of doctrine\collection that marks the $initialized property as private https://github.com/doctrine/collections/blob/v1.2/lib/Doctrine/Common/Collections/AbstractLazyCollection.php
3. Hence writing to the initialized variable fails. And thus code related to initialization fails.

A fix is already applied to doctrine\orm https://github.com/doctrine/collections/commit/e2eef4629349fd847c8e080b8f729ab33e81e10f but is not tagged. Possible fix would be to release a new version of doctrine\collection as 1.2.1.



 Comments   
Comment by Roel [ 14/Apr/15 ]

Due to this several tests fail in our code-base.

Comment by Marco Pivetta [ 14/Apr/15 ]

This is a bug caused by the fact that ORM 2.5 should depend on Collections 1.3.0 - I'll look into it ASAP.

Comment by Marco Pivetta [ 15/Apr/15 ]

Collections 1.3.0 was released, but I'll keep this open until ORM 2.5.1 is out.

Comment by Benjamin Eberlei [ 16/Jun/15 ]

I pushed v1.2.1 with changing $initialized to protected already.





[DDC-3775] Partial hydration of an object removes ability to correctly retrieve any other object of the same type Created: 16/Jun/15  Updated: 16/Jun/15

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

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


 Description   

Partial hydration of an object removes ability to correctly retrieve any other object of the same type

PR: https://github.com/doctrine/doctrine2/pull/1428






[DDC-3776] [GH-1428] Add test to reproduce [DDC-3775] Created: 16/Jun/15  Updated: 16/Jun/15

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 NinoFloris:

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

Message:

Partial hydration of an object removes ability to correctly retrieve any other object of the same type






[DDC-3774] [GH-1427] Method chaining make it easy to use em Created: 15/Jun/15  Updated: 16/Jun/15  Resolved: 16/Jun/15

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Incomplete Votes: 0
Labels: entitymanager, fluent


 Description   

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

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

Message:

Method chaining make it easy to use em



 Comments   
Comment by Doctrine Bot [ 16/Jun/15 ]

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





[DDC-3773] [GH-1426] Method chaining make it easy to use Created: 15/Jun/15  Updated: 16/Jun/15  Resolved: 16/Jun/15

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

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


 Description   

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

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

Message:






[DDC-3772] ORM\PreFlush() not Persisted in Database but return right value in my form Created: 15/Jun/15  Updated: 15/Jun/15

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


 Description   

I have a problem with a Preflush() method.

When I valid my form, my form return to me the values that expected but they are not persisted into the database in the case where I create a new Entity.

to a better understand for you, all files that I'm using are in this Gist :
https://gist.github.com/zagloo/1eaedffc2f479686d98f

I have 2 Entities :

  • «First» with fields named «field1» and «field2»
  • «Other» with fields named «field3» and «field4»

These 2 Entities have these relation between them :

  • «First» have OneToMany with «Other»
  • «Other» have ManyToOne with «First»

Then I my controller TestController, I create a form with «FirstType» and «OtherType» and render it in test_preflush,html,twig

Feature of my form : I'm using a custom textarea named «textarea_test» thanks to a TestType which using a Transformer TestTranformer.

This Transformer allows to transform a PersistCollection in a String and conversely with the reverseTransform.

In the Transformer TestTranformer, public function transform($value) method concatenate each field3 from Other Entity in <div> tag.

Vsual example :

Database for «First» Entity

Database for «Other» Entity

The render in twig of the form with the transformer :

Until here, no problem, I have what I expected, a textarea with a concatenation of field3 !

Then, if I modify a value, no problem, the PreFluch() contained at the end of «First» Entity works.
-> value of field3 for the first entity Other is changed by "toto" in database and returned right in my twig form !

/**
*@ORM\PreFlush()
*/

public function testPreFlush()
{
    $this->Others->first()->setField3('toto');
}

Database for «Other» Entity

The render in twig of the form with the transformer :

Now, here is my PROBLEM !
I delete all in my textarea and add a new <div> with an ID and a new value like <div id="88">NEW VALUE</div>

Normally, my Reversetransformer create a new Other() and set value into it. (see TestTransformer Gist from the line 55).

But when I valid the form, in return, in my twig I get a good text area with <div id="17">toto</div> BUT in the Database the Preflush has not been persisted !

My twig (Good return)

My Database Other Entity

TO RESUME,

if I just modify values in text area, no problem
=> toto is persisted in database and return in my form twig.

But if I add a new field3, toto is returned into my twig (good!) but not persisted into the database (not good....!!)...

Where is the problem please ? (and sorry for my english)

For Information , here are the different versions that I'm using thanks to the command composer show -i in the console of my IDE :

For Symfony :
symfony/symfony v2.7.0 The Symfony PHP framework

For Doctrine :
doctrine/annotations v1.2.4 Docblock Annotations Parser
doctrine/cache v1.4.1 Caching library offering an object-oriented API for many cache backends
doctrine/collections v1.3.0 Collections Abstraction library
doctrine/common v2.5.0 Common Library for Doctrine projects
doctrine/data-fixtures v1.1.1 Data Fixtures for all Doctrine Object Managers
doctrine/dbal v2.4.4 Database Abstraction Layer
doctrine/doctrine-bundle v1.5.0 Symfony DoctrineBundle
doctrine/doctrine-cache-bundle v1.0.1 Symfony2 Bundle for Doctrine Cache
doctrine/doctrine-fixtures-bundle dev-master c5ff054 Symfony DoctrineFixturesBundle
doctrine/inflector v1.0.1 Common String Manipulations with regard to casing and singular/plural rules.
doctrine/lexer v1.0.1 Base library for a lexer that can be used in Top-Down, Recursive Descent Parsers.
doctrine/orm v2.4.7 Object-Relational-Mapper for PHP






[DDC-3761] Entity Cache Key save bug Created: 08/Jun/15  Updated: 14/Jun/15

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

Type: Bug Priority: Major
Reporter: Mark Assignee: Fabio B. Silva
Resolution: Unresolved Votes: 0
Labels: None


 Description   

When using memcached for caching query or entities, queries will be performed each time, since EntityCacheKey use space in its key. I can submit PR if needed. Let me know if it is needed to be fixed in other places, however i looked through the code and have not found any other places



 Comments   
Comment by Mark [ 10/Jun/15 ]

any news on this one? Should i submit PR or is there any internals issues?

Comment by Fabio B. Silva [ 10/Jun/15 ]

That seems to be the issue,
Please fell free to send a PR

Comment by Mark [ 14/Jun/15 ]

fixed it with simple replacing spaces to dots, in this PR https://github.com/doctrine/doctrine2/pull/1423. We already use this in production with Second Level Cache, however we replaced whole key with md5() for simplicity. Also it may not be question for you but why there is no checks for key length for cache? Since default policy for SCL is to rely on namespaces when generate keys it can easily go out of 250 bytes for memcached, since it invoke a lot of prefixing and so on.

Comment by Mark [ 14/Jun/15 ]

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





[DDC-3771] [GH-1424] [DDC-3761] Fixed cache key Created: 14/Jun/15  Updated: 14/Jun/15

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 Ragazzo:

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

Message:

Related with this [one](https://github.com/doctrine/doctrine2/pull/1423)






[DDC-3770] [GH-1423] Second Level Cache key Created: 14/Jun/15  Updated: 14/Jun/15

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 Ragazzo:

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

Message:

Various cache engines may not support spaces in key, like memcached, this will result in cache miss since cache component will return false on persisting data to cache






[DDC-3769] Doctine column name truncation can cause syntax errors in Oracle Created: 12/Jun/15  Updated: 12/Jun/15

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

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


 Description   

Reproduction
Given the following entity:

namespace Test\Entity;
/**
 * @Entity
 * @Table(name="test_doctrine_defect")
 */
  class TestObject
  {
      /**
       * @Id
       * @Column(type=int, length=15, name="my_column_name_is_toooooo_long")
        */
        protected $id;

        public function __construct($val)
        {
            $this->id = $val;
        }
  }

and a table defined as

CREATE TABLE test_doctrine_defect (id NUMBER(15) PRIMARY KEY);

and populated with a single record of id = 1

Run the following:

$entityManager->getRepository('Test\Entity\TestObject')->find(1);

Expected Results
We find the record with ID = 1 and return the corresponding entity

Actual Results
We die with an exception:

[error] AppException 2015-06-12T15:39:08.80813Z 15c28eec.1d7.2e136
	type:Doctrine\DBAL\DBALException
	file:/vendor/doctrine/dbal/lib/Doctrine/DBAL/DBALException.php
	line:119
	message:An exception occurred while executing 'SELECT t0.my_column_name_is_toooooo_long AS _COLUMN_NAME_IS_TOOOOOO_LONG_1 FROM test_doctrine_defect t0 WHERE t0.my_column_name_is_toooooo_long = ?' with params ["1"]:

ORA-00911: invalid character

	trace: vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php:836 in Doctrine\DBAL\DBALException::driverExceptionDuringQuery(Object[XLS\DBAL\XLSOCI8\Driver], Object[Doctrine\DBAL\Driver\OCI8\OCI8Exception], 'SELECT t0.my_column_name_is_toooooo_long AS _COLUMN_NAME_IS_TOOOOOO_LONG_1 FROM test_doctrine_defect t0 WHERE t0.my_column_name_is_toooooo_long = ?', Array[1])
		vendor/doctrine/orm/lib/Doctrine/ORM/Persisters/Entity/BasicEntityPersister.php:712 in Doctrine\DBAL\Connection->executeQuery('SELECT t0.my_column_name_is_toooooo_long AS _COLUMN_NAME_IS_TOOOOOO_LONG_1 FROM test_doctrine_defect t0 WHERE t0.my_column_name_is_toooooo_long = ?', Array[1], Array[1])
		vendor/doctrine/orm/lib/Doctrine/ORM/Persisters/Entity/BasicEntityPersister.php:730 in Doctrine\ORM\Persisters\Entity\BasicEntityPersister->load(Array[1], '')
		vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php:462 in Doctrine\ORM\Persisters\Entity\BasicEntityPersister->loadById(Array[1])
		vendor/doctrine/orm/lib/Doctrine/ORM/Decorator/EntityManagerDecorator.php:180 in Doctrine\ORM\EntityManager->find('Test\Entity\TestObject', '1', '', '')
		vendor/doctrine/orm/lib/Doctrine/ORM/EntityRepository.php:154 in Doctrine\ORM\Decorator\EntityManagerDecorator->find('Test\Entity\TestObject', '1', '', '')
		myfile.php:527 in Doctrine\ORM\EntityRepository->find('1')

This is caused by the first character in the column name becoming _ after truncation.

Oracle has a maximum column length of 30 characters, so Doctrine truncates the column after applying the _N suffix to guarantee unique column aliases. However, this causes a problem with the _N suffix is the same length as the number of characters before the first underscore in said column for Oracle.






[DDC-3768] [GH-1421] bugfix: when the database is purged, is not addign schema Created: 12/Jun/15  Updated: 12/Jun/15

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 rafreis:

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

Message:






[DDC-3766] [GH-1420] bugfix: when the database is purged, is not addign schema Created: 12/Jun/15  Updated: 12/Jun/15  Resolved: 12/Jun/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Incomplete Votes: 0
Labels: fixtures, quoting, schema, sql


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 12/Jun/15 ]

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

Comment by Doctrine Bot [ 12/Jun/15 ]

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





[DDC-3764] MappingException thrown on table not in filter Created: 11/Jun/15  Updated: 12/Jun/15

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

Type: Bug Priority: Minor
Reporter: Jordan Gigov Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: import, mapping, postgresql


 Description   

I'm using the command line to import the database schema from en existing project in another language, however this happens every time

jordan@jordan:~/workspace/testimport$ app/console -v doctrine:mapping:import OldBundle --filter=Users

  [Doctrine\ORM\Mapping\MappingException]
  It is not possible to map entity 'QrtzTriggers' with a composite primary key as part of the primary key of another entity 'QrtzCronTriggers#schedName'.
  

As maybe you can see I've specified a filter to only give me one table, but it throws an exception on a completely unrelated one. There are absolutely no database relations between the Qrtz tables and everything else. The only workaround is to drop the tables, just so I can do the import, but that means I'll have to restore the database later. Those tables are for a distinct module within our system, which can't be ported, even if we decide to migrate.

Whatever analyser you're calling in there should really respect the filters. Not only is it doing extra work, but it's also causing this crash.



 Comments   
Comment by Marco Pivetta [ 11/Jun/15 ]

Loading invalid mappings, regardless of how they are filtered afterwards, is still invalid.

Comment by Jordan Gigov [ 12/Jun/15 ]

Invalid? Tell that to the people at Postgre and Quartz. I'm sure they'll agree you can't possibly have an entity with a composite primary key be referenced by others.

Anyway I'm not asking for composite key references to be implemented (I could try doing it once I get familiar with the system), I'm asking that the filter be respected.

Comment by Marco Pivetta [ 12/Jun/15 ]

Invalid? Tell that to the people at Postgre and Quartz.

Well, the ORM, like any other tool, has its limits.

The filtering happens post-load, so your suggestion would require a massive rewrite of the entire functionality.

You could also simply dump the relevant schema and drop the tables from the dump, as you suggested above.





[DDC-3767] orm-alternative connection to use different database is working fine but then I have to use orm-default as a driver and not orm-alternative as driver while it should have been the other way. Created: 12/Jun/15  Updated: 12/Jun/15

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

Type: Bug Priority: Major
Reporter: Ovi Mughal Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: mapping
Environment:

Windows 7, Doctrine-ORM-Module 0.9, ZF2 2.5



 Description   

I needed to create module level database connection, I did override to orm-default and created orm-alternative connection but when using driver for it as orm-alternative, object manager instance is not created but when I use orm-default as driver everything works fine. But why?

Here is what is my config:
NOTE: if change orm_oz_default to orm-default on line #25, everything works fine.

return array(
1. 'doctrine' => array(
2. 'connection' => array(
3. 'orm_oz_default' => array(
4. 'driverClass' => 'Doctrine\DBAL\Driver\PDOMySql\Driver',
5. 'params' => array(
6. 'host' => 'localhost',
7. 'port' => '3306',
8. 'user' => 'root',
9. 'password' => '',
10. 'dbname' => 'zfdocttwo',
11. )
12. )
13. ),
14. 'entitymanager' => array(
15. 'orm_oz_default' => array(
16. 'connection' => 'orm_oz_default',
17. )
18. ),
19. 'driver' => array(
20. 'moduletwo_Entity' => array(
21. 'class' => 'Doctrine\ORM\Mapping\Driver\AnnotationDriver',
22. 'cache' => 'array',
23. 'paths' => array(_DIR_.'/../src/Moduletwo/Entity')
24. ),
25. 'orm_oz_default' => array(
26. 'drivers' => array(
27. 'Moduletwo\Entity' => 'moduletwo_Entity'
28. )
28. )
30. )
31. ),
32.);






[DDC-3763] Passing "false" boolean value to eq() function in query builder does not end up SQL query Created: 09/Jun/15  Updated: 09/Jun/15  Resolved: 09/Jun/15

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

Type: Bug Priority: Trivial
Reporter: Danijel Assignee: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: querybuilder

Issue Links:
Duplicate
duplicates DDC-3762 Passing "false" boolean value to eq()... Resolved

 Description   

$qb->andWhere($qb->expr()->eq('d.active', true));

produces:

[_dql:Doctrine\ORM\Query:private] => SELECT COUNT(r.id) FROM Game:Roll r INNER JOIN r.hand d WHERE d.userId = :userId AND d.active = 1

$qb->andWhere($qb->expr()->eq('d.active', false));

produces:

[_dql:Doctrine\ORM\Query:private] => SELECT COUNT(r.id) FROM Game:Roll r INNER JOIN r.hand d WHERE d.userId = :userId AND d.active =

and this query fails with an error:

[Syntax Error] line 0, col -1: Error: Expected Literal, got end of string.

As a workaround I am using 1 and 0 instead of "true" and "false"






[DDC-3762] Passing "false" boolean value to eq() function in query builder does not end up SQL query Created: 09/Jun/15  Updated: 09/Jun/15  Resolved: 09/Jun/15

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

Type: Bug Priority: Trivial
Reporter: Danijel Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: querybuilder

Issue Links:
Duplicate
is duplicated by DDC-3763 Passing "false" boolean value to eq()... Resolved

 Description   
$qb->andWhere($qb->expr()->eq('d.active', true));

produces:

   [_dql:Doctrine\ORM\Query:private] => SELECT COUNT(r.id) FROM Game:Roll r INNER JOIN r.hand d WHERE d.userId = :userId AND d.active = 1
$qb->andWhere($qb->expr()->eq('d.active', false));

produces:

   [_dql:Doctrine\ORM\Query:private] => SELECT COUNT(r.id) FROM Game:Roll r INNER JOIN r.hand d WHERE d.userId = :userId AND d.active = 

and this query fails with an error:

[Syntax Error] line 0, col -1: Error: Expected Literal, got end of string.

As a workaround I am using 1 and 0 instead of "true" and "false"



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

You are not using parameter binding. Expressions use string concatenation internally, so this outcome is actually expected. Instead, you should do following:

$qb->andWhere($qb->expr()->eq('a.field', ':key'));
$qb->setParameter('key', false);




[DDC-3758] Transactional parallelism Created: 07/Jun/15  Updated: 07/Jun/15

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

Type: Improvement Priority: Major
Reporter: Facundo Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: transactions
Environment:

Software platform



 Description   

Assuming that I am in an application that supports concurrency, as most Web applications, this is the problem:

The transactions do not currently have an execution context.
To work with a transaction I must do the following:

$em-> getConnection () -> beginTransaction (); // Auto-commit suspend
try {
    // ... Do some work
    $ user = new User;
    $ user-> setName ('George');
    $ em-> persist ($ user);
    $ em-> flush ();
    $ em-> getConnection () -> commit ();
} catch (Exception $ e) {
    $em-> getConnection () -> rollback ();
    throw $e;
}

But what if another (parallel) request executes "flush" before it?

I think that the problem is because the transaction lives in the context of the EntityManager. Because of that any need to "flush" apply to that object.

The best thing would be to do something like:

$transaction = $em-> getConnection () -> CreateTransaction (); // Auto-commit suspend
try {
    // ... Do some work
    $user = new User;
    $user-> setName ('George');
    $transaction-> persist ($ user);
    $transaction-> flush ();
    $transaction-> commit ();
} catch (Exception $ e) {
    $transaction-> rollback ();
    throw $ e;
}


 Comments   
Comment by Marco Pivetta [ 07/Jun/15 ]

Facundo I don't understand the question. Are you aware that EntityManager#flush() implicitly starts a new transaction?

Comment by Facundo [ 07/Jun/15 ]

Marco, all the changes I do in the EntityManager until call flush or commit, are collected by the EntityManager. This is dangerous in a web application, where the requests can imply a race condition.

The changes are not collected in any transaction abstracrion and the state of the EntityManager is what realy modify.

Comment by Marco Pivetta [ 07/Jun/15 ]

There's your confusion

In Doctrine, the EntityManager IS the abstraction of a transaction.

This may be changed in future, when we'll maybe have different sessions/transactions spawned from the EntityManager, but right now the EntityManager is your transaction.

Comment by Facundo [ 07/Jun/15 ]

Oh, thanks for the answer.

Last think... I'm using Symfony, do you know if the getManager method return allways the same object? Because in that case I don't know how to resolver that problem.

Comment by Marco Pivetta [ 07/Jun/15 ]

Yes, in symfony, getManager will give you the same instance over multiple calls.

A good way to solve the problem is to force a transaction around your controller dispatch logic - that creates a "safe bubble" where you can operate quite safely.

Comment by Facundo [ 07/Jun/15 ]

That's the race condition I'm talking about.
If I have 2 actions and both call beginTransaction, in a race condition can be interpreted as nested transactions instead of paralell transactions.

Comment by Marco Pivetta [ 07/Jun/15 ]

If I have 2 actions and both call beginTransaction, in a race condition can be interpreted as nested transactions instead of paralell transactions.

They happen on different processes anyway, so the nesting level is not relevant.





[DDC-3759] QueryBuilder crash with a negative value on a WHERE IN expression Created: 07/Jun/15  Updated: 07/Jun/15

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

Type: Bug Priority: Major
Reporter: Sullivan SENECHAL Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: dql, mysql


 Description   

Here the following piece of code to reproduce.

$qb = $this->getDoctrine()->getRepository('AppBundle:Server')->createQueryBuilder('s');
$qb->where($qb->expr()->in('s.status', [-1]));
$servers = $qb->getQuery()->execute();

Throw the following error:

QueryException: [Syntax Error] line 0, col 149: Error: Expected Literal, got '-'

But the DQL seems to be OK (tested manually on PMA):

SELECT s FROM AppBundle\Entity\Server s WHERE s.status IN(-1)

You can get this error also by calling `getSQL`:

$qb->getQuery()->getSQL();

Possibly affect 2.3 and 2.4 versions also, found this error a while ago but was thinking about an another vendor issue: https://github.com/sonata-project/SonataAdminBundle/issues/1061 (Dec 11, 2012)



 Comments   
Comment by Marco Pivetta [ 07/Jun/15 ]

This usage is incorrect. You are doing:

$qb->where($qb->expr()->in('s.status', [-1]));

Assuming that this means that some parameter binding is going on. Instead, an array to string cast is what you get.

The correct usage is:

$qb->where($qb->expr()->in('s.status', ':status'));
$qb->setParameter('status', [-1], Connection::PARAM_INT_ARRAY);
Comment by Sullivan SENECHAL [ 07/Jun/15 ]

Thanks for your quick answer.

So I'm not authorized to pass value directly?

So, can you explain me why this:

$qb->where($qb->expr()->in('s.status', [1]));

Works perfectly?

Your second solution works for negative value. Just a reminder for other: Don't forget this use statement:

use Doctrine\DBAL\Connection;
Comment by Sullivan SENECHAL [ 07/Jun/15 ]

BTW, `Connection::PARAM_INT_ARRAY` is not required to get it working.

Comment by Marco Pivetta [ 07/Jun/15 ]

So I'm not authorized to pass value directly?

No, it's not designed to work like that. The second parameter is supposed to be a string or an expression, not a value.

This works by luck:

$qb->where($qb->expr()->in('s.status', [1]));

The parser simply doesn't understand negative numbers in this context, but it shouldn't either: parameter binding is the way to go here.

Comment by Marco Pivetta [ 07/Jun/15 ]

Actually, I'm going to reopen the issue: negative values should be allowed by the parser, but parameter binding is still supposed to be the correct way of handling this kind of situation.

Comment by Marco Pivetta [ 07/Jun/15 ]

BTW, `Connection::PARAM_INT_ARRAY` is not required to get it working.

Please do use it, or you will have nasty cast bugs at PDO level.





[DDC-3757] [GH-1417] Generator: Associations annotations improvement Created: 06/Jun/15  Updated: 06/Jun/15

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

Type: Improvement Priority: Minor
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: annotation, orm


 Description   

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

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

Message:

  • [ ] Replace `Doctrine\Common\Collections\Collection` by `RelatedEntity[]|\Doctrine\Common\Collections\ArrayCollection`
  • [ ] Add `use` statement for related entities and ArrayCollection
  • [ ] Remove FQN annotation usage

This is a proposal for association mapping annotations improvement.

In a nutshell, I replaced `Collection` by `ArrayCollection` on getter annotation because `ArrayCollection` is used on constructor. I also add `RelatedEntity[]` annotation which is more IDE friendly.

I'm planning to add `use` statement too for FQN usage avoiding.

If you this made some regressions, we could maybe introduce it as an option.

Regards






[DDC-3751] [GH-1415] [DDC-3750] EntityGenerator::hasMethod returns true for abstract methods Created: 29/May/15  Updated: 06/Jun/15

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

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


 Description   

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

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

Message:

Fixed. May be hasProperties must return false for abstract too?



 Comments   
Comment by Lev Shagalov [ 06/Jun/15 ]

what is AWAITING FEEDBACK ?





[DDC-3750] EntityGenerator::hasMethod returns true, if target class extends abstract with abstract target method Created: 29/May/15  Updated: 06/Jun/15

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

Type: Bug Priority: Major
Reporter: Lev Shagalov Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: None


 Description   

abstract class AbstractClass

{ abstract public function getId(); }

I what to generate myEntity class that extends abstractClass (or implement interface with getId). myEntity have id and other properties and I what to generate setters/getters. EntityGenerator will skip generation getId method, because hasMethod will return true for abstract method.



 Comments   
Comment by Lev Shagalov [ 06/Jun/15 ]

what is AWAITING FEEDBACK ?





[DDC-2089] Modify OneToMany to allow unidirectional associations without the need of a JoinTable Created: 19/Oct/12  Updated: 05/Jun/15

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

Type: Improvement Priority: Major
Reporter: Enea Bette Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 2
Labels: onetomany, persister, unidirectional
Environment:

Debian Wheezy, Mysql 5.1, Apache2, PHP 5.4



 Description   

As I sayd in the title, it would be nice if the ORM layer could permit to map a 1:n association in the db as an unidirectional OneToMany in the classes, without using a JoinTable in the database.
This would permit us to get rid of the unnecessary database JoinTable, which creates disorder and decreases performance for no valuable reason.

Is it possible?



 Comments   
Comment by Enea Bette [ 16/Dec/12 ]

A little up... for inspiration from JPA

http://en.wikibooks.org/wiki/Java_Persistence/OneToMany#Undirectional_OneToMany.2C_No_Inverse_ManyToOne.2C_No_Join_Table_.28JPA_2.0_ONLY.29

Comment by Daniel Pitts [ 07/Oct/14 ]

This is also a big issue for Symfony2 forms. It's very difficult to make a form type for a collection of "things", where the "things" are fully owned by the parent object.

Comment by Florian Vogelpohl [ 05/Jun/15 ]

There are any plans to implement this feature?
The unidirection OneToMany with JoinTable is a little bit tricky, because in some cases you can't remove entities from parent. Also its not a real "Object-relation-mapping" because you need to add a (unnecessary) inverse field. This brakes the object domain model.

E.g.: If you have an entity Account which holds a collectionof Members (unidirectional) and now you want to remove a Member from the collection you get an "Cannot delete or update a parent row: a foreign key constraint fails " error ...





[DDC-3755] Flushing a single entity does not cascade flushes Created: 03/Jun/15  Updated: 03/Jun/15

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

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


 Description   

I have a bidirectional onetoone entities set up like this

class user

@OneToOne(targetEntity="Address", inversedBy="user",  cascade={"persist"})
$address

class Address

@OneToOne(targetEntity="User", mappedBy="address")
$user

@Column()
$city

Now say I saved a new user

$user = new User();
$address = new Address();
$address->setCity("Chicago");
$user->setAddress($address);
$em->persist($user);
$em->flush($user);

I get the expected result saved to the database.
Now say I want to update the city

$address = $user->getAddress()
$address->setCity("new york");
$user->setAddress($address);
$em->persist($user);
$em->flush($user);

The updated address information does not save even though cascade persist is enabled. I need to do a full flush ($em->flush()) for it to save properly

I would think since it does cascade the insert, that it should also cascade the update?

So Expected result:
Address information is saved to database

Actual Result:
Address information is not saved to the database






[DDC-3754] Entity cloning Created: 03/Jun/15  Updated: 03/Jun/15  Resolved: 03/Jun/15

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

Type: Bug Priority: Minor
Reporter: Evgen Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: proxy


 Description   

Sometimes doctrine query results proxy objects, even if them loaded directly. Proxy class overriding _clone method, so i can't reset id fields for it.I used another method "_clone_again_for_random_proxified_entity" to reset image id, but i'm sure its not the way this shuld work.
My code as example:

             $imgs = $this->getService('doctrine')->getQueryBuilder()
                    ->select('i')
                    ->from('Page\\Image', 'i')
                    ->where('i.page=:p')
                    ->getQuery()
                    ->setParameter('p',$source)
                    ->getResult();
                foreach($imgs as $img){
                    $copy = clone $img;
                    if(is_callable([$img, '__isInitialized'])){ //is a proxy
                        $copy->__clone_again_for_random_proxified_entity();
                    }
                    $entity->addPart($copy);
                }

i wasted half of day to catch collction with proxified entity (i think its loaded some where before as a proxy and then initialized on query)
i think its easy to fix by adding parent::__clone call on a proxy objects and avoid this kind of bugs. Thanks.



 Comments   
Comment by Marco Pivetta [ 03/Jun/15 ]

parent::__clone should actually be in the proxies. If that's not the case, then please write a test case against https://github.com/doctrine/common

See also https://github.com/doctrine/common/blob/ff72726b0876638fa7db2f28b0f26e3f1f6656ca/tests/Doctrine/Tests/Common/Proxy/ProxyMagicMethodsTest.php#L216-L231

Comment by Evgen [ 03/Jun/15 ]

Manual proxy regeneration solved this problem. Thanks a lot.





[DDC-3753] ManyToMany Relations from Value objects Created: 03/Jun/15  Updated: 03/Jun/15  Resolved: 03/Jun/15

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

Type: Bug Priority: Minor
Reporter: Maximilian Bosch Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: mapping, mysql, orm
Environment:

Ubuntu 14.04 (Virtualbox)/PHP 5.5.25/MySQL 5.5.43


Attachments: PNG File doctrine-user.PNG     PNG File doctrine-userdetails.PNG     PNG File doctrine-vm.PNG    

 Description   

I was trying to setup a many-to-many and a one-to-one relation from an embeddable object, but doctrine ignores these relation columns/tables (see screenshots).
As you can see, I've created a relation for followers called SEN_Following and SEN_UserToRole, but when reviewing the tables on the mysql, these tables are not shown.

When executing "php app/console doctrine:schema:update" I get the following message:
Nothing to update - your database is already in sync with the current entity metadata.



 Comments   
Comment by Maximilian Bosch [ 03/Jun/15 ]

in order to review the whole code, I've pushed to a remote feature branch on github: https://github.com/Ma27/SenNetwork/tree/SenNetwork-108

Comment by Marco Pivetta [ 03/Jun/15 ]

Value Objects should not reference entities in any case.

Comment by Maximilian Bosch [ 03/Jun/15 ]

ok thanks.

but just out of interest: why shouldn't they do??

Comment by Marco Pivetta [ 03/Jun/15 ]

Maximilian Bosch a value object can be compared with another value object by its value, whereas an entity is compared via identifier.

If you include an entity inside your VO you are comparing also the entity state (which is not comparable except for the identifier), and that breaks the entire idea of VO.

VOs should only reference other VOs and primitive types.

Comment by Maximilian Bosch [ 03/Jun/15 ]

Marco Pivetta thank you for your explanation.
but is there a way, how to persist collections inside a value objects??

serialization is IMHO a bad idea. For example I'd like to create a list which shows all users having a specific role, I had to load all users and the UserDetail object and check if they have the value object. With another table I could write a query for that.

Comment by Marco Pivetta [ 03/Jun/15 ]

but is there a way, how to persist collections inside a value objects??

currently not, and I'd still suggest serialization as a fallback (serialization is usually supported by VOs)

Comment by Maximilian Bosch [ 03/Jun/15 ]

Marco Pivetta ok thank you for your help.

I think the simplest solution is moving these relations into the entity and waiting for that feature.
The problem I'll ran into with serialization is that it's virtually impossible to query against a serialized string





[DDC-3752] no walkers for WhenClauseExpression Created: 01/Jun/15  Updated: 01/Jun/15

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

Type: Bug Priority: Major
Reporter: Jurj Alin Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Fatal error: Call to undefined method Application\Extended\Doctrine\Walkers\Custom::walkWhenClauseExpression() in vendor/doctrine/orm/lib/Doctrine/ORM/Query/AST/WhenClause.php on line 60






[DDC-3344] Flush on a specific entity is not correctly cascaded to associated entities Created: 10/Oct/14  Updated: 31/May/15

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


 Description   

In a setup with a simple entity associated entity, the cascade is not performed when flushing the parent entity. This violates contract specified by EntityManager#flush($entity) PHPDoc:

If an entity is explicitly passed to this method only this entity and the cascade-persist semantics + scheduled inserts/removals are synchronized.

It seems that the reason behind this is UnitOfWork#computeAssociationChanges, which expects that a #computeChangeSets is called elswehere (which it is not when flushing a specific entity):

MANAGED associated entities are already taken into account during changeset calculation anyway, since they are in the identity map.

This makes flushing and cascading very confusing. Also I believe this might be a cause of other issues, like DDC-3113.



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

Doctrine\ORM\EntityManager#flush() is not supposed to be called with a specific entity when there are cascade operations involved.

The optional argument has to be only used for performance reasons, but can indeed break things.

Comment by Pavel Horal [ 10/Oct/14 ]

Thank you for the reply. I am probably (and possibly other people) misinterpretting the PHPDoc. Can you explain what is meant by "and the cascade-persist semantics"?

Comment by Marco Pivetta [ 19/Oct/14 ]

Pavel Horal I don't really understand that bit myself, but git blame states that the comment was introduced in https://github.com/doctrine/doctrine2/commit/5d3298e706b1457ca8be02469b00ef219afe84e6 by Benjamin Eberlei.

Maybe it just needs a docblock rewrite

Comment by Pavel Horal [ 19/Oct/14 ]

Commit is linked with DDC-720 . Again, that gives me an impression that events should be cascaded:

In a nutshell, this change would mean that flush() can optionally accept an entity as an argument. When that happens, the resulting changeset will be limited to that entity and any entity reachable from it.

Comment by Marco Pivetta [ 19/Oct/14 ]

Again, that gives me an impression that events should be cascaded

No, the entire flush($entity) functionality is just to limit the entire Doctrine\ORM\UnitOfWork operations over the single object: it's expected behavior.

In general, you should use flush($entity) only if you have very high priority performance optimizations, as it was never meant to be reliable API when using listeners.

I'd even suggest deprecating it for removal in the next major release, as it has only caused issues so far.

Comment by John Kleijn [ 31/May/15 ]

I also ran into this. I foolishly made the assumption that flush($entity) was intended to flush an entity and all associations (following "persist" cascade rules).

Intended or not, I firmly believe this should be the default behavior (or create a second set of cascade rules, eg "flush"). The reasoning behind it is one of encapsulation. Client code calling flush() cannot know what is flushed unless it owns all entity interaction, which is both undesirable and unrealistic. A single service may very well own all interactions on a specific object and its associations though.





[DDC-3749] [GH-1414] Added: A public SQLFilter Hash Function Created: 29/May/15  Updated: 29/May/15

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 nea:

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

Message:

Hi

To be more flexible from a custom SQLFilter perspective, a dedicated hash function was added, which is not final and can be used by any implementing class to manipulate their e.g. caching behaviour.

The idea came from the event of having a query cache running and a filter, requiring to add actual current timestamps to the queries for comparison purposes (i.e. SoftDeleteable). As the old timestamps are cached too and the parser not fired again, old entities were returned.

As the cache id is based also on the filters hash, a quick and I think good, slick solution would be to add a Hash Function that can be manipulated by an owning filter, to handle its behaviour on its own.

It defaults back to __toString and therefore nothing changes in basics but it could be.

Cheers

Changes:

  • Added: A public SQLFilter Hash Function (defaults to __toString)
  • Changed: FilterCollection to use the newly added SQLFilter Hash Function





[DDC-3743] There is a BC break in the ORM 2.5 in the DQL parser Created: 22/May/15  Updated: 28/May/15

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

Type: Bug Priority: Critical
Reporter: Christophe Coevoet Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: dql


 Description   

The following DQL query is working fine on 2.4 but breaks on 2.5:

SELECT COUNT(l) FROM Incenteev\WebBundle\Entity\Discussion\Liker l INNER JOIN l.message m INNER JOIN m.thread t WHERE t.space IN (:space_ids) AND l.date >= :from

This is the exception triggered in 2.5:

[Semantical Error] line 0, col 13 near 'l) FROM Incenteev\WebBundle\Entity\Discussion\Liker': Error: Invalid PathExpression. Must be a StateFieldPathExpression. 

The exception happens in Parser->processDeferredPathExpressions.

The Liker class has a compound identifier based on 2 relations.

I suspect it is related to https://github.com/doctrine/doctrine2/pull/1122



 Comments   
Comment by Christophe Coevoet [ 22/May/15 ]

I'm not sure it is a BC break though. Looking at the SQL generated in 2.4, it was not counting the right thing (is was counting only the message ids, not the combination message id/user id being the primary key.

Comment by Christophe Coevoet [ 28/May/15 ]

Actually, it was counting the right thing when not using DISTINCT (the 2.4 generated SQL was broken for DISTINCT though)

Comment by Guilherme Blanco [ 28/May/15 ]

Yep, that PR was the culript. I can look into this issue later.





[DDC-2076] Optimization for MEMBER OF Created: 14/Oct/12  Updated: 28/May/15

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

Type: Improvement Priority: Minor
Reporter: Christophe Coevoet Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dql


 Description   

Currently, using MEMBER OF for a ManyToMany collection does a join on the table of the related entity, whereas all it needs is in the join table.

Using the following DQL:

SELECT p FROM Player p
WHERE NOT :team MEMBER OF p.targetedBy

Here is the current generated SQL:

WHERE NOT EXISTS (SELECT 1 FROM player_team p1_ INNER JOIN Team t2_ ON p1_.team_id = t2_.id WHERE p1_.player_id = p0_.id AND t2_.id = ?)

whereas it could drop the join:

WHERE NOT EXISTS (SELECT 1 FROM player_team p1_ WHERE p1_.player_id = p0_.id AND p1_.team_id = ?)


 Comments   
Comment by Christophe Coevoet [ 28/May/15 ]

Guilherme Blanco is there any case where the CollectionMemberExpression would really need to join the target entity table rather than just using the join table ? I don't see any





[DDC-3218] Argument 3 passed to Doctrine\ORM\Event\PreUpdateEventArgs::__construct() must be of the type array, null given Created: 18/Jul/14  Updated: 28/May/15  Resolved: 09/Feb/15

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

Type: Bug Priority: Major
Reporter: Grégoire Pineau Assignee: Marco Pivetta
Resolution: Incomplete Votes: 1
Labels: None
Environment:

Linux / Mint 15
php 5.5.*



 Description   

Argument 3 passed to Doctrine\ORM\Event\PreUpdateEventArgs::__construct() must be of the type array, null given, called in /home/greg/dev/product/insight/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php on line 1009 and defined

Stack trace:

[1] PHPUnit_Framework_Error: Argument 3 passed to Doctrine\ORM\Event\PreUpdateEventArgs::__construct() must be of the type array, null given, called in /project/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php on line 1009 and defined
at n/a
in /project/vendor/doctrine/orm/lib/Doctrine/ORM/Event/PreUpdateEventArgs.php line 47

at PHPUnit_Util_ErrorHandler::handleError('4096', 'Argument 3 passed to Doctrine\ORM\Event\PreUpdateEventArgs::__construct() must be of the type array, null given, called in /project/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php on line 1009 and defined', '/project/vendor/doctrine/orm/lib/Doctrine/ORM/Event/PreUpdateEventArgs.php', '47', array('entity' => object(Violation), 'em' => object(EntityManager)))
in /project/vendor/doctrine/orm/lib/Doctrine/ORM/Event/PreUpdateEventArgs.php line 47

at Doctrine\ORM\Event\PreUpdateEventArgs->__construct(object(Violation), object(EntityManager), null)
in /project/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php line 1009

at Doctrine\ORM\UnitOfWork->executeUpdates(object(ClassMetadata))
in /project/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php line 341

at Doctrine\ORM\UnitOfWork->commit(null)
in /project/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php line 389

at Doctrine\ORM\EntityManager->flush()
in /project/src/SensioLabs/Bundle/MyBundle/Controller/MyController.php line 127

at SensioLabs\Bundle\MyBundle\Controller\MyController->ignoreAction(object(Request), object(Project), object(Analysis), '4')
in line

at call_user_func_array(array(object(MyController), 'ignoreAction'), array(object(Request), object(Project), object(Analysis), '4'))
in /project/app/bootstrap.php.cache line 1043

at Symfony\Component\HttpKernel\HttpKernel->handleRaw(object(Request), '1')
in /project/app/bootstrap.php.cache line 1015

at Symfony\Component\HttpKernel\HttpKernel->handle(object(Request), '1', true)
in /project/app/bootstrap.php.cache line 1154

at Symfony\Component\HttpKernel\DependencyInjection\ContainerAwareHttpKernel->handle(object(Request), '1', true)
in /project/app/bootstrap.php.cache line 435

at Symfony\Component\HttpKernel\Kernel->handle(object(Request))
in /project/vendor/symfony/symfony/src/Symfony/Component/HttpKernel/Client.php line 81

at Symfony\Component\HttpKernel\Client->doRequest(object(Request))
in /project/vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Client.php line 111

at Symfony\Bundle\FrameworkBundle\Client->doRequest(object(Request))
in /project/vendor/symfony/symfony/src/Symfony/Component/BrowserKit/Client.php line 319

at Symfony\Component\BrowserKit\Client->request('POST', '/projects/id-foo/analyses/2/rule/4/ignore', array('ignore_rule' => array('comment' => 'Message about why this rule has been ignored', '_token' => 'CxEFTSv4GZQSWYXtRt-eHybaML4z8I0WK1DHiwr8Ih0')))
in /project/src/SensioLabs/Bundle/MyBundle/Test/Client.php line 489

at SensioLabs\Bundle\MyBundle\Test\Client->ignoreRuleViolations('id-foo', '2', '4', false)
in /project/src/SensioLabs/Bundle/MyBundle/Tests/Acceptance/ViolationCommentsTest.php line 217

at SensioLabs\Bundle\MyBundle\Tests\Acceptance\ViolationCommentsTest->testDashboardWithCriticalIgnoredRules()
in line

at ReflectionMethod->invokeArgs(object(ViolationCommentsTest), array())
in /project/vendor/phpunit/phpunit/src/Framework/TestCase.php line 951

at PHPUnit_Framework_TestCase->runTest()
in /project/vendor/phpunit/phpunit/src/Framework/TestCase.php line 817

at PHPUnit_Framework_TestCase->runBare()
in /project/vendor/phpunit/phpunit/src/Framework/TestResult.php line 686

at PHPUnit_Framework_TestResult->run(object(ViolationCommentsTest))
in /project/vendor/phpunit/phpunit/src/Framework/TestCase.php line 753

at PHPUnit_Framework_TestCase->run(object(PHPUnit_Framework_TestResult))
in /project/vendor/phpunit/phpunit/src/Framework/TestSuite.php line 675

at PHPUnit_Framework_TestSuite->run(object(PHPUnit_Framework_TestResult))
in /project/vendor/phpunit/phpunit/src/TextUI/TestRunner.php line 426

at PHPUnit_TextUI_TestRunner->doRun(object(PHPUnit_Framework_TestSuite), array('listGroups' => false, 'loader' => null, 'useDefaultConfiguration' => true, 'configuration' => '/project/app/phpunit.xml.dist', 'filter' => 'testDashboardWithCriticalIgnoredRules', 'testSuffixes' => array('Test.php', '.phpt')))
in /opt/dotfiles/vendor/phpunit/phpunit/PHPUnit/TextUI/Command.php line 176

at PHPUnit_TextUI_Command->run(array('/usr/local/bin/phpunit', 'c', 'app/', '-filter', 'testDashboardWithCriticalIgnoredRules', 'src/SensioLabs/Bundle/MyBundle/Tests/Acceptance/ViolationCommentsTest.php'), true)
in /opt/dotfiles/vendor/phpunit/phpunit/PHPUnit/TextUI/Command.php line 129

at PHPUnit_TextUI_Command::main()
in /opt/dotfiles/vendor/phpunit/phpunit/composer/bin/phpunit line 63

I fails in this code

    private function executeUpdates($class)
    {
        $className          = $class->name;
        $persister          = $this->getEntityPersister($className);
        $preUpdateInvoke    = $this->listenersInvoker->getSubscribedSystems($class, Events::preUpdate);
        $postUpdateInvoke   = $this->listenersInvoker->getSubscribedSystems($class, Events::postUpdate);

        foreach ($this->entityUpdates as $oid => $entity) {
            if ($this->em->getClassMetadata(get_class($entity))->name !== $className) {
                continue;
            }

            if ($preUpdateInvoke != ListenersInvoker::INVOKE_NONE) {
// => this line
                $this->listenersInvoker->invoke($class, Events::preUpdate, $entity, new PreUpdateEventArgs($entity, $this->em, $this->entityChangeSets[$oid]), $preUpdateInvoke);
                $this->recomputeSingleEntityChangeSet($class, $entity);
            }

            if ( ! empty($this->entityChangeSets[$oid])) {
                $persister->update($entity);
            }

            unset($this->entityUpdates[$oid]);

            if ($postUpdateInvoke != ListenersInvoker::INVOKE_NONE) {
                $this->listenersInvoker->invoke($class, Events::postUpdate, $entity, new LifecycleEventArgs($entity, $this->em), $postUpdateInvoke);
            }
        }
    }


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

Requires a test case

Comment by Victor [ 26/Aug/14 ]

I have same bug when call flush() method from entity manager in my few event listeners in Symfony.

P.S. If I call flush() only from one listener - it works well, but when call flush() in first, and then in second - it fails. And it does not matter in which order listeners are called.

Comment by Grégoire Pineau [ 26/Aug/14 ]

yeah, the bug occurs in the same circumstance as described by victor.
(sorry for the delay, and sorry to not provider a test case)

Comment by Christophe Coevoet [ 26/Aug/14 ]

Calling flush() inside a Doctrine listener is not a supported Doctrine usage. it means you are trying to nest several flushes inside each other, which can indeed break the unit of work

Comment by Grégoire Pineau [ 26/Aug/14 ]

I refactored this part of our code base, to remove all flush from the listener. Everything works right now.
But I did not know this was not possible. (And it's not me the guy who created this **** in our codebase )

Comment by Victor [ 26/Aug/14 ]

So, for example, if I use postUpdate Doctrine event to modify the entity after save them to DB, I can't save additional changes to DB again with flush() in my listener?
Is it will be fixed or it's a normal behavior of Doctrine?

Comment by Timur Ramazanov [ 09/Feb/15 ]

I ran into the same issue, I wonder, what should I do?

if I use postUpdate Doctrine event to modify the entity after save them to DB, I can't save additional changes to DB again with flush() in my listener?

Is there an answer on this?

Comment by Marco Pivetta [ 09/Feb/15 ]

Flushing in a listener that acts during EntityManagerInterface#flush() is disallowed.

Comment by Marco Pivetta [ 09/Feb/15 ]

I'm marking this issue as incomplete: not reproducible without a test case.

Comment by Grzegorz Korba [ 27/May/15 ]

I'm facing this problem right now (doctrine/orm 2.5).

In my case:

  • We have listener for one specified entity's field, which subscribes to preUpdate, postPersist and postUpdate
  • in preUpdate we check if this is valid entity and old value of specified field differs from new value, if yes we internally store some array with data like below:
    [
    'mode' => 'manual',
    'entity' => $entity,
    'oldValue' => $oldValue,
    'newValue' => $newValue,
    ]
    
  • in postPersist (works ok) and postUpdate (ContextErrorException) we're using custom logger, which has handler based on database, for storing changelog record. We create new entity, which has relation to modified entity. Exception rises when flushing changelog entity, which again dispatches preUpdate on related entity with null 3rd argument.

I can't post more code because it's company's property, but flow is described and clear (I think so).

Comment by Marco Pivetta [ 27/May/15 ]

That's not enough to reproduce the problem. From what I am thinking, this looks like a case where flush() was called (again) in a listener (unsupported).

I suggest you to write a test case, if this is still valid.

Comment by Grzegorz Korba [ 27/May/15 ]

Yes, flush() was called in postUpdate.. I've changed it to connection's insert() and now it works. Too bad it's unsupported (and not intuitive).

Comment by Damien ALEXANDRE [ 28/May/15 ]

Would be a good idea to throw a real exception when trying to flush in a flush; Making this mistake better known.





[DDC-3381] orm:schema-tool:update shows incorrect changes with MasterSlaveConnection wrapper class Created: 09/Nov/14  Updated: 28/May/15

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

Type: Bug Priority: Major
Reporter: Pieter Vogelaar Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: connection, ddl, master-slave, schematool


 Description   

My entities and database are in sync. If I use the default Doctrine connection configuration it shows "Nothing to update - your database is already in sync with the current entity metadata.". This is what I would expect and is correct.

'doctrine' => array(
        'connection' => array(
            'orm_default' => array(
                'driverClass' => 'Doctrine\DBAL\Driver\PDOMySql\Driver',
                'params' => array(
                    'host'     => 'localhost',
                    'port'     => '3306',
                    'user'     => 'myuser',
                    'password' => 'mypassword',
                    'dbname'   => 'example',
                    'charset'  => 'utf8',
                ),
        ),
),

But with the MasterSlaveConnection configuration, I always get the same changes which are a lot, you would think the database is empty at the moment.

'doctrine' => array(
        'connection' => array(
            'orm_default' => array(
                'wrapperClass' => 'Doctrine\DBAL\Connections\MasterSlaveConnection',
                'params' => array(
                    'driver' => 'pdo_mysql',
                    'master' => array(
                        'host' => 'localhost',
                        'port' => '3306',
                        'user' => 'myuser',
                        'password' => 'mypassword',
                        'dbname' => 'example',
                        'charset' => 'utf8',
                    ),
                    'slaves' => array(
                        array(
                            'host' => 'localhost',
                            'port' => '3306',
                            'user' => 'myuser',
                            'password' => 'mypassword',
                            'dbname' => 'example',
                            'charset' => 'utf8',
                        ),
                    ),
                ),
            ),
        ),
    ),
),


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

Can you come up with a functional test case for this? Couldn't reproduce from here.

Comment by Dennis Smink [ 28/May/15 ]

Hello, I'm on a Symfony 2.6.6 project and I encountered the same problems. Although:

shell> php app/console doctrine:cache:clear-metadata

.. did the trick for me!





[DDC-1390]  Lazy loading does not work for the relationships of an entity instance, whose class inherits from another entity class Created: 22/Sep/11  Updated: 27/May/15  Resolved: 27/May/15

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

Type: Bug Priority: Major
Reporter: Daniel Alvarez Arribas Assignee: Benjamin Eberlei
Resolution: Cannot Reproduce Votes: 0
Labels: None
Environment:

Debian Linux 6.0, MySQL 5.0.51a


Attachments: File CommissionNoteCreatorResult.php     File ConsumerInvoiceExporterResult.php     File DataObject.php     File DataVersion.php     File DDC1390Test.php     File InvoiceCreatorResult.php     File Result.php     File Run.php    

 Description   

Lazy loading does not work for the relationships of an instance of an entity, whose class inherits from another entity class.

Assume there are two entity classes, A and B, where A inherits from B.

Now let $a be an instance of A, e. g. the result of "SELECT a FROM \A WHERE a.id = 1".

Outputting $a will confirm it is a valid instance of a proxy object inheriting from A.

Assume that the database row corresponding to $a contains a non-null foreign key that actually links to an existing row in another table, corresponding to another entity instance of a different class.

Now, $a->someRelationship will always returns null in this scenario. I assume this is unintended behaviour, because clearly, the other entity should be lazily loaded on accessing it, and there is a value in the database.

The fetch annotation attribute on that relationship has not been explicitly set, so I assume it is set to the default value, which, according to the docs, should be "lazy".

The loading only fails when accessing the relationships of an entity instance, whose class inherits from another entity class. For entity instances, whose classes do not inherit from another entity class, lazy loading of their relationships works as expected.

I had a look at the proxy objects and verified that they are present and override the __get method with an implementation containing a call to the load() method. Still, the loading won't work for some reason.

This could be related to Bug DDC-1389 (http://www.doctrine-project.org/jira/browse/DDC-1389) which also happens exclusively in an inheritance scenario. Maybe the current implementation of inheritance is generally wrong or incomplete.



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

Did this get fixed with the correction of your data?

Comment by Daniel Alvarez Arribas [ 01/Nov/11 ]

No it did not. This issue is completely unrelated to the other one.

For this, I have manually implemented workarounds, fetching the associations using DQL queries. Lazy loading in the inheritance scenario above still would not work.

Comment by Benjamin Eberlei [ 01/Nov/11 ]

So A is an entity in a hierachy A -> B, and "someRelationship" is a field on A or on B towards an Entity C that is in an inheritance hierachy or not?

Could you post parts of the mappings (entity docblock and the relationship)?

Comment by Daniel Alvarez Arribas [ 06/Nov/11 ]

Hey, thanks for taking care of this.

I attached the entities involved in the szenario to this issue.

I had problems lazy loading entities through the following associations:

Run.invoiceCreatorResult
Run.commissionNoteCreatorResult
Run.consumerInvoiceExporterResult

as well as

InvoiceCreatorResult.dataVersion
CommissionNoteCreatorResult.dataVersion
ConsumerInvoiceExporterResult.dataVersion

In this scenario, InvoiceCreatorResult, CommissionNoteCreatorResult and ConsumerInvoiceExporterResult all inherit from Result, which in turn inherits from a mapped superclass DataObject. Run and DataVersion inherit from DataObject directly.

The associations where lazy loading does not work are associations both to and from the entity classes InvoiceCreatorResult, CommissionNoteCreatorResult and ConsumerInvoiceExporterResult.

Comment by Benjamin Eberlei [ 18/Nov/11 ]

Now let $a be an instance of A, e. g. the result of "SELECT a FROM \A WHERE a.id = 1".

Outputting $a will confirm it is a valid instance of a proxy object inheriting from A.

Just a short Q on understanding: Why is $a a proxy of A if you select it explicitly?

Comment by Benjamin Eberlei [ 18/Nov/11 ]

This a working test-case with a model that i believe resembles yours exactly.

I also put your models into another test and ran schema validation on them, which works out without problems.

From the workflow with proxies, maybe DDC-1452 might be related to your issue?

Comment by Daniel Alvarez Arribas [ 18/Nov/11 ]

Regarding the proxy question, I just ment the query to be an example to further illustrate the type of $a. It was redundant and unnecessary though and probably misleading. Sorry for that. I did not select anything in the actual scenario. $a is merely some object of type A. No queries are involved.

Comment by Daniel Alvarez Arribas [ 18/Nov/11 ]

Have you been able to make the tests fail with the original data provided?

If not, I could set up a test case and post it.

Comment by Benjamin Eberlei [ 18/Nov/11 ]

No i only checked the validity of mappings with the original data. If you could setup a testcase that would be really great.

Comment by Daniel Alvarez Arribas [ 19/Nov/11 ]

I will set up a test case and upload it. I'll see if I can do it one of the next evenings.

Comment by Benjamin Eberlei [ 17/Dec/11 ]

I tried again, also extended DDC-1390, but it was impossible for me to reproduce this. I ran this against master, 2.1.x and 2.1.1 specifically.

Comment by Daniel Alvarez Arribas [ 05/Jan/13 ]

Sorry, I got swamped with work. Now I am working on this dedicatedly, testing against the latest release. Will let you know once I have a testcase.

Comment by Benjamin Eberlei [ 06/Jan/13 ]

Good to hear, thanks for the persistent work on this.

Comment by Daniel Alvarez Arribas [ 27/May/15 ]

I have to admit I really goofed up on this one, sorry.

Right now I no longer have access the setup, since I am working on unrelated things.

Closing this for now as non-reproducible. If I should ever have another scenario at hand where the issue occurs, I will reopen the issue and provide you with a test case.





[DDC-3747] Embeddables should not conatain Id definitions Created: 27/May/15  Updated: 27/May/15

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

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


 Description   

Hi! I have an Sku entity which contains an SkuId embeddable object, which is an Id for the Sku entity. At the same time, the Sku entity also contains a ProductId embeddable which is an Id for the Product entity, not the Sku. But as the Id definition is inside the embeddable, I can't embed the ProductId class in the Sku entity because Doctrine thinks this is a composite primary key, which breaks quite a lot of things.

mapping.yml
Sku\Sku:
  type: entity
  fields:
    name:
      type: string
      length: 100
  embedded:
    skuId:
      class: Ulabox\Inventory\Domain\Model\Sku\SkuId
      columnPrefix: false
    productId:
      class: Ulabox\Inventory\Domain\Model\Product\ProductId
      columnPrefix: product_
Sku\SkuId:
  type: embeddable
  id:
    id:
      type: guid
Product\ProductId:
  type: embeddable
  id:
    id:
      type: guid

I've switched to using custom types for this "class Id's" but I think that the Id definition should be separated from the Embeddable definition because sometimes an Embeddable might be the Id of an entity, but it also could be a simple field, which is not possible right now. Maybe some kind of "type" attribute in the "embedded" definition that could mark if the Embeddable fields are going to be used as simple fields or id fields

mapping.yml
Sku\Sku:
  type: entity
  fields:
    name:
      type: string
      length: 100
  embedded:
    skuId:
      type: id
      class: Ulabox\Inventory\Domain\Model\Sku\SkuId
      columnPrefix: false
    productId:
      class: Ulabox\Inventory\Domain\Model\Product\ProductId
      columnPrefix: product_
Sku\SkuId:
  type: embeddable
  fields:
    id:
      type: guid
Product\ProductId:
  type: embeddable
  fields:
    id:
      type: guid





[DDC-3372] PersistentCollection clear function takes snapshot when the collection is cleared Created: 06/Nov/14  Updated: 27/May/15

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: Ward Peeters Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: collection, orm
Environment:

Symfony 2.5.6



 Description   

I'm not sure if it's a bug or you guys have a reason why you do it. The problem occurs when you do a $coll->clear() he will clear the collection and whenever it's cleared the takeSnapshot is ran as well so our snapshot is empty so we lose the prevous state of the collection.

public function clear()
    {
        if ($this->initialized && $this->isEmpty()) {
            return;
        }

        $uow = $this->em->getUnitOfWork();

        if ($this->association['type'] & ClassMetadata::TO_MANY &&
            $this->association['orphanRemoval'] &&
            $this->owner) {
            // we need to initialize here, as orphan removal acts like implicit cascadeRemove,
            // hence for event listeners we need the objects in memory.
            $this->initialize();

            foreach ($this->coll as $element) {
                $uow->scheduleOrphanRemoval($element);
            }
        }

        $this->coll->clear();

        $this->initialized = true; // direct call, {@link initialize()} is too expensive

        if ($this->association['isOwningSide'] && $this->owner) {
            $this->changed();

            $uow->scheduleCollectionDeletion($this);

            $this->takeSnapshot();
        }
    }


 Comments   
Comment by Marco Pivetta [ 07/Nov/14 ]

Can you please abstract your problem into a test case?

Comment by Ward Peeters [ 07/Nov/14 ]

if that helps yes. The problem is that i'm not sure it's a bug. It might be the way you guys wanted it to be.
I'll create a test case might be better to understand.

Comment by Marco Pivetta [ 07/Nov/14 ]

It looks like a bug to me: the snapshot should be taken only when no snapshot was there upfront, as far as I know.

Comment by Oleg Namaka [ 27/May/15 ]

I just got bitten by the same issue. I need to have access to all elements being cleared in a collection before it gets actually cleared, but because its internal collection gets cleared before PersistentCollection is able to take a snapshot, all these elements are lost.

Comment by Oleg Namaka [ 27/May/15 ]

@Ward Peeters, have you ever created the test case in question?

Comment by Ward Peeters [ 27/May/15 ]

No i haven't will make one today if you're not doing it. I made workaround for now.





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

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

Type: Bug Priority: Major
Reporter: Dennis Væversted Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 4
Labels: None

Attachments: Text File undefined-joinColumn.patch    
Issue Links:
Duplicate
duplicates DDC-2808 Notice: Undefined index: joinColumns ... Resolved
Reference
is referenced by DDC-3578 [GH-1307] Test for DDC-2988 Open

 Description   

When trying to use findBy on a ManyToMany field i receive the error:

Notice: Undefined index: joinColumns in lib/Doctrine/ORM/Persisters/BasicEntityPersister.php

It seems to be caused internally by the code expecting 'joinColumns' to be directly on the association, however it is found under 'joinTable'.
I have attached a patch that atleast fixes my case, hopefully it can be used to pin-point what the error is.



 Comments   
Comment by Dennis Væversted [ 19/Feb/14 ]

Might be related to this one: http://www.doctrine-project.org/jira/browse/DDC-2808

Comment by Litz Ouille [ 28/May/14 ]

Doctrine ORM 2.4.2 Here.

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

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

Comment by Marco Pivetta [ 30/May/14 ]

Calin Pristavu did you validate your mappings?

Comment by Calin Pristavu [ 30/May/14 ]

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

The many-to-one works just fine !

Comment by Litz Ouille [ 03/Jun/14 ]

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

Comment by Marco Pivetta [ 03/Jun/14 ]

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

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

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

Comment by Litz Ouille [ 03/Jun/14 ]

EDIT: Ok my bad.

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

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

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

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

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

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

multiple users can have multiple departments:

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

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

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

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

This results in this error:

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

Comment by Alexander [ 29/Jan/15 ]

I have same problem with doctrine 2.4.7:

Acme\ProjectBundle\Entity\Employee:
  manyToMany:
    projectbag:
      targetEntity: ProjectBag
      mappedBy: bagemployee
Acme\ProjectBundle\Entity\ProjectBag:
  manyToMany:
    bagemployee:
          targetEntity: Employee
          inversedBy: projectbag
          joinTable:
            name: ProjectBag_Employee
            joinColumns:
              ProjectBag_id:
                referencedColumnName: id
            inverseJoinColumns:
              Employee_id:
                referencedColumnName: id

$em->getRepository('AcmeProjectBundle:ProjectBag')->findBy(array('bagemployee'=>$em->getRepository('AcmeProjectBundle:Employee')->find(828)));

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

Comment by George Brooks [ 06/Feb/15 ]

What is meant by "Awaiting feedback"?

After encountering the same error as described above I've created a new Symfony project with the sole purpose of reproducing the error. If this would be of use in resolving the issue please let me know. I can make the code available in whatever form would be the most useful.

Comment by Marco Pivetta [ 06/Feb/15 ]

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

We don't need a symfony project or an example app: we have our own test suite that can be found at https://github.com/doctrine/doctrine2/tree/master/tests

Comment by Carl Boisvert [ 13/Feb/15 ]

I have the same issue. Want to filter on a relationship on the owning side (Because I got an error on the non owning side saying I needed to be on the owning side) and I get the exact same error.

Comment by Ilya Antipenko [ 19/Feb/15 ]

As workaround we can collect IDs and pass it to queryBuilder, like:

    public function findAllSwitcherTypeByComponents($components)
    {
        $ids = [];
        /** @var Component $component */
        foreach ($components as $component) {
            $ids[] = $component->getId();
        }

        $query = $this->createQueryBuilder('component_switcher_type');
        $query
            ->join( 'component_switcher_type.components', 'components', 'WITH', $query->expr()->in('components.id', $ids));

        return $query->getQuery()->getResult();
}
Comment by Marco Pivetta [ 19/Feb/15 ]

Don't code workarounds: provide a test case, so that a patch can be created

Comment by Ilya Antipenko [ 19/Feb/15 ]

I'll this ASAP.

Comment by Ilya Antipenko [ 20/Feb/15 ]

Here is the test: https://github.com/doctrine/doctrine2/pull/1307
Here is the test log on travis-ci: https://travis-ci.org/aivus/doctrine2/builds/51516067

Comment by Doctrine Bot [ 16/Mar/15 ]

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

Comment by Ilya Antipenko [ 26/May/15 ]

On master branch getting this error now:

Column not found: 1054 Unknown column 'users_to_groups.group_id' in 'where clause'

for this test: https://github.com/doctrine/doctrine2/pull/1307





[DDC-2022] DiscriminatorMap mixing up namespaces Created: 10/Sep/12  Updated: 26/May/15  Resolved: 17/Sep/12

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

Type: Bug Priority: Major
Reporter: Kim Wauters Assignee: Benjamin Eberlei
Resolution: Can't Fix Votes: 0
Labels: None


 Description   

I have a superclass RuleLine that has NO namespace which has a discriminator map with 2 entities of which 1 has a namespace and one does not, doctrine however will always try to load the entity without namespace with the one that does saying something like :
Doctrine\ORM\Mapping\MappingException : Entity class 'Core\domain\meal\DietRuleLine' used in the discriminator map of class 'Core\domain\meal\MealRuleLine' does not exist.

Example:

<?php
/**
 * @Entity
 * @InheritanceType("SINGLE_TABLE")
 * @DiscriminatorColumn(name="discr", type="string")
 * @DiscriminatorMap({"diet" = "\DietRuleLine", "meal" = "Core\domain\meal\MealRuleLine"})
 * @Table(name="ruleline")
 */
abstract class RuleLine extends \IdentifiableEntity {

MealRuleLine (WITH namespace):

<?php

namespace Core\domain\meal;

/**
 * @Entity
 * @Table(name="mealruleline")
 */
class MealRuleLine extends \RuleLine {

And DietRuleLine (NO NAMESPACE):

<?php

/**
 * @Entity
 * @Table(name="dietRuleLine")
 */
class DietRuleLine extends \RuleLine {

This always gives the following error :

Doctrine\ORM\Mapping\MappingException : Entity class 'Core\domain\meal\DietRuleLine' used in the discriminator map of class 'Core\domain\meal\MealRuleLine' does not exist.



 Comments   
Comment by Kim Wauters [ 10/Sep/12 ]

DDC-1349 seems like the same problem to me

Comment by Benjamin Eberlei [ 17/Sep/12 ]

This is an edge-case that cannot be fixed. We had this issue before as you pointed out. Sorry to dissappoint you here

Comment by Sullivan SENECHAL [ 26/May/15 ]

No hope to get this as a new feature? Thanks.

Comment by Sullivan SENECHAL [ 26/May/15 ]

My bad, this works on 2.5.

Comment by Marco Pivetta [ 26/May/15 ]

This simply looks like an autoloading issue - should no longer be valid, and should actually work with a simple classmap autoloader.





[DDC-3746] lack of flexibility in persisters Created: 25/May/15  Updated: 25/May/15

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

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


 Description   

I tried to implement driver for HandlerSocket protocol, which is mysql nosql plugin.

BasicEntityPersister is a problem - it fully depends(and others and more) on SQL.
I can`t say to Doctrine, how the data must be fetched from my own Driver.
I think it is a logical mistake, such logic(creating query to DB) must be inside a db driver bridge.
I found two solution:
1) Get persisters configurable from entity manager config
2) Try to find persisters inside the DBAL driver

What do u think about it?

Thanks, Konstantin.






[DDC-2788] Create Table If Not Exists - doctrine:schema:update Created: 11/Nov/13  Updated: 25/May/15

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

Type: Improvement Priority: Minor
Reporter: jayem Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: command, schematool


 Description   

I am not positive if this issue is in the correct project. Sorry if I placed it in the wrong area.

I was wondering if it would be possible to have the doctrine:schema:update command updated to use CREATE IF NOT EXISTS for tables that already exist.

For example, here is my setup:

Author.php
    /**
     * The relationship between an author and its associated book entities.
     *
     * @ORM\ManyToMany(targetEntity="Book")
     * @ORM\JoinTable(name="authors_books",
     *     joinColumns={@ORM\JoinColumn(name="book_id", referencedColumnName="id")},
     *     inverseJoinColumns={@ORM\JoinColumn(name="author_id", referencedColumnName="id")}
     * )
     */
    protected $books;

The above code is an example, so the exact column names may not be 100% correct. The import aspect is the join table name. If that table already exists in the database, I will get the following error when I run the doctrine:schema:update --dump-sql command:

[Doctrine\DBAL\Schema\SchemaException]
The table with the name 'authors_books' already exists.

This is because it is trying to CREATE TABLE 'authors_books' and that table is already in the database. Could the command instead use CREATE TABLE IF NOT EXISTS 'authors_books' when "IF NOT EXISTS" is available for the configured database type?

Thanks!



 Comments   
Comment by Frank.Shi [ 25/May/15 ]

you can reference this question, http://stackoverflow.com/questions/3220998/check-for-table-existence-before-dropping





[DDC-3745] OneToOne identity through foreign entity exception on flush Created: 22/May/15  Updated: 22/May/15

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

Type: Bug Priority: Minor
Reporter: Dawid Nowak Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Also asked at SO: https://stackoverflow.com/questions/30402203
I'm adding it here as well as an issue here, because I believe it just might be Doctrine's bug.


I have `User` and `UserProfile` OneToOne–related Doctrine ORM entities. They should always exist as a pair, there should be no `User` without `UserProfile`.

User should get its id from autoincrement, while UserProfile should have User's id. So they both should have the same id and there is no other column to set up the relationship ([Doctrine docs: Identity through foreign Entities](https://doctrine-orm.readthedocs.org/en/latest/tutorials/composite-primary-keys.html#identity-through-foreign-entities)).

User's id is both a primary key (PK) and foreign key (FK) at the same time.

I managed to set it up, but it requires that User is saved first and only later UserProfile is created and saved in a separate step.

What I want is that UserProfile is always created with User, in the constructor, but if I do that, I get this exception:

`Doctrine\ORM\ORMInvalidArgumentException: The given entity of type 'AppBundle\Entity\UserProfile' (AppBundle\Entity\UserProfile@0000000052e1b1eb00000000409c6f2c) has no identity/no id values set. It cannot be added to the identity map.`

Please see code below – it works, but not the way I want. The php comments show what I want to achieve.

Test.php
    /**
     * It works, both saving and loading.
     * BUT, it requires that I create and save UserProfile 
     * in a separate step than saving User step.
     */
    
    // create and save User
    $user = new User();
    $objectManager->persist($user);
    $objectManager->flush();
    
    // create and save UserProfile (this should be unnecessary)
    $user->createProfile()
    $objectManager->flush();
User.php
    use Doctrine\ORM\Mapping as ORM;
    
    /**
     * @ORM\Entity(repositoryClass="AppBundle\Entity\UserRepository")
     * @ORM\Table(name="users")
     */
    class User
    {
    	/**
    	 * @var int
    	 *
    	 * @ORM\Column(name="uid", type="integer")
    	 * @ORM\Id
    	 * @ORM\GeneratedValue(strategy="AUTO")
    	 */
    	private $id;
    	
    	/**
    	 * It's NULL at first, I create it later (after saving User).
    	 * 
    	 * @var UserProfile|null
    	 *
    	 * @ORM\OneToOne(targetEntity="UserProfile", mappedBy="user", cascade="persist")
    	 */
    	private $profile = null;
    	
    	public function __construct()
    	{
    		// I want to create UserProfile inside User's constructor,
    		// so that it is always present (never NULL):
    		//$this->profile = new UserProfile($this);
    		
    		// but this would give me error:
    		//
    		// Doctrine\ORM\ORMInvalidArgumentException: 
    		// The given entity of type 'AppBundle\Entity\UserProfile' 
    		// (AppBundle\Entity\UserProfile@0000000058af220a0000000079dc875a)
    		// has no identity/no id values set. It cannot be added to the identity map.
    	}
    
    	public function createProfile()
    	{
    		$this->profile = new UserProfile($this);
    	}	
    }
UserProfile.php
    
    use Doctrine\ORM\Mapping as ORM;
    
    /**
     * @ORM\Entity
     * @ORM\Table(name="profiles")
     */
    class UserProfile
    {
    	/**
    	 * – UserProfile's "uid" column points to User's "uid" column
    	 * – it is PK (primary key)
    	 * - it is FK (foreign key) as well
    	 * – "owning side"
    	 *
    	 * @var User
    	 *
    	 * @ORM\Id
    	 * @ORM\OneToOne(targetEntity="User", inversedBy="profile")
    	 * @ORM\JoinColumn(name="uid", referencedColumnName="uid", nullable=false)
    	*/
    	private $user;
        
    	public function __construct(User $user)
    	{
    		$this->user = $user;
    	}    
    }





[DDC-3383] [GH-1179] Fix embeddables class metadata (work-in-progress) Created: 10/Nov/14  Updated: 22/May/15

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/1179

Message:

ClassMetadataInfo is returning more than one result in getFieldNames() for the embeddables properties. This method is used by DoctrineModule\Stdlib\Hydrator\DoctrineObject in the extraction process.

Since its returning a number of results equal the number of properties of the embedded object, it will never find the correct setter for the extraction and that causes that property to be removed from the extracted array.

I was able to solve the issue by hacking into the getFieldNames() for testing and merging the duplicated entries, and then the object was successfully extracted.

By digging into the code, i found out that there is a mapEmbedded(), but instead of using that for embeddeds, its using the default mapField, which may be the root cause of the problem.

  • [x] Hack into the getFieldNames() method to see if the expected solution would work
  • [x] Remove multiple class declaration in the same file from the files i'll work with
  • [x] Create a failing testcase
  • [ ] Create a solution


 Comments   
Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 22/May/15 ]

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





[DDC-3742] Use UTCDatetimeType with lifecycle callbacks Created: 22/May/15  Updated: 22/May/15

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

Type: Bug Priority: Major
Reporter: pablo Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal, orm
Environment:

Fedora 20 x64 with Phalcon 2.0 and doctrine downloaded via composer:
"doctrine/orm": "2.*",
"doctrine/mongodb-odm": "dev-master",



 Description   

I'm trying to save my entities (yaml), which have lifecyclecallbacks with a createdAt and updatedAt UTCDatetimeType fields. If I save them with prePersist or preUpdate, the insert of new rows into the mysql database fails because of blank date fields, but they are already populated in my entity.

If I replace the UTCDateTimeType by datetime, it works.



 Comments   
Comment by pablo [ 22/May/15 ]

I'm using UTCDateTimeType from: http://doctrine-orm.readthedocs.org/en/latest/cookbook/working-with-datetime.html

It makes a $value->format($format, $timezone)

I was passing a \Datetime object, so format only has one parameter, not 2...Then, Or I'm passing an unexpected $value or the format method is not properly coded there.

So, I've modified convertToDatabaseValue to the following:

        if ($value === null) {
            return null;
        }

        if (is_null(self::$utc)) {
            self::$utc = new \DateTimeZone('UTC');
        }

        if (!($value instanceof \DateTime)) {
            $value = \DateTime::createFromFormat(
                $platform->getDateTimeFormatString(),
                $value,
                self::$utc
            );
        }

        $value->setTimeZone(self::$utc);

        $val = $value->format($platform->getDateTimeFormatString());

        return $val;
Comment by Marco Pivetta [ 22/May/15 ]

pablo what exactly is the action to be taken here? It's unclear to me.

Comment by pablo [ 22/May/15 ]

I replaced the metod convertToDatabaseValue from http://doctrine-orm.readthedocs.org/en/latest/cookbook/working-with-datetime.html with mine.

For example:

<code>
date_default_timezone_set('Europe/Madrid');
$expireAt = new \DateTime();
$entity = newEntity();
$entity->setExpireAt($expireAt);

$this->em->persist($entity);
$this->em->flush();
</code>

My expireAt field is UTCDateTimeType, so it will be converted from my Europe/Madrid timezone to UTC. But using the code from URL it doesn't works because ->format() method has 2 parameters instead of one.





[DDC-1078] Cannot select inverse side of many-to-many relationship with a many-to-many DQL query Created: 25/Mar/11  Updated: 21/May/15  Resolved: 25/Mar/11

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

Type: Bug Priority: Major
Reporter: Daniel Moore Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None


 Description   

I have two classes - Page and SiteVersion, which have a many to many relationship. Only SiteVersion is aware of the relationship (because the site is modular and I want to be able to take away and drop in the module that SiteVersion belongs to).

I do not seem to be able select pages based on criteria of SiteVersion.

Using this query on the cli tool:

SELECT p FROM SiteVersion v JOIN v.pages p WHERE v.id = 5 AND p.slug='index'

Gives me the error:

[Doctrine\ORM\Query\QueryException]
[Semantical Error] line 0, col -1 near 'SELECT p FROM': Error: Cannot select entity through identification variables without choosing at least one root entity alias.

Using the alternative join syntax does not work either:

SELECT p FROM SiteVersion v, Page p WHERE v.id = 5 AND p.slug='index' AND v.pages = p

Which gives me:

[Doctrine\ORM\Query\QueryException]
[Semantical Error] line 0, col 98 near 'pages = p': Error: Invalid PathExpression. StateFieldPathExpression or SingleValuedAssociationField expected.



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

This is not a bug, it is not supported as per the Exception Message is already telling you.

You have to have the entity in the FROM clause that you are SELECTing. Just reverse the condition and use the inverse side of bidirectional assocation to do the query.

Comment by Benjamin Eberlei [ 25/Mar/11 ]

Ah, just reading the association is just unidirectional. In this case the query you want to do is not possible. Speaking semantically, if you omit one direction of a query, then Doctirne does not allow you to query this way. Just about right.

Comment by Miguel Alvarez Rodriguez [ 21/May/15 ]

I have the exact same problem with a many to many bidirectional association.
This would be very easy to do with SQL.
Can't it be done with DQL?

---
BlogEntry:
  type: entity
  id:
    id:
      type: integer
      generator:
        strategy: AUTO
  fields:
    title:
      type: string
    body:
      type: text
    published:
      type: boolean
  manyToMany:
    tags:
      targetEntity: Tag
      inversedBy: blogEntry
...
---
Tag:
  type: entity
  id:
    id:
      type: integer
      generator:
        strategy: AUTO
  fields:
    name:
      type: string
  manyToMany:
    blogEntry:
      targetEntity: BlogEntry
      mappedBy: tags
...

There is a join table like:

CREATE TABLE blogentry_tag (blogentry_id INTEGER NOT NULL, tag_id INTEGER NOT NULL, PRIMARY KEY(blogentry_id, tag_id), CONSTRAINT FK_AAA8A8A2228815BC FOREIGN KEY (blogentry_id) REFERENCES BlogEntry (id) ON DELETE CASCADE NOT DEFERRABLE INITIALLY IMMEDIATE, CONSTRAINT FK_AAA8A8A2BAD26311 FOREIGN KEY (tag_id) REFERENCES Tag (id) ON DELETE CASCADE NOT DEFERRABLE INITIALLY IMMEDIATE);




[DDC-875] Merge can sometimes add the same entity twice into a collection Created: 11/Nov/10  Updated: 19/May/15  Resolved: 11/Mar/12

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

Type: Bug Priority: Major
Reporter: Dave Keen Assignee: Roman S. Borschel
Resolution: Cannot Reproduce Votes: 1
Labels: None

Attachments: File multipleaddmerge.diff     File multipleaddmerge2.diff    

 Description   

When merging some cascade merge object-graphs, the same entity in a ManyToMany association can be put into a collection twice during doMerge.

The attached patch should stop this from happening.



 Comments   
Comment by Benjamin Eberlei [ 15/Nov/10 ]

which conditions lead to this problem? I want to write a test for it

Comment by Benjamin Eberlei [ 15/Nov/10 ]

not doint the unwrap() but add() directly was a bugfix for one of your other issues .Why is unwrap in here again?

Comment by Dave Keen [ 20/Dec/10 ]

Oops - that was a mistake. I have attached multipleaddmerge2.diff which no longer uses unwrap to add the element.

Comment by Benjamin Eberlei [ 27/Dec/10 ]

That is exactly the same code in the patch, the lines are just formatted differently.

Comment by Dave Keen [ 06/Jan/11 ]

Sorry, I am still getting the hang of git and diff and maybe what I put in there isn't what I meant to. I have now pushed the code to the DDC-875 branch on my ccapndave/doctrine2 fork on GitHub, hopefully this works better.

As far as I can tell I am using unwrap() in order to check whether the element already exists in the array, but then calling >add() directly on the PersistentCollection rather than the ArrayCollection, triggering $this>changed().

Comment by Benjamin Eberlei [ 26/Feb/11 ]

It seems even this issue is caused by multiple calls to persist. I cannot reproduce this with just a single bidirectional cascade merge.

Comment by Alexander [ 11/Mar/12 ]

We cannot reproduce this error and haven't had similar complaints ever-since. Feel free to open a new issue with a failing testcase.

Comment by Vivek Soni [ 19/May/15 ]

I am also facing this issue, I have String as primary key for a table (brand table) getting this error

A new entity was found through the relationship 'Application\Entity\Pcds#brandCode' that was not configured to cascade persist operations for entity: Company\Model\Entity\Brand@000000003beb6d2200007ffa52ab9a34. To solve this issue: Either explicitly call EntityManager#persist() on this unknown entity or configure cascade persist this association in the mapping for example @ManyToOne(..,cascade=

{"persist"}

). If you cannot find out which entity causes the problem implement 'Company\Model\Entity\Brand#__toString()' to get a clue.

If i var_dump this $brand entity it shows that it have primary key inside it.

Comment by Vivek Soni [ 19/May/15 ]

This stackoverflow question solved my problem, instead of persist, i had to do merge

http://stackoverflow.com/questions/18215975/doctrine-a-new-entity-was-found-through-the-relationship





[DDC-3740] \Doctrine\ORM\LazyCriteriaCollection::count() returns "0" instead of 0 Created: 16/May/15  Updated: 16/May/15

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


 Description   

Getting the count of a LazyCriteriaCollection results in numerical string instead of integer.






[DDC-3739] [GH-1410] Skip generate lifecycle methods if they already generated Created: 15/May/15  Updated: 15/May/15

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 aivus:

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

Message:

This happens when I use one lifecycle method in prePersist and preUpdate together. Like
```yml
lifecycleCallbacks:
prePersist: [setCreatedAtValue, setUpdatedAtValue]
preUpdate: [setUpdatedAtValue]
```

Before generator generate two methods with the same names.

@Ocramius, what do you think what is better way to write test for this?
Should I test generateEntityLifecycleCallbackMethods directly?






[DDC-3737] [GH-1408] [doc] Remove unused variable from sample code Created: 14/May/15  Updated: 14/May/15

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 baileylo:

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

Message:

Removes lexer since it's not used.






[DDC-3736] Support for Objects as Identifiers with Strategy AUTO Created: 14/May/15  Updated: 14/May/15

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

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


 Description   

According to the official documentation (http://doctrine-orm.readthedocs.org/en/latest/changelog/migration_2_5.html#support-for-objects-as-identifiers) using objects as Identifiers work .

The issue is that if in the mapping settings generator strategy is set to AUTO, the BasicEntityPersister won't hydrate the id to an Object , but keep it as a scalar.

\\Doctrine\ORM\Persisters\Entity::executeInserts() , line 257
$generatedId = $idGenerator->generate($this->em, $entity);
$id = array(
    $this->class->identifier[0] => $generatedId
);
$postInsertIds[] = array(
    'generatedId' => $generatedId,
    'entity' => $entity,
);

This could be tracked down to the IdGenerator :

\\Doctrine\ORM\Id\IdentityGenerator::generate() , line 53
public function generate(
        EntityManager $em, $entity)
    {
        return (int)$em->getConnection()->lastInsertId($this->sequenceName);
    }


 Comments   
Comment by Andrei Mocanu [ 14/May/15 ]

Workaround:

id:
        id:
            type: UserId
            column: id
            generator:
                strategy: CUSTOM
            customIdGenerator:
                class: MyApp\ORM\Id\ObjectIdentityGenerator

Create a ObjectIdentityGenerator that extends AbstractIdGenerator and implement generate:

public function generate(
        EntityManager $em, $entity)
    {
        $entityClass = get_class($entity);
        $idFieldName = $em->getClassMetadata($entityClass)->getSingleIdentifierColumnName();
        $reflection = new ReflectionClass($entityClass);
        $params = $reflection->getConstructor()->getParameters();
        foreach ($params AS $param) {
            if ($param->getName() === $idFieldName && $idClass = $param->getClass()) {
                return new $idClass->name((int) $em->getConnection()->lastInsertId($this->sequenceName));
            }
        }
        return (int)$em->getConnection()->lastInsertId($this->sequenceName);
    }




[DDC-3735] Problem with Collate Created: 13/May/15  Updated: 13/May/15

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

Type: Bug Priority: Major
Reporter: Hugo Henrique Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: dbal, mapping, mysql, schematool
Environment:

development



 Description   

I'm using Migrations and always when a new version changes in my schema in action `up` SQL removes the definition of the table COLLATE for example:

Version20150513194922.php
public function up(Schema $schema)
{
    $this->addSql('ALTER TABLE customer CHANGE user_id user_id CHAR(36) DEFAULT NULL COMMENT \'(DC2Type: guid)\'');
}

public function down(Schema $schema)
{
    $this->addSql('ALTER TABLE customer CHANGE user_id user_id CHAR(36) NULL DEFAULT COLLATE utf8_unicode_ci COMMENT \'(DC2Type: guid)\'');
}
User.php
/**
 * @ORM\Table(name="user")
 * @ORM\HasLifecycleCallbacks
 */
class User
{
    /**
     * @ORM\Id
     * @ORM\Column(type="guid", options={"unsigned"=true})
     * @ORM\GeneratedValue(strategy="UUID")
     */
    protected $id;

Customer.php
/**
 * @ORM\Entity
 * @ORM\Table(name="customer")
 */
class Customer
{
    /**
     * @ORM\Id
     * @ORM\Column(type="bigint", options={"unsigned"=true})
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;

    /**
     * @ORM\OneToOne(targetEntity="User")
     * @ORM\JoinColumn(name="user_id", referencedColumnName="id")
     */
    protected $user;

schema.sql
CREATE TABLE `user` (
  `id` varchar(255) COLLATE utf8_unicode_ci NOT NULL COMMENT '(DC2Type:guid)',
  `name` varchar(60) COLLATE utf8_unicode_ci NOT NULL,
  `username` varchar(40) COLLATE utf8_unicode_ci DEFAULT NULL,
  `username_canonical` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `email` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  `email_canonical` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  `password` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  `salt` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
PRIMARY KEY (`id`),
  UNIQUE KEY `UNIQ_8D93D649E7927C74` (`email`),
  UNIQUE KEY `UNIQ_8D93D649F85E0677` (`username`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

CREATE TABLE `customer` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `user_id` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL COMMENT '(DC2Type:guid)',
  `gender` varchar(1) COLLATE utf8_unicode_ci DEFAULT NULL,
  `zipcode` varchar(10) COLLATE utf8_unicode_ci DEFAULT NULL,
  `birthday` date DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `UNIQ_705B3727A76ED395` (`user_id`),
  CONSTRAINT `FK_705B3727A76ED395` FOREIGN KEY (`user_id`) REFERENCES `user` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;





[DDC-3120] Warning: Erroneous data format for unserializing PHP5.6+ Created: 11/May/14  Updated: 13/May/15  Resolved: 27/Aug/14

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

Type: Bug Priority: Critical
Reporter: Cornelis Brouwers Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: mapping, orm
Environment:

Webserver Apache/2.4.7 (Win32) OpenSSL/1.0.1e PHP/5.6.0beta2

and

PHP-CLI (Win32) PHP/5.6.0beta2


Issue Links:
Duplicate
is duplicated by DDC-3252 [GH-1109] DDC-3120 - PHP 5.6-RC3 comp... Resolved
Reference
is referenced by DDC-3156 [GH-1050] DDC-3120 -- Catch Reflectio... Resolved
is referenced by DDC-3339 [GH-1154] Hotfix/php 5.6 serializatio... Resolved

 Description   

Hi all,

There seems to be something strange going on in the method newInstance() of the class \Doctrine\ORM\Mapping\ClassMetadataInfo.

The original class method looks like this:

\Doctrine\ORM\Mapping\ClassMetadataInfo#newInstance()

    {
        if ($this->_prototype === null) {
            $this->_prototype = unserialize(sprintf('O:%d:"%s":0:{}', strlen($this->name), $this->name));
        }

        return clone $this->_prototype;
    }

What happens now when a class that implements \Serializable is that a "Warning: Erroneous data format for unserializing" shows up and the function unserialize() returns false.

That is because a class that implements \Serializable is expected to have the letter 'C' in the serialize string instead of the letter 'O'.

I've made a quick work-around like this:

\Doctrine\ORM\Mapping\ClassMetadataInfo#newInstance()

    {
        if ($this->_prototype === null) {
            $this->_prototype = @unserialize(sprintf('O:%d:"%s":0:{}', strlen($this->name), $this->name));
            if ($this->_prototype === false) {
                $this->_prototype = unserialize(sprintf('C:%d:"%s":0:{}', strlen($this->name), $this->name));
            }
        }

        return clone $this->_prototype;
    }

That seems to work in my isolated tests and with Symfony2 and Doctrine2 and FOSUserBundle together.

I've noticed this because the Model\User class from FOSUserBundle implements \Serializable.

I had to implement a check in Model\User class because when using 'C:%d:"%s":0:{}' the $serialized parameter of the unserialize method in the Model\User class is a empty string then.

That warning seems only to happen with PHP5.6+. PHP5.5.12 and below doesn't show that warning.

I hope someone can shine some light on this, thank you,

Cornelis.



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

Indeed, for PHP 5.4+ we should use

ReflectionClass#newInstanceWithoutConstructor()
Comment by Cornelis Brouwers [ 11/May/14 ]

Just tested it. That works as expected, far more better then the dirty hacks I did, thanks a lot!

Any idea when this would be implemented into the code?

Comment by Marco Pivetta [ 11/May/14 ]

Send a pull request and I'll merge it later today (we could also need a failing test with an entity implementing the Serializable interface)

Comment by Evert Harmeling [ 30/May/14 ]

Seems to be a problem in the latest PHP 5.4 version too.

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

Comment by Doctrine Bot [ 30/May/14 ]

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

Comment by Julian Reyes Escrigas [ 02/Jun/14 ]

I am facing this same error i have PHP 5.5.13, I'm using Symfony, Doctrine ORM and FOSUserBUndle

Comment by Marco Pivetta [ 02/Jun/14 ]

Julian Reyes Escrigas the patch landed in master (2.5.x) for now.

Comment by Marco Pivetta [ 02/Jun/14 ]

Merged via DDC-3147

Comment by Thomas Buhk [ 04/Jun/14 ]

When can we expect the version with this bugfix?

Comment by Anthony Rey [ 08/Jun/14 ]

Why don't you tag 2.4.3 version with this fix ? Because the error is already present in PHP 5.5.13 which is a stable version and it's a blocking issue when you're using FOSUserBundle for example. There is also no opened issue refering this version and the due date is in april.

Comment by Jovan Perovic [ 19/Jun/14 ]

I'm still seeing this bug, although my PHP_VERSION_ID is 50600

So, version based condition is no good...

Comment by Marco Pivetta [ 19/Jun/14 ]

The approach to be taken for 50600 is still under discussion in php-internals.

Comment by Cornelis Brouwers [ 20/Jun/14 ]

Hi all,

I've just downloaded PHP5.6RC1 and updated doctrine and the error is back indeed.

A little peek at the code starting on line 866 of file Doctrine\ORM\Mapping\ClassMetadataInfo.php shows this:

    public function newInstance()
    {
        if ($this->_prototype === null) {
            if (PHP_VERSION_ID === 50429 || PHP_VERSION_ID === 50513) {
                $this->_prototype = $this->reflClass->newInstanceWithoutConstructor();
            } else {
                $this->_prototype = unserialize(sprintf('O:%d:"%s":0:{}', strlen($this->name), $this->name));
            }
        }

        return clone $this->_prototype;
    }

As can be seen, PHP5.6 is out of the picture, it only checks for the exact versions 5.4.29 and 5.5.13.

So for the code to work correctly on PHP5.6 one can add PHP5.6 to the test condition, or just skip the test all together if you don't mind the old PHP5.3. According to PHP, ReflectionClass::newInstanceWithoutConstructor is available since PHP >= 5.4.0.

Greetings, Cornelis.

Comment by Marco Pivetta [ 21/Jun/14 ]

As I already pointed out, this is still being discussed in php internals. See http://news.php.net/php.internals/75009

This won't be dealt with in 5.6 until there's either a stable release or internals decides what has to be done.

Comment by Marco Pivetta [ 21/Jun/14 ]

Also, ReflectionClass#newInstanceWithoutConstructor() still doesn't cover the pre-existing "hack" using unserialize, so we're still waiting for a reliable API from PHP core.

Comment by Chase Noel [ 23/Jul/14 ]

Using PHP 5.6RC2 and ORM 2.4.4 I am still experiencing this issue. I have also tested with PHP 5.5.15 and I am still getting the issue. Do i need to be using a different build of ORM to have the fix applied?

Comment by pascall [ 23/Jul/14 ]

Hi,
I'm using 5.6.0beta3 and ORM 2.4.4 and i have the same probleme
Warning: Erroneous data format for unserializing .. in orm/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php line 872

and in current code in ClassMetadataInfo.php line 872 is :

public function newInstance()
{
if ($this->_prototype === null) {
if (PHP_VERSION_ID === 50429 || PHP_VERSION_ID === 50513)

{ $this->_prototype = $this->reflClass->newInstanceWithoutConstructor(); }

else {
$this->_prototype = unserialize(sprintf('O:%d:"%s":0:{}', strlen($this->name), $this->name));
}
}

return clone $this->_prototype;
}

Comment by Evert Harmeling [ 23/Jul/14 ]

As stated by Marco Pivetta; "This won't be dealt with in 5.6 until there's either a stable release or internals decides what has to be done.". And besides that 5.6 still is in development, not stable.
If you still want to use 5.6 you can fork the code and extend the 5.4 / 5.5 check to support 5.6.

Comment by Chase Noel [ 23/Jul/14 ]

5.6 has an RC which should mean a stable API, and that only bugs will be fixed before an official stable release?

Comment by Evert Harmeling [ 23/Jul/14 ]

Looking at http://news.php.net/php.internals/75966 it's still being discussed, and they are planning to have it fixed in RC3.

Comment by Marco Pivetta [ 23/Jul/14 ]

Internals still didn't get to a clear decision. Until then, we won't support 5.6 officially.

Comment by Ronan [ 24/Jul/14 ]

Same error encountered with PHP 5.5.13 (cli) (built: May 30 2014 10:43:29)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies
with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2014, by Zend Technologies
with Xdebug v2.2.3, Copyright (c) 2002-2013, by Derick Rethans

(PHP 5.5 installed via http://php-osx.liip.ch/)

Comment by Marco Pivetta [ 24/Jul/14 ]

Ronan what D2 version? We fixed it for 2.4.x (temporarily)

Comment by Ronan [ 24/Jul/14 ]

My bad: reading my composer.lock: doctrine/orm, v2.4.2, ref 0363a5548d9263f979f9ca149decb9cfc66419ab, "time": "2014-02-08 16:35:09"... Well.. this is was an old one !

`composer update` fixed it. Sorry for disturbing.

Comment by Chase Noel [ 12/Aug/14 ]

Im still getting this error running php 5.6RC2 and the dev-master(6ac19b04bfbd7a97aad5ed8c2abd6279ff5e0022) build of D2/orm. Am i missing something?

Comment by Marco Pivetta [ 12/Aug/14 ]

This was semi-fixed in PHP5.6-RC3, and it will be patched into ORM once doctrine/instantiator is out

Comment by Chase Noel [ 12/Aug/14 ]

Ok good to know. Thanks

Comment by Marco Pivetta [ 13/Aug/14 ]

Not yet fixed for PHP 5.6

Comment by Marco Pivetta [ 14/Aug/14 ]

Provided a hotfix proposal at https://github.com/doctrine/doctrine2/pull/1109 - please check it out with PHP 5.6.0-RC3 or later

Comment by Doctrine Bot [ 27/Aug/14 ]

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

Comment by Marco Pivetta [ 27/Aug/14 ]

Due to a new introduced dependency, this issue will only be solved for PHP 5.6 in 2.5.0 and later.

Comment by Doctrine Bot [ 28/Aug/14 ]

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

Comment by Dominik Zogg [ 10/Sep/14 ]

@ocramius would be great if there where backports for 2.4 and 2.3

Comment by Attila Bukor [ 28/Sep/14 ]

I agree with Dominik, we'd like to use the latest stable version and would need this patch.

Comment by Marco Pivetta [ 06/Oct/14 ]

This has been backported in DDC-3339

Comment by sysko [ 13/May/15 ]

I still have this error even 2.5.0+ and PHP5.6+
https://travis-ci.org/allan-simon/oauth2-symfony2-vagrant-fosuserbundle/jobs/62429219





[DDC-3662] "Improve efficiency of One-To-Many EAGER" still do 2 db request when Criteria::$firstResult set Created: 04/Apr/15  Updated: 13/May/15

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

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


 Description   

In Doctrine 2.5 when I have entity with association One-To-Many and fetch="EAGER", doctrine still do 2 db request , when use Criteria with Criteria::$firstResult and Criteria::$maxResults

last time I tested on Doctrine 2.5 RC 1, and there this have work perfect: doctrine have use JOIN to load association.

I think it get broken between 2.5 rc1 and 2.5

for load the items I use

$criteria->setFirstResult(0);// this and next, cause 2 request per item
$criteria->setMaxResults(10);
$items = $repositiry->matching($criteria);


 Comments   
Comment by Marco Pivetta [ 04/Apr/15 ]

Fedir Zinchuk could you come up with an example?

This looks like logic that goes through the paginator, if I'm not mistaken...

Comment by Fedir Zinchuk [ 05/Apr/15 ]

Example you have entities: Gallery and Image,
where Gallery have field 'images' that is bidirectional association One-To-Many and fetch="EAGER" with Image,
and you load the galleries using matching($criteria), then:

This code will do 1 db request for load Galleries list + 1 db request for each Gallery item, to load its Images

$repositiry = $em->getRepository('Gallery');
$criteria  = Criteria::create();
$criteria->where(Criteria::expr()->eq("published", 1));
$criteria->setFirstResult(0);
$criteria->setMaxResults(20);

$galleries = $repositiry->matching($criteria);

This code will do 1 db request for load All: Galleries and its Images

$repositiry = $em->getRepository('Gallery');
$criteria  = Criteria::create();
$criteria->where(Criteria::expr()->eq("published", 1));

$galleries = $repositiry->matching($criteria);

I use setFirstResult() and setMaxResults() because I use external pagination not from Doctrine.

After small investigation, I found that it because $this->currentPersisterContext->handlesLimits there https://github.com/doctrine/doctrine2/blob/e57be9da5e0c6bb31ac286d213e204784a34aa43/lib/Doctrine/ORM/Persisters/Entity/BasicEntityPersister.php#L1221

Comment by Fedir Zinchuk [ 13/May/15 ]

seems this issue introduced in that commit https://github.com/doctrine/doctrine2/commit/a37fa97be35e446a84d43c7790d54e2a13e5570b

after I remove

if ((($assoc['type'] & ClassMetadata::TO_MANY) > 0) && $this->currentPersisterContext->handlesLimits) {
      continue;
}

I get 1 DB request, but I not sure which impact it could on other cases :/





[DDC-3734] [GH-1407] Add return to removeMethodTemplate Created: 13/May/15  Updated: 13/May/15

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 aivus:

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

Message:






[DDC-3732] Entity with string @id can't be fetches Created: 10/May/15  Updated: 11/May/15  Resolved: 10/May/15

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

Type: Bug Priority: Blocker
Reporter: Peter Zwegat Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: mysql, orm
Environment:

MySQL



 Description   

I defined an entity id field with the annotation:

@ORM\Id
@ORM\Column(type="string", length=2)

It's not possible to fetch the entity neither with ->find() nor manually with a query builder (quoted etc., tried everything).

$qb->where('l.id = ?1');
$qb->setParameters([
1 => $this->getEntityManager()->getConnection()->quote($id)
]);

This return just null even if the entity with the given id exists.

When I not quote the passed id value it, I become this error:

Doctrine\ORM\Query\QueryException: [Semantical Error] line 0, col 121 near 'fi': Error: 'fi' is not defined. (/..../vendor/doctrine/orm/lib/Doctrine/ORM/Query/QueryException.php: 63)

'fi' ist just the country identifier here that is the entity id.



 Comments   
Comment by Marco Pivetta [ 10/May/15 ]

Quoting parameters explicit is not necessary.

Also, quoting parameters is not needed in DQL, as DQL is translated by looking at mappings anyway.

Comment by Peter Zwegat [ 10/May/15 ]

Yeah I only quoted the id for test purposes.
I go a step back:
->find('de') throws the exception that I posted in the issue.

String Id's are possible normally not?

Comment by Marco Pivetta [ 10/May/15 ]

Peter Zwegat yes, it is allowed, but what exception are you getting?

Comment by Peter Zwegat [ 11/May/15 ]

This one when I try to find an entity by it's id:

Doctrine\ORM\Query\QueryException: [Semantical Error] line 0, col 121 near 'fi': Error: 'fi' is not defined. (/..../vendor/doctrine/orm/lib/Doctrine/ORM/Query/QueryException.php: 63)

'fi' is here the key. Just used the ->find method.

Comment by Marco Pivetta [ 11/May/15 ]

Please show some actual code in a gist - I'm doing guesswork here :-P





[DDC-3731] [GH-1405] EntityManager#getReference throw ORMException for unrecognized id Created: 09/May/15  Updated: 09/May/15

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 taueres:

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

Message:

  • Unreachable statements have been removed
  • Throw ORMException for unrecognized identifier field (same
    behavior as EntityManager#find)


 Comments   
Comment by Doctrine Bot [ 09/May/15 ]

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

Comment by Doctrine Bot [ 09/May/15 ]

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





[DDC-3730] Embeddable hydrates to object instead of null Created: 08/May/15  Updated: 08/May/15

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

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


 Description   

Good afternoon,

When hydrating an Embeddable with nullable attributes the result is an instance of the Embeddable class , this is obviously correct and expected behavior.

If all the attributes are null the hydrator will still return an instance of the class with all of its properties null , even if I persist and flush my Entity with the Embeddable being set as null .

For clarification :


class MyEntity
{
    protected $myEmbeddable;

    public function setMyEmbeddable(MyEmbeddable $myEmbeddable = null)
    {
        $this->myEmbeddable = $myEmbeddable;
    }
    [...]
}

$newEntity = new MyEntity();
$newEntity->setMyEmbeddable(null);

$em->persist($newEntity);
$em->flsuh($newEntity);

Calling $newEntity->getMyEmbeddable() will return an instance of the MyEmbeddable object with all of it's attributes set to null .

I expected $newEntity->getMyEmbeddable() to be NULL .

Can someone clarify is this is expected behaviour ? In case it is , how can I achieve what I'm looking for ?

Best regards






[DDC-3728] [GH-1403] Typo in PHPDoc Created: 07/May/15  Updated: 07/May/15  Resolved: 07/May/15

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

Type: Documentation Priority: Trivial
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: docblock, entitymanager, phpdoc, typo


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 07/May/15 ]

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





[DDC-3729] [GH-1404] Fix PHPDoc typo Created: 07/May/15  Updated: 07/May/15  Resolved: 07/May/15

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

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


 Description   

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

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

Message:

Title says all.



 Comments   
Comment by Doctrine Bot [ 07/May/15 ]

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





[DDC-2531] ManyToManyPersister does not take Custom Types into account Created: 26/Jun/13  Updated: 07/May/15

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

Type: Bug Priority: Major
Reporter: George van Vliet Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 2
Labels: None


 Description   

When two entities, both using a custom type for the "@Id" column, have a "@ManyToMany" (bidirectional) relationship, the ManyToManyPersister does not take into account the custom type of the referenced id columns and therefore does not convert the values using the appropriate "convertToDatabaseValue" function.

The entities themselves are saved propery, but the insertion into the join table always fails.



 Comments   
Comment by Ben Getsug [ 07/May/15 ]

My scenario:

  • EntityA uses a custom type for its @Id column (specifically so I can store UUIDs in a binary column...see DDC-3721)
  • EntityA has a (unidirectional) many-to-many association with EntityB, and the usual ArrayCollection initialization on the property
  • I clear the entire collection by calling ArrayCollection::clear()
  • I call EntityManager::flush()
  • No errors occur, but no rows actually get deleted from the database.

Through debugging, I found that ManyToManyPersister::getDeleteSQL() does not handle custom types like ManyToManyPersister::getDeleteRowSQL() or ManyToManyPersister::removeElement(). So the proper SQL DELETE statement doesn't get executed.

My current workaround is to loop through my collection of EntityB, calling ArrayCollection::removeElement() with each entity. Given the complexity of ManyToManyPersister, I'm a bit leery of attempting a fix and submitting a PR, but at least wanted to document my issue here.





[DDC-3726] [GH-1401] Remove HHVM-nightly builds Created: 05/May/15  Updated: 06/May/15  Resolved: 05/May/15

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: build-speed, ci, hhvm, hhvm-nightly, travis

Issue Links:
Reference
is referenced by DBAL-1226 [GH-853] Remove HHVM-nightly builds Resolved

 Description   

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

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

Message:

hhvm-nightly is not available anymore on Travis because HHVM dropped support for Ubuntu Precise, which is still used by Travis.

This avoids creating useless jobs in the matrix which are killed by Travis from the start.



 Comments   
Comment by Doctrine Bot [ 05/May/15 ]

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

Comment by Doctrine Bot [ 05/May/15 ]

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

Comment by Doctrine Bot [ 05/May/15 ]

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





[DDC-3220] Association mappings of embedded class not loaded into entity classMetadata Created: 21/Jul/14  Updated: 06/May/15

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

Type: Bug Priority: Major
Reporter: Anatolie Marinescu Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: embeddables


 Description   

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






[DDC-3727] [GH-1402] AbstractCommand: use name of helper, do not require alias Created: 05/May/15  Updated: 05/May/15

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 TomasVotruba:

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

Message:

Name for the helper is "entityManager", see https://github.com/doctrine/doctrine2/blob/330f88e44ba0e5e6f932a92ae63b64cdd5cdc046/lib/Doctrine/ORM/Tools/Console/Helper/EntityManagerHelper.php#L70

Using "em" forces creating an alias.

Seems like some forgotten name change.






[DDC-3725] [GH-1400] pgsql and mysqli are supported by HHVM Created: 04/May/15  Updated: 04/May/15

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 photodude:

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

Message:






[DDC-3724] Resolve target entity also in discriminator map: does not work with non-alphabetical order Created: 04/May/15  Updated: 04/May/15

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

Type: Bug Priority: Minor
Reporter: Alan Poulain Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Using a discriminator map and interfaces lead to an exception when there are not in alphabetical order.
For example,

/**
 * @ORM\DiscriminatorMap({
 *     "a" = "AEntityInterface",
 *     "b" = "BEntityInterface"
 * })
 */

is working but,

/**
 * @ORM\DiscriminatorMap({
 *     "b" = "BEntityInterface",
 *     "a" = "AEntityInterface"
 * })
 */

lead to:

[Doctrine\Common\Persistence\Mapping\MappingException]
Class 'BEntityInterface' does not exist






[DDC-3719] Criteria won't work on non-owning side of many to many collection Created: 29/Apr/15  Updated: 03/May/15

Status: Open
Project: Doctrine 2 - ORM
Component/s: Lazy Loading, ORM
Affects Version/s: Git Master
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Logan Bailey Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 1
Labels: many-to-many, orm

Issue Links:
Reference
is referenced by DDC-3723 [GH-1399] Fix for DDC-3719. Open

 Description   

I received the following error when trying to call matching on a ManyToMany relationship from the non-owning side.

ErrorException in ManyToManyPersister.php line 234: Undefined index: relationToSourceKeyColumns

ManyToManyPersister::loadCriteria relies on the relationToSourceKeyColumns data from the mapping data. This value is set in ClassMetadataInfo::_validateAndCompleteManyToManyMapping, but it's only set on the owning side of the relationship.






[DDC-3723] [GH-1399] Fix for DDC-3719. Created: 03/May/15  Updated: 03/May/15

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-3719 Criteria won't work on non-owning sid... Open

 Description   

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

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

Message:

Switch to relationToTargetKeyColumns when matching non-owning side with Criteria. Fixes DDC-3719.






[DDC-3722] XmlExporter driver ignore entityListeners Created: 03/May/15  Updated: 03/May/15

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

Type: Bug Priority: Major
Reporter: Fedir Zinchuk Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: entityListeners, export, orm


 Description   

<entity-listeners> missed in XML export result, when export the entity mapping with entityListeners

And after quick look in the code, seems other drivers also ignore it






[DDC-3721] [GH-1398] When using a custom data type, SchemaTool does not pass column length field mapping to relation join columns Created: 29/Apr/15  Updated: 30/Apr/15

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

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


 Description   

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

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

Message:

We have a custom data type for storing UUIDs in a BINARY column in MySQL:

class UuidType extends Type
{
    const UUID = 'uuid';


    /**
     * @inheritdoc
     */
    public function getSqlDeclaration(array $fieldDeclaration, AbstractPlatform $platform)
    {
        return $platform->getBinaryTypeDeclarationSQL($fieldDeclaration);
    }


    /**
     * @inheritdoc
     */
    public function getName()
    {
        return self::UUID;
    }


    /**
     * @inheritdoc
     */
    public function convertToPhpValue($value, AbstractPlatform $platform)
    {
        if ($value !== null) {
            return strtoupper(bin2hex($value));
        }
    }


    /**
     * @inheritdoc
     */
    public function convertToDatabaseValue($value, AbstractPlatform $platform)
    {
        if ($value !== null) {
            // If the app put any dashes in, we strip them, just in case
            return hex2bin(str_replace('-', '',$value));
        }
    }

    
    /**
     * @inheritdoc
     */
    public function requiresSQLCommentHint(AbstractPlatform $platform)
    {
        return true;
    }
    

    /**
     * Generate a UUID that is optimized for MySQL's InnoDB engine
     * Based on UUID1, but transposed for more optimal inserts and sized for binary(16) column
     *
     * @return string MySQL-optimized UUID that works well with UUID column type
     */
    public static function generateUuid()
    {
        $uuid = Uuid::uuid1()->toString();

        $uuidFormattedForMySQL = self::transposeUuid($uuid);

        return $uuidFormattedForMySQL;
    }


    /**
     * Optimize format of UUID for storing as binary in MySQL
     *
     * @param $uuid
     *
     * @return string
     *
     * @see http://www.percona.com/blog/2014/12/19/store-uuid-optimized-way/
     */
    public static function transposeUuid($uuid)
    {
        /*
         * orig UUID1: 13341cb5-c1f8-11e4-91e7-080027880ca6
         * transpose:  11e4-c1f8-13341cb5-91e7-080027880ca6
         * format:     11E4C1F813341CB591E7080027880CA6  <-- this is what can be ideally stored as binary in MySQL
         */
        $uuidOptimizedOrderForMySQL = substr($uuid, 14, 4) . substr($uuid, 9, 4) . substr($uuid, 0, 8) . substr(
                $uuid,
                19,
                17
            );
        $uuidFormattedForMySQL = strtoupper(str_replace('-', '', $uuidOptimizedOrderForMySQL));

        return $uuidFormattedForMySQL;
    }

...and the following related (example) entities:

/**
 * @Entity
 */
class Thing 
{
    /**
     * @Id
     * @var string UUID
     * @Column(type="uuid", length=16)
     * @GeneratedValue(strategy="CUSTOM")
     * @CustomIdGenerator(class="Fisdap\Doctrine\Extensions\IdGenerator\UuidGenerator")
     */
    protected $id;

   /**
     * @OneToOne(targetEntity="OtherThing", mappedBy="thing")
     */
    protected $otherThing;
}

/**
 * @Entity
 */
class OtherThing 
{
        /**
	 * @Id
	 * @Column(type="integer")
	 * @GeneratedValue
	 */
	protected $id;

       /**
	 * @OneToOne(targetEntity="Thing", inversedBy="otherThing")
	 */
	protected $thing;
}

In our case, since SchemaTool::gatherRelationJoinColumns() doesn't copy $fieldMapping['length'] to $columnOptions['length'] for non-string / custom data types, the resulting CREATE TABLE SQL for the OtherThing entity will have a column definition for its association with Thing as thing_id BINARY(0). Of course, MySQL/InnoDB will be unable to create the index for a column with zero length, and multiple exceptions are thrown.

I believe the fix here is to simply check whether $fieldMapping['length'] is set, regardless of the value of $fieldMapping['type']. For good measure, I did the same for $fieldMapping['scale'] and $fieldMapping['precision'].






[DDC-3718] Inifinite schema diff when using decimal with options unsigned Created: 29/Apr/15  Updated: 29/Apr/15

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

Type: Bug Priority: Major
Reporter: Khang Minh Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mysql, orm, schematool
Environment:

Php 5.6.7 (cli)
MariaDB 10.0.17
Symfony 2.6.1



 Description   

When using a mapping similar to:

        field_name:
            type: decimal
            scale: 2
            options:
                unsigned: true

I keep getting this when issuing app/console doctrine:schema:update --dump-sql (symfony console):

ALTER TABLE table_name CHANGE field_name field_name NUMERIC(10, 2) NOT NULL;

could be related to: http://www.doctrine-project.org/jira/browse/DC-752






[DDC-3717] [GH-1397] Add Expr::concat support for multiple arguments Created: 28/Apr/15  Updated: 28/Apr/15

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

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


 Description   

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

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

Message:

DQL CONCAT function support variable number of arguments (2+) since version `2.4.0`.

The `Expr` class, on the other hand, is still limited to 2 arguments, and require multiple call to achive a similar result (see [this SO question](http://stackoverflow.com/questions/22169324/concat-three-or-more-fields-in-doctrine/29913780)). I've improved `Expr` implementation to support variable number of arguments in a backward compatible way.

Please, consider backporting to `2.4` branch if you plan to release other versions, since `2.5` introduce many features and may not be possible to easily upgrade. I may be wrong, though.






[DDC-3716] [GH-1396] [Documentation] Initializing embeddables doc Created: 27/Apr/15  Updated: 27/Apr/15

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

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


 Description   

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

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

Message:






[DDC-3697] WHERE conditions can get moved into JOIN conditions with JOINed Inheritance and non-association-JOINs Created: 17/Apr/15  Updated: 27/Apr/15

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

Type: Bug Priority: Major
Reporter: Malte Wunsch Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: dql, orm


 Description   

With the following entities:

/**
 * @ORM\Entity()
 * @ORM\InheritanceType("JOINED")
 * @ORM\DiscriminatorColumn(name="discriminaor", type="integer")
 * @ORM\DiscriminatorMap({"1" = "GeneralEntity", "2" = "SpecializedEntity"})
 */
class GeneralEntity {
    /**
     * @ORM\Id
     * @ORM\GeneratedValue
     * @ORM\Column(type="integer")
     */
    protected $id;
}

/**
 * @ORM\Entity()
 */
class SpecializedEntity extends GeneralEntity {
}

you can create a DQL query (note we're JOINing freely here without traversing a defined association) like

SELECT g1.id
FROM GeneralEntity g1
JOIN GeneralEntity g2
WHERE g2.id = 1

This gets converted to the following SQL:

SELECT g0_.id AS id0
FROM GeneralEntity g0_
LEFT JOIN SpecializedEntity s1_ ON g0_.id = s1_.id
INNER JOIN GeneralEntity g2_
LEFT JOIN SpecializedEntity s3_ ON g2_.id = s3_.id AND (g2_.id = 1)

As you can see, the condition in the WHERE part (g2.id = 1) is no longer in a WHERE clause by it's own, but got moved to the LEFT JOIN of the table inheritance. In this simple special case it probably makes no difference, but in general it does and leads to wrong results.



 Comments   
Comment by Matthias Pigulla [ 27/Apr/15 ]

Here's my attempt at fixing it: https://github.com/doctrine/doctrine2/pull/1395.

Depending on what the WHERE condition looks like, instead of just selecting a small fraction of rows from the root table you may end up selecting all rows plus a mostly useless LEFT JOIN result.





[DDC-3715] [GH-1395] Fix for DDC-3697 Created: 26/Apr/15  Updated: 26/Apr/15

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 mpdude:

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

Message:

Also fix Lexer::match() so it does not accept T_WHERE when T_WITH is supposed to be matched. (DDC-3701)






[DDC-3714] [GH-1394] Fix result cache setting query caching Created: 24/Apr/15  Updated: 24/Apr/15

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 mente:

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

Message:

Hello!

This PR fixes the issue with result caching option when query caching is on.

Reproduce is pretty easy. Call same query twice: first time with `Query::useResultCache(true)`, second time with `Query::useResultCache(false)`. If query cache is on - `useResultCache()` setting will be cached along with query itself.

Use case is when you want to keep query cache always on but want sometimes to bypass result cache (e.g. you're sure that underlying data was updated).

P.S. Is it possible to backport fix to 2.4? I can provide another PR for it