[DDC-3859] Overriding default identifier generation strategy has no effect on associations Created: 31/Jul/15  Updated: 31/Jul/15

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

Type: Bug Priority: Major
Reporter: Grzegorz Szaliński Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: association, generator-strategy, orm
Environment:

Windows 7 Enterprise SP1, Symfony 2.7.2, Doctrine ORM 2.4.7, MySQL 5.6.12, PHP 5.5.0.



 Description   

Hello everyone,

I have an entity with custom ID generator strategy. It works flawlessly.
In some circumstances I have to override this strategy with a "handmade" Id. It works when the main entity is being flushed without associations. But it doesn't work with associations. This example error is thrown:

An exception occurred while executing 'INSERT INTO articles_tags (article_id, tag_id) VALUES (?, ?)' with params ["a004r0", 4]:

SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (sf-test1.articles_tags, CONSTRAINT FK_354053617294869C FOREIGN KEY (article_id) REFERENCES article (id) ON DELETE CASCADE)

This is when foreign keys are configured. For testing I deleted the foreign keys definitions manually. The result was no error, and the associated entity was saved with the foreign key generated based on the default generation strategy (loosing the actual associations). I posted more details on how to reproduce on StackOverflow: http://stackoverflow.com/q/31594338/709626.

I first found the issue using "pure" Doctrine 2.5.0. Then, while trying to debug, I reproduced it in Symfony 2.7.2.

Actually I'm not sure whether it's a bug or I am doing something not correctly. Also this is my first report here so please let me know if I should provide any more details.






[DDC-3858] Doctrine SLC and @version, failure to get optimistic lock Created: 31/Jul/15  Updated: 31/Jul/15

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

Type: Bug Priority: Minor
Reporter: Dorrogeray Assignee: Fabio B. Silva
Resolution: Unresolved Votes: 0
Labels: SLC
Environment:

PHP 5.5.9, ubuntu



 Description   

Greetings everyone,

I am using Doctrine 2.5 with SLC enabled (memcached) and I have encountered some strange behaviour. When doctrine fetches entities from cache, the @version column is actually set to NULL instead of whatever value is correctly in the database - looks like the @version doesn't get updated as far as cache is concerned.

Note that afected entity uses @ORM\Cache(usage="NONSTRICT_READ_WRITE", region="Entity\Contact")

If I restart memcached, correct @version is loaded (because of the force reload).

This also leads to failure to get optimistic lock (due to incorrectly evaluated version mismatch).

I have no idea, but could this be somehow related to http://www.doctrine-project.org/jira/browse/DDC-3781 ?

For now, Ill try to prevent this issue from occurring by clearing updated entities from cache, and thus forcing their reload by whoever will request them next.

Thanks for any response/advice!

Here is part of call stack, this time failing on different entity, but for the same reason:

#0 /var/www/TravelSupport/vendor/doctrine/orm/lib/Doctrine/ORM/Persisters/Entity/BasicEntityPersister.php(483): Doctrine\ORM\OptimisticLockException::lockFailed(Object(DoctrineORMModule\Proxy_CG_\CsnTour\Entity\Customer))
#1 /var/www/TravelSupport/vendor/doctrine/orm/lib/Doctrine/ORM/Persisters/Entity/BasicEntityPersister.php(366): Doctrine\ORM\Persisters\Entity\BasicEntityPersister->updateTable(Object(DoctrineORMModule\Proxy_CG_\CsnTour\Entity\Customer), '`customer`', Array, true)
#2 /var/www/TravelSupport/vendor/doctrine/orm/lib/Doctrine/ORM/Cache/Persister/Entity/NonStrictReadWriteCachedEntityPersister.php(95): Doctrine\ORM\Persisters\Entity\BasicEntityPersister->update(Object(DoctrineORMModule\Proxy_CG_\CsnTour\Entity\Customer))
#3 /var/www/TravelSupport/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php(1069): Doctrine\ORM\Cache\Persister\Entity\NonStrictReadWriteCachedEntityPersister->update(Object(DoctrineORMModule\Proxy_CG_\CsnTour\Entity\Customer))
#4 /var/www/TravelSupport/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php(384): Doctrine\ORM\UnitOfWork->executeUpdates(Object(Doctrine\ORM\Mapping\ClassMetadata))
#5 /var/www/TravelSupport/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php(356): Doctrine\ORM\UnitOfWork->commit(NULL)
#6 /var/www/TravelSupport/module/CsnTour/src/CsnTour/Controller/TicketController.php(2014): Doctrine\ORM\EntityManager->flush()






[DDC-2780] IS [NOT] NULL conditions with JOINs Created: 06/Nov/13  Updated: 31/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.

Comment by Peter Jasiulewicz [ 16/Jul/15 ]

Hi,

also experiencing this error. Worked fine with 2.4.7, now trying to migrate to 2.5.0 and getting this error. The problem is, even when I do select the variable to SELECT, still getting the error.

Comment by James Hudson [ 31/Jul/15 ]

I'm seeing this too - but I actually think the "players.id IS NULL" is right - otherwise what you're really asking for is something like "COUNT(r.players) == 0" - which might cause problems when you combine the query with pagination (for instance, using the KNP Paginator in Symfony).





[DDC-3857] [GH-1485] Changed references from PHP6 to PHP7 Created: 31/Jul/15  Updated: 31/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 hasumedic:

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

Message:

Found a reference to PHP6 while reading the best practices docs.

While doing this tiny change, I also found a couple more references to it in the tests which I changed too.

If this is a funny reference to it, I'm happy for you to leave it as is. Otherwise, this PR replaces the existing references to PHP6 for PHP7 instead.






[DDC-3856] [GH-1484] Make exception message configurable for NoResultException Created: 31/Jul/15  Updated: 31/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 haeber:

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

Message:

Currently it's not possible to use a custom exception message for the NoResultException. It would be great to use a custom one. For example you can define what specific result was expected or with what query it was executed, let's say you want to find members with a select query. Then it would be great if the message could be 'No members found for query.', instead of the default message.

This change is backward compatible, because it checks for emptiness of the message, and only if it's not empty it uses the custom message. Furthermore it's now possible to loop the parameters $code and $prevision exception throw this NoResultException.






[DDC-3855] Inheritance JOINED, left select child entity retrieves not valid object Created: 30/Jul/15  Updated: 30/Jul/15

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

Type: Bug Priority: Major
Reporter: Gregory Pokrovsky Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: DQL, Inheritance, Joined, Query,


 Description   

Delivery is child of inheritance parent Place. If delivery not set in query, result will have array of PlaceAddress entities, because PlaceAddress is a root alias, but when delivery added to select, then result will contain array of PlaceTypeDelivery but root alias stays PlaceAddress. Is this a bug?

$this->_em
->createQueryBuilder()
->select(['partial addresses.

{id,realAddress,phone}

','place','partial workday.

{id}','partial delivery.{id}

'])
->from('CommonBundle:PlaceAddress', 'addresses')
->leftJoin("addresses.place", "place", "WITH", "addresses.place = place.id")
->leftJoin("addresses.workday", "workday", "WITH", "workday.address = addresses.id")
->where("place INSTANCE OF CommonBundle:PlaceTypeDelivery")
->andWhere("place.enabled = 1");






[DDC-1628] onUpdate parameter on @JoinColumn not supported Created: 31/Jan/12  Updated: 30/Jul/15  Resolved: 21/Mar/13

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

Type: Task Priority: Major
Reporter: Chris Richard Assignee: Marco Pivetta
Resolution: Invalid Votes: 3
Labels: None


 Description   

It looks like this is in the older documentation (2.0) but not mentioned in the latest.

I need to use ON UPDATE CASCADE in a few cases. Seems odd to support onDelete and not onUpdate. Am I missing something?



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

We removed onUpdate because we couldnt come up with a use-case. CAn you share yours?

Comment by Chris Richard [ 08/Mar/12 ]

I assume it's just the mysql driver but all the constraints get created such that you cannot change the primary keys (even if it's not an auto-gen PK). ON UPDATE CASCADE would probably be a better default.

Comment by Kaspars Sproģis [ 28/Aug/12 ]

I really hope onUpdate annotation attribute will be restored.
I used it in PostgreSQL very often. In some entities in some projects Primary Key ID can be very important its sequence, and if you want to change it, then "ON UPDATE CASCADE" changed it for all the references too. It was must have feature. Now few of my applications are broken with latest doctrine orm.
Please consider restoring it back.
Thank you

Comment by Václav Novotný [ 11/Oct/12 ]

+1 - onUpdate attribute is very useful for PostgreSQL databases, it controls operations with foreign keys.

Comment by Kenneth Kataiwa [ 10/Nov/12 ]

What do you mean, you couldn't come up with a use-case? If one is migrating data from one table to another and requires that all foreign key references be changed to map the ones in the new table created, before deleting the last table. And there are may more case. Maybe I am missing some thing here, if it's a use-case for the MySQL and PostgreSQL guys, why would you not support it.

Comment by Marco Pivetta [ 10/Nov/12 ]

Kenneth Kataiwa updating identifiers is something you don't do, and I sincerely also don't have a use case for this, not in the context of an ORM at least. Also, handling changes in your identifiers in the UnitOfWork is a real problem that adds a lot overhead.

Comment by Václav Novotný [ 12/Nov/12 ]

+1 - onUpdate attribute is very useful for PostgreSQL databases, it controls operations with foreign keys.

I'm taking my words back. It is not a good idea to define onUpdate on foreign keys. Yes, PostgreSQL supports it but it doesn't mean that we should use it in ORM.
Thanks for your time.

Comment by Marco Pivetta [ 21/Mar/13 ]

This issue is invalid, since data migration is not a task for the ORM anyway.

Comment by Gary Golden [ 01/May/13 ]

I have a third party table which holds users:

CREATE TABLE `user`
(
`user_id` INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
`email` VARCHAR(255) NOT NULL UNIQUE,
) ENGINE=InnoDB CHARSET="utf8";

In my table I want to use natural foreign key, so I reference `email`.

CREATE TABLE `transaction` (
`id` INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
`user_email` VARCHAR(255) NOT NULL,
FOREIGN KEY (`user_email`) REFERENCES `user`(`email`)
);

I would like to RDBMS handle email updates on the foreign records.

That is a real-life use case of the onDelete, which you decided to remove.
Please, get it back if possible.

Comment by I. S. [ 07/Jan/14 ]

I have a good use case and I am really missing the onUpdate cascade.
However it is working inside a many-to-one association but not in a one-to-one association.
The use case is a little complicated but I can send it to you if it could change something.

Comment by James Hudson [ 30/Jul/15 ]

Sorry to drag this up again, but…

I've also come across a use case as I'm migrating data in MySQL. I had to migrate data from a single table to MTI, which meant I had to investigate INFORMATION_SCHEMA, find the relevant constraints and change them in the migration script before I could migrate my data.

I appreciate that migrations and emails/usernames as PKs, are probably the only use cases, and that in general you wouldn't want the onUpdate to cascade... but is there some sort of extension that can update the constraints of all tables referencing the PK of a specified table to allow the onUpdate? If not, is that possible? Perhaps this should be raised against the doctrine migrations project... I'm not sure and would value some steer.

For anyone wondering, here's how I found the relevant constraints to batch update the onUpdate behaviour during migrations in mysql:
```sql
SELECT a.CONSTRAINT_SCHEMA, a.CONSTRAINT_NAME, a.TABLE_NAME, a.COLUMN_NAME, a.REFERENCED_TABLE_NAME, a.REFERENCED_COLUMN_NAME, c.UPDATE_RULE, c.DELETE_RULE FROM KEY_COLUMN_USAGE a LEFT JOIN REFERENTIAL_CONSTRAINTS c ON a.CONSTRAINT_NAME = c.CONSTRAINT_NAME AND a.CONSTRAINT_SCHEMA=c.CONSTRAINT_SCHEMA WHERE a.CONSTRAINT_SCHEMA = '<db-name>' AND a.REFERENCED_TABLE_NAME='<table-name>'
```
Then repeat the following for each constraint whose UPDATE_RULE is RESTRICT:
```sql
ALTER TABLE <table-name> DROP FOREIGN KEY `<constraint-name>`
ALTER TABLE <table-name> ADD CONSTRAINT `<constraint-name>` FOREIGN KEY (`<column-name>`) REFERENCES `<referenced-table-name>` (`<referenced-column-name>`) ON UPDATE CASCADE ON DELETE CASCADE");
```





[DDC-3854] [GH-1483] fix typo Created: 30/Jul/15  Updated: 30/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 longkey1:

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

Message:






[DDC-3851] [GH-1478] attributeOverride on mappedSpuerclass YamlDriver Created: 27/Jul/15  Updated: 29/Jul/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 bigfoot90:

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

Message:

This allows the use of ```attributeOverride``` on a mappedSpuerclass yaml format.
Without this you have exception
```[Doctrine\ORM\Mapping\MappingException] Invalid field override named 'field' for class 'Acme\DemoBundle\Entity\Custom'```

replace of https://github.com/doctrine/doctrine2/pull/1477 beacause of wrong branch.






[DDC-3852] [GH-1479] Quoted field - yaml driver Created: 28/Jul/15  Updated: 29/Jul/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 bigfoot90:

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

Message:

Allow the usage of ```quoted``` field mapping option in yaml mappings

Example:
```
MyModel:
type: entity
fields:
values:
type: string
quoted: true
```






[DDC-3853] [GH-1480] Allow custom id generators to handle composite keys Created: 28/Jul/15  Updated: 28/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 kaiwa:

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

Message:

Currently when using composite keys, any other id generation strategy than
NONE (assigned identifiers) is triggering an exception in ClassMetadataInfo.

This commit allows to use the CUSTOM strategy with composite keys, therefore
to allow a custom id generator to handle the composite key identifier
generation.






[DDC-3730] Embeddable hydrates to object instead of null Created: 08/May/15  Updated: 28/Jul/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



 Comments   
Comment by Eugene Dounar [ 28/Jul/15 ]

See https://github.com/doctrine/doctrine2/pull/1275





[DDC-3834] [GH-1465] Spl_object_hash conflict on Merge Created: 16/Jul/15  Updated: 28/Jul/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 moroine:

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

Message:

This is proper PR which was originally https://github.com/doctrine/doctrine2/pull/1461(https://github.com/doctrine/doctrine2/pull/1461)

Hi,

First of all, this is just a proposal and I'm sure there is a better solution for the problem described here. As this is my first hack into doctrine source code I'm not sure consequences that might be cause by my modification (even all unit tests passes).

I have encounter a problem due to spl_object_hash. I have written a functional test in order to reveal my issue.

The problem is when I merge an entity, here $user, UOW keep data on the original entity identified by it's spl_object_hash. Then if I unset this $user the spl_object_hash is now available for new object. So I experimented in my case reuse of previous hash which cause a managed+dirty entity error.

So I see two solutions

UOW keep reference to the entity given as even the given variable is unset there is remaining reference in UOW so the spl_hash will not be released.
Do not store data about the given entity, as merge operation isn't supposed to modified given entity.
I tried to implement the second solution as the first may consume a much more memory.

I don't why the merge operation need to do this, so I encapsulated it to prevent unwanted bug






[DDC-3850] [GH-1477] attributeOverride on mappedSpuerclass YamlDriver Created: 27/Jul/15  Updated: 27/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 bigfoot90:

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

Message:

This allows the use of ```attributeOverride``` on a mappedSpuerclass yaml format.
Without this you have exception
```[Doctrine\ORM\Mapping\MappingException] Invalid field override named 'field' for class 'Acme\DemoBundle\Entity\Custom'```



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

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





[DDC-3106] [GH-1023] [DDC-3027] Avoid duplicated mapping using Embedded in MappedSuperclass Created: 30/Apr/14  Updated: 27/Jul/15  Resolved: 15/May/14

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

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


 Description   

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

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

Message:



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

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

Comment by Doctrine Bot [ 15/May/14 ]

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

Comment by Damian Dlugosz [ 27/Jul/15 ]

I've commented the line ```if (!$class->isMappedSuperclass) {```
https://github.com/doctrine/doctrine2/pull/1023/files#diff-ecaa162f62bde19c758286c766911141R144
and tests are good anyway, is this line really necessary?





[DDC-3825] simple_array slush with empty array Created: 14/Jul/15  Updated: 27/Jul/15

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

Type: Bug Priority: Minor
Reporter: Damian Dlugosz Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal


 Description   

I'm using "doctrine/orm": v2.5.0 and have simple_array type.
If I persist the class where the property with type simple_array is empty array() the query fails.

I'm coming with solution, please see the github PR https://github.com/doctrine/dbal/pull/877



 Comments   
Comment by Damian Dlugosz [ 27/Jul/15 ]

I've mapped the field as nullable=false, so it should never be null.
If you cannot merge this quickly, you should at least add an warning in the docs saying that the field must be mapped set as nullable.





[DDC-3846] [GH-1473] Docs fix ref and title Created: 24/Jul/15  Updated: 25/Jul/15  Resolved: 25/Jul/15

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

Type: Documentation Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: documentation, headers, rst


 Description   

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

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

Message:

Pretty Ref and Fixed WARNING: Duplicate explicit target name

/doctrine2/docs/en/changelog/migration_2_5.rst:2: WARNING: Duplicate explicit target name: "pull request".
/doctrine2/docs/en/changelog/migration_2_5.rst:2: WARNING: Duplicate explicit target name: "pull request".
/doctrine2/docs/en/changelog/migration_2_5.rst:2: WARNING: Duplicate explicit target name: "pull request".
/doctrine2/docs/en/changelog/migration_2_5.rst:2: WARNING: Duplicate explicit target name: "pull request".
/doctrine2/docs/en/changelog/migration_2_5.rst:2: WARNING: Duplicate explicit target name: "pull request".
/doctrine2/docs/en/changelog/migration_2_5.rst:2: WARNING: Duplicate explicit target name: "pull request".

Fixed WARNING: Title underline too short

/doctrine2/docs/en/reference/second-level-cache.rst:622: WARNING: Title underline too short.
/doctrine2/docs/en/reference/caching.rst:89: WARNING: Title underline too short.






[DDC-3849] [GH-1476] Enhancement: Enable caching of dependencies between builds Created: 24/Jul/15  Updated: 25/Jul/15  Resolved: 25/Jul/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: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: build-speed, cache, ci, composer, travis


 Description   

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

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

Message:

This PR

  • [x] enables caching of dependencies as installed with Composer between builds


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

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





[DDC-3848] [GH-1475] Fix: Development dependencies are installed by default Created: 24/Jul/15  Updated: 25/Jul/15  Resolved: 25/Jul/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: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: ci, composer, travis


 Description   

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

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

Message:

This PR

  • [x] removes the `--dev` option when installing dependencies, as `development` dependencies are installed by default


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

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





[DDC-3847] [GH-1474] Fix: Remove unused imports Created: 24/Jul/15  Updated: 24/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 localheinz:

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

Message:

This PR

  • [x] removes apparently unused imports





[DDC-3845] Add logger to track information how much time hydration of entities was spent and how many entities was hydrated Created: 23/Jul/15  Updated: 23/Jul/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: Dmytro Malyshenko Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm


 Description   

Maybe it worth to make a logger like Doctrine\DBAL\Logging which will track an information how much time was spent on a hydration of entities and how many entities were hydrated.

Because of lazy loading there could be hydrated a much more objects than it needed and it hard to track.

If a logger will be created, later in Symfony, for example, in doctrine/DoctrineBundle, it could be injected in Doctrine\ORM\Configuration and collected information might be displayed in a web profiler panel.

I've made a symfony bundle which implements the functionality - https://github.com/debesha/DoctrineProfileExtraBundle

Here https://github.com/debesha/DoctrineProfileExtraBundle/wiki I tried to explain why I think it is necessary.

If it will be considered to be worth to implement, I can make a coding myself and push it into hobodave/doctrine2.git






[DDC-3844] [GH-1472] Add test for MariaDB 5.5 and 10.1 on Travis Created: 23/Jul/15  Updated: 23/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 PowerKiKi:

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

Message:

This use the brand new supported addon mariadb (not yet officially announced).
This is unfortunately a bit verbose, but I don't think there is any
alternative because we cannot install the addon when testing against mysql
otherwise it would overwrite mysql install.






[DDC-3212] Remove ArrayHydrator logic Created: 14/Jul/14  Updated: 22/Jul/15

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

Type: Improvement Priority: Critical
Reporter: Marco Pivetta Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: hydration, hydrator


 Description   

The Doctrine\ORM\Internal\Hydration\ArrayHydrator ( https://github.com/doctrine/doctrine2/blob/85fbf684363b932a4ebaf543ef059f9ee1e512b0/lib/Doctrine/ORM/Internal/Hydration/ArrayHydrator.php ) is currently very messy and complicated due to the lack of actual Doctrine\ORM\UnitOfWork references when working with it, since we are not dealing with objects.

In order to reduce the amount of bugs and code duplication when working with array hydration, I would simply suggest making use of the Doctrine\ORM\Internal\Hydration\ObjectHydrator ( https://github.com/doctrine/doctrine2/blob/85fbf684363b932a4ebaf543ef059f9ee1e512b0/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php ) and its siblings, and then extracting data coming from the results in it as an array.

This could be a simple reflection-based extraction (pseudo):

class ArrayHydrator
{
    public function hydrateAllData()
    {
        foreach ($this->objectHydrator->hydrateAllData() as $object) {
            yield $this->extractData($object);
        }
    }
}

The point here is that array-based hydration is not the primary focus of the ORM, and users should probably rely on SQL only when they want array hydration.



 Comments   
Comment by Marco Pivetta [ 14/Jul/14 ]

Note: performance is one of our biggest requirements, and array hydration is meant to achieve that. As I stated above, plain SQL is probably better for this sort of operation, so the issue is more about deprecating the ArrayHydrator completely, providing utilities to manipulate SQL resultsets instead.

Comment by Claudio [ 22/Jul/15 ]

I know of some intern projects, where the ArrayHydrator is used. It is right, that an ORM should be about objects, but that also counts for ScalarHydrator, and SingleScalarHydrator, which also aren't Object hydrator. Isn't there a way to reduce the complexity of the ArrayHydrator without ObjectHydrator? It would be a shame when a project build up with DQL Queries need to switch partially to SQL.





[DDC-16] DQL Ignores properties of subclasses Created: 15/Sep/09  Updated: 22/Jul/15  Resolved: 24/Feb/13

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

Type: Improvement Priority: Minor
Reporter: Avi Block Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 6
Labels: None

Issue Links:
Duplicate
is duplicated by DDC-1377 Doctrine doesn't understand associati... Closed
is duplicated by DDC-3342 Join with child tables Resolved

 Description   

I have a classes B and C which inherit from superclass A. I would like
to get a list of all A's but filter the list to ignore those in C
which have a property d set to 2.

select a from A where a.d == 2 fails because "d" is not a property of A.



 Comments   
Comment by Roman S. Borschel [ 31/Mar/10 ]

Thats indeed tricky. That syntax alone can, however, never work, because there might be several subclasses that have a field named "d", so Doctrine would not know which field you mean.

We might need special syntax for such constructs but I'm not sure it is worth it. If anyone has an idea, just shoot.

Alternatively, apart from using a native query, what about this DQL:

select a from A a where a.id not in (select c.id from C c where c.d = 2)
Comment by Benjamin Eberlei [ 01/Apr/10 ]

I am sorry, but isn't this sort of query a violation of object oriented programming, Accessing a Superclass A and checking for a property that exists on a certain child is not possible in any strict OO language without specific casting into the type beforehand.

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

Thats why I said "we would need special syntax for such constructs", i.e. casting syntax

However, the alternative query I showed should work just fine for such purposes.

Comment by Menno Holtkamp [ 18/Jul/11 ]

+1 for this request.

When displaying data (stored in a database) to end-users using generated tables, server-side sorting and filtering on properties that belong to subclasses is a common task, for instance to provide the data presented in a JQuery Datatable: http://www.datatables.net.

For this purpose, DQL is great to generate the required queries dynamically. However, since properties of subclasses can currently not be 'accessed', sorting and filtering on these properties becomes impossible, or at least cumbersome to implement. Currently I have lifted/copied specific properties to a general 'value' property of the superclass, which CAN be used for ordering and filtering. Of course, this work-around significantly decreases the power of inheritance strategy in the originally envisioned model.

In Hibernate this seems to have been solved in HQL using downcasting, which seems a viable approach, but as Benjamin already mentioned not a best practice in a strict OO approach. Therefore a specific syntax might be required to hint on the to-be-expected casts:

For additional motivation of this subject, check a recent post of mine at the user groups: http://groups.google.com/group/doctrine-user/msg/caebf8139e06e01a

Comment by Avi Block [ 18/Jul/11 ]

Honestly I gave up on all of this a long time ago, and now use a CQRS approach. I make views, or denormalized tables for every view in my application, and just use straight SQL.

When I need to do creating or updating or whatever, I use doctrine.

Comment by Glen Ainscow [ 19/Jul/11 ]

I would like this as well (though my use case involves joining to the subclass).

Registration has one Opponent (superclass to Player and TeamSelection). I would like to count the number of registrations for a particular team within a specific tournament. For example:

SELECT COUNT(*)
FROM Registration r
INNER JOIN r.opponent CAST TeamSelection ts
INNER JOIN ts.team t
WHERE r.tournament = 1
AND t.name = "Team #1"
Comment by Glen Ainscow [ 19/Jul/11 ]

Thinking about this a bit more, it can actually improve query performance, as it would no longer be necessary to join the other subclasses. In other words, since you're casting the opponent to a TeamSelection, it's not necessary to join to the players table.

A cast should probably also restrict the result using the discriminator column, for example (SQL):

INNER JOIN opponents o ON o.id = r.opponent_d AND o.type = "TeamSelection"
Comment by Guilherme Blanco [ 15/Sep/11 ]

Possible solution:

SELECT p FROM CAST(Person AS User) p

Or:

SELECT a, p FROM Article a JOIN CAST(a.person AS User) p
Comment by Glen Ainscow [ 16/Sep/11 ]

If you're casting a Person (superclass) to a User (subclass), then shouldn't the alias be "u" and not "p"?

i.e. SELECT a, u FROM Article a JOIN CAST(a.person AS User) u

Comment by Benjamin Eberlei [ 16/Sep/11 ]

the alias is that, an alias, you can use whatever you want.

Comment by Glen Ainscow [ 16/Sep/11 ]

Yes I know that, I'm just making sure that I understand the syntax.

Comment by Jaka Jancar [ 18/Feb/12 ]

I just ran into a similar problem and am not sure the above cast solution would do.

I'm trying to do:

SELECT
    s
FROM
    Superclass s
WHERE
    s INSTANCE OF SubclassA OR
    s INSTANCE OF SubclassB AND s.foo = 'bar';

So I'd need to use CAST in a WHERE condition, not in the FROM/JOIN clause, e.g:

SELECT
    s
FROM
    Superclass s
WHERE
    s INSTANCE OF SubclassA OR
    s INSTANCE OF SubclassB AND (CAST s AS SubclassB).foo = 'bar';
Comment by Wladimir Coka [ 03/Apr/12 ]

Is there any workaround? Would be perfect if I could just:

 SELECT a, p FROM Article a JOIN CAST(a.person AS User) p 

(+1 for Guilherme Blanco possible solution)

Comment by Wladimir Coka [ 04/Apr/12 ]

I was trying a workaround:

Before executing the dql query, I change the mapping info of the association to the concrete type that I was going to use. Like this:

        $cmf = $this->em->getMetadataFactory();
        $class = $cmf->getMetadataFor("Article");
        $class->associationMappings["person"]["targetEntity"]="User";

But now my problem is that I'm actually using an inverse side (in query where this is needed), so when I change the targetEntity, the sql join that is generated, is using the table of the concrete class (User in this case) and not the base class (Person)

class Person {
...
	/**
	 * @OneToOne(targetEntity="Order",cascade={"persist"})
	 * @JoinColumn(name="order_id", referencedColumnName="orden_id")
	 */
	private $order;
...
}

class Order {
...
    /**
     * @OneToOne(targetEntity="Person", mappedBy="order")
     */
    private $person;
...
}

The SQL generated is joining as if the "user" table has orden_id field

Comment by Marco Pivetta [ 24/Feb/13 ]

I am closing this one.

The requirement of this issue is basically violating OO principles.

If you really need to filter across multiple child-entities in your inheritance, then try something as following instead:

SELECT
    r
FROM
    Root r
WHERE
    r.id IN (
        SELECT
            c.id
        FROM
            Child c
        WHERE
            c.field = :value
    )

Up-casting is not really a viable solution anyway, since it would be even more weird to cast in DQL and then have hydration still retrieve the root entity type.

Comment by Bogdan Yurov [ 17/Jul/14 ]

@Marco You are wrong. There is no way to do this. It is just not wise to deny a feature just because it violates OO principles when this is the only method.

There are usecases, when we have nothing to do. For example, we are searching through the whole table in STI. We use quick filters like "Like" so there is not need in difficult indexes/additional tables for them. We CAN NOT in ANY way overcome this limitation when we need to use fields of different classes.

This is certainly not a bug, when we may say "WONT FIX" and just ignore all those people who face it.

Comment by Marco Pivetta [ 17/Jul/14 ]

It is just not wise to deny a feature just because it violates OO principles when this is the only method.

We are working on an ORM (Object-Relational-Mapper), therefore Object-Orientation is first-class citizen and prioritized over everything else in the ORM.

There are usecases, when we have nothing to do.

There are use-cases for everything, but that doesn't mean that they should clutter the tool. This does not only apply to Doctrine ORM. An edge case functionality that has multiple workarounds and that cannot be implemented correctly within the tool does NOT need to land in the tool.

I provided a workaround that respects the OO and ORM rules and works also with the OO paradigm. Here is a pseudo-code description of what the DQL I pasted above does:

  • select all objects that are instance of Child by $someCriteria
  • select all objects that are instance of Root
  • iterate over Root instances and filter out those that are not in the results of the first selection

We CAN NOT in ANY way overcome this limitation when we need to use fields of different classes.

Yes you can: there's SQL. SQL is a "structured query language" that is weakly typed and allows this sort of operation natively. This is a problem of the SQL domain, and it should be solved with SQL whenever the DQL becomes too complex/limited. Don't try to stuff a feature that is only possible in the SQL domain into DQL just because they look similar.
They are not the same thing.

This is certainly not a bug, when we may say "WONT FIX" and just ignore all those people who face it.

We are not ignoring the problem: we just point you to the right scope/tools to solve it. DQL has one way of solving it, which may or may not be viable to you. SQL has another way of solving this same problem, and it's not going to be implemented in DQL because DQL is statically typed, and upcasts and type juggling are not going to land in DQL.

Comment by Bogdan Yurov [ 17/Jul/14 ]

If we provide a workaround, is there any way to merge it to master branch? What we can do to vote up this feature?

Comment by Marco Pivetta [ 17/Jul/14 ]

Bogdan Yurov we already tried looking into this multiple times.

The only "clean-ish" solution would be to support upcasting somehow, and the effort and complexity derived from it is not worth it.

Comment by Bogdan Yurov [ 17/Jul/14 ]

@ocramius
What about "CAST()" construction? You were talking about OO, but there are some languages, that could argue with you.

For example, Delphi. It supports casting manually to selected type (for example TObject -> TButton). Does it break best violates OO principles too? No, of course.
Another example is Java. It has exactly same language construction for exactly same purpose. Is doctrine more concentrated on OO principles than Java or Delphi?

Comment by Marco Pivetta [ 22/Jul/14 ]

Bogdan Yurov I think Guilherme Blanco is thinking of providing a cast syntax.

Comment by Adrian Grayson [ 07/Jul/15 ]

"For example, Delphi. It supports casting manually to selected type (for example TObject -> TButton). Does it break best violates OO principles too? No, of course.
Another example is Java. It has exactly same language construction for exactly same purpose. Is doctrine more concentrated on OO principles than Java or Delphi?"

I agree. I fail to see how a type safe CAST() violates OO. We're not talking about dangerously casting anything, at least not in theory. It's polymorphism.

Comment by Bogdan Yurov [ 22/Jul/15 ]

Is there any chance that this would be implemented?

Comment by Marco Pivetta [ 22/Jul/15 ]

Unlikely right now.

Comment by Bogdan Yurov [ 22/Jul/15 ]

Is it worth it to try to implement such behavior? I am not well aware of Doctrine internals thus I can not chose what to do. Would it require rewriting of doctrine kernel and major changes, or it could be implemented somehow without much patching?

Comment by Marco Pivetta [ 22/Jul/15 ]

Implementing it is not the problem. The problem is that it violates ORM invariants that we want to keep.





[DDC-3842] [GH-1471] Platform built twice on closed connections Created: 21/Jul/15  Updated: 22/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: close, connection, platform


 Description   

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

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

Message:

There is a loop when a closed connection is asked for its Database Platform, in which the resulting Platform object gets overwriten by a new one and all modifications made in the postConnect event is lost.

The commited test adds the event BEFORE the connection gets opened automatically by the OrmFunctionalTestCase setUp method. I know this is not a common test scenario, but I had to make this hack in order to reuse all the other FunctionalTestCase stuff.

I believe this only happens in Drivers that implement VersionAwarePlatformDriver, as I could not reproduce it with sqlite.

I believe what's happening is:

  • `Connection` tries to `detectPlatformDriver`
  • As connection is closed, `getDatabasePlatformVersion` tries to `$this->connect()` it
  • `Connection::connect()` has a `null` on `$this->platform` because it didn't finish detecting, so it tries to detect again
  • This time the connection is opened, so `detectPlatormDriver` succedes.
  • `Connection` fires the event
  • The rest of the first `detectPlatformDriver` call executes, overriding `$this->platform`

I was using the postConnect event to add types only when the connection is opened, instead of adding them every time I constructed the EntityManager, to prevent connections from being opened every time.






[DDC-3843] indexBy collection loses index key after calling a ->matching(criteria) on it Created: 22/Jul/15  Updated: 22/Jul/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: Minor
Reporter: Matteo Orefice Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: collection, orm
Environment:

Linux Debian (7.8) NGINX (1.8.0) PHP (5.5.25-1~dotdeb) MySQL (5.6.24-72.2)



 Description   

When I retrieve a filtered collection of entities which has indexBy attribute it loses index keys in the result. Before calling matching() method i tried to call toArray() and It solved the problem, I don't know if it is a bug .

class Entity {
/**
     * @var ArrayCollection
     * @ORM\OneToMany(targetEntity="Entity\Arcansel\BasketItem",mappedBy="userSession",indexBy="id",cascade={"persist","remove","merge"})
     */
    protected $basketItems;


// Some comments here
public function getBasketItems()
    {
        $date = DateTime::newDateTimeUniversal();
        $criteria = Criteria::create()->where(Criteria::expr()->gt("addTime",$date));
        // next line of code prevents returned collection to lose indexBy keys
        $a = $this->basketItems->toArray();
        return $this->basketItems->matching($criteria);
    }
}





[DDC-3841] [GH-1470] [CI] Added dev requirement for "doctrine/coding-standard" Created: 20/Jul/15  Updated: 21/Jul/15

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

Type: Improvement Priority: Minor
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: CI, CS, Tools

Issue Links:
Reference
relates to DDC-585 Create a coding standards document Open

 Description   

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

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

Message:

Q A
-------------
Bug fix? no
New feature? yes
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets
License MIT
Doc PR
  • Added dev requirement for ```doctrine/coding-standard```.
  • Updated Travis config in order to use the new requirement within
    ```before_script``` lifecycle.


 Comments   
Comment by Phansys [ 20/Jul/15 ]

Take this as a probe of the current status of the Doctrine's CS. IMO, we should decide how to proceed in order to get a clean codebase, and I think we should apply some tool like PHP-CS-Fixer or update PHP_CodeSniffer to 2.0 in order to achieve the same feature.

Ping @Ocramius.

Comment by Marco Pivetta [ 21/Jul/15 ]

Phansys I already replied on the PR: needs CS changes before merging, and other PRs take priority first.

Comment by Phansys [ 21/Jul/15 ]

Marco Pivetta, auto CS fixes aren't available with PHP_CodeSniffer at 1.x version (they are in yet unreleased 2.x); that is why I created this PR https://github.com/doctrine/doctrine2/pull/1460 using PHP-CS-fixer, while I've also added a rule for Doctrine's logical NOT CS: https://github.com/FriendsOfPHP/PHP-CS-Fixer/pull/1303.
IMO, at some point we should use any of these tools to ensure all the CS rules are respected.





[DDC-585] Create a coding standards document Created: 13/May/10  Updated: 20/Jul/15

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

Type: Documentation Priority: Major
Reporter: Roman S. Borschel Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 1
Labels: CS

Issue Links:
Reference
is referenced by DDC-3841 [GH-1470] [CI] Added dev requirement ... Open
is referenced by DDC-2408 [GH-649] Update coding standards Resolved

 Description   

We need a new coding standards document for Doctrine 2.



 Comments   
Comment by Benjamin Morel [ 29/Jan/13 ]

Has there been any work on a coding standards document yet?
I'm currently working on fixing documentation on this project, and it might be a good time to define a standard.
I've started compiling a few recommendations based on various feedbacks I've got in my pull requests, and I can post them here.
Please let me know if there have been previous attempts so far!

Comment by Marco Pivetta [ 29/Jan/13 ]

Benjamin Morel Guilherme Blanco may have a CS ruleset, but it's not ready yet. Perfect timing btw, we really need to automate this to avoid having all these useless CS fix comments in pull requests

Comment by Benjamin Morel [ 29/Jan/13 ]

Ok, I'll post my document here once ready, and Guilherme Blanco will be able to compare it with his ruleset!

Comment by Benjamin Morel [ 30/Jan/13 ]

Here is a first draft: https://gist.github.com/4676670

Please comment!

Comment by Benjamin Morel [ 11/Feb/13 ]

Guilherme Blanco, if you don't have time to compare your ruleset with my draft, maybe you could publish your current ruleset so that others can have a look?

Comment by Benjamin Morel [ 02/Aug/13 ]

Any update guys? I'm willing to spend some time on this work, but if no one answers, we won't be going forward

Comment by Marco Pivetta [ 02/Aug/13 ]

Benjamin Morel I think a pull request against the doctrine website (https://github.com/doctrine/doctrine-website-sphinx) would be fine...

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

This should go into https://github.com/doctrine/coding-standard repo (long term).

Comment by Phansys [ 14/Jul/15 ]

Could we define PSR-2 as base?

Comment by Marco Pivetta [ 15/Jul/15 ]

Please just refer to https://github.com/doctrine/coding-standard, which is already PSR-2 based (with variations and more strictness)

Comment by Phansys [ 15/Jul/15 ]

@ocramius, Is there a rule for spaces arround `!` operator? https://github.com/doctrine/doctrine2/pull/1133#discussion_r17459791

Comment by Phansys [ 15/Jul/15 ]

I just found another set of rules inside https://github.com/doctrine/doctrine2/blob/14ff7f50cfea67d8a4dca37b8ca364d2a83b9864/CONTRIBUTING.md#coding-standard. Which is the current valid standard?

Comment by Marco Pivetta [ 15/Jul/15 ]

Phansys yes, that's doctrine specific (spaces around {{ ! }} )

Comment by Phansys [ 15/Jul/15 ]

Perfect! https://github.com/FriendsOfPHP/PHP-CS-Fixer/pull/1303
What about the disambiguation between the CS? https://github.com/doctrine/coding-standard/tree/master/Docs#doctrine-coding-standard vs https://github.com/doctrine/doctrine2/blob/14ff7f50cfea67d8a4dca37b8ca364d2a83b9864/CONTRIBUTING.md#coding-standard





[DDC-3840] [GH-1469] Fix version compare Created: 20/Jul/15  Updated: 20/Jul/15  Resolved: 20/Jul/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: annotation, entityGenerator, generation, namespace, simplified-annotation


 Description   

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

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

Message:

Generate entity with '@ORM' annotation because comparison error.






[DDC-3826] [GH-1459] [Dependencies] Used semantic version constraint for "satooshi/php-coveralls" Created: 14/Jul/15  Updated: 20/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: Minor
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: composer, constraint, dependency, version


 Description   

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

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

Message:

Q A
-------------
Bug fix? yes
New feature? no
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets
License MIT
Doc PR





[DDC-3839] EventListener not called when clearing a ManyToMany collection by reference Created: 20/Jul/15  Updated: 20/Jul/15

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

Type: Bug Priority: Minor
Reporter: Jonathan Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: event, many-to-many

Attachments: File ManyToManyEventTest.php    

 Description   

I have an issue with a ManyToMany relation. I don't know if it is a bug or the normal behaviour but when I clear a ManyToMany relation of an entity with the following code :

$user->getGroups()->clear();

the event listener linked to my entity is not called when I flush the entity manager.

I have updated the test \Doctrine\Tests\ORM\Functional\ManyToManyEventTest in order to reproduce the issue (see file attached).






[DDC-1339] New DQL function: IDENTITY(SingleValuedAssociationPathExpression) Created: 19/Aug/11  Updated: 18/Jul/15  Resolved: 08/Sep/11

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

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


 Description   

Suppose the association: User N:1 Group and user wants to be able to retrieve "users.group_id" without joining the Group entity.
This lead us to create a new DQL function:

SELECT IDENTITY(u.Group) AS group_id FROM User u WHERE u.id = ?0


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

Implemented https://github.com/doctrine/doctrine2/commit/a7f3af8328b031a6f006eef1062554bf9f57e1df

Comment by Marcony Felipe [ 12/Mar/15 ]

Hi Guilherme! How r u?

Abel has sending a BIG THANK YOU!

Bye!

Comment by Marcos Passos [ 18/Jul/15 ]

It does not work properly for custom types, see:
http://www.doctrine-project.org/jira/browse/DDC-3797





[DDC-3838] Add support for usig DTOs as constructor arguments Created: 18/Jul/15  Updated: 18/Jul/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: Marcos Passos Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dql


 Description   

I've a user case where I need to instantiate a DTO that requires use another DTO as argument:

SELECT NEW User(user.name, user.email, NEW Address(address.street, ...))

..

Today it's not possible and an exception is thrown:

[Syntax Error] line 0, col 95: Error: Unexpected 'NEW'





[DDC-3837] [GH-1468] Travis: Enable cache for composer Created: 17/Jul/15  Updated: 17/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 Majkl578:

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

Message:

Travis is now able to persist caches and reuse them in future builds. This could avoid re-downloading of stable packages (5 atm).
As @stof suggested in #1466, after removing `--prefer-source`, stable versions will be downloaded as an archive while dev versions will be still cloned by git directly.
More info in [Caching Dependencies and Directories](http://docs.travis-ci.com/user/caching/).






[DDC-3836] [GH-1467] switch/case with colon instead of semicolon Created: 17/Jul/15  Updated: 17/Jul/15  Resolved: 17/Jul/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: Marco Pivetta
Resolution: Incomplete Votes: 0
Labels: syntax


 Description   

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

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

Message:

A semicolon is also correct ( http://php.net/manual/en/control-structures.switch.php "It's possible to use a semicolon instead of a colon after a case like: ") but there are colons on the other cases.



 Comments   
Comment by Doctrine Bot [ 17/Jul/15 ]

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





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

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

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


 Description   

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

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

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



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

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

Comment by Benno Eggnauer [ 17/Jun/14 ]

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

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

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

Comment by Marco Pivetta [ 17/Jun/14 ]

Benno Eggnauer can you eventually provide a pull request?

Comment by James Blizzard [ 01/Dec/14 ]

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

Comment by Guglielmo Carandente [ 16/Jan/15 ]

I have the same problem when is generated QueryCacheId It consider only the name of active filters and not the value of the filter
This is the code at line 646 of class \Doctrine\ORM\Query
protected function _getQueryCacheId()

{ ksort($this->_hints); return md5( $this->getDql() . var_export($this->_hints, true) . ($this->_em->hasFilters() ? $this->_em->getFilters()->getHash() : '') . '&firstResult=' . $this->_firstResult . '&maxResult=' . $this->_maxResults . '&hydrationMode='.$this->_hydrationMode.'DOCTRINE_QUERY_CACHE_SALT' ); }
Comment by Pele Odiase [ 08/Jul/15 ]

I also have the same issue, there are circumstances where filters are dynamic and not stateless particularly when dealing with multi-site / multi-lingual platforms. Is there an appetite for the ORM to take this into consideration.

Comment by Bram Gerritsen [ 17/Jul/15 ]

I have the same issue. We are using SQL filters a lot to filter entities by website and locale. It would be nice if the filter values can be taken into account as well. For now I disabled the query cache in the concerning repositories.





[DDC-3835] [GH-1466] Travis: Switch to container-based infrastructure Created: 16/Jul/15  Updated: 16/Jul/15  Resolved: 16/Jul/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
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, sudo, travis


 Description   

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

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

Message:

This PR migrates Travis builds to the new container-based infrastructure.
See [Using container-based infrastructure](http://docs.travis-ci.com/user/workers/container-based-infrastructure/) for details.






[DDC-3725] [GH-1400] pgsql and mysqli are supported by HHVM Created: 04/May/15  Updated: 16/Jul/15  Resolved: 16/Jul/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: ci, hhvm, misqli, travis


 Description   

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

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

Message:



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

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

Comment by Doctrine Bot [ 16/Jul/15 ]

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

Comment by Doctrine Bot [ 16/Jul/15 ]

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





[DDC-3723] [GH-1399] Fix for DDC-3719. Created: 03/May/15  Updated: 16/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

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.



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

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





[DDC-3829] [GH-1462] Add a note to documentation for transactional()'s return values Created: 16/Jul/15  Updated: 16/Jul/15  Resolved: 16/Jul/15

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

Type: Documentation Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: documentation, entitymanager, legacy, limitations, transactional


 Description   

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

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

Message:

Related to problems encountered in #1392.






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

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers, Second Level Cache
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: metadata, performance, second-level-cache


 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).



 Comments   
Comment by Doctrine Bot [ 15/Jul/15 ]

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

Comment by Doctrine Bot [ 16/Jul/15 ]

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

Comment by Doctrine Bot [ 16/Jul/15 ]

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





[DDC-3833] [GH-1464] [DDC-3609] Syntax error in class table inheritance join when WITH is used in DQL query #1328 Created: 16/Jul/15  Updated: 16/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 sp-rhm:

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

Message:

I found that in SqlWalker::walkJoin(), it is using ON if the join type is LEFT or LEFT OUTER. That seems weird, because SqlWalker::walkRangeVariableDeclaration() always adds a JOIN with ON, even in the case of LEFT or LEFT OUTER join. Furthermore, the tests in SelectSqlGenerationTest seem to incorrectly check for the second ON to be present.

However, this change only fixes one of the tests by @adeanzan, the other two are still failing. So I don't know if my fix is correct.






[DDC-3824] [GH-1457] Updated syntax for "integer" and "boolean" types Created: 14/Jul/15  Updated: 16/Jul/15

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
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: 0
Labels: CS, docblock, entityGenerator, generation


 Description   

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

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

Message:

Q A
-------------
Bug fix? no
New feature? no
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets
License MIT
Doc PR

Used short syntax for ```integer``` and ```boolean``` types.

*Before*
```php
/**

  • @var integer
    *
  • @ORM\Column(name="some_integer_field", type="integer")
    */
    private $someIntegerField;

/**

  • @var boolean
    *
  • @ORM\Column(name="some_boolean_field", type="boolean")
    */
    private $someBooleanField;
    ```

*After*
```php
/**

  • @var int
    *
  • @ORM\Column(name="some_integer_field", type="integer")
    */
    private $someIntegerField;

/**

  • @var bool
    *
  • @ORM\Column(name="some_boolean_field", type="boolean")
    */
    private $someBooleanField;
    ```





[DDC-3832] readOnly should be renamed to immutable in the mapping Created: 16/Jul/15  Updated: 16/Jul/15

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

Type: Improvement Priority: Minor
Reporter: Christophe Coevoet Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: None


 Description   

readOnly in the mapping is currently very confusing. Some people are using it to map entities to views, and then complain about SchemaTool-based projects (migrations for instance) because it handles things as table.
But this is not the actual meaning of this mapping flag. Read-only entities can be inserted and deleted. The only forbidden action on them are updates. This makes the naming totally unsuited.

For reference, Hibernate uses "mutable=false" for the feature corresponding to our "readOnly=true".






[DDC-3818] Paginator fails to retrieve entities linked with One-To-Many Created: 10/Jul/15  Updated: 16/Jul/15

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

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


 Description   

This happens when you deal with entities with children as One-To-Many, and you perform a search on one of the child.
Let's use a real example :

a Company has 1,N Employees.
Data is the following :

Company

ID COMPANY NAME
1 ACME LTD
2 PEACH SOFTWARE

Employee

ID Name Employee company ID
1 Basil 1
2 Robert 1
3 Donald 1
4 Daniel 2
5 Tom 2

Following DQL query will work and return two companies with property 'employees' hidrated :

SELECT c, e FROM Company c LEFT JOIN c.employees e

Now let's add a WHERE clause :

SELECT c, e FROM Company c LEFT JOIN c.employees e WHERE e.name = 'Robert'

We will get Company #1, but only 1 employee on it (Robert) instead of three.

Explanation

This is how Paginator works :
1) Query is a Count with distinct
2) Query with LIMIT to find all entities ID related
3) retrieve entities with WHERE IN()

Problem is in query 3 : WHERE clause is copied and IN() is added. To work properly, we should reset the WHERE clause and only use IN().

This bug went unseen because Doctrine is using massive cache on Entities based on @id. Tests did not show this bug because the full object is retrieved from the cache version, where all descendants are present.

Solution

in ORM\Tools\Pagination\WhereInWalker.php, reset $AST->whereClause.
I realize just now that this would break applications using WhereInWalker class directly. I wondered if the proper fix would be to duplicate this class as PaginationWhereInWalker and use this last class in Paginator.
Another problem happens with prepared statements (that we should all use with Doctrine) : as we remove some WHERE clauses, we have more parameters than what's bind. Latest pull request contains a fix to not copy parameters in WhereInQuery, and only add what's needed.

This is when I work on such a bug that I understand how complex Doctrine is ... I hope I did not open the pandora's box. If my fix is not implemented properly, I'll will be happy to discuss it.

Full pull Request, containg test and fixes : http://www.doctrine-project.org/jira/browse/DDC-3819






[DDC-3713] [GH-1393] Composite key id used in nullable relations Created: 24/Apr/15  Updated: 16/Jul/15  Resolved: 16/Jul/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: Invalid Votes: 0
Labels: association, composite-identifier, derived-identifier, hydration, hydrator, identifier, identifier-association


 Description   

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

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

Message:

This provides a fix, when you're using a composite primary key, and using part of the composite key as a join column, that will make sure you don't overwrite the composite id key.

Also the fix to Unit of Work needed to consider if part of a composite key was null, it should not try to map the entity.



 Comments   
Comment by Doctrine Bot [ 15/Jul/15 ]

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

Comment by Doctrine Bot [ 16/Jul/15 ]

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

Comment by Doctrine Bot [ 16/Jul/15 ]

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

Comment by Marco Pivetta [ 16/Jul/15 ]

Mappings provided with the PR are invalid (field shared across identifier, field mappings and association mappings)





[DDC-3831] [GH-1463] Fixed issue when paginator orders by a subselect expression Created: 16/Jul/15  Updated: 16/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 ehimen:

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

Message:

On platforms that support the ROW_NUMBER() OVER() function, we've found issues when ordering by a subselect expression. Have included a test demonstrating the problem that was failing with a syntax error under Postgres:

```
Caused by
PDOException: SQLSTATE[42601]: Syntax error: 7 ERROR: syntax error at or near "SELECT"
LINE 1: ...d = c0_.id) AS sclr_4, ROW_NUMBER() OVER(ORDER BY SELECT MAX...






[DDC-3677] [GH-1375] DDC-3671 prevent duplicate unique index Created: 08/Apr/15  Updated: 16/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

Issue Links:
Duplicate
duplicates DDC-3671 Duplicated unique indexes (@UniqueCon... Open

 Description   

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

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

Message:



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

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





[DDC-3830] Duplicate unique index on OneToOne relation create Created: 16/Jul/15  Updated: 16/Jul/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: Alexander Ivanov Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Should check if unique exists in Doctrine\ORM\Tools\SchemaTool:gatherRelationJoinColumns() method. Now $uniqueConstraints is set to empty array at the beginning of method, so new unique are force created even if unique on column already exists.






[DDC-3714] [GH-1394] Fix result cache setting query caching Created: 24/Apr/15  Updated: 15/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 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

Alex



 Comments   
Comment by Doctrine Bot [ 15/Jul/15 ]

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





[DDC-3811] [GH-1451] composer: autoload via PSR-4 Created: 08/Jul/15  Updated: 15/Jul/15  Resolved: 15/Jul/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: autoloader, composer


 Description   

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

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

Message:






[DDC-3712] [GH-1392] transactional() wrapper corrupts return values Created: 23/Apr/15  Updated: 15/Jul/15  Resolved: 15/Jul/15

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

Type: Bug Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Can't Fix Votes: 1
Labels: entitymanager, transactional


 Description   

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

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

Message:

The EntityManager::transactional() method has undocumented behavior, which unexpectedly rewrites all `false`-ish return values into `true` before passing them on:

    $result = $this->_em->transactional(function (){
        return array();
    }
    assert(is_array($result)); // Fails

I think there's a very strong case to be made that this is undesirable, *however* it's been in existence for a few years now (since DDC-1125) and it's very likely at least a few users have code that relies on the undocumented behavior.

This PR represents the most direct fix, but as a practical matter we may want to improve the documentation instead. If that is the decision, I'd be happy to create a separate PR for documentation changes.



 Comments   
Comment by Marco Pivetta [ 15/Jul/15 ]

This issue cannot be fixed in 2.x, and requires a change/rewrite for 3.0 instead.





[DDC-3704] [GH-1390] Document the ChainCache class Created: 20/Apr/15  Updated: 15/Jul/15  Resolved: 15/Jul/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Documentation
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: cache, chain-cache, documentation


 Description   

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

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

Message:

I was thisclose to writing a ChainCache class myself, and only avoided it by actually looking in the source. There's no mention of ChainCache on Google, probably because there's no docs for it. ChainCache is a bit different from other drivers in that it's something implementers will want to use in their own code in place of an ArrayCache or static array. However, I also added a link to the cache drivers given there's quite a few that aren't mentioned in the docs.






[DDC-3715] [GH-1395] Fix for DDC-3697 Created: 26/Apr/15  Updated: 15/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 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)



 Comments   
Comment by Doctrine Bot [ 15/Jul/15 ]

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





[DDC-3702] [GH-1388] Fix Lexer::match() so it does not accept T_WHERE when T_WITH is supposed to be matched Created: 19/Apr/15  Updated: 15/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 mpdude:

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

Message:

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



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

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

Comment by Matthias Pigulla [ 19/Apr/15 ]

Please disregard / close.

Comment by Doctrine Bot [ 15/Jul/15 ]

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





[DDC-3703] [GH-1389] Fix Lexer::match() so it does not accept T_WHERE when T_WITH is supposed to be matched Created: 19/Apr/15  Updated: 15/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 mpdude:

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

Message:

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



 Comments   
Comment by Matthias Pigulla [ 19/Apr/15 ]

This is the PR for DDC-3701. Please close or mark as duplicate of DDC-3701, whatever your workflow is.

Comment by Doctrine Bot [ 15/Jul/15 ]

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





[DDC-3699] [GH-1387] Fix skipping properties if they are listed after a not loaded relation. Created: 17/Apr/15  Updated: 15/Jul/15  Resolved: 15/Jul/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: collection, inheritance, lazy-loading, merge, persistent-collection, properties, proxy


 Description   

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

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

Message:

This issue fixes an issue that occurs when merging entites, when the entity that is being merged has some other properties after a association type field.

Fixes the following scenario :
Your entity extends a parent entity and when it is merged by the entity manager first its fields are computed, this is done correctly bby `ReflectionPropertiesGetter::getProperties()`, but in the `mergeEntityStateIntoManagedCopy` method the iteration is stopped when it gets to a field that is a relationship and it is Proxy and was not loaded yet.
The order in which the fields are computed is : current class properties and then the parent properties, so if the current class has a lazy loaded relationship then the properties of the parent are not merged.

So the fix doesn't stop the iteration it just skips the current property that is not loaded yet and goes to the next property.



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

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

Comment by Doctrine Bot [ 15/Jul/15 ]

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





[DDC-3691] Filtering by 'date' column does not return enough values on SQLite Created: 14/Apr/15  Updated: 15/Jul/15

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

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

Windows 8.1 x64
PHP 5.6.2
date.timezone => Europe/Berlin


Attachments: Zip Archive sandbox.zip    

 Description   

When using a column of type 'date' in a where clause, filtering fails and does not return entries which clearly should match.

I have implemented a small proof of concept on the Doctrine sandbox. You can find it by checking out my branch at https://github.com/XitasoChris/doctrine2/tree/date_filter_bug and then run the tools/sandbox/index.php . Alternatively, I have zipped the sandbox folder and attached it to this bug report.

I don't know whether this affects other database systems as well. I only tested it on SQLite.



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

Linking the diff: https://github.com/doctrine/doctrine2/compare/master...XitasoChris:date_filter_bug

Should be a test case, XitasoChris - can you convert it?

Comment by XitasoChris [ 14/Apr/15 ]

@Marco: I will try, though I have never done that on the doctrine project before.

Comment by XitasoChris [ 14/Apr/15 ]

Test case created: https://github.com/doctrine/doctrine2/pull/1383

Comment by XitasoChris [ 17/Apr/15 ]

After some more debugging: The problem is that the type of the parameter is inferred as "datetime", leading Doctrine to format the value as "2015-03-01 00:00:00". However, SQLite needs the value formatted as "2015-03-01" to find a match.

A workaround is to tell Doctrine to format the parameter as a date [$queryBuilder->setParameter("date", $date, "date")] and then the test case works fine.

My question now is: is this behavior expected? If so, then the bug report is probably invalid.

Comment by Doctrine Bot [ 15/Jul/15 ]

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





[DDC-3692] [GH-1383] DDC-3691 add test case Created: 14/Apr/15  Updated: 15/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 XitasoChris:

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

Message:

Test case for DDC-3691



 Comments   
Comment by Doctrine Bot [ 15/Jul/15 ]

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





[DDC-3684] [GH-1381] Fixes ClassMetadata wakeupReflection with embeddable and StaticReflectio... Created: 11/Apr/15  Updated: 15/Jul/15  Resolved: 15/Jul/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: embeddables, metadata, reflection, serialize


 Description   

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

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

Message:

...nService

When the `StaticReflectionService` is used, then the wakeupReflection will cause an error with embedded properties. This is because the `getAccessibleProperty` method of the `StaticReflectionService` will always return null, so the parentReflFields will only have null values.

I found this problem when I was generating a Symfony form based on an entity with embedded properties.



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

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

Comment by Doctrine Bot [ 13/Apr/15 ]

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

Comment by Doctrine Bot [ 15/Jul/15 ]

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





[DDC-3683] [GH-1380] Fix issue with second-level-cache tests and versioned entities Created: 10/Apr/15  Updated: 15/Jul/15  Resolved: 15/Jul/15

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

Type: Bug Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: cache, testing, version

Issue Links:
Dependency
is required for DDC-3681 [GH-1378] Feature to force-increment ... Closed

 Description   

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

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

Message:

I'm not sure why this bug doesn't show normally `master`, but I ran across it with build [3930.1](https://travis-ci.org/doctrine/doctrine2/jobs/57975906), where it complained since `$targetPersister` was not an instance of `CachedPersister`.

The immediate fix seems straightforward, because `DefaultCollectionHydrator` doesn't even accept the second argument.

@FabioBatSilva : Please let me know if you see some better resolution to this, or if it indicates some edge-case in the second-level-cache logic that requires a new test.



 Comments   
Comment by Doctrine Bot [ 15/Jul/15 ]

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





[DDC-3828] Spl_object_hash conflict on Merge Created: 15/Jul/15  Updated: 15/Jul/15

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

Type: Bug Priority: Major
Reporter: Moroine Bentefrit Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: merge, orm, spl_object_hash, unitofwork


 Description   

I have created a PR: https://github.com/doctrine/doctrine2/pull/1461

Hi,

First of all, this is just a proposal and I'm sure there is a better solution for the problem described here. As this is my first hack into doctrine source code I'm not sure consequences that might be cause by my modification (even all unit tests passes).

I have encounter a problem due to spl_object_hash. I have written a functional test in order to reveal my issue.

The problem is when I merge an entity, here `$user`, UOW keep data on the original entity identified by it's spl_object_hash. Then if I unset this `$user` the spl_object_hash is now available for new object. So I experimented in my case reuse of previous hash which cause a `managed+dirty entity` error.

So I see two solutions

  • UOW keep reference to the entity given as even the given variable is unset there is remaining reference in UOW so the spl_hash will not be released.
  • Do not store data about the given entity, as merge operation isn't supposed to modified given entity.

I tried to implement the second solution as the first may consume a much more memory.

I don't why the merge operation need to do this, so I encapsulated it to prevent unwanted bug






[DDC-3827] [GH-1461] Spl_object_hash conflict on Merge Created: 15/Jul/15  Updated: 15/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 moroine:

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

Message:

Hi,

First of all, this is just a proposal and I'm sure there is a better solution for the problem described here. As this is my first hack into doctrine source code I'm not sure consequences that might be cause by my modification (even all unit tests passes).

I have encounter a problem due to spl_object_hash. I have written a functional test in order to reveal my issue.

The problem is when I merge an entity, here `$user`, UOW keep data on the original entity identified by it's spl_object_hash. Then if I unset this `$user` the spl_object_hash is now available for new object. So I experimented in my case reuse of previous hash which cause a `managed+dirty entity` error.

So I see two solutions

  • UOW keep reference to the entity given as even the given variable is unset there is remaining reference in UOW so the spl_hash will not be released.
  • Do not store data about the given entity, as merge operation isn't supposed to modified given entity.

I tried to implement the second solution as the first may consume a much more memory.

I don't why the merge operation need to do this, so I encapsulated it to prevent unwanted bug






[DDC-2408] [GH-649] Update coding standards Created: 21/Apr/13  Updated: 14/Jul/15  Resolved: 21/Apr/13

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

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

Issue Links:
Reference
relates to DDC-585 Create a coding standards document Open

 Description   

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

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

Message:

Removing underscores from property/method names and change use statements to PSR-2



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

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

Comment by Marco Pivetta [ 21/Apr/13 ]

merged

Comment by Doctrine Bot [ 04/Aug/14 ]

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

Comment by Doctrine Bot [ 04/Aug/14 ]

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





[DDC-3781] Fix Optimistic Locking Scenarios for Versioned Entities in Bidirectional Relationships Created: 18/Jun/15  Updated: 14/Jul/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
is referenced by DDC-3823 [GH-1456] No-frills support for Entit... Awaiting Feedback

 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.

Comment by Darien Hager [ 14/Jul/15 ]

I've submitted DDC-3823 as a possible precursor for this ticket. It exposes a mechanism for UOW to record that an entity is scheduled to have its version increased for some reason other than direct alterations.





[DDC-3823] [GH-1456] No-frills support for Entity version bumping Created: 14/Jul/15  Updated: 14/Jul/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: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: locking, persistence, versioned

Issue Links:
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/1456

Message:

A cut-down version of DDC-3640 / PR #1378

This PR focuses on the "support code", and does not contain any annotations or other mechanisms for knowing when an entity's version should be bumped in the absence of "direct" modifications. Instead, it provides a basic mechanism of:

$unitOfWork->scheduleForVersionBump($entity);
$unitOfWork->isScheduledForVersionBump();

This simple will allow advanced users can solve their problems with custom event-listeners, until someday when DDC-3781 defines an officially-sanctioned method for cascading version-changes across entities.






[DDC-3822] Nullable embeddables [Feature Request] Created: 13/Jul/15  Updated: 13/Jul/15

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

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


 Description   

I've noticed that when using embeddables that they are always created in the entity not matter what. For example, a User has a PhoneNumber(embeddable) and the PhoneNumber only has one field, "value". If it's reasonable for a User to not have a PhoneNumber in the system, then I don't believe a PhoneNumber instance should be created for the User entity when hydrated. If the value object's class has a __toString() method then you are forced to check if the value is null and if it is then return an empty string which is very hacky.

I propose to add a new "nullable" option to embeddables. If all of the columns that make up the embedded object are null then the embedded object should not be created if "nullable" is set to true.

Here's a gist illustrating the problem and the possible solution in yml.

https://gist.github.com/dadamssg/25714381e97220147ce2






[DDC-339] Parser incorrectly assumes arithmetic expression when finding lower(something) Created: 14/Feb/10  Updated: 13/Jul/15  Resolved: 20/Feb/10

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

Type: Bug Priority: Major
Reporter: Russ Flynn (rooster) Assignee: Roman S. Borschel
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates DDC-334 QueryBuilder throws QueryException wh... Closed

 Description   

$dql = "SELECT f FROM foo f WHERE f.something LIKE :str

works ok, but cannot be converted to a case insensitive search

$dql = "SELECT f FROM foo f WHERE lower(f.something) LIKE :str

Fails with syntax error (Expected =, <, <=, etc) got 'LIKE'



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

Reproduced with CMS Model Set:

    /**
     * @group DDC-339
     */
    public function testStringFunctionLikeExpression()
    {
        $this->assertSqlGeneration(
            "SELECT u.name FROM Doctrine\Tests\Models\CMS\CmsUser u WHERE LOWER(u.name) LIKE '%foo OR bar%'",
            ""
        );
    }
Comment by Roman S. Borschel [ 20/Feb/10 ]

Should be fixed in trunk.





[DDC-3820] [GH-1455] Update ExprTest.php Created: 13/Jul/15  Updated: 13/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 xoeoro:

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

Message:

expr()->countDistinct allows to create COUNT(DISTINCT) expression with mulltiple fields but parser requires only one field.

\Doctrine\ORM\Query\Parser::AggregateExpression

some body, please, fix this problem






[DDC-3819] [GH-1454] Add test for DDC-3818 - Paginator fails to retrieve entities linked with One-To-Many Created: 10/Jul/15  Updated: 10/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 odoucet:

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

Message:

Please see http://www.doctrine-project.org/jira/browse/DDC-3818

Reminder : using a DQL query with WHERE on a One-To-Many relationship fails to retrieve full object.

This went unseen in previous tests because cache is used to retrieve the originating object.






[DDC-3817] hydrating many-to-many relation crashes, when trying to access auto created adder with collection (instead of single entity) Created: 10/Jul/15  Updated: 10/Jul/15  Resolved: 10/Jul/15

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

Type: Bug Priority: Minor
Reporter: Stefan T. Assignee: Steve Müller
Resolution: Duplicate Votes: 0
Labels: AllowRemoveByValue, ArrayCollection, DoctrineModule, EntityGenerator, Hydrator, ORM, Stdlib, Strategy, Tools, add, generateEntityStubMethods, hydrate, remove, to-many
Environment:

doctrine-module 0.8.1
zend-framework 2.5.1
PHP 5.5.12
Apache 2.4.9 (Win64)
WampServer 2.5



 Description   

my concern

IF Doctrine\ORM\Tools\EntityGenerator::generateEntityStubMethods (auto) generates adder, which will expect the parameter to be target entity

WHY would DoctrineModule\Stdlib\Hydrator\Strategy\AllowRemoveByValue::hydrate call this very same adder, passing an ArrayCollection

auto generated code:

abstract entity
public function addAnotherEntity(\NameSpace\Entity\AnotherEntity $xy)
{
    $this->anotherEntity[] = $xy;
}

outline of a (quick) workaround:

abstract entity
public function addAnotherEntity($xy)
{
    if($xy instanceof \NameSpace\Entity\AnotherEntity)
        $this->anotherEntity[] = $xy;
    if($xy instanceof \Doctrine\Common\Collections\ArrayCollection)
        foreach($xy as $entity)
            $this->anotherEntity[] = $entity;
}

(Same goes for removing elements from any "to-many"-collection.)

my question\s

Did I miss something on my way?
Is there any way to "enable" some kind of "multi-adding"?
Is there any chance to (further) influence that adding-part with my xml declaration?

Any advice is very welcome.

Maybe I could write my own EntityGenerator. Maybe I should use a custom Hydrator. But right now it seems to me like a little inconsistency in the library.



 Comments   
Comment by Stefan T. [ 10/Jul/15 ]

created twice (maybe a subconscious double click)





[DDC-3816] hydrating many-to-many relation crashes, when trying to access auto created adder with collection (instead of single entity) Created: 10/Jul/15  Updated: 10/Jul/15

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

Type: Bug Priority: Minor
Reporter: Stefan T. Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: AllowRemoveByValue, ArrayCollection, DoctrineModule, EntityGenerator, Hydrator, ORM, Stdlib, Strategy, Tools, add, generateEntityStubMethods, hydrate, remove, to-many
Environment:

doctrine-module 0.8.1
zend-framework 2.5.1
PHP 5.5.12
Apache 2.4.9 (Win64)
WampServer 2.5



 Description   

my concern

IF Doctrine\ORM\Tools\EntityGenerator::generateEntityStubMethods (auto) generates adder, which will expect the parameter to be target entity

WHY would DoctrineModule\Stdlib\Hydrator\Strategy\AllowRemoveByValue::hydrate call this very same adder, passing an ArrayCollection

auto generated code:

abstract entity
public function addAnotherEntity(\NameSpace\Entity\AnotherEntity $xy)
{
    $this->anotherEntity[] = $xy;
}

outline of a (quick) workaround:

abstract entity
public function addAnotherEntity($xy)
{
    if($xy instanceof \NameSpace\Entity\AnotherEntity)
        $this->anotherEntity[] = $xy;
    if($xy instanceof \Doctrine\Common\Collections\ArrayCollection)
        foreach($xy as $entity)
            $this->anotherEntity[] = $entity;
}

(Same goes for removing elements from any "to-many"-collection.)

my question\s

Did I miss something on my way?
Is there any way to "enable" some kind of "multi-adding"?
Is there any chance to (further) influence that adding-part with my xml declaration?

Any advice is very welcome.

Maybe I could write my own EntityGenerator. Maybe I should use a custom Hydrator. But right now it seems to me like a little inconsistency in the library.






[DDC-3815] setParameter switching values Created: 09/Jul/15  Updated: 09/Jul/15

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

Type: Bug Priority: Major
Reporter: erik willems Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dql, orm
Environment:

zend framework 2



 Description   

It seems that doctrine sets parameters in a wrong order. I have the following parameter array:

$params = array(
1 => array(1, 2, 3, 4, 5, 6),
2 => array(150, 12, 130),
3 => 'CALLED',
4 => array('ND', 'PF', 'OS'),
5 => '2015-07-02 00:00:00',
6 => '2015-07-05 00:00:00'
);

And i have the following query

$query = $this->getEntityManager()->createQuery('
SELECT c FROM Customers\Entity\Customer c
WHERE c.customer_categories_id IN(?1)
AND c.countries_id IN(?2)
AND c.state = ?3
AND c.potential_diamonds IN(?4)
AND c.last_call NOT BETWEEN ?5 AND ?6
');

And this is the final query:

SELECT c0_.id AS id_0, c0_.company AS company_1, c0_.vat_number AS vat_number_2, c0_.first_name AS first_name_3, c0_.last_name AS last_name_4, c0_.phone AS phone_5, c0_.phone2 AS phone2_6, c0_.mobile AS mobile_7, c0_.email AS email_8, c0_.email2 AS email2_9, c0_.fax AS fax_10, c0_.address AS address_11, c0_.address2 AS address2_12, c0_.postal_code AS postal_code_13, c0_.town AS town_14, c0_.province AS province_15, c0_.countries_id AS countries_id_16, c0_.customer_titles_id AS customer_titles_id_17, c0_.customer_categories_id AS customer_categories_id_18, c0_.present_list AS present_list_19, c0_.vip_list AS vip_list_20, c0_.previous_sold AS previous_sold_21, c0_.previous_bought AS previous_bought_22, c0_.opening_hours AS opening_hours_23, c0_.main_office AS main_office_24, c0_.newsletter AS newsletter_25, c0_.website AS website_26, c0_.`state` AS state_27, c0_.potential_diamonds AS potential_diamonds_28, c0_.remarks AS remarks_29, c0_.date_created AS date_created_30, c0_.date_changed AS date_changed_31, c0_.last_call AS last_call_32, c0_.customer_languages_id AS customer_languages_id_33, c0_.display_state AS display_state_34, c0_.longitude AS longitude_35, c0_.latitude AS latitude_36 FROM customers c0_ WHERE c0_.customer_categories_id IN ('ND', '2015-07-05 00:00:00', 'CALLED', 130, 130, 'CALLED') AND c0_.countries_id IN ('ND', '2015-07-05 00:00:00', '2015-07-02 00:00:00') AND c0_.`state` = 'PF' AND c0_.potential_diamonds IN ('2015-07-02 00:00:00', 'OS', 'PF') AND c0_.last_call NOT BETWEEN 'OS' AND 12

if we look in the WHERE part of the query than we see that the parameters are completely flipped. This is very strange. does anyone have an explanation for this or have the same problem? There is not much to find on google.

Thanks in advance






[DDC-3814] counting inverse column of in dql Created: 08/Jul/15  Updated: 08/Jul/15

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

Type: Bug Priority: Major
Reporter: Maximilian Bosch Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: collection, dql, mysql, orm

Attachments: PNG File doctrine-query.PNG     PNG File dql-fail.PNG    

 Description   

I have a self-referenced bidirectional relation in order to show users and their followers. Now I'd like to show the users with the most followers.
But when executing the unit test, doctrine2 tells me that the inverse column user.followers is not valid.

On the first attachement you can see the code. This fetches the user entity and the amount of followers hidden (the followers column is not the owning side, but the inversed column).
On the second picture you can see the complete error message and the call stack






[DDC-3813] [GH-1453] Filter factory added Created: 08/Jul/15  Updated: 08/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 TomasVotruba:

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

Message:

This proposal is to allow DI/IOC support for filters.
Based on #1129, resp. https://github.com/doctrine/doctrine2/pull/1129#issuecomment-54178893

I don't have Doctrine coding standard under my skin yet, so feel free to comment as well.
I look forward for any feedback.






[DDC-3812] [GH-1452] composer: dev is now by default Created: 08/Jul/15  Updated: 08/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 TomasVotruba:

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

Message:






[DDC-3810] [GH-1450] [DX] Link annotation ref to locking explanation Created: 07/Jul/15  Updated: 07/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 davidfuhr:

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

Message:

The annotation reference contained no cross reference to the great
transaction and concurrency page. But this might be very useful for the
reader.






[DDC-3809] Notice: Undefined index in /lib/Doctrine/ORM/Query/SqlWalker.php at line 1920 Created: 07/Jul/15  Updated: 07/Jul/15  Resolved: 07/Jul/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: Major
Reporter: Dalibor Karlović Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None


 Description   

I have two entities, AchievementGoal & AchievementLevel, like so:

/**
 * AchievementLevel
 * @ORM\Table("achievements_levels")
 * @ORM\Entity
 * @ORM\Entity(repositoryClass="AppBundle\Entity\AchievementLevelRepository")
 */
class AchievementLevel
{
    /**
     * @ORM\OneToMany(targetEntity="AppBundle\Entity\AchievementGoal", mappedBy="achievementLevel")
     **/
    private $goals;

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

/**
 * AchievementGoal
 * @ORM\Table("achievements_goals")
 * @ORM\Entity
 */
class AchievementGoal
{
    /**
     * @var AchievementLevel
     * @ORM\Id
     * @ORM\ManyToOne(targetEntity="AppBundle\Entity\AchievementLevel", inversedBy="goals")
     * @ORM\Column(name="achievement_level_id")
     */
    private $achievementLevel;

    /**
     * @var Variable
     * @ORM\Id
     * @ORM\ManyToOne(targetEntity="AppBundle\Entity\Variable")
     */
    private $variable;
}

When I try to do query like:

        $qb = $this->getEntityManager()->createQueryBuilder();
        $qb->select('l')
            ->from('AppBundle:AchievementLevel', 'l')
            ->where('EXISTS (
                SELECT g FROM AppBundle:AchievementGoal g WHERE g MEMBER OF l.goals
            )');

I get the error:
Notice: Undefined index: achievementLevel in vendor/doctrine/orm/lib/Doctrine/ORM/Query/SqlWalker.php at line 1920. There seems to be a problem when using both @Id and @Column on the property, if I remove either one, it works (throws some other error, but unrelated to this).



 Comments   
Comment by Dalibor Karlović [ 07/Jul/15 ]

Well, this is awkward. It seems I used @Column instead of @JoinColumn. Only figured it out once I saw Symfony toolbar said I have an invalid mapping. Is there a way for a error to be thrown here?

Hope this helps someone, closing.

Comment by Dalibor Karlović [ 07/Jul/15 ]

Invalid issue, using @Column instead of @JoinColumn. Should trigger an error if possible here, though.





[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-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-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-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... Resolved
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: