[DDC-2520] [GH-705] [DDC-2519] Partial association identifier Created: 20/Jun/13 Updated: 20/Jun/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Doctrine Bot | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of FabioBatSilva: Url: https://github.com/doctrine/doctrine2/pull/705 Message: http://www.doctrine-project.org/jira/browse/DDC-2519 |
[DDC-2519] Unable to DQL SELECT PARTIAL entity with association identifier Created: 19/Jun/13 Updated: 20/Jun/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | DQL |
| Affects Version/s: | 2.3.4 |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Gordon Forsythe | Assignee: | Fabio B. Silva |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Ubuntu, OSX, PHP5.4.x |
||
| Description |
|
Entity\Person: id, name, etc Trying DQL: FROM Entity\User u |
[DDC-1398] loading one item at a time when indexBy and EXTRA_LAZY fetch mode is used on a collection Created: 29/Sep/11 Updated: 19/Jun/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | None |
| Fix Version/s: | 2.x |
| Security Level: | All |
| Type: | Improvement | Priority: | Major |
| Reporter: | Reio Piller | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 3 |
| Labels: | None | ||
| Description |
|
collection->get($key) Atm in 2.1.2 this is loading the entire collection. It would be really handy that it would extra lazy load only one item using the association and indexBy fields and given key value (if collection is not initialized and the key havent been loaded yet ofc) Am i making sense with this? |
| Comments |
| Comment by Guilherme Blanco [ 20/Dec/11 ] |
|
Updating fix version |
| Comment by German Caseres [ 05/Mar/12 ] |
|
Is there any fix for this? i have the same problem. |
| Comment by Oleg Namaka [ 10/Mar/12 ] |
|
It makes a perfect sense here, I wish it was possible, it would give us a room for even more optimization. Any input on the issue from the developers? |
| Comment by Sander Marechal [ 19/Jun/13 ] |
|
Any progress on this? I'd love to have get() that works on EXTRA_LAZY collections. |
| Comment by Marco Pivetta [ 19/Jun/13 ] |
|
Sander Marechal pull requests are welcome |
[DDC-2517] [GH-703] Clear visitedCollections Created: 19/Jun/13 Updated: 19/Jun/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Doctrine Bot | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of shulcsm: Url: https://github.com/doctrine/doctrine2/pull/703 Message: Visited collections are cleared only in commit(). Commit clears up only if it actually has something to do. Processing large amounts of records without changing them cause visitedCollections to grow without any way of clearing. |
[DDC-2516] Undefined offset in ObjectHydrator while working with iterableResult Created: 19/Jun/13 Updated: 19/Jun/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | 2.3.4 |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Johanny Clerc-Renaud | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | orm | ||
| Environment: |
using Symfony2 |
||
| Description |
|
Following this documentation page http://doctrine-orm.readthedocs.org/en/2.0.x/reference/batch-processing.html#iterating-large-results-for-data-processing I tried to create a batch process on 75k entities. But an error came in the ObjectHydrator on line 511 there's an Undefined offset. Now, i just use the SimpleObjectHydrator and it solve the problem. but i'm wondering if it's a real bug or just a miss use of Doctrine. |
[DDC-2515] Schema tool ignores index names in mapping file and uses generated name Created: 18/Jun/13 Updated: 18/Jun/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM, Tools |
| Affects Version/s: | 2.3.4 |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Minor |
| Reporter: | Daniel Huss | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
I have defined an index on a foreign key colum in my .dcm.xml mapping file: <indexes> <index name="ix_date_created__client_id" columns="date_created,client_id"/> <index name="ix_user_id" columns="user_id"/> </indexes> However, the resulting CREATE TABLE statement includes:
INDEX IDX_4848DD9FA76ED395 (user_id),
INDEX IDX_4848DD9F4239E22F (accessgroup_id),
INDEX IDX_4848DD9FD2112630 (usergroup_id),
INDEX ix_date_created__client_id (date_created, client_id),
So Doctrine seems to be auto-generating indexes for all foreign key columns. I'm assuming this is a feature, even though I'd argue that there are real-life examples where the mere presence of a foreign key constraint does not justify indexing that column. Anyway, the expected behavior is that Doctrine does not replace existing indexes with generated ones. I will attach a failing test case unless this bug is immediately dismissed as wontfix. |
[DDC-2513] [GH-702] ANSI compliant quote strategy Created: 18/Jun/13 Updated: 18/Jun/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Doctrine Bot | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of FabioBatSilva: Url: https://github.com/doctrine/doctrine2/pull/702 Message: |
[DDC-2509] Add CLI detection for the APC check on Console cache commands Created: 17/Jun/13 Updated: 17/Jun/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | Tools |
| Affects Version/s: | 2.3.4 |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Jonathan Cardoso Machado | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
There is some instanceof checks on the \Doctrine\ORM\Tools\Console\Command\ClearCache* commands to detect if APC is being used, they were introduced here: https://github.com/doctrine/doctrine2/commit/8efae0b232210b27200f2709e7fcb24c7f02c5de I would like to know if it's possible to add a CLI check too, something like: if ($cacheDriver instanceof Cache\ApcCache && PHP_SAPI === 'cli' ) Yeah, I know that those are CLI commands, and so the check looks like unecessary, however, in the particular case that I found it's necessary, I'm running the commands under an WebUI: After: |
| Comments |
| Comment by Marco Pivetta [ 17/Jun/13 ] |
|
CLI commands are not meant to be used in WEB environment (at least not the Symfony CLI ones). You should probably replicate that logic instead. |
[DDC-2506] WITH Conditionals on Class Table Inheritance LEFT JOINs are inserted incorrectly Created: 14/Jun/13 Updated: 14/Jun/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | DQL |
| Affects Version/s: | Git Master |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Matt Janssen | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | dql, inheritance, joins, sql-walker | ||
| Description |
|
The following JOIN JOIN c.ctiRelationship cti WITH cti.id IN (42) generates unexpected SQL LEFT JOIN class_base p1_ ON u1_.cti_id = p1_.id LEFT JOIN class_child1 p2_ ON p1_.id = p2_.id LEFT JOIN class_child2 p3_ ON p1_.id = p3_.id AND (p1_.id IN (42)) when it SHOULD be generating LEFT JOIN class_base p1_ ON u1_.cti_id = p1_.id AND (p1_.id IN (42)) LEFT JOIN class_child1 p2_ ON p1_.id = p2_.id LEFT JOIN class_child2 p3_ ON p1_.id = p3_.id |
| Comments |
| Comment by Matt Janssen [ 14/Jun/13 ] |
[DDC-2507] [GH-698] Fix for [DDC-2506] CTI JOINs and WITH conditionals Created: 14/Jun/13 Updated: 14/Jun/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Doctrine Bot | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of mattjanssen: Url: https://github.com/doctrine/doctrine2/pull/698 Message: http://www.doctrine-project.org/jira/browse/DDC-2506 Moved the `SqlWalker::walkConditionalExpression()` out of `walkJoin()` and into `walkJoinAssociationDeclaration()` after the base class JOIN but *before* the `_generateClassTableInheritanceJoins()`, thus allowing WITH conditions in Class Table Inheritance joins to apply correctly. On a side note, I'm not able to get phpunit to run (even on a clean Master) so I'm leaving the testing up to Travis. |
[DDC-2505] [GH-697] Fix phpDoc syntax in ClassMetadataInfo.php Created: 14/Jun/13 Updated: 14/Jun/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Doctrine Bot | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of michaelperrin: Url: https://github.com/doctrine/doctrine2/pull/697 Message: |
| Comments |
| Comment by Doctrine Bot [ 14/Jun/13 ] |
|
A related Github Pull-Request [GH-697] was closed: |
[DDC-2504] [GH-696] extra lazy joined test Created: 14/Jun/13 Updated: 14/Jun/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Doctrine Bot | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of Padam87: Url: https://github.com/doctrine/doctrine2/pull/696 Message: Hi, This is just a bug report, not an actual PR, you don't have to merge. When you have a JOINED inheritance, and you have another class, which is related to the parent class of the inheritance, and you only have an association for one of the child classes, EXTRA_LAZY fetch mode creates a fatal error, because it is not joining the parent table to the count query. There are many ways around this fortunately, but I thought I should report it anyway. |
[DDC-2484] Lazy loaded associated entities do not trigger the postLoad event Created: 03/Jun/13 Updated: 13/Jun/13 |
|
| Status: | Awaiting Feedback |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | Git Master |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Tom Anderson | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | event, orm | ||
| Description |
|
An entity retrieved with $entity = $em->find will correctly trigger the postLoad event but an entity associated with that entity $association = $entity->association which is lazy loaded will retrieve and return the associated entity without triggering postLoad. Eager loading does follow the lifecycle path of triggering postLoad. Functional Test: |
| Comments |
| Comment by Fabio B. Silva [ 10/Jun/13 ] |
|
Hi Tom, You CANNOT check the entity class by using get_class, doctrine uses the pattern proxy to delay the load from database. Then $args->getEntity() might be a different class that extends your entity $entity = $args->getEntity(); if ($entity instanceof DDC2484_Car) { $entity->setBrand('BMW'); } Also when you try to load the same entity more than once : $eagerDriver->getCar(); $lazyDriver->getCar(); The entity will be cached at the first time, triggering onLoad just once. It means that the entity will be always the same instance, assertSame($eagerDriver->getCar(), $lazyDriver->getCar()); |
[DDC-1413] Automatically create index for discriminator column Created: 11/Oct/11 Updated: 12/Jun/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM, Tools |
| Affects Version/s: | 2.1.2 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Minor |
| Reporter: | A.J. Brown | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | None | ||
| Description |
|
It would be nice if the command line orm schema-tool would suggest an index on the discriminator column for single inheritance tables. Since that column would almost always be in the query, I can't think of a case when you wouldn't want it to be in an index |
| Comments |
| Comment by Menno Holtkamp [ 12/Jun/13 ] |
|
This topic suggests it is a bad practice though: In case of a big STI hierarchy, this might become usefull, additional testing required. However, as soons as a STI hierarchy becomes big, Class Table Inheritance might be more appropriate... |
[DDC-2486] Getting started does not work with current release Created: 04/Jun/13 Updated: 11/Jun/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | 2.3.4 |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Documentation | Priority: | Major |
| Reporter: | Julian Picht | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
The tutorial states: "This tutorial assumes you work with Doctrine 2.3 and above. Some of the code will not work with lower versions." I'm using 2.3.4 When running "php vendor/bin/doctrine orm:schema-tool:create" this happens: PHP Fatal error: Call to undefined method Doctrine\ORM\Tools\Console\ConsoleRunner::createHelperSet() in /var/www/project/cli-config.php on line 5 PHP 2. include() /var/www/project/vendor/doctrine/orm/bin/doctrine:4 PHP 3. require() /var/www/project/vendor/doctrine/orm/bin/doctrine.php:31 Fatal error: Call to undefined method Doctrine\ORM\Tools\Console\ConsoleRunner::createHelperSet() in /var/www/project/cli-config.php on line 5 Call Stack: 0.0001 619840 1. {main} () /var/www/project/vendor/doctrine/orm/bin/doctrine:0 This is because some commits are not yet in the release. The current GIT version probably works but is not an option for me. |
| Comments |
| Comment by Benton Jackson [ 11/Jun/13 ] |
|
I'm seeing this problem too. Kinda hard to learn Doctrine when the tutorial is brain dead. |
| Comment by Benton Jackson [ 11/Jun/13 ] |
|
"CreateHelperSet" appears to be a method in 2.4. I adapted the "2.3 configuring the command line" code to make my "cli-config.php" file read like this, and it appears to work: <?php $em = $entityManager; $helperSet = new \Symfony\Component\Console\Helper\HelperSet(array( |
[DDC-2387] convert-mapping not working correctly with composite primary keys/foreign keys in 2.4.0-RC1 Created: 03/Apr/13 Updated: 11/Jun/13 |
|
| Status: | Reopened |
| Project: | Doctrine 2 - ORM |
| Component/s: | Mapping Drivers |
| Affects Version/s: | None |
| Fix Version/s: | 2.3.4 |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Nicholas Van Dusen | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | None | ||
| Environment: |
Symfony 2.2.0, MySQL 5.1 |
||
| Description |
|
(Apologies if this is somehow a Symfony-specific issue) I updated my application via Composer yesterday, and received Doctrine 2.4.0-RC1. After this update, generating entities has been problematic under certain circumstances. Here is an example table in MySQL: CREATE TABLE `user_email` ( `user_id` int(10) unsigned NOT NULL COMMENT 'FK to user', `email` varchar(254) NOT NULL, `email_datasource` smallint(1) unsigned NOT NULL COMMENT 'FK to datasource_code', `insert_date` datetime NOT NULL, PRIMARY KEY (`user_id`,`email`,`email_datasource`), KEY `FK_UserEmail_DataSourceCode` (`email_datasource`), CONSTRAINT `FK_UserEmail_User` FOREIGN KEY (`user_id`) REFERENCES `user` (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 In Doctrine 2.3, the mapping works correctly, and you end up with a 3-part primary key, with a user property mapped to the User entity, and a datasourceCode property mapped to the DatasourceCode entity. All good. In 2.4, the following error is given: Single id is not allowed on composite primary key in entity UserEmail. Removing one of the foreign keys in the table (either to User or DatasourceCode) but keeping the primary key set to all 3 columns allows the mapping to work. But, if you then remove one of the columns from the primary key (say, email_datasource) it fails again. |
| Comments |
| Comment by Benjamin Eberlei [ 04/Apr/13 ] |
|
Can you provide the full stack trace to the exception please? $e->getTraceAsString(); |
| Comment by Nicholas Van Dusen [ 11/Apr/13 ] |
|
Benjamin, I'm not sure how to get the trace for you, since I'm running from inside the Symfony2 doctrine:mapping:import command line item. |
| Comment by Christophe Coevoet [ 11/Apr/13 ] |
|
Use the --verbose option when running the command |
| Comment by Nicholas Van Dusen [ 11/Apr/13 ] |
|
I was able to get a trace for you: #0 /var/www/html/voxrepublic/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php(1571): Doctrine\ORM\Mapping\MappingException::singleIdNotAllowedOnCompositePrimaryKey('UserEmail') #1 /var/www/html/voxrepublic/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php(422): Doctrine\ORM\Mapping\ClassMetadataInfo->getSingleIdentifierFieldName() #2 /var/www/html/voxrepublic/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php(136): Doctrine\ORM\Mapping\ClassMetadataFactory->completeIdGeneratorMapping(Object(Doctrine\ORM\Mapping\ClassMetadata)) #3 /var/www/html/voxrepublic/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php(302): Doctrine\ORM\Mapping\ClassMetadataFactory->doLoadMetadata(Object(Doctrine\ORM\Mapping\ClassMetadata), NULL, false, Array) #4 /var/www/html/voxrepublic/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php(212): Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->loadMetadata('UserEmail') #5 /var/www/html/voxrepublic/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php(112): Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->getMetadataFor('UserEmail') #6 /var/www/html/voxrepublic/vendor/doctrine/doctrine-bundle/Doctrine/Bundle/DoctrineBundle/Command/ImportMappingDoctrineCommand.php(108): Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->getAllMetadata() #7 /var/www/html/voxrepublic/vendor/symfony/symfony/src/Symfony/Component/Console/Command/Command.php(240): Doctrine\Bundle\DoctrineBundle\Command\ImportMappingDoctrineCommand->execute(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) #8 /var/www/html/voxrepublic/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php(195): Symfony\Component\Console\Command\Command->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) #9 /var/www/html/voxrepublic/vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Console/Application.php(78): Symfony\Component\Console\Application->doRun(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) #10 /var/www/html/voxrepublic/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php(106): Symfony\Bundle\FrameworkBundle\Console\Application->doRun(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) #11 /var/www/html/voxrepublic/app/console(22): Symfony\Component\Console\Application->run(Object(Symfony\Component\Console\Input\ArgvInput)) #12 {main} |
| Comment by Benjamin Eberlei [ 14/Apr/13 ] |
|
The problem is that Doctrine seems to detect that you only have on id field on this entity and then a new function of 2.4 throws this error. I will try to reproduce this with your table. Until then could you show me the var_dump() of the $class variable in Doctrine\ORM\ClassMetadataFactory#completeIdGeneratorMapping()? This would help very much already. |
| Comment by Maximilian Beck [ 15/Apr/13 ] |
|
I have the same error when using "doctrine:mapping:import" CREATE TABLE IF NOT EXISTS `dev_Recipe`.`step` (
`recipe_id` INT NOT NULL ,
`step_number` INT NOT NULL ,
`description` TEXT NULL ,
`timer` INT NULL ,
`image` VARCHAR(100) NULL ,
PRIMARY KEY (`recipe_id`, `step_number`) ,
INDEX `recipe_id_idx` (`recipe_id` ASC) ,
INDEX `step_number` (`step_number` ASC) ,
CONSTRAINT `step_recipe_id`
FOREIGN KEY (`recipe_id` )
REFERENCES `dev_Recipe`.`recipe` (`recipe_id` )
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
Exception trace: () at \htdocs\SF2\vendor\doctrine\orm\lib\Doctrine\ORM\Mapping\MappingException.php:258 Doctrine\ORM\Mapping\MappingException::singleIdNotAllowedOnCompositePrimaryKey() at \htdocs\SF2\vendor\doctrine\orm\lib\Doctrine\ORM\Mapping\ClassMetadataInfo.php:1571 Doctrine\ORM\Mapping\ClassMetadataInfo->getSingleIdentifierFieldName() at \htdocs\SF2\vendor\doctrine\orm\lib\Doctrine\ORM\Mapping\ClassMetadataFactory.php:422 Doctrine\ORM\Mapping\ClassMetadataFactory->completeIdGeneratorMapping() at \htdocs\SF2\vendor\doctrine\orm\lib\Doctrine\ORM\Mapping\ClassMetadataFactory.php:136 Doctrine\ORM\Mapping\ClassMetadataFactory->doLoadMetadata() at \htdocs\SF2\vendor\doctrine\common\lib\Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory.php:302 Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->loadMetadata() at \htdocs\SF2\vendor\doctrine\common\lib\Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory.php:212 Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->getMetadataFor() at \htdocs\SF2\vendor\doctrine\common\lib\Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory.php:112 Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->getAllMetadata() at \htdocs\SF2\vendor\doctrine\orm\lib\Doctrine\ORM\Tools\Console\Command\ConvertMappingCommand.php:126 Doctrine\ORM\Tools\Console\Command\ConvertMappingCommand->execute() at \htdocs\SF2\vendor\doctrine\doctrine-bundle\Doctrine\Bundle\DoctrineBundle\Command\Proxy\ConvertMappingDoctrineCommand.php:59 Doctrine\Bundle\DoctrineBundle\Command\Proxy\ConvertMappingDoctrineCommand->execute() at \htdocs\SF2\vendor\symfony\symfony\src\Symfony\Component\Console\Command\Command.php:240 Symfony\Component\Console\Command\Command->run() at \htdocs\SF2\vendor\symfony\symfony\src\Symfony\Component\Console\Application.php:193 Symfony\Component\Console\Application->doRun() at \htdocs\SF2\vendor\symfony\symfony\src\Symfony\Bundle\FrameworkBundle\Console\Application.php:78 Symfony\Bundle\FrameworkBundle\Console\Application->doRun() at \htdocs\SF2\vendor\symfony\symfony\src\Symfony\Component\Console\Application.php:106 Symfony\Component\Console\Application->run() at \htdocs\SF2\app\console:22 "var_dump($class);" returns: object(Doctrine\ORM\Mapping\ClassMetadata)#470 (36) {
["name"]=>
string(10) "Ingredient"
["namespace"]=>
string(0) ""
["rootEntityName"]=>
string(10) "Ingredient"
["customGeneratorDefinition"]=>
NULL
["customRepositoryClassName"]=>
NULL
["isMappedSuperclass"]=>
bool(false)
["parentClasses"]=>
array(0) {
}
["subClasses"]=>
array(0) {
}
["namedQueries"]=>
array(0) {
}
["namedNativeQueries"]=>
array(0) {
}
["sqlResultSetMappings"]=>
array(0) {
}
["identifier"]=>
array(1) {
[0]=>
string(12) "ingredientId"
}
["inheritanceType"]=>
int(1)
["generatorType"]=>
int(1)
["fieldMappings"]=>
array(4) {
["ingredientId"]=>
array(6) {
["id"]=>
bool(true)
["fieldName"]=>
string(12) "ingredientId"
["columnName"]=>
string(13) "ingredient_id"
["type"]=>
string(7) "integer"
["unsigned"]=>
bool(false)
["nullable"]=>
bool(false)
}
["name"]=>
array(6) {
["fieldName"]=>
string(4) "name"
["columnName"]=>
string(4) "name"
["type"]=>
string(6) "string"
["length"]=>
int(45)
["fixed"]=>
bool(false)
["nullable"]=>
bool(false)
}
["color"]=>
array(5) {
["fieldName"]=>
string(5) "color"
["columnName"]=>
string(5) "color"
["type"]=>
string(7) "integer"
["unsigned"]=>
bool(false)
["nullable"]=>
bool(false)
}
["img"]=>
array(6) {
["fieldName"]=>
string(3) "img"
["columnName"]=>
string(3) "img"
["type"]=>
string(6) "string"
["length"]=>
int(45)
["fixed"]=>
bool(false)
["nullable"]=>
bool(true)
}
}
["fieldNames"]=>
array(4) {
["ingredient_id"]=>
string(12) "ingredientId"
["name"]=>
string(4) "name"
["color"]=>
string(5) "color"
["img"]=>
string(3) "img"
}
["columnNames"]=>
array(4) {
["ingredientId"]=>
string(13) "ingredient_id"
["name"]=>
string(4) "name"
["color"]=>
string(5) "color"
["img"]=>
string(3) "img"
}
["discriminatorValue"]=>
NULL
["discriminatorMap"]=>
array(0) {
}
["discriminatorColumn"]=>
NULL
["table"]=>
array(1) {
["name"]=>
string(10) "ingredient"
}
["lifecycleCallbacks"]=>
array(0) {
}
["associationMappings"]=>
array(1) {
["ingredientCategory"]=>
array(15) {
["fieldName"]=>
string(18) "ingredientCategory"
["targetEntity"]=>
string(18) "IngredientCategory"
["mappedBy"]=>
string(10) "ingredient"
["type"]=>
int(8)
["inversedBy"]=>
NULL
["isOwningSide"]=>
bool(false)
["sourceEntity"]=>
string(10) "Ingredient"
["fetch"]=>
int(2)
["cascade"]=>
array(0) {
}
["isCascadeRemove"]=>
bool(false)
["isCascadePersist"]=>
bool(false)
["isCascadeRefresh"]=>
bool(false)
["isCascadeMerge"]=>
bool(false)
["isCascadeDetach"]=>
bool(false)
["orphanRemoval"]=>
bool(false)
}
}
["isIdentifierComposite"]=>
bool(false)
["containsForeignIdentifier"]=>
bool(false)
["idGenerator"]=>
NULL
["sequenceGeneratorDefinition"]=>
NULL
["tableGeneratorDefinition"]=>
NULL
["changeTrackingPolicy"]=>
int(1)
["isVersioned"]=>
NULL
["versionField"]=>
NULL
["reflClass"]=>
NULL
["isReadOnly"]=>
bool(false)
["namingStrategy":protected]=>
object(Doctrine\ORM\Mapping\DefaultNamingStrategy)#258 (0) {
}
["reflFields"]=>
array(0) {
}
["_prototype":"Doctrine\ORM\Mapping\ClassMetadataInfo":private]=>
NULL
}
object(Doctrine\ORM\Mapping\ClassMetadata)#472 (36) {
["name"]=>
string(18) "IngredientCategory"
["namespace"]=>
string(0) ""
["rootEntityName"]=>
string(18) "IngredientCategory"
["customGeneratorDefinition"]=>
NULL
["customRepositoryClassName"]=>
NULL
["isMappedSuperclass"]=>
bool(false)
["parentClasses"]=>
array(0) {
}
["subClasses"]=>
array(0) {
}
["namedQueries"]=>
array(0) {
}
["namedNativeQueries"]=>
array(0) {
}
["sqlResultSetMappings"]=>
array(0) {
}
["identifier"]=>
array(1) {
[0]=>
string(2) "id"
}
["inheritanceType"]=>
int(1)
["generatorType"]=>
int(1)
["fieldMappings"]=>
array(3) {
["id"]=>
array(6) {
["id"]=>
bool(true)
["fieldName"]=>
string(2) "id"
["columnName"]=>
string(2) "id"
["type"]=>
string(7) "integer"
["unsigned"]=>
bool(false)
["nullable"]=>
bool(false)
}
["name"]=>
array(6) {
["fieldName"]=>
string(4) "name"
["columnName"]=>
string(4) "name"
["type"]=>
string(6) "string"
["length"]=>
int(255)
["fixed"]=>
bool(false)
["nullable"]=>
bool(false)
}
["description"]=>
array(4) {
["fieldName"]=>
string(11) "description"
["columnName"]=>
string(11) "description"
["type"]=>
string(4) "text"
["nullable"]=>
bool(true)
}
}
["fieldNames"]=>
array(3) {
["id"]=>
string(2) "id"
["name"]=>
string(4) "name"
["description"]=>
string(11) "description"
}
["columnNames"]=>
array(3) {
["id"]=>
string(2) "id"
["name"]=>
string(4) "name"
["description"]=>
string(11) "description"
}
["discriminatorValue"]=>
NULL
["discriminatorMap"]=>
array(0) {
}
["discriminatorColumn"]=>
NULL
["table"]=>
array(1) {
["name"]=>
string(19) "ingredient_category"
}
["lifecycleCallbacks"]=>
array(0) {
}
["associationMappings"]=>
array(2) {
["ingredient"]=>
array(19) {
["fieldName"]=>
string(10) "ingredient"
["targetEntity"]=>
string(10) "Ingredient"
["inversedBy"]=>
string(18) "ingredientCategory"
["joinTable"]=>
array(3) {
["name"]=>
string(30) "ingredient_category_ingredient"
["joinColumns"]=>
array(1) {
[0]=>
array(2) {
["name"]=>
string(22) "ingredient_category_id"
["referencedColumnName"]=>
string(2) "id"
}
}
["inverseJoinColumns"]=>
array(1) {
[0]=>
array(2) {
["name"]=>
string(13) "ingredient_id"
["referencedColumnName"]=>
string(13) "ingredient_id"
}
}
}
["type"]=>
int(8)
["mappedBy"]=>
NULL
["isOwningSide"]=>
bool(true)
["sourceEntity"]=>
string(18) "IngredientCategory"
["fetch"]=>
int(2)
["cascade"]=>
array(0) {
}
["isCascadeRemove"]=>
bool(false)
["isCascadePersist"]=>
bool(false)
["isCascadeRefresh"]=>
bool(false)
["isCascadeMerge"]=>
bool(false)
["isCascadeDetach"]=>
bool(false)
["joinTableColumns"]=>
array(2) {
[0]=>
string(22) "ingredient_category_id"
[1]=>
string(13) "ingredient_id"
}
["relationToSourceKeyColumns"]=>
array(1) {
["ingredient_category_id"]=>
string(2) "id"
}
["relationToTargetKeyColumns"]=>
array(1) {
["ingredient_id"]=>
string(13) "ingredient_id"
}
["orphanRemoval"]=>
bool(false)
}
["parent"]=>
array(19) {
["fieldName"]=>
string(6) "parent"
["targetEntity"]=>
string(18) "IngredientCategory"
["joinColumns"]=>
array(1) {
[0]=>
array(2) {
["name"]=>
string(9) "parent_id"
["referencedColumnName"]=>
string(2) "id"
}
}
["type"]=>
int(2)
["mappedBy"]=>
NULL
["inversedBy"]=>
NULL
["isOwningSide"]=>
bool(true)
["sourceEntity"]=>
string(18) "IngredientCategory"
["fetch"]=>
int(2)
["cascade"]=>
array(0) {
}
["isCascadeRemove"]=>
bool(false)
["isCascadePersist"]=>
bool(false)
["isCascadeRefresh"]=>
bool(false)
["isCascadeMerge"]=>
bool(false)
["isCascadeDetach"]=>
bool(false)
["sourceToTargetKeyColumns"]=>
array(1) {
["parent_id"]=>
string(2) "id"
}
["joinColumnFieldNames"]=>
array(1) {
["parent_id"]=>
string(9) "parent_id"
}
["targetToSourceKeyColumns"]=>
array(1) {
["id"]=>
string(9) "parent_id"
}
["orphanRemoval"]=>
bool(false)
}
}
["isIdentifierComposite"]=>
bool(false)
["containsForeignIdentifier"]=>
bool(false)
["idGenerator"]=>
NULL
["sequenceGeneratorDefinition"]=>
NULL
["tableGeneratorDefinition"]=>
NULL
["changeTrackingPolicy"]=>
int(1)
["isVersioned"]=>
NULL
["versionField"]=>
NULL
["reflClass"]=>
NULL
["isReadOnly"]=>
bool(false)
["namingStrategy":protected]=>
object(Doctrine\ORM\Mapping\DefaultNamingStrategy)#258 (0) {
}
["reflFields"]=>
array(0) {
}
["_prototype":"Doctrine\ORM\Mapping\ClassMetadataInfo":private]=>
NULL
}
object(Doctrine\ORM\Mapping\ClassMetadata)#474 (36) {
["name"]=>
string(6) "Recipe"
["namespace"]=>
string(0) ""
["rootEntityName"]=>
string(6) "Recipe"
["customGeneratorDefinition"]=>
NULL
["customRepositoryClassName"]=>
NULL
["isMappedSuperclass"]=>
bool(false)
["parentClasses"]=>
array(0) {
}
["subClasses"]=>
array(0) {
}
["namedQueries"]=>
array(0) {
}
["namedNativeQueries"]=>
array(0) {
}
["sqlResultSetMappings"]=>
array(0) {
}
["identifier"]=>
array(1) {
[0]=>
string(8) "recipeId"
}
["inheritanceType"]=>
int(1)
["generatorType"]=>
int(1)
["fieldMappings"]=>
array(3) {
["recipeId"]=>
array(6) {
["id"]=>
bool(true)
["fieldName"]=>
string(8) "recipeId"
["columnName"]=>
string(9) "recipe_id"
["type"]=>
string(7) "integer"
["unsigned"]=>
bool(false)
["nullable"]=>
bool(false)
}
["name"]=>
array(6) {
["fieldName"]=>
string(4) "name"
["columnName"]=>
string(4) "name"
["type"]=>
string(6) "string"
["length"]=>
int(255)
["fixed"]=>
bool(false)
["nullable"]=>
bool(false)
}
["description"]=>
array(4) {
["fieldName"]=>
string(11) "description"
["columnName"]=>
string(11) "description"
["type"]=>
string(4) "text"
["nullable"]=>
bool(true)
}
}
["fieldNames"]=>
array(3) {
["recipe_id"]=>
string(8) "recipeId"
["name"]=>
string(4) "name"
["description"]=>
string(11) "description"
}
["columnNames"]=>
array(3) {
["recipeId"]=>
string(9) "recipe_id"
["name"]=>
string(4) "name"
["description"]=>
string(11) "description"
}
["discriminatorValue"]=>
NULL
["discriminatorMap"]=>
array(0) {
}
["discriminatorColumn"]=>
NULL
["table"]=>
array(1) {
["name"]=>
string(6) "recipe"
}
["lifecycleCallbacks"]=>
array(0) {
}
["associationMappings"]=>
array(2) {
["recipeCategory"]=>
array(15) {
["fieldName"]=>
string(14) "recipeCategory"
["targetEntity"]=>
string(14) "RecipeCategory"
["mappedBy"]=>
string(6) "recipe"
["type"]=>
int(8)
["inversedBy"]=>
NULL
["isOwningSide"]=>
bool(false)
["sourceEntity"]=>
string(6) "Recipe"
["fetch"]=>
int(2)
["cascade"]=>
array(0) {
}
["isCascadeRemove"]=>
bool(false)
["isCascadePersist"]=>
bool(false)
["isCascadeRefresh"]=>
bool(false)
["isCascadeMerge"]=>
bool(false)
["isCascadeDetach"]=>
bool(false)
["orphanRemoval"]=>
bool(false)
}
["users"]=>
array(19) {
["fieldName"]=>
string(5) "users"
["targetEntity"]=>
string(5) "Users"
["inversedBy"]=>
string(12) "recipeRecipe"
["joinTable"]=>
array(3) {
["name"]=>
string(13) "users_recipes"
["joinColumns"]=>
array(1) {
[0]=>
array(2) {
["name"]=>
string(16) "recipe_recipe_id"
["referencedColumnName"]=>
string(9) "recipe_id"
}
}
["inverseJoinColumns"]=>
array(1) {
[0]=>
array(2) {
["name"]=>
string(8) "users_id"
["referencedColumnName"]=>
string(2) "id"
}
}
}
["type"]=>
int(8)
["mappedBy"]=>
NULL
["isOwningSide"]=>
bool(true)
["sourceEntity"]=>
string(6) "Recipe"
["fetch"]=>
int(2)
["cascade"]=>
array(0) {
}
["isCascadeRemove"]=>
bool(false)
["isCascadePersist"]=>
bool(false)
["isCascadeRefresh"]=>
bool(false)
["isCascadeMerge"]=>
bool(false)
["isCascadeDetach"]=>
bool(false)
["joinTableColumns"]=>
array(2) {
[0]=>
string(16) "recipe_recipe_id"
[1]=>
string(8) "users_id"
}
["relationToSourceKeyColumns"]=>
array(1) {
["recipe_recipe_id"]=>
string(9) "recipe_id"
}
["relationToTargetKeyColumns"]=>
array(1) {
["users_id"]=>
string(2) "id"
}
["orphanRemoval"]=>
bool(false)
}
}
["isIdentifierComposite"]=>
bool(false)
["containsForeignIdentifier"]=>
bool(false)
["idGenerator"]=>
NULL
["sequenceGeneratorDefinition"]=>
NULL
["tableGeneratorDefinition"]=>
NULL
["changeTrackingPolicy"]=>
int(1)
["isVersioned"]=>
NULL
["versionField"]=>
NULL
["reflClass"]=>
NULL
["isReadOnly"]=>
bool(false)
["namingStrategy":protected]=>
object(Doctrine\ORM\Mapping\DefaultNamingStrategy)#258 (0) {
}
["reflFields"]=>
array(0) {
}
["_prototype":"Doctrine\ORM\Mapping\ClassMetadataInfo":private]=>
NULL
}
object(Doctrine\ORM\Mapping\ClassMetadata)#476 (36) {
["name"]=>
string(14) "RecipeCategory"
["namespace"]=>
string(0) ""
["rootEntityName"]=>
string(14) "RecipeCategory"
["customGeneratorDefinition"]=>
NULL
["customRepositoryClassName"]=>
NULL
["isMappedSuperclass"]=>
bool(false)
["parentClasses"]=>
array(0) {
}
["subClasses"]=>
array(0) {
}
["namedQueries"]=>
array(0) {
}
["namedNativeQueries"]=>
array(0) {
}
["sqlResultSetMappings"]=>
array(0) {
}
["identifier"]=>
array(1) {
[0]=>
string(2) "id"
}
["inheritanceType"]=>
int(1)
["generatorType"]=>
int(1)
["fieldMappings"]=>
array(3) {
["id"]=>
array(6) {
["id"]=>
bool(true)
["fieldName"]=>
string(2) "id"
["columnName"]=>
string(2) "id"
["type"]=>
string(7) "integer"
["unsigned"]=>
bool(false)
["nullable"]=>
bool(false)
}
["name"]=>
array(6) {
["fieldName"]=>
string(4) "name"
["columnName"]=>
string(4) "name"
["type"]=>
string(6) "string"
["length"]=>
int(45)
["fixed"]=>
bool(false)
["nullable"]=>
bool(false)
}
["description"]=>
array(6) {
["fieldName"]=>
string(11) "description"
["columnName"]=>
string(11) "description"
["type"]=>
string(6) "string"
["length"]=>
int(45)
["fixed"]=>
bool(false)
["nullable"]=>
bool(true)
}
}
["fieldNames"]=>
array(3) {
["id"]=>
string(2) "id"
["name"]=>
string(4) "name"
["description"]=>
string(11) "description"
}
["columnNames"]=>
array(3) {
["id"]=>
string(2) "id"
["name"]=>
string(4) "name"
["description"]=>
string(11) "description"
}
["discriminatorValue"]=>
NULL
["discriminatorMap"]=>
array(0) {
}
["discriminatorColumn"]=>
NULL
["table"]=>
array(1) {
["name"]=>
string(15) "recipe_category"
}
["lifecycleCallbacks"]=>
array(0) {
}
["associationMappings"]=>
array(2) {
["recipe"]=>
array(19) {
["fieldName"]=>
string(6) "recipe"
["targetEntity"]=>
string(6) "Recipe"
["inversedBy"]=>
string(14) "recipeCategory"
["joinTable"]=>
array(3) {
["name"]=>
string(22) "recipe_category_recipe"
["joinColumns"]=>
array(1) {
[0]=>
array(2) {
["name"]=>
string(18) "recipe_category_id"
["referencedColumnName"]=>
string(2) "id"
}
}
["inverseJoinColumns"]=>
array(1) {
[0]=>
array(2) {
["name"]=>
string(9) "recipe_id"
["referencedColumnName"]=>
string(9) "recipe_id"
}
}
}
["type"]=>
int(8)
["mappedBy"]=>
NULL
["isOwningSide"]=>
bool(true)
["sourceEntity"]=>
string(14) "RecipeCategory"
["fetch"]=>
int(2)
["cascade"]=>
array(0) {
}
["isCascadeRemove"]=>
bool(false)
["isCascadePersist"]=>
bool(false)
["isCascadeRefresh"]=>
bool(false)
["isCascadeMerge"]=>
bool(false)
["isCascadeDetach"]=>
bool(false)
["joinTableColumns"]=>
array(2) {
[0]=>
string(18) "recipe_category_id"
[1]=>
string(9) "recipe_id"
}
["relationToSourceKeyColumns"]=>
array(1) {
["recipe_category_id"]=>
string(2) "id"
}
["relationToTargetKeyColumns"]=>
array(1) {
["recipe_id"]=>
string(9) "recipe_id"
}
["orphanRemoval"]=>
bool(false)
}
["parent"]=>
array(19) {
["fieldName"]=>
string(6) "parent"
["targetEntity"]=>
string(14) "RecipeCategory"
["joinColumns"]=>
array(1) {
[0]=>
array(2) {
["name"]=>
string(9) "parent_id"
["referencedColumnName"]=>
string(2) "id"
}
}
["type"]=>
int(2)
["mappedBy"]=>
NULL
["inversedBy"]=>
NULL
["isOwningSide"]=>
bool(true)
["sourceEntity"]=>
string(14) "RecipeCategory"
["fetch"]=>
int(2)
["cascade"]=>
array(0) {
}
["isCascadeRemove"]=>
bool(false)
["isCascadePersist"]=>
bool(false)
["isCascadeRefresh"]=>
bool(false)
["isCascadeMerge"]=>
bool(false)
["isCascadeDetach"]=>
bool(false)
["sourceToTargetKeyColumns"]=>
array(1) {
["parent_id"]=>
string(2) "id"
}
["joinColumnFieldNames"]=>
array(1) {
["parent_id"]=>
string(9) "parent_id"
}
["targetToSourceKeyColumns"]=>
array(1) {
["id"]=>
string(9) "parent_id"
}
["orphanRemoval"]=>
bool(false)
}
}
["isIdentifierComposite"]=>
bool(false)
["containsForeignIdentifier"]=>
bool(false)
["idGenerator"]=>
NULL
["sequenceGeneratorDefinition"]=>
NULL
["tableGeneratorDefinition"]=>
NULL
["changeTrackingPolicy"]=>
int(1)
["isVersioned"]=>
NULL
["versionField"]=>
NULL
["reflClass"]=>
NULL
["isReadOnly"]=>
bool(false)
["namingStrategy":protected]=>
object(Doctrine\ORM\Mapping\DefaultNamingStrategy)#258 (0) {
}
["reflFields"]=>
array(0) {
}
["_prototype":"Doctrine\ORM\Mapping\ClassMetadataInfo":private]=>
NULL
}
object(Doctrine\ORM\Mapping\ClassMetadata)#478 (36) {
["name"]=>
string(4) "Step"
["namespace"]=>
string(0) ""
["rootEntityName"]=>
string(4) "Step"
["customGeneratorDefinition"]=>
NULL
["customRepositoryClassName"]=>
NULL
["isMappedSuperclass"]=>
bool(false)
["parentClasses"]=>
array(0) {
}
["subClasses"]=>
array(0) {
}
["namedQueries"]=>
array(0) {
}
["namedNativeQueries"]=>
array(0) {
}
["sqlResultSetMappings"]=>
array(0) {
}
["identifier"]=>
array(2) {
[0]=>
string(10) "stepNumber"
[1]=>
string(6) "recipe"
}
["inheritanceType"]=>
int(1)
["generatorType"]=>
int(1)
["fieldMappings"]=>
array(4) {
["stepNumber"]=>
array(6) {
["id"]=>
bool(true)
["fieldName"]=>
string(10) "stepNumber"
["columnName"]=>
string(11) "step_number"
["type"]=>
string(7) "integer"
["unsigned"]=>
bool(false)
["nullable"]=>
bool(false)
}
["description"]=>
array(4) {
["fieldName"]=>
string(11) "description"
["columnName"]=>
string(11) "description"
["type"]=>
string(4) "text"
["nullable"]=>
bool(true)
}
["timer"]=>
array(5) {
["fieldName"]=>
string(5) "timer"
["columnName"]=>
string(5) "timer"
["type"]=>
string(7) "integer"
["unsigned"]=>
bool(false)
["nullable"]=>
bool(true)
}
["image"]=>
array(6) {
["fieldName"]=>
string(5) "image"
["columnName"]=>
string(5) "image"
["type"]=>
string(6) "string"
["length"]=>
int(100)
["fixed"]=>
bool(false)
["nullable"]=>
bool(true)
}
}
["fieldNames"]=>
array(4) {
["step_number"]=>
string(10) "stepNumber"
["description"]=>
string(11) "description"
["timer"]=>
string(5) "timer"
["image"]=>
string(5) "image"
}
["columnNames"]=>
array(4) {
["stepNumber"]=>
string(11) "step_number"
["description"]=>
string(11) "description"
["timer"]=>
string(5) "timer"
["image"]=>
string(5) "image"
}
["discriminatorValue"]=>
NULL
["discriminatorMap"]=>
array(0) {
}
["discriminatorColumn"]=>
NULL
["table"]=>
array(1) {
["name"]=>
string(4) "step"
}
["lifecycleCallbacks"]=>
array(0) {
}
["associationMappings"]=>
array(1) {
["recipe"]=>
array(20) {
["fieldName"]=>
string(6) "recipe"
["targetEntity"]=>
string(6) "Recipe"
["id"]=>
bool(true)
["joinColumns"]=>
array(1) {
[0]=>
array(2) {
["name"]=>
string(9) "recipe_id"
["referencedColumnName"]=>
string(9) "recipe_id"
}
}
["type"]=>
int(1)
["mappedBy"]=>
NULL
["inversedBy"]=>
NULL
["isOwningSide"]=>
bool(true)
["sourceEntity"]=>
string(4) "Step"
["fetch"]=>
int(2)
["cascade"]=>
array(0) {
}
["isCascadeRemove"]=>
bool(false)
["isCascadePersist"]=>
bool(false)
["isCascadeRefresh"]=>
bool(false)
["isCascadeMerge"]=>
bool(false)
["isCascadeDetach"]=>
bool(false)
["sourceToTargetKeyColumns"]=>
array(1) {
["recipe_id"]=>
string(9) "recipe_id"
}
["joinColumnFieldNames"]=>
array(1) {
["recipe_id"]=>
string(9) "recipe_id"
}
["targetToSourceKeyColumns"]=>
array(1) {
["recipe_id"]=>
string(9) "recipe_id"
}
["orphanRemoval"]=>
bool(false)
}
}
["isIdentifierComposite"]=>
bool(true)
["containsForeignIdentifier"]=>
bool(true)
["idGenerator"]=>
NULL
["sequenceGeneratorDefinition"]=>
NULL
["tableGeneratorDefinition"]=>
NULL
["changeTrackingPolicy"]=>
int(1)
["isVersioned"]=>
NULL
["versionField"]=>
NULL
["reflClass"]=>
NULL
["isReadOnly"]=>
bool(false)
["namingStrategy":protected]=>
object(Doctrine\ORM\Mapping\DefaultNamingStrategy)#258 (0) {
}
["reflFields"]=>
array(0) {
}
["_prototype":"Doctrine\ORM\Mapping\ClassMetadataInfo":private]=>
NULL
}
|
| Comment by Benjamin Eberlei [ 09/May/13 ] |
|
Fixed and merged back to 2.3 |
| Comment by Nicholas Van Dusen [ 29/May/13 ] |
|
I tested this again using 2.3.4 (the version which contains this fix) and it is still occurring. Attempting to import mapping for a table with 2 foreign keys in the primary key results in the error "Database does not have any mapping information." Adding a third column on the primary key "fixes" the issue. Currently our developers are being asked to add a fake third part to the key to work around the issue, then delete that key once they get into the entity class. This is a bit tedious and I'd love to see a fix! |
| Comment by Nicholas Van Dusen [ 29/May/13 ] |
|
Issue still present in 2.3.4 and 2.4.0-RC1 |
| Comment by Guillermo [ 11/Jun/13 ] |
|
The database engine I use is PostgreSQL. I'm having problems when mapping entities with composite primary keys in other tables. CREATE TABLE public.establecimiento ( id_establecimiento integer NOT NULL, establecimiento character varying(100) NOT NULL, CONSTRAINT pk_establecimiento PRIMARY KEY (id_establecimiento ) ) WITH ( OIDS=FALSE ); CREATE TABLE public.establecimiento_sec ( id_establecimiento_sec integer NOT NULL, id_establecimiento integer NOT NULL, det_seccion character varying(40) NOT NULL, plano character varying(100), sector_ingreso character varying(254), sponsor_imagen_sec character varying(96000), CONSTRAINT pk_establecimientos_sec PRIMARY KEY (id_establecimiento_sec , id_establecimiento ), CONSTRAINT fk_establec_reference_establec FOREIGN KEY (id_establecimiento) REFERENCES public.establecimiento (id_establecimiento) MATCH SIMPLE ON UPDATE RESTRICT ON DELETE RESTRICT ) WITH ( OIDS=TRUE ); CREATE TABLE public.establecimiento_sec_plano ( id_establecimiento_sec_plano integer NOT NULL, id_establecimiento_sec integer NOT NULL, id_establecimiento integer NOT NULL, det_plano character varying(512), cantidad integer NOT NULL, precio double precision, insert_charge double precision DEFAULT 0, descr character varying(254), CONSTRAINT pk_establecimiento_sec_plano PRIMARY KEY (id_establecimiento_sec_plano , id_establecimiento_sec , id_establecimiento ), CONSTRAINT fk_establecimiento_sec FOREIGN KEY (id_establecimiento, id_establecimiento_sec) REFERENCES public.establecimiento_sec (id_establecimiento, id_establecimiento_sec) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE CASCADE ) WITH ( OIDS=FALSE ); Defining the entity establecimientoSecPlano, $establecimientoSec variable containing the keys $establecimiento and $id_establecimiento_sec //Entity/EstablecimientosSecPlano /**
* @ORM\Id
* @ORM\ManyToOne(targetEntity="Ticketway\PruebaBundle\Entity\EstablecimientosSec")
* @ORM\JoinColumns(
* @ORM\JoinColumn(name="id_establecimiento_sec", referencedColumnName="id_establecimiento_sec"),
* @ORM\JoinColumn(name="id_establecimiento", referencedColumnName="id_establecimiento"))
*/
private $establecimientoSec;
//Entity/EstablecimientosSec /**
* @ORM\Id
* @ORM\ManyToOne(targetEntity="Ticketway\PruebaBundle\Entity\Establecimientos")
* @ORM\JoinColumn(name="id_establecimiento", referencedColumnName="id_establecimiento")
*/
private $establecimiento;
When executing the command doctrine: mapping: import I get the following error [Doctrine\ORM\Mapping\MappingException] |
[DDC-2495] Partial objects not working with STI Created: 10/Jun/13 Updated: 11/Jun/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | 2.3.4 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Radoslaw Ejsmont | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | STI, dql, orm, partial | ||
| Environment: |
Symfony2 project, Doctrine ORM with MySQL database backend |
||
| Attachments: |
|
| Description |
|
When I try to create a query retrieving partial objects of a root class in single table inheritance hierarchy, the resulting SQL includes all fields from the whole class hierarchy. DQL: FROM VIB\FliesBundle\Entity\Vial v WHERE v.id IN (1,2,3,4,5,6,7,8,9,10) SQL: |
| Comments |
| Comment by Fabio B. Silva [ 10/Jun/13 ] |
|
Could you please provide your entities ? Thanks |
| Comment by Radoslaw Ejsmont [ 11/Jun/13 ] |
|
This is the whole class hierarchy. |
| Comment by Radoslaw Ejsmont [ 11/Jun/13 ] |
|
I have actually noticed, that the "partial" keyword is ignored even for entities that are not using any inheritance schema. So it seems that this keyword is generally ignored. Right now the following query: SELECT e, partial p. {id}, o, s FROM VIB\FliesBundle\Entity\StockVial e LEFT JOIN e.parent p LEFT JOIN e.position o LEFT JOIN e.stock s WHERE e.setupDate > :date AND e.trashed = false ORDER BY e.setupDate DESC ORDER BY e.id DESC would result in the following SQL: SELECT v0_.setupDate AS setupDate0, v0_.flipDate AS flipDate1, v0_.notes AS notes2, v0_.size AS size3, v0_.labelPrinted AS labelPrinted4, v0_.trashed AS trashed5, v0_.temperature AS temperature6, v0_.id AS id7, v1_.id AS id8, r2_.rackRow AS rackRow9, r2_.rackColumn AS rackColumn10, r2_.id AS id11, s3_.name AS name12, s3_.genotype AS genotype13, s3_.notes AS notes14, s3_.vendor AS vendor15, s3_.infoURL AS infoURL16, s3_.verified AS verified17, s3_.id AS id18, v0_.type AS type19, v0_.parent_id AS parent_id20, v0_.position_id AS position_id21, v0_.prevPosition_id AS prevPosition_id22, v0_.incubator_id AS incubator_id23, v0_.stock_id AS stock_id24, v1_.type AS type25, v1_.parent_id AS parent_id26, v1_.position_id AS position_id27, v1_.prevPosition_id AS prevPosition_id28, v1_.incubator_id AS incubator_id29, v1_.stock_id AS stock_id30, v1_.male_id AS male_id31, v1_.virgin_id AS virgin_id32, v1_.targetStock_id AS targetStock_id33, v1_.targetStockVial_id AS targetStockVial_id34, r2_.rack_id AS rack_id35, s3_.sourceCross_id AS sourceCross_id36 FROM Vial v0_ LEFT JOIN Vial v1_ ON v0_.parent_id = v1_.id AND v1_.type IN ('vial', 'stock', 'cross', 'injection') LEFT JOIN RackPosition r2_ ON v0_.position_id = r2_.id LEFT JOIN Stock s3_ ON v0_.stock_id = s3_.id WHERE (v0_.setupDate > '2013-04-11' AND v0_.trashed = 0) AND v0_.type IN ('stock') ORDER BY v0_.setupDate DESC, v0_.id DESC Please note that ALL properties of parent have been included in the generated SQL. You can find the whole project (Symfony2) on github: https://github.com/rejsmont/LabDB Best, R. |
| Comment by Radoslaw Ejsmont [ 11/Jun/13 ] |
|
I have noticed that using the setHint(Doctrine\ORM\Query::HINT_FORCE_PARTIAL_LOAD, 1) forces partial load, however then even the entities I want loaded entirely (with proxied references) are partially loaded (i.e. all the references are forced to null, unless explicitly loaded via join). |
[DDC-2235] Single table inheritance discriminator in WHERE when using arbitrary join syntax Created: 11/Jan/13 Updated: 11/Jun/13 |
|
| Status: | Reopened |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | 2.3 |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Jordi Forns | Assignee: | Alexander |
| Resolution: | Unresolved | Votes: | 6 |
| Labels: | None | ||
| Issue Links: |
|
||||||||
| Description |
|
The condition on the discriminator column is placed in the WHERE clause when using arbitrary join syntax, which renders LEFT JOINs useless. Given these classes:
$qb->select('a.id AS idA, b.id AS idB')
->from('\Entity\A', 'a')
->leftJoin('\Entity\B1', 'b', \Doctrine\ORM\Query\Expr\Join::WITH, 'a.something=b.something');
And the SQL Doctrine generates is something like this:
SELECT a.id, b.id FROM a LEFT JOIN b ON (a.something=b.something) WHERE b.type IN ('1', '2', '3')
The problems is that the WHERE condition makes the left join useless. The condition on the discriminator column should be placed in the JOIN clause to avoid the problem. |
| Comments |
| Comment by Ondrej Hlavaty [ 10/Feb/13 ] |
|
Can this be somehow worked around? If not, it is really serious problem... |
| Comment by Jordi Forns [ 18/Feb/13 ] |
|
I couldn't find any workaround. |
| Comment by Michel Salib [ 22/Mar/13 ] |
|
Easier way to workaround right now, is to declare a OneToMany from class A to class B on a protected field (no need of getter or setter). That way you can do classic join via relationship transversing and then the condition will be placed in the ON part of the query. |
| Comment by Yuta Konishi [ 01/Apr/13 ] |
|
I could access with below codes. You should use RAW SQL it is easy solution I guess. good luck. $qb = $em->createQueryBuilder();
$qb->select('a, b')
->from('YourEntity1', 'a')
->leftJoin('YourEntity2', 'b', \Doctrine\ORM\Query\Expr\Join::WITH, 'a.id = b.relationId');
$raw_sql = $qb->where(
$qb->expr()->in('a.relationId', $ids)
)
->orderBy('a.updatedAt', 'DESC')
->setMaxResults(10)
->getQuery()->getSQL();
$conn = $em->getConnection();
$stmt = $conn->query($raw_sql);
/* $stmt->fetchAll(); // access as Array */
|
| Comment by Benjamin Eberlei [ 04/Apr/13 ] |
|
Assigned to Alexander |
| Comment by Benjamin Eberlei [ 14/Apr/13 ] |
|
Duplicate of DDC-1940 |
| Comment by Jordi Forns [ 22/Apr/13 ] |
|
Benjamin: this bug doesn't seem to be a dupe of DDC-1940. Actually that issue doesn't seem to be a bug at all. As a reminder, the problem in this issue is that when performing arbitrary left joins on entities that are part of a class hierarchy, the discriminator condition is placed in the where clause instead of the join clause. This means that rows that could not be joined will have null values in the discriminator column and thus will not be returned because of the where condition (which will contain something like " where x.discriminator in (1,2,3) "). |
| Comment by Tom Arnfeld [ 27/Apr/13 ] |
|
Has this issue been resolved elsewhere? From reading over DDC-1940 it doesn't seem to be a duplicate at all. I'm experiencing the same problem as Jordi and can't seem to find a solution. Is there any particular reason the `IN ()` predicate is not a part of the join, but instead placed in the main `WHERE` clause? |
| Comment by Tom Arnfeld [ 28/Apr/13 ] |
|
I've been looking into the root cause of this bug (or feature..) to try and understand why it's happening, and after trying various possible fixes (a little hard without full understanding of the Doctrine/Query internals) I've ended up with a fix that seems to work well for my use case, at least. I've not run any of the unit tests (I plan to, and may adjust my fix based on that) but the top revision is my change... https://gist.github.com/tarnfeld/a6bb50ec707c7af1c5dc/revisions Would love some feedback. Pull request here: https://github.com/doctrine/doctrine2/pull/656 |
| Comment by Jordi Forns [ 29/Apr/13 ] |
|
Tom's fix moves the condition of the discriminator column to the LEFT JOIN, which is exactly what was needed. Alexander: could you please give it a look? |
| Comment by Jordi Forns [ 23/May/13 ] |
|
Tom's proposal seems to fix the issue. |
| Comment by Gordon Forsythe [ 11/Jun/13 ] |
|
Agree, Tom's pull request looks like it fixes the issue. Is there a reason this hasn't been merged yet? |
[DDC-54] Trigger postLoad events and callbacks after associations have been initialized Created: 15/Oct/09 Updated: 07/Jun/13 |
|
| Status: | In Progress |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | 2.0-ALPHA2 |
| Fix Version/s: | 2.x |
| Security Level: | All |
| Type: | Improvement | Priority: | Major |
| Reporter: | Roman S. Borschel | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 6 |
| Labels: | None | ||
| Description |
|
Currently the postLoad events and callbacks are triggered after the entity has been created and filled with its "primitive" state but before associations are available. The postLoad events and callbacks should be postponed so that they are triggered after associations have been initialized. |
| Comments |
| Comment by Roman S. Borschel [ 30/Aug/10 ] |
|
If this is to be included in 2.0 it needs to happen for RC1. However, it is not clear yet whether it will be done in time. |
| Comment by Benjamin Eberlei [ 23/Sep/10 ] |
|
How would you solve this Roman? I thought of adding a query hint so that the postLoad inside unit of work is not triggered and gathering all the entities that have a post load event in an array inside the object hydrator, then iterating it after taking the snapshots of all collections inside hydrateAll |
| Comment by Roman S. Borschel [ 24/Sep/10 ] |
|
@Benjamin: Not sure what you would use the query hint for but in general that is the approach I had in mind, yes. You can't get around iterating over the entities after the actual hydration. |
| Comment by Benjamin Eberlei [ 27/Sep/10 ] |
|
The query hint would do something like: //TODO: These should be invoked later, after hydration, because associations may not yet be loaded here. if (isset($class->lifecycleCallbacks[Events::postLoad]) && !isset($hints['hydrationPostLoad'])) { $class->invokeLifecycleCallbacks(Events::postLoad, $entity); } if ($this->evm->hasListeners(Events::postLoad) && !isset($hints['hydrationPostLoad'])) { $this->evm->dispatchEvent(Events::postLoad, new LifecycleEventArgs($entity, $this->em)); } another way would be to move that code out of UoW::createEntity completly and have the persisters call it when they use that method. |
| Comment by Roman S. Borschel [ 28/Sep/10 ] |
|
Leaving that code in UoW does not make sense to me, if it is moved, it needs to be moved completely. Why do you think the persisters should do it? Initially I thought collecting the affected entities during hydration and then when hydration is done iterating over them and triggering the postLoad events. |
| Comment by Benjamin Eberlei [ 28/Sep/10 ] |
|
Yes but postLoad has to be triggered for non Hydrated entities (i.e. Persister) also |
| Comment by Benjamin Eberlei [ 30/Oct/10 ] |
|
Moved back |
| Comment by Kacper Gunia [ 15/Apr/12 ] |
|
Hi Gyus, I need access to associations in postLoad or similar event, and my idea is to dispatch new event after full initialisation of object, what do You think about it? If I can help please let me know |
| Comment by Alexander Pasichnick [ 25/Sep/12 ] |
|
Now in my PostLoad access to associations is work fine. Why this issue is still in Unresolved status? |
| Comment by Łukasz Cybula [ 11/Oct/12 ] |
|
What do you (Roman and Benjamin) think about adding postHydrate event which would be called within ObjectHydrator::hydrateAllData() on every entity collected during hydration? I could prepare a patch for this. I personally think this would be better than adding a hint that changes behaviour of postLoad event. |
| Comment by Slavik Derevyanko [ 07/Jun/13 ] |
|
Just stumbled upon this issue. Seems like my associated entities aren't yet loaded in PostLoad event handler. I've noticed that I have two different paths of execution: 2. When the DQL is used, ObjectHydrator is used to perform a hydration, and the associations aren't made ready in PostLoad event: Hope this helps to solve the issue. |
[DDC-2487] UnitOfWork::getEntityIdentifier() contains objects when custom mapping types are part of an entity's identity Created: 04/Jun/13 Updated: 04/Jun/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | 2.3.4 |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Benjamin Morel | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | identity | ||
| Description |
|
I'm using a custom mapping type for a LocalDate class (mapped to a DATE field in the MySQL database). Given the following entity:
/**
* @Entity
*/
class Timeslot
{
/**
* @Id
* @ManyToOne(targetEntity="Restaurant")
*/
protected $restaurant;
/**
* @Id
* @Column(type="localdate")
*/
protected $date;
}
When var_export() -ing the result of UnitOfWork::getEntityIdentifier() on an instance of this class, the result is similar to:
array(
'restaurant' => '5',
'date' => LocalDate::__set_state(array('year' => 2013, 'month' => 6, 'day' => 26))
)
This is a bit weird, because as far as I understand it, it should return the identity as it maps to database fields: array( 'restaurant' => '5', 'date' => '2013-06-26' ) If we take the $restaurant example, it returns the restaurant ID, and not the Restaurant entity, so my opinion is that it should be the same for $date. Shouldn't the UnitOfWork use Type::convertToDatabaseValue() on custom mapping types to infer their value, when computing the identity of an entity? |
| Comments |
| Comment by Marco Pivetta [ 04/Jun/13 ] |
|
Benjamin Morel why would getEntityIdentifier convert types? The UoW doesn't worry about the DBAL representation of the objects - actually, the UoW doesn't know of the DBAL at all. |
| Comment by Benjamin Morel [ 04/Jun/13 ] |
|
Your point is valid, but that's still annoying. Why would getEntityIdentifier() return objects? |
| Comment by Marco Pivetta [ 04/Jun/13 ] |
|
Benjamin Morel that is because that is the identifier in your object. It's composed by the identifier of an associated entity and a datetime object (scalar) |
| Comment by Benjamin Morel [ 04/Jun/13 ] |
|
Marco Pivetta Then why does it return the restaurant ID, and not the Restaurant object? |
[DDC-2485] [GH-685] Functional ticket for DDC-2484 Created: 03/Jun/13 Updated: 03/Jun/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Doctrine Bot | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of TomHAnderson: Url: https://github.com/doctrine/doctrine2/pull/685 Message: This shows how the postLoad can change an entity but associations are not passed through postLoad |
[DDC-2479] Add possibility to only query for root entities in a class table inheritance Created: 30/May/13 Updated: 30/May/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | DQL, ORM |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Steve Müller | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | dql,, inheritance | ||
| Description |
|
It is not possible to query for root/topmost class entities (only) in a class table inheritance situation without extra JOINs to the child entities/classes. E.g. The DQL: SELECT p also joins Employee even though I am not interested in Employee properties. Person is the base class in this use case and it should be possible to only retrieve those information. Thinking of OOP, if I instanciate Person I do not have any reference to its child either. IMO the DQL should be modified to allow selecting root/base information only, similar to the INSTANCE OF operator, that allows selecting specific childs only. |
[DDC-2332] [UnitOfWork::doPersist()] The spl_objact_hash() generate not unique hash! Created: 05/Mar/13 Updated: 30/May/13 |
|
| Status: | Awaiting Feedback |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Critical |
| Reporter: | Krisztián Ferenczi | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Symfony 2.1.8, php 5.4.7 and php 5.4.12, Windows 7 |
||
| Attachments: |
|
| Description |
|
I created fixtures and some data was inserted many times without calling the Task entity PrePersist event listener. I printed the used and generated hash and I saw a Proxies_CG_\Asitly\ProjectManagementBundle\Entity\User hash equal a Task entity hash! |
| Comments |
| Comment by Marco Pivetta [ 05/Mar/13 ] |
|
Please provide either a code example or a test case. As it stands, this issue is incomplete |
| Comment by Benjamin Eberlei [ 05/Mar/13 ] |
|
Are you calling EntityManager#clear() inbetween? Because PHP reuses the hashes. The ORM accounts for this. |
| Comment by Benjamin Eberlei [ 05/Mar/13 ] |
|
This is not a reproduce case, i don't want to execute your whole project. I want to know, what is the actual bug that you see? Can you just print a list of all the hashes? Because the hashes dont differ at the end, bu tjust somewhere in the middle. |
| Comment by Krisztián Ferenczi [ 05/Mar/13 ] |
|
I attached a hashlogs.txt file. The last Task class hash is 0000000050ab4aba0000000058e1cb12 ( line 3 129 ) This is not unique, view the line 2 760 . The Task is not being saved and the program don't call the prePersist listener. The "UnitOfWork" believe the entity has been saved because the isset($this->entityStates[$oid]) is true. But it is an other entity. |
| Comment by Krisztián Ferenczi [ 06/Mar/13 ] |
|
The EntityManager::clear() fix the problem, but this is not "good" and "beautiful" solution. Shows no sign of that conflicts were and this is causing the problem. I was looking for the problem 7 hours. |
[DDC-2477] [GH-681] Sequence generator fix Created: 29/May/13 Updated: 29/May/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Doctrine Bot | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of lighthart: Url: https://github.com/doctrine/doctrine2/pull/681 Message: $this->_sequenceName=$em->getClassMetadata(get_class($entity))->sequenceGeneratorDefinition['sequenceName']; The sequence generator does not read the class metadata, so if there is table remapping via event listeners, any new entity won't have the appropriate changes in table names. This pull request adds a remap the Sequence Generator to read the class metadata to determine the sequence name if there is an entity passed to the generate function. Tests: 1854, Assertions: 6224, Skipped: 96. |
[DDC-2467] Incorrect work with default values, indexes, autoincrement (patch attached) Created: 23/May/13 Updated: 28/May/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | Mapping Drivers, ORM, Tools |
| Affects Version/s: | 2.3.4 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Minor |
| Reporter: | And | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Attachments: |
|
| Description |
|
If you use in your MySQL database default values, indexes or string primary key, you get incorrect mapping by mapping generator. For get it - just use in database one or more from listed abilities, generate mapping for that and then try to dump-sql with schema-tool:update. Hope you fix it. Tnx! |
| Comments |
| Comment by Marco Pivetta [ 23/May/13 ] |
|
Marked as minor improvement - thank you for the patch! |
| Comment by And [ 28/May/13 ] |
|
When it will be merged? Maybe, planned version? |
| Comment by Marco Pivetta [ 28/May/13 ] |
|
And such a patch requires failing tests before being applied - that's up to whoever picks it up. |
| Comment by And [ 28/May/13 ] |
|
So if I add patch with tests - it will be merged? =) |
| Comment by Marco Pivetta [ 28/May/13 ] |
|
Most probably - you can open a pull request against the current ORM master for that |
[DDC-2472] [GH-677] Type fix in ORM\PersistentCollection Created: 27/May/13 Updated: 27/May/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Doctrine Bot | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of michaldudek: Url: https://github.com/doctrine/doctrine2/pull/677 Message: The ```ORM\PersistentCollection``` class accepts anything as 3rd argument to its constructor while it should be either array or ```Collection``` object. The ```$this->coll``` phpdoc says that it's a ```Collection``` while the constructor's phpdoc says it's an array. The class assumes ```Collection``` but there isn't any type check at all. I have added conversion of array into ```ArrayCollection``` in the constructor as in some (very unclear) cases it likes to die with a fatal error: ```Fatal error: Call to a member function add() on a non-object in Doctrine/ORM/PersistentCollection.php on line 169``` |
| Comments |
| Comment by Doctrine Bot [ 27/May/13 ] |
|
A related Github Pull-Request [GH-677] was closed: |
[DDC-2464] useless index for the middle table of many-to-many relationship Created: 21/May/13 Updated: 21/May/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | Tools |
| Affects Version/s: | Git Master |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Improvement | Priority: | Minor |
| Reporter: | scourgen | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | ddl, schematool | ||
| Description |
|
I have entity A and B, the relationship between A and B is many-to-many. which means Doctrine2 will generate a middle table called AB for me. entity A:
class Station {
/**
* @ORM\ManyToMany(targetEntity="Fun", mappedBy="stations")
*/
protected $funs;
}
entity B:
class Fun {
/**
* @ORM\ManyToMany(targetEntity="Station", inversedBy="funs")
* @ORM\JoinTable(name="stations_have_funs")
*/
protected $stations;
}
the schema of middle table stations_have_funs: CREATE TABLE `stations_have_funs` ( `fun_id` int(11) NOT NULL, `station_id` int(11) NOT NULL, PRIMARY KEY (`fun_id`,`station_id`), KEY `IDX_45C921911CA4BE49` (`fun_id`), KEY `IDX_45C9219121BDB235` (`station_id`), CONSTRAINT `FK_45C921911CA4BE49` FOREIGN KEY (`fun_id`) REFERENCES `funs` (`id`) ON DELETE CASCADE, CONSTRAINT `FK_45C9219121BDB235` FOREIGN KEY (`station_id`) REFERENCES `stations` (`id`) ON DELETE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci; I noticed that there are 2 useless index(fun_id and station_id). Since fun_id and station_id are the primary key of this table. Do we really need 2 extra/duplicated index ? |
[DDC-2462] [GH-674] Shortcut for force Created: 20/May/13 Updated: 20/May/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Doctrine Bot | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of TorbenBr: Url: https://github.com/doctrine/doctrine2/pull/674 Message: |
[DDC-2459] ANSI compliant quote strategy. Created: 17/May/13 Updated: 17/May/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Fabio B. Silva | Assignee: | Fabio B. Silva |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
In order to simplify and speed up the sql generation The implementation would be something like : <?php class AnsiQuoteStrategy implements \Doctrine\ORM\Mapping\QuoteStrategy { /** * {@inheritdoc} */ public function getColumnName($fieldName, ClassMetadata $class, AbstractPlatform $platform) { return $class->fieldMappings[$fieldName]['columnName']; } /** * {@inheritdoc} */ public function getTableName(ClassMetadata $class, AbstractPlatform $platform) { return $class->table['name']; } /** * {@inheritdoc} */ public function getSequenceName(array $definition, ClassMetadata $class, AbstractPlatform $platform) { return $definition['sequenceName']; } /** * {@inheritdoc} */ public function getJoinColumnName(array $joinColumn, ClassMetadata $class, AbstractPlatform $platform) { return $joinColumn['name']; } /** * {@inheritdoc} */ public function getReferencedJoinColumnName(array $joinColumn, ClassMetadata $class, AbstractPlatform $platform) { return $joinColumn['referencedColumnName']; } /** * {@inheritdoc} */ public function getJoinTableName(array $association, ClassMetadata $class, AbstractPlatform $platform) { return $association['joinTable']['name']; } /** * {@inheritdoc} */ public function getIdentifierColumnNames(ClassMetadata $class, AbstractPlatform $platform) { return $class->identifier; } /** * {@inheritdoc} */ public function getColumnAlias($columnName, $counter, AbstractPlatform $platform, ClassMetadata $class = null) { return $platform->getSQLResultCashing($columnName . $counter); } } |
[DDC-2454] To-Many OrderBy mechanism should allow many-to-one associations Created: 16/May/13 Updated: 16/May/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Oleg Namaka | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | association, orderBy | ||
| Description |
class ProductCategory
{
/**
* Store
*
* @var Store
*
* @ORM\ManyToOne(targetEntity="Store")
* @ORM\JoinColumn(name="store_id", referencedColumnName="store_id")
*/
private $Store;
/**
* storeId (for ordering in Product::ProductCategories only)
*
* @var integer
*
* @ORM\Column(name="store_id", type="integer")
*/
private $storeId;
...
class Product
{
/**
* Associated categories
*
* @var \Doctrine\Common\Collections\Collection
*
* @ORM\OneToMany(targetEntity="ProductCategory", mappedBy="Product")
* @ORM\OrderBy({"storeId"="ASC"})
*/
private $ProductCategories;
}
}
If it is possible now to sort the ProductCategories collection by the storeId field, it should also be possible to sort them by the Store association. Currently a set of two fields is required: Store as a regular Many-To-One association and if a need arises to be able to use it to sort the One-To-Many collections then storeId needs to be added to the ProductCategory entity. In that case the ProductCategory entity does not pass the schema validation but is perfectly usable. This should be allowed:
class Product
{
/**
* Associated categories
*
* @var \Doctrine\Common\Collections\Collection
*
* @ORM\OneToMany(targetEntity="ProductCategory", mappedBy="Product")
* @ORM\OrderBy({"Store"="ASC"})
*/
private $ProductCategories;
}
|
[DDC-2452] Additional `WITH` condition in joins between JTI roots cause invalid SQL to be produced Created: 16/May/13 Updated: 16/May/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | DQL, ORM |
| Affects Version/s: | Git Master |
| Fix Version/s: | 2.4 |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Marco Pivetta | Assignee: | Marco Pivetta |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | dql, sql-walker | ||
| Environment: |
irrelevant |
||
| Description |
|
Given a simple Joined Table Inheritance like following: /** * @Entity @Table(name="foo") @InheritanceType("JOINED") * @DiscriminatorColumn(name="discr", type="string") * @DiscriminatorMap({"foo" = "DDC2452Foo", "bar" = "DDC2452Bar"}) */ class DDC2452Foo { /** @Id @Column(type="integer") @GeneratedValue */ public $id; } /** @Entity @Table(name="bar") */ class DDC2452Bar extends DDC2452Foo { } Following DQL SELECT foo1 FROM DDC2452Foo foo1 JOIN DDC2452Foo foo2 WITH 1=1 Will produce broken SQL: SELECT
f0_.id AS id0, f0_.discr AS discr1
FROM
foo f0_
LEFT JOIN bar b1_
ON f0_.id = b1_.id
LEFT JOIN foo f2_
LEFT JOIN bar b3_
ON f2_.id = b3_.id
ON (1 = 1)
(please note the duplicate `ON` in the SQL) That is caused because of the SQL walker producing the JTI filter with already the `ON` clause in it. That happens because the JTI join conditions are added in https://github.com/doctrine/doctrine2/blob/2.4.0-BETA2/lib/Doctrine/ORM/Query/SqlWalker.php#L823-L825 (`walkRangeVariableDeclaration`), while the additional defined `WITH` conditions are considered in `walkJoinAssociationDeclaration` later on. Added a test case and fix at https://github.com/doctrine/doctrine2/pull/668 |
[DDC-2449] Amazon Redshift Support Created: 15/May/13 Updated: 15/May/13 |
|
| Status: | Awaiting Feedback |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | New Feature | Priority: | Major |
| Reporter: | Kirill F | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Amazon Redshift |
||
| Description |
|
It would be nice to get doctrine compatible with Amazon Redshift. It uses a Postgres connector but there are some differences. I'm currently facing an issue with the primary id, in Redshift the generation of an id is different from Postgres and so I'm getting errors associated with generating an id. Here are some references that might be useful: Amazon Manual: |
[DDC-2052] Custom tree walkers are not allowed to add new components to the query Created: 02/Oct/12 Updated: 14/May/13 |
|
| Status: | Reopened |
| Project: | Doctrine 2 - ORM |
| Component/s: | DQL |
| Affects Version/s: | 2.3 |
| Fix Version/s: | 2.4 |
| Type: | Improvement | Priority: | Major |
| Reporter: | Łukasz Cybula | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | dql | ||
| Description |
|
Custom tree walkers have freedom in modifying the AST but when you try to add a new query component (i.e. new join in walkSelectStatement() ) to the AST then the SqlWalker throws an exception because it does not has the new component in its _queryComponents array. I see two possible ways to resolve this: |
| Comments |
| Comment by Benjamin Eberlei [ 06/Oct/12 ] |
|
Ok this is much more complicated to allow then i thought. The problem is that the QueryComponents are passed by value, as an array, not by reference. That prevents changing them because this change wouldn't be visible in the output walker. I can add a method to allow this in the OutputWalker for now, but generally this requires a bigger refactoring on the Query Components. |
| Comment by Benjamin Eberlei [ 06/Oct/12 ] |
|
Added setQueryComponent() in SQL Walker to allow modification in output walker. |
| Comment by Łukasz Cybula [ 08/Oct/12 ] |
|
I'm afraid that this doesn't solve the initial problem at all. I'll try to describe it in more details to show what I mean. Suppose we have two doctrine extensions each of which contain its own tree walker. Each of these tree walkers need to modify AST and add new component to it (joined with some component already existing in the query). The first problem is that each tree walker has its own queryComponents array which is not passed between them, although they not necessary need to use queryComponents - they could use only AST. The second, bigger problem is that the Parser class does not know anything about modifications of queryComponents in tree walkers and cannot pass modified version to the OutputWalker. The goal of submitting this issue was to allow adding new components to the query in tree walkers which is not achievable by your fix. I think it may be the first step in the right direction. Maybe TreeWalkerAdapter should have public method getQueryComponents() which would be used by the Parser to pass modified queryComponents between different tree walkers and finally to the OutputWalker ? This would not break backward compatibility and solve this issue. What do you think about it? |
| Comment by Łukasz Cybula [ 08/Oct/12 ] |
|
I've tried to implement the solution mentioned in previous comment but it's also not so clean and easy as I thought. Each tree walker (including TreeWalkerChain) would have to implement getQueryComponents() and setQueryComponent($alias, array $component) methods. The same with SqlWalker, so the TreeWalker interface should have these methods, which would break BC in some way (walkers that do not inherit from SqlWalker or TreeWalkerAdapter will fail to compile). So maybe my first solution (PR #464) is not so bad for now? In the future queryComponents could be replaced by a special object or could be passed by a reference to allow modifications. |
| Comment by Benjamin Eberlei [ 09/May/13 ] |
|
Marked as improvement as its not a bug. A solution might probably implement an object holding all the QueryComponent, implementing ArrayAccess. So that way the state can be shared. |
| Comment by Marco Pivetta [ 14/May/13 ] |
|
Just hit this while developing an ast walker... Will look into it too since I need it more than soon. |
| Comment by Marco Pivetta [ 14/May/13 ] |
|
As a VERY UGLY workaround, I used a static variable and a custom sql walker in combination with my AST walker. namespace Comcom\Versioning\ORM\Query; use Doctrine\ORM\Query\SqlWalker; class WorkaroundSqlWalker extends SqlWalker { public function __construct($query, $parserResult, array $queryComponents) { parent::__construct($query, $parserResult, $queryComponents); foreach (VersionWalker::$additionalAliases as $alias => $value) { $this->setQueryComponent($alias, $value); } } } |
[DDC-2448] orm:schema-tool:update reports already updated NUMERIC fields Created: 14/May/13 Updated: 14/May/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | Tools |
| Affects Version/s: | 2.3.4 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Francesco Montefoschi | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
PHP 5.3.10-1ubuntu3.6 with Suhosin-Patch (cli) (built: Mar 11 2013 14:31:48) |
||
| Description |
|
I have a table defined in this way: CREATE TABLE `my_table` ( When I run I get While of course the field is already updated. The same happens in SQL Server 2008 and Postgres 9. |
[DDC-1970] DiscriminatorMap recursion when using self-reference Created: 06/Aug/12 Updated: 10/May/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | 2.3 |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | New Feature | Priority: | Major |
| Reporter: | Krzysztof Kolasiak | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | None | ||
| Description |
|
I've ran into a problem with self-referencing entity. When fetching an entity, recursion occurs, fetching every related entity defined by ManyToOne relation /** * @ORM\Entity(repositoryClass="Acme\Bundle\UserBundle\Entity\Repository\UserRepository") * @ORM\Table(name="f_user") * @ORM\InheritanceType("JOINED") * @ORM\DiscriminatorColumn(name="type", type="string") * @ORM\DiscriminatorMap({"user_person" = "UserPerson", "user_company" = "UserCompany"}) */ abstract class UserBase extends FOSUser /* .... */ /** * @var UserBase * * @ORM\OneToMany(targetEntity="UserBase", mappedBy="sponsor") */ protected $referrals; /** * @ORM\ManyToOne(targetEntity="UserBase", inversedBy="referrals") * @ORM\JoinColumn(name="sponsor_id", referencedColumnName="id") */ protected $sponsor; |
| Comments |
| Comment by Alexander [ 14/Aug/12 ] |
|
I have changed this into a feature request because you have hit the limitations of using inheritance and self referencing entities. Doctrine2 cannot currently lazy load UserBase#$sponsor because we don't know which proxy we have to insert. It can either be UserPerson or UserCompany. In order to know this Doctrine2 has to query the actual object to determine its type. The current strategy is then to load the actual entity because we have all data anyway. In order to implement this feature we need to insert a proxy instead of the actual entity. If we do that there should be no recursion happening. |
| Comment by Marco Pivetta [ 21/Feb/13 ] |
|
Reduced priority |
| Comment by Prathap [ 10/May/13 ] |
|
It'd be great if this is a configurable option. |
[DDC-1884] leftJoin via composite key part not hydrated if joining table solely consists of identifiers Created: 20/Jun/12 Updated: 09/May/13 |
|
| Status: | In Progress |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | 2.2.0-RC1 |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Sander Coolen | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | None | ||
| Environment: |
MAMP |
||
| Description |
|
Suppose I have the following entities:
/** * @ORM\Entity * @ORM\Table(name="driver") */ class Driver { /** * @ORM\Id * @ORM\Column(type="integer") * @ORM\GeneratedValue(strategy="AUTO") */ private $id; /** * @ORM\Column(type="string", length=255); */ private $name; /** * @ORM\OneToMany(targetEntity="DriverRide", mappedBy="driver") */ private $driverRides; } /** * @ORM\Entity * @ORM\Table(name="driver_ride") */ class DriverRide { /** * @ORM\Id * @ORM\ManyToOne(targetEntity="Driver", inversedBy="driverRides") * @ORM\JoinColumn(name="driver_id", referencedColumnName="id") */ private $driver; /** * @ORM\Id * @ORM\ManyToOne(targetEntity="Car", inversedBy="carRides") * @ORM\JoinColumn(name="car", referencedColumnName="brand") */ private $car; } /** * @ORM\Entity * @ORM\Table(name="car") */ class Car { /** * @ORM\Id * @ORM\Column(type="string", length=25) * @ORM\GeneratedValue(strategy="NONE") */ private $brand; /** * @ORM\Column(type="string", length=255); */ private $model; /** * @ORM\OneToMany(targetEntity="DriverRide", mappedBy="car") */ private $carRides; } And want to query for Cars that a Driver drove in:
$qb = $em->createQueryBuilder();
$qb->select('d, dr, c')
->from('Driver', 'd')
->leftJoin('d.driverRides', 'dr')
->leftJoin('dr.car', 'c')
->where('d.id = ?1') /* some Driver id */
->getQuery()->getArrayResult();
Expected results: Actual result: When I started doing some testing I found out I get a different result when I add a third column to the DriverRide table that isn't part of the composite primary key. When I removed the composite key and used an auto-generated id-column, everything worked as expected. Some test data you might want to use: INSERT INTO `car` (`brand`, `model`) VALUES
('BMW', '7 Series'),
('Crysler', '300'),
('Mercedes', 'C-Class'),
('Volvo', 'XC90');
INSERT INTO `driver` (`id`, `name`) VALUES
(1, 'John Doe'),
(2, 'Foo Bar');
INSERT INTO `driver_ride` (`driver_id`, `car`) VALUES
(1, 'Crysler'),
(1, 'Mercedes'),
(1, 'Volvo'),
(2, 'BMW');
|
| Comments |
| Comment by Benjamin Eberlei [ 05/Jul/12 ] |
|
Can you update to at least 2.2.1 and try again, because this fix here http://www.doctrine-project.org/jira/browse/DDC-1652 look like it could be related to your problem. |
| Comment by Sander Coolen [ 07/Jul/12 ] |
|
We're already using the 2.2.x-dev package. It does look similar to |
| Comment by Sander Coolen [ 08/Jul/12 ] |
|
Added testcase on 2.1.x (not the right one unfortunately) branch: https://github.com/doctrine/doctrine2/pull/395 BTW I was adding said testcase on master and got an error similar to |
| Comment by Benjamin Eberlei [ 09/May/13 ] |
|
I upgraded the testcase to master locally, and it seems to fail on Array hydration only now, with a notice: Exception: [PHPUnit_Framework_Error] Argument 1 passed to Doctrine\ORM\Internal\Hydration\ArrayHydrator::updateResultPointer() must be of the type array, string given, called in /home/benny/code/php/workspace/doctrine2/lib/Doctrine/ORM/Internal/Hydration/ArrayHydrator.php on line 196 and defined I remember fixing something similar for ObjectHydration (which works for your testcases). Will investigate more when I have time. |
[DDC-2281] Validation against database-first generated xml requires that the column order within a composite primary key match the order the columns are in in mapping xml Created: 06/Feb/13 Updated: 09/May/13 |
|
| Status: | Awaiting Feedback |
| Project: | Doctrine 2 - ORM |
| Component/s: | Mapping Drivers |
| Affects Version/s: | 2.3.2 |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Minor |
| Reporter: | Aaron Moore | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
In using a database-first approach utilizing orm:convert-mapping to generate xml, the validation and schema-tool reports that my composite primary key (ex. Columns A, C, B) be dropped and added in the order in which the mapping appears in the xml (ex. Columns A, B, C). These columns are not auto-increment and are simply a mixture of int and varchar. |
| Comments |
| Comment by Benjamin Eberlei [ 09/May/13 ] |
|
Is the composite key a mix of association and field types? |
| Comment by Aaron Moore [ 09/May/13 ] |
|
I'm trying to remember the usage as it was a short term project but I believe it is. For example a user has a userid. The table in question might have a primary key consisting of the userid and an int representing a year.. |
[DDC-2339] [GH-605] DDC-2338 Added failing test for composite foreign key persistance Created: 07/Mar/13 Updated: 09/May/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Improvement | Priority: | Major |
| Reporter: | Benjamin Eberlei | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of alex88: Url: https://github.com/doctrine/doctrine2/pull/605 Message: I've added this test regarding ticket DDC-2338 |
| Comments |
| Comment by Benjamin Eberlei [ 09/May/13 ] |
|
This is documented behavior and would just be an improvement |
[DDC-2190] findBy() support finding by a single DateTime but not by multiple DateTime Created: 06/Dec/12 Updated: 09/May/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Christophe Coevoet | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Attachments: |
|
| Description |
|
The following code works: $repository->findBy(array('date' => new \DateTime()))
but the following code fails as it does not apply the conversion of the date type for each element: $repository->findBy(array('date' => array(new \DateTime(), new \DateTime('tomorrow')))
|
| Comments |
| Comment by Benjamin Eberlei [ 06/Jan/13 ] |
|
This is actually very hard to implement, the problem is that we only have ARRAY constants for PDO::PARAM_INT and PDO::PARAM_STR - all the other types would require special handling. |
| Comment by Benjamin Eberlei [ 09/May/13 ] |
|
Attaching failing testcase. The idea is to have something like "datetime[]" as type and detect this in the SQLParserUtils of DBAL. Another approach would be to convert the values in the ORM already, before passing to the DBAL. |
[DDC-2411] Null values get reset when rehydrating an already managed entity Created: 23/Apr/13 Updated: 09/May/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | 2.3 |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Simon Garner | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | hydration | ||
| Description |
|
Scenario: 1) You have an entity with a ManyToOne relation (and probably other kinds too, but this is all I have tested) to another entity which is nullable. For example, let's say you have a Book entity which has an "illustrator" field which refers to a Person entity, representing the person who illustrated the book. If the book is not illustrated then you set the field to null. 2) You fetch a Book (by ID) which has its illustrator set to a particular Person. 3) You set that Book's illustrator to null. 4) Without flushing, you fetch the Book again, using different criteria: for example, by title. Because entities are Identity Mapped, this will run a query but then locate the same instance in memory, and try to hydrate that instance with the old data it just fetched. 5) Any fields on the instance that have modified values retain their new values (for example, if we changed the illustrator to a different Person, this would be retained), BUT any fields on the instance which are null get overwritten with the old data (so if we previously set the illustrator to null, without flushing, it would now be reset to the Person value that it had before). There seems to be a mistaken assumption here that null values are fields that have not been hydrated, when this is not necessarily the case. Is this the intended behaviour? The code that causes this behaviour is here: https://github.com/doctrine/doctrine2/blob/e561f47cb2205565eb873f0643637477bfcfc2ff/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php#L471 If you are wondering why anybody would want to fetch the entity again in step 4, my use case for this is the Symfony Validator (but I presume there could be others). If there are any unique constraints (Symfony ones, not Doctrine ones) on the entity, e.g. if we had a unique constraint on the Book title field, then when validating the Book the Symfony Validator would check if there are already any Book entities with the same title as the Book we're validating. It will find the Book that we are working with, and because entities are identity mapped, it will act upon the same instance, and the situation above occurs. Code example: <?php // Create some entities $john = new Person(); $jane = new Person(); $joe = new Person(); $book = new Book(); $em->persist($john); // Now let's try modifying the book $book = $bookRepository->find(123); // make some changes // now validate our changes with Symfony Validator // what happened to our book?? |
| Comments |
| Comment by Fabio B. Silva [ 24/Apr/13 ] |
|
Hi Simon, Could you please try to write a failing test case or paste your entities ? Cheers |
| Comment by Benjamin Eberlei [ 09/May/13 ] |
|
Verified by code review that this issue exists, but it will be very tricky to fix, because the null check is there for other reasons as well. |
[DDC-2147] Custom annotation in MappedSuperclass Created: 15/Nov/12 Updated: 07/May/13 |
|
| Status: | Awaiting Feedback |
| Project: | Doctrine 2 - ORM |
| Component/s: | Mapping Drivers, ORM |
| Affects Version/s: | 2.2.1 |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | kluk | Assignee: | Marco Pivetta |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Linux 3.6.6-1.fc17.x86_64 |
||
| Attachments: |
|
| Description |
|
When you try use custom annotation in mappedsuperclass like here http://pastebin.com/YMxKvcLk and then i try get metadata for class i get this error |
| Comments |
| Comment by kluk [ 15/Nov/12 ] |
|
error log from orm:validate-schema |
| Comment by Marco Pivetta [ 23/Jan/13 ] |
|
Copying from pastebin: use \Doctrine\ORM\Mapping as ORM; use \xxx\Doctrine\Annotation\Entity as re; use \xxx\Doctrine\Annotation\Forms as rf; use \Doctrine\Common\Collections; /** * @ORM\Entity */ class EventPicture extends \Picture { /** * @ORM\ManyToOne(targetEntity="Event", inversedBy="eventPicture") * @ORM\JoinColumn(name="FK_Event", referencedColumnName="id") */ protected $event; } use \Doctrine\ORM\Mapping as ORM; use \xxx\Doctrine\Annotation\Entity as re; use \xxx\Doctrine\Annotation\Forms as rf; use \Doctrine\Common\Collections; /** @ORM\MappedSuperclass */ class Picture extends \xxx\Doctrine\Entity\BaseEntity { /** * @ORM\Id * @ORM\Column(type="integer") * @ORM\GeneratedValue(strategy="IDENTITY") * @var type */ protected $id; /** * @ORM\Column(type="string",unique=true, nullable=false) * @rf\FileUpload(fileSize="php",uploadType="local",fieldName="link",formControl="FileUploadField",image=true) * */ protected $link; } kluk does this happen also with any other simple custom annotation? For example following:
/**
* @Annotation
* @Target({"PROPERTY","ANNOTATION"})
*/
final class Entity implements Annotation
{
/**
* @var string
*/
public $value;
}
|
| Comment by kluk [ 30/Jan/13 ] |
|
the same error when using simple annotation.
<?php
use \Doctrine\ORM\Mapping as ORM;
use \xxx\Doctrine\Annotation\Entity as re;
use \xxx\Doctrine\Annotation\Forms as rf;
use \Doctrine\Common\Collections;
/** @ORM\MappedSuperclass */
class Picture extends \xxx\Doctrine\Entity\BaseEntity {
/**
* @ORM\Id
* @ORM\Column(type="integer")
* @ORM\GeneratedValue(strategy="IDENTITY")
* @var type
*/
protected $id;
/**
* @ORM\Column(type="integer")
* @rf\SetClass({"class","hide"})
*/
public $value;
/**
* @ORM\Column(type="string",unique=true, nullable=true)
* @rf\FileUpload(fileSize="php",uploadType="local",fieldName="link",formControl="FileUploadField",image=true)
*
*/
protected $link;
}
When i remove $value , $picture from class everything goes ok.
/**
* INTERNAL:
* Adds a field mapping without completing/validating it.
* This is mainly used to add inherited field mappings to derived classes.
*
* @param array $fieldMapping
*
* @return void
*/
public function addInheritedFieldMapping(array $fieldMapping)
{
if(isset($fieldMapping['fieldName'])){
$this->fieldMappings[$fieldMapping['fieldName']] = $fieldMapping;
$this->columnNames[$fieldMapping['fieldName']] = $fieldMapping['columnName'];
$this->fieldNames[$fieldMapping['columnName']] = $fieldMapping['fieldName'];
}
}
But i dont know if this fix can break another part of doctrine. |
| Comment by Benjamin Eberlei [ 04/May/13 ] |
|
Can you put the code of your annotations online? I can't seem to understand why this happens. |
| Comment by kluk [ 07/May/13 ] |
|
Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml namespace libs\Doctrine\Annotation\Entity; use Doctrine\Common\Annotations\Annotation; /** @Annotation */ class CustomMapping extends Annotation { /** * * @var string */ public $className; /** * * * @var IQueryable| string */ public $dataSource; } |
[DDC-2424] Removing an inherited entity via a delete cascade constraint does not remove the parent row Created: 02/May/13 Updated: 06/May/13 |
|
| Status: | Awaiting Feedback |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | 2.3.3 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Bruno Jacquet | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Mysql 5.1.66 / Symfony 2.2.1 |
||
| Description |
|
For a parent class: /** * @ORM\Entity * @ORM\Table(name="Base") * @ORM\InheritanceType("JOINED") * @ORM\DiscriminatorColumn(name="discr", type="string") * @ORM\DiscriminatorMap({"child1" = "Child1", "child2" = "Child2"}) */ and simple Child1 & Child2 entities. With another entity (let's call it ExternalEntity) having a bidirectional OneToOne relation owned by Child1: class Child1 extends Base { /** * @ORM\OneToOne(targetEntity="ExternalEntity", inversedBy="xxx") * @ORM\JoinColumn(onDelete="CASCADE", nullable=false) */ private theForeignKey; } Enough for the context. $em->remove(instanceOfExternalEntity); removes the ExternalEntity row and the Child1 row. But a dangling row in the Base table is still there for the now inexistent Child1 instance. Though, a manual delete of either the associated Child1 OR Base row and then the ExternalEntity works. The problem with the cascading deletion of the parent seems to be only present when deleting through a MYSQL cascading delete from another row which has a foreign key on a child. (Not tested with a foreign key on the parent though) |
| Comments |
| Comment by Benjamin Eberlei [ 04/May/13 ] |
|
Can you show the CREATE TABLE and FOREIGN KEY statements of all the tables involved? It seems the cascade of the foreign keys is not propagated between multiple tables? |
| Comment by Bruno Jacquet [ 06/May/13 ] |
|
CREATE TABLE Base (id INT AUTO_INCREMENT NOT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB; ALTER TABLE Child1 ADD CONSTRAINT FK_179B6E88E992F5A FOREIGN KEY (foreignKey) REFERENCES ExternalEntity (id) ON DELETE CASCADE; |
| Comment by Bruno Jacquet [ 06/May/13 ] |
|
The problem is that, the SQL model never explicitely tells the DB to delete the corresponding Base when Child1 gets removed. It looks like it is handled by the doctrine entity manager layer and not the actual DB engine (Base has no on delete cascade nor foreign key to its children). |
| Comment by Bruno Jacquet [ 06/May/13 ] |
|
Maybe using cascade={"remove"}
, instead of onDelete="CASCADE"
to force the cascading process to be handled by doctrine would workaround the bug... But I prefer to have my DB do the logic work as much as possible. |
[DDC-2319] [GH-590] DQL Query: process ArrayCollection values to ease development Created: 25/Feb/13 Updated: 04/May/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Improvement | Priority: | Major |
| Reporter: | Benjamin Eberlei | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of michaelperrin: Url: https://github.com/doctrine/doctrine2/pull/590 Message: I added some code to ease "where in" parameter binding. As you know, when a where condition is added, the object itself can be passed as a parameter and it's id is automatically retrieved: ```php But it doesn't work for collections: Where categories is an `ArrayCollection` object (retrieved from a many to one relation for instance). This doesn't work in the current version of Doctrine, and my PR solved that. So far, the only solution is to do the following: ```php foreach ($categories as $category) { $categoryIds[] = $category->getId(); }$queryBuilder = $this And this is pretty borring when you have to do it several times for several entities. Note that I didn't add any unit test for this feature. Can you explain me where I should add the test? Thanks! |
[DDC-2316] [GH-588] ClassMetadataInfo: use reflection for creating new instance (on PHP >=5.4) Created: 23/Feb/13 Updated: 04/May/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 3.0 |
| Security Level: | All |
| Type: | Improvement | Priority: | Major |
| Reporter: | Benjamin Eberlei | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of Majkl578: Url: https://github.com/doctrine/doctrine2/pull/588 Message: On PHP >=5.4, use proper way for instantiating classes without invoking constructor. |
| Comments |
| Comment by Benjamin Eberlei [ 04/May/13 ] |
|
Scheduling this for 3.0, when we move to php 5.4 or higher requirement |
[DDC-2254] Exporting and restoring a query. Created: 23/Jan/13 Updated: 04/May/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | Documentation, DQL, ORM |
| Affects Version/s: | Git Master, 2.3.2 |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Improvement | Priority: | Major |
| Reporter: | Dries De Peuter | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | dql, rebuild, restore, save | ||
| Environment: |
OSX |
||
| Description |
|
When you have a queryBuilder and you want to break it down using getDQLParts, You can't restore it by looping over the parts and adding them. This is what I am doing:
$parts = $qb->getDQLParts();
// save the parts and use them in a different environment.
$newQb = $em->createQueryBuilder();
foreach ($parts as $name => $part) {
$newQb->add($name, $part);
}
|
| Comments |
| Comment by Dries De Peuter [ 23/Jan/13 ] |
|
I wrote a test showing the issue. https://github.com/NoUseFreak/doctrine2/commit/8574b79fd3d245532bbe7e310c5cbe083892057a |
| Comment by Benjamin Eberlei [ 04/May/13 ] |
|
This is not a bug, because restoring queries is not yet a feature of the QueryBuilder. Marking as possible improvement for future. |
[DDC-2167] [GH-522] [DDC-2166] Refactor identity hash generation Created: 25/Nov/12 Updated: 01/May/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Improvement | Priority: | Major |
| Reporter: | Benjamin Eberlei | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of beberlei: Url: https://github.com/doctrine/doctrine2/pull/522 Message: This work prepares for the merge of GH-232, allowing more complex and robust identifier hash generation. |
[DDC-2133] Issue with Query::iterate and query mixed results Created: 09/Nov/12 Updated: 01/May/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | 2.2.1 |
| Fix Version/s: | 3.0 |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Oleg Namaka | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||
| Description |
|
Consider this code:
$dql = "
SELECT Page, Product.name
FROM Dlayer\\Entity\\Page Page
INNER JOIN Page.Product Product
";
$q = ($em->createQuery($dql));
foreach ($q->iterate() as $entry) {
$page = $entry[0][0];
$name = $entry[0]['name'];
}
This results with undefined index: 'name' for the second entry. First result keys are (notice just one array element with index 0):
0
array(2) {
[0] =>
int(0)
[1] =>
string(4) "name"
}
but all others are different (notice two array elements with index 0 and the other one that is incrementing):
the second one:
0
array(1) {
[0] =>
int(0)
}
1
array(1) {
[0] =>
string(4) "name"
}
the third one:
0
array(1) {
[0] =>
int(0)
}
2
array(1) {
[0] =>
string(4) "name"
}
What's wrong with this approach? Is it a bug or mixed results should not be used with the iterate method? |
| Comments |
| Comment by Benjamin Eberlei [ 12/Nov/12 ] |
|
This is a known issue that we don't have found a BC fix for and as I understand Guilherme Blanco requires considerable refactoring. |
[DDC-349] Add support for specifying precedence in joins in DQL Created: 18/Feb/10 Updated: 01/May/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | DQL |
| Affects Version/s: | 2.0-ALPHA4 |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Improvement | Priority: | Major |
| Reporter: | Dennis Verspuij | Assignee: | Roman S. Borschel |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | None | ||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Description |
|
This request is in followup to my doctrine-user message "Doctrine 2.0: Nested joins'. As a short example the following is a SQL statement with a nested join, where the nesting is absolutely necessary to return only a's together with either both b's and c's or no b's and c's at all: SELECT * In order for Doctrine 2 to support this the BNF should be something like: This would allow DQL like: SELECT A, B, C What further needs to be done is that the DQL parser loosly couples the ConditionalExpression to any of the previously parsed JoinAssociationPathExpression's instead of tieing it explicitely to the JoinAssociationPathExpression that preceedes it according to the old BNF notation. The new BNF should however not require any changes to the hydrator. Therefore I have the feeling that improving the DQL parser for nested joins does not require extensive work, while the benefit of running these kind of queries is considerable. As an extra substantiation here are links to (BNF) FROM clause documentations of the RDBMS's that Doctrine 2 supports, they all show support for nested joins: I surely hope you will consider implementing this improvement because it would save me and others from the hassle of writing raw SQL queries or executing multiple (thus slow) queries in DQL for doing the same. Thanks anyway for the great product so far! |
| Comments |
| Comment by Guilherme Blanco [ 13/Apr/10 ] |
|
This seems to be a valid issue to me. This implementation is the actual solution to associations retrieval that are inherited (type joined). Example: /** Joined */
class Base {}
class Foo extends Base {}
class Bar {
public $foo;
}
// This causes the CTI to link as INNER JOIN, which makes the result become 0
// il if you have no Foo's defined (although it should ignore this)
$q = $this->_em->createQuery('SELECT b, f FROM Bar b LEFT JOIN b.foo f');
|
| Comment by Roman S. Borschel [ 13/Apr/10 ] |
|
Yes, this is a possible solution for |
| Comment by Roman S. Borschel [ 13/Apr/10 ] |
|
So, no, this has nothing to do with |
| Comment by Roman S. Borschel [ 13/Apr/10 ] |
|
On a side note I would still like to know/see the following for this issue:
So far, my stance on this issue is: 1) It doesnt make sense (semantically) in DQL Thus I am currently leaning towards "Wont fix" for this issue. |
| Comment by Dennis Verspuij [ 13/Apr/10 ] |
|
Hi Roman. I understand your doubts, and I have been breaking my head over SELECT A.id, A.username, A.balance, COALESCE(SUM(B.stake), 0) AS sumstake, COUNT(B.id) AS nrbets But let's put it another way. I would also like this feature to be supported in DQL Btw, I recall to have successfully used the nested join syntax in HQL (.NET Hibernate) Furthermore, in reply to your stances: Well, this is it, can't find any more words to promote and make you enthusiastic.... lol. |
| Comment by Dennis Verspuij [ 13/Apr/10 ] |
|
Ok, I have not given up yet... Imagine a book store that sells books of various authors and keeps track of those sales. SELECT A., B., S.* In DQL it would then be something like: SELECT A., B., S.* If the database would contain thousands of books, but sales for just a I have attached a test casefor a similar query, though without the additional One last note, you shouldn't be afraid that nesting joins is not in the P.S. I had a hard time finding out how to run the test cases, I could not find |
| Comment by Dennis Verspuij [ 13/Apr/10 ] |
|
Test case as SVN patch using a parenthesized join. |
| Comment by Roman S. Borschel [ 29/May/10 ] |
|
@"The need for native queries partly reverts the benefits Doctrine offers in the first place." That is something I hugely disagree with. Neither SQL abstraction, nor database vendor independence is the main purpose of an ORM like Doctrine 2. We could rip out DQL and any other querying mechanism except a basic find() (and lazy-loading, of course), only providing the native query facility and even only supporting MySQL and would still retain all the core ORM functionality. NativeQuery is one of the best and core "features" of the project. It is even the foundation for DQL. A DQL query is nothing more than an additional (beautiful) abstraction but what comes out is a native query + a ResultSetMapping, the same thing you can build yourself in the first place, even using the mapping metadata to construct the query. Nothing forces you to hardcode table and column names in native queries if you don't want that. Just use the mapping metadata, DQL does the same. SQL abstraction and database vendor independence is icing on the cake, not the heart of the ORM. |
[DDC-2078] [GH-479] [WIP][Mapping] Ported some of the yaml driver to use Symfony config Created: 14/Oct/12 Updated: 01/May/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Improvement | Priority: | Major |
| Reporter: | Benjamin Eberlei | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of kimhemsoe: Url: https://github.com/doctrine/doctrine2/pull/479 Message: Looking for some input. How much validation and normailization should i push to the configuration ? Should i use default values so we can remove alot of lines from the driver ? Is the way im allowing to extend the configuration good enough for Gedmo and others (untested)? |
[DDC-2406] Merging of new detached entities with PrePersist lifecycle callback breaks Created: 19/Apr/13 Updated: 01/May/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | 2.3.2 |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Oleg Namaka | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | merge,, prePersist | ||
| Description |
|
Merging of new detached entities with PrePersist lifecycle callback breaks: Code snippet:
class A
{
/**
* @ORM\ManyToOne(targetEntity= ...
* @ORM\JoinColumn(name=" ...
*/
protected $b;
public function getB()
{
return $this->b;
}
public function setB($b)
{
$this->b = $b;
}
/**
*
* @ORM\PrePersist
*
* @return void
*/
public function onPrePersist()
{
if ($this->getB() === null) {
throw new \Exception('B instance must be defined);
}
....
}
}
class B
{
}
$a = new A();
$b = $em->find('B', 1);
$a->setB($b);
$em->persist($a); // works fine as B instance is set
$em->detach($a);
$a = $em->merge($a) // breaks in onPrePersist
The reason it happens is that the merge operation is trying to persist a new entity created by uow::newInstance($class) without populating its properties first: // If there is no ID, it is actually NEW. .... if ( ! $id) { $managedCopy = $this->newInstance($class); $this->persistNew($class, $managedCopy); } else { .... This should happen first for the $managedCopy:
// Merge state of $entity into existing (managed) entity
foreach ($class->reflClass->getProperties() as $prop) {
....
|
| Comments |
| Comment by Fabio B. Silva [ 28/Apr/13 ] |
|
Benjamin Eberlei, Is this an expected behavior ? I mean.. This issue is about dispatch the event before copy the original values into the managed instance. |
| Comment by Benjamin Eberlei [ 01/May/13 ] |
|
Fabio B. Silva he talks about $em->merge() on a detached entity calling pre persist. This should only happen on a NEW entity, not on a DETACHED one. |
| Comment by Oleg Namaka [ 01/May/13 ] |
|
I tend to disagree with the statement above about pre persist that should not happen on a detached entity being merged back in. If this event handler contains a business logic that this entity needs to be checked against and the detached entity was modified before the merge operation in a way that invalidates it in the prePersist than I will end up with the invalid entity in the identity map. If the merge operation calls persist it must run the prePersist event handler as well for consistency. If there is a logic that prevents persisting invalid entities why should it bypassed in the merge operation? |
[DDC-2420] [GH-656] [DDC-2235] Fix for using a LEFT JOIN onto an entity with single table inheritance Created: 28/Apr/13 Updated: 28/Apr/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Doctrine Bot | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of tarnfeld: Url: https://github.com/doctrine/doctrine2/pull/656 Message: Possible fix for the bug DDC-2235. I'd love to hear some opinions on whether this is the right way to go about this issue. I'm not particularly familiar with the internals of doctrine so there may be a better solution. ------ The issue is when using DQL to perform a left join on an entity using single However when using a left join having an `IN()` in the main where clause makes I've added some regression tests to ensure this bug never creeps back in. They fail on master (highlighting the bug) and pass after these commits have been applied. I've also included a couple of other queries as tests to be sure only this one case has been affected. |
[DDC-776] Persisters use a fixed "SELECT" SQL statements Created: 29/Aug/10 Updated: 23/Apr/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | 2.0-BETA3 |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Improvement | Priority: | Major |
| Reporter: | Aaron DM | Assignee: | Roman S. Borschel |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Windows 7, Apache 2.2, MSSQL Server, PHP 5.3.3 |
||
| Description |
|
I am currently trying to work with BINARY columns with Doctrine 2 and MSSQL. In order to get my Entities working I had to create a custom Mapping Type for Binary columns. All went well in this case and I've got it running. The problem arises when I am attempting to use Associative mapping (OneToOne/ManyToMany). The problem is, in order to do a select for an SQL column, I had to create a DQL function called "CONVERT" so that I use WHERE statements: return $this->createQueryBuilder('u') As you see, I must do this in order to get a result. However, when I'm using associative mapping; this is what it does: return 'SELECT ' . $this->_getSelectColumnListSQL() As you can see, its some what hard coded and I cannot change it without changing the actual code in So, I would first like to know if there was maybe a way you could allow us to customize the SELECT statement that the persisters use - or maybe (though I'm not sure how this will be done) make them use user-defined repository functions? Like $myRepo->find($identifier) Not entirely sure if I explained this properly and I do realize my circumstance is highly odd - but this does seem like a limitation and because of this I cannot use associative mapping. |
| Comments |
| Comment by locs [ 23/Apr/13 ] |
|
Hi, i try to make my custom type for binary field in MSSQL. |
[DDC-2405] Changing strategy generates bad query. Created: 19/Apr/13 Updated: 21/Apr/13 |
|
| Status: | Reopened |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Van Rotemberg | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
For (unit, acceptance, functional) testing purpose I need to change the strategy of my GameStuff Entity class. In previous version is was using php instruction below, but since doctrine orm 2.3, it doesn't work anymore. $orm->getClassMetaData('Entities\GameStuff')->setIdGeneratorType(\Doctrine\ORM\Mapping\ClassMetadata::GENERATOR_TYPE_NONE); will trigger: Doctrine\DBAL\DBALException: An exception occurred while executing 'INSERT INTO vbank_accounts (game_id, updated_at, created_at) VALUES (?, ?, ?)' with params {"1":1000010, "2":0,"3":"2013-04-19 17:16:05","4":"2013-04-19 17:16:05"}: SQLSTATE[HY093]: Invalid parameter number: number of bound variables does not match number of tokens |
| Comments |
| Comment by Benjamin Eberlei [ 20/Apr/13 ] |
|
The problem is that changing ClassMetadata after generating it from the cache is not really supported and depends on the Internal State of other classes. Have you tried creating a completly new EntityManager and then directly setting this? It could be that the SQL for the entity was already generated inside Doctrine, with the ID Generator information at IDENTITY_AUTO. |
| Comment by Van Rotemberg [ 21/Apr/13 ] |
|
> The problem is that changing ClassMetadata after generating it from the cache is not really supported Yeah, it is a problem indeed, why set ticket status to resolved ? Please fix it or put setIdGeneratorType as private, or AT LEAST add a context exception ... |
| Comment by Marco Pivetta [ 21/Apr/13 ] |
|
Almost every interaction with metadata outside the `loadClassMetadata` event will cause unexpected problems. I don't think throwing an exception there helps in any way. |
| Comment by Van Rotemberg [ 21/Apr/13 ] |
|
@marco pivetta The generation of the actual exception comes from DBALException on the query excetion and point a bad generated query (Invalid parameter number), Adding an exception is just the fast way pointing where the problem comes from and that "setting metadata after loadMetadata is not supported anymore". (It will spare developper's time that used to set metadata, but also help future contribution) > Please fix it or put setIdGeneratorType as private, or AT LEAST add a context exception ... |
[DDC-2401] INDEX BY not working on multiple columns Created: 16/Apr/13 Updated: 18/Apr/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | Documentation, ORM |
| Affects Version/s: | 2.3.3 |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Quintenvk | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Attachments: |
|
| Description |
|
According to the docs on this page: The following "multi-dimensional index" should be perfectly possible, with a default hydration mode: However, b.id is completely ignored (it is a numeric primary key). I tried to go further, giving 2 products a matching barcode and indexing by barcode and then a (unique, numeric) productid. Only the barcode worked as a key and only one of the products with a matching barcode was selected. I used this query to test: I also flagged the docs, because I don't think a userid should/could be starting from 0. |
| Comments |
| Comment by Fabio B. Silva [ 18/Apr/13 ] |
|
Hi Quintenvk Could you please try to write a failing test case ? Thanks |
| Comment by Quintenvk [ 18/Apr/13 ] |
|
I added a testcase. Please note that the database settings are to be configured in Core/simplys/simplys.php, and that the dump is in dummy.sql. Apart from that all should run well immediately. |
| Comment by Quintenvk [ 18/Apr/13 ] |
|
Fabio, Please check the zip I just attached. I hope this helps you in finding the problem. Thanks, |
| Comment by Fabio B. Silva [ 18/Apr/13 ] |
|
Thanks Quintenvk, SELECT p.barcode, p.id, p.name FROM \core\Simplys\Entity\Products p INDEX BY p.barcode JOIN p.businessid b INDEX BY p.id In this DQL you are trying to index by scalar values, Also the INDEX BY documentations seems wrong to me. The given DQL : SELECT u.id, u.status, upper(u.name) nameUpper FROM User u INDEX BY u.idJOIN u.phonenumbers p INDEX BY p.phonenumber Show the following result : array
0 =>
array
1 =>
object(stdClass)[299]
public '__CLASS__' => string 'Doctrine\Tests\Models\CMS\CmsUser' (length=33)
public 'id' => int 1
..
'nameUpper' => string 'ROMANB' (length=6)
1 =>
array
2 =>
object(stdClass)[298]
public '__CLASS__' => string 'Doctrine\Tests\Models\CMS\CmsUser' (length=33)
public 'id' => int 2
...
'nameUpper' => string 'JWAGE' (length=5)
Which IMHO represents another DQL, something like : SELECT u, p , upper(u.name) nameUpper FROM User u INDEX BY u.id JOIN u.phonenumbers p INDEX BY p.phonenumber |
| Comment by Quintenvk [ 18/Apr/13 ] |
|
Thanks for your reply Fabio. Thanks, |
| Comment by Fabio B. Silva [ 18/Apr/13 ] |
|
Not sure if it's exactly the result you need but you can try Something like : SELECT p, b FROM \core\Simplys\Entity\Products p INDEX BY p.barcode JOIN p.businessid b INDEX BY p.id or something like : SELECT PARTIAL p.{id, barcode, name}, b.{id, attributesYouNeed} FROM \core\Simplys\Entity\Products p INDEX BY p.barcode JOIN p.businessid b INDEX BY p.id
And than : $result = $query->getArrayResult(); |
| Comment by Quintenvk [ 18/Apr/13 ] |
|
Both produce the same result as the query I had. I think i'll move on to loops after a bit more research, too bad it can't be done (at least for now) though... Would've been nice. Thanks for your help though! |
[DDC-1940] Doctrine DQL: erroneous sql generation from dql join with "WITH" or "WHERE" clause Created: 23/Jul/12 Updated: 14/Apr/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | DQL |
| Affects Version/s: | 2.2.2 |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Enea Bette | Assignee: | Guilherme Blanco |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | None | ||
| Environment: |
LAMP, debian squeeze |
||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Description |
|
I'm having big troubles while developing a quietly advanced DQL query for a tiny DMS: The schema: DmsObject is a superclass for which two subclasses exist (document and folder) UserRights and GroupRight (which are associative entities in the db, pointing respectively to user and group tables). User and Group represent (obvious) the dms "actors". SELECT o, ur, gr from module\EDMS\business\DmsObject o join o.userRights ur join o.groupRights gr WHERE o.ownerUser=ur.user AND o.ownerGroup=gr.group The WHERE condition is WRONG! Doctrine switches the two tables. I've already checked the mapping (it's ok!) and checked also where the fk's point in the database (ok!).
...
LEFT JOIN dms_folder d1_
ON d0_.id = d1_.id
LEFT JOIN dms_document d2_
ON d0_.id = d2_.id
INNER JOIN dms_user_object_rights d3_
ON d0_.id = d3_.document_id
INNER JOIN dms_group_object_rights d4_
ON d0_.id = d4_.document_id
WHERE d0_.sys_group_owner = d3_.user_id
AND d0_.sys_user_owner = d4_.group_id
...
This seems to be a bug in the DQL translator. |
| Comments |
| Comment by Benjamin Eberlei [ 29/Jul/12 ] |
|
Enea Bette Can you attach the entities (stripped down to the fields we need here)? Can you check guilherme? This looks really weird. It should be: WHERE d0_.sys_user_owner = d3_.user_id AND d0_.sys_group_owner = d4_.group_id |
| Comment by Guilherme Blanco [ 29/Jul/12 ] |
|
Enea Bette Can you please provide your entities? |
| Comment by Hugo Henrique [ 11/Apr/13 ] |
|
I'm having a similar problem with the query: SELECT um, p FROM Ciwwic\AppBundle\Entity\Provider p LEFT JOIN Ciwwic\UserBundle\Entity\UserMeta um WITH um.user = p.id WHERE p.id = 30 When you run this query DQL she returns an empty array. SELECT p, um FROM Ciwwic\AppBundle\Entity\Provider p LEFT JOIN Ciwwic\UserBundle\Entity\UserMeta um WHERE p.id = 30 AND um.user = 30 |
| Comment by Fabio B. Silva [ 14/Apr/13 ] |
|
Hi Enea If i got it correctly /** * @ORM\ManyToOne(targetEntity="library\system\business\User", fetch="EAGER") * @ORM\JoinColumn(name="sys_group_owner", referencedColumnName="ID") */ protected $ownerUser; /** * @ORM\ManyToOne(targetEntity="library\system\business\Group", fetch="EAGER") * @ORM\JoinColumn(name="sys_user_owner", referencedColumnName="ID") */ protected $ownerGroup; It should be : /** * @ORM\ManyToOne(targetEntity="library\system\business\User", fetch="EAGER") * @ORM\JoinColumn(name="sys_user_owner", referencedColumnName="ID") */ protected $ownerUser; /** * @ORM\ManyToOne(targetEntity="library\system\business\Group", fetch="EAGER") * @ORM\JoinColumn(name="sys_group_owner", referencedColumnName="ID") */ protected $ownerGroup; |
[DDC-2374] [GH-634] [WIP] Value objects Created: 26/Mar/13 Updated: 14/Apr/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | New Feature | Priority: | Major |
| Reporter: | Benjamin Eberlei | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||
| Description |
|
This issue is created automatically through a Github pull request on behalf of beberlei: Url: https://github.com/doctrine/doctrine2/pull/634 Message: This pull request takes a different approach than GH-265 to implement ValueObjects. Instead of changing most of the code in every layer, we just inline embedded object class metadata into an entities metadata and then use a reflection proxy that looks like "ReflectionProperty" to do the rewiring. The idea is inspired from Symfony Forms 'property_path' option, where you can write and read values to different parts of an object graph. This is a WIP, there have been no further tests made about the consequences of this approach. The implementation is up for discussion. |
[DDC-93] It would be nice if we could have support for ValueObjects Created: 01/Nov/09 Updated: 14/Apr/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | None |
| Fix Version/s: | 2.x |
| Security Level: | All |
| Type: | New Feature | Priority: | Major |
| Reporter: | Avi Block | Assignee: | Guilherme Blanco |
| Resolution: | Unresolved | Votes: | 37 |
| Labels: | None | ||
| Issue Links: |
|
||||||||||||||||
| Description |
| Comments |
| Comment by Benjamin Eberlei [ 05/Nov/09 ] |
|
formated snippets nicely |
| Comment by Andrea Turso [ 09/Dec/09 ] |
|
I need this feature too. But I would suggest using the same annotation used by JPA @Embeddable +1 |
| Comment by Alan Gabriel Bem [ 17/Dec/09 ] |
|
You should also take into consideration different storage strategies of ValueObjects. Martin Fowler points out - in „PoEAA" - two approaches: Embedded Value (which is the one presented above) and Serialized LOB . |
| Comment by Avi Block [ 17/Dec/09 ] |
|
Of course technically we can similate a serialized LOB with a new Doctrine 2 type. |
| Comment by Alan Gabriel Bem [ 17/Dec/09 ] |
|
I don't like that idea - Its so not generic. VO as a pattern is important building block of domain model, which clearly indicates that VO as a feature of Doctrine2 should be tailor-made. To anyone of dev-team reading this issue: without VOs Doctrine is not yet DDD-ready, please hurry |
| Comment by Roman S. Borschel [ 18/Dec/09 ] |
|
Serialized LOB is not very useful IMHO and has lots of problems (many mentioned in PoEEA already). @Alan: I appreciate your nice reminder and I'm sure you mean it in a friendly way, but please keep in mind that noone is paid to work on this project. It all happens in free/spare time and the current state of the project already consumed at least 1 1/2 years spending many hours weekly on this project from me alone. Not to speak of the others. Thus, there is no point in demanding something or telling us to hurry. The best way to get a feature in is to provide a (good) patch that we find worth including. I started to add notes to this issue to collect all the things that need to be done for this feature. In the meantime, its not too hard/ugly to get a half-way decent embedded value yourself: /** @Entity @HasLifecycleCallbacks */
class Foo {
// annotations not shown
private $id;
private $embedded;
private $value1; // never reveal to public
private $value2; // never reveal to public
private $value3; // never reveal to public
public function getEmbedded() {
return $this->embedded;
}
public function setEmbedded($embedded) {
$this->embedded = $embedded;
}
/** @PrePersist @PreUpdate */
function _destructEmbedded() {
// destruct $embedded into $value1, $value2, $value3
}
/** @PostLoad */
function _constructEmbedded() {
// construct $embedded from $value1, $value2, $value3
}
}
Several variations of this are possible, also with an external event listener instead of callbacks but in that case you might need to use reflection to get at the values. |
| Comment by Alan Gabriel Bem [ 25/Dec/09 ] |
|
I want to share my thoughts on possible VOs collections implementations. 1. As it was mentioned earlier serialized (C)LOB is one solution. Implementation of storing/retrieving object graphs alone is quite simple, but it's complex in terms of SELECTs with conditions. I'm not taking Regexp or XPath operators into consideration as only few RDBMS support them. 2. The second solution is to break VOs graph into separate related table... or tables if we consider that VO can contain another VO(s). It's not so fast as serialized LOB but more flexible and it utilize power of RDMS, In conclusion: I can't tell which approach is superior, because each of them is valid under different circumstances. Hope this helps. @Alan: I appreciate your nice reminder and I'm sure you mean it in a friendly way [...] Of course I do. |
| Comment by Benjamin Eberlei [ 13/Mar/10 ] |
|
It would be easy to implement value objects in userland using the XML capabilities of many RDBMS: 1. Implement an Xpath function on the Dql Parser The second point can be heavily optimized when value objects are immutable with an own identiy map of value types inside the Type flyweight instance. |
| Comment by Avi Block [ 13/Mar/10 ] |
|
I more or less suggested something similar above. |
| Comment by Benjamin Eberlei [ 14/Mar/10 ] |
|
ah, my bad - i must have overseen this |
| Comment by John Kleijn [ 16/May/10 ] |
|
+1 This would be awesome. |
| Comment by Matthias Pigulla [ 09/Nov/10 ] |
|
Don't forget (especially with regard to SLOBs) that values might in turn contain references to Entities. Example: An "Order" might be an @Entity and might have a field (an array) of OrderLineItems as value. Each OrderLineItem might e. g. carry quantity or disconunt and references a Product (@Entity). So even if you don't need the traversal from Product to all the Orders it is contained in, serializing the OrderLineItems needs a way to "cut off" the object graph at the transition towards the Product but must place some kind of referral there so that upon unserialization (of the OrderLineItem list, that is, during Order load) the Product references in every OrderLineItem are at least initialized with proxies again. Don't know whether/how referential integrity (OrderLineItems <-> Products) would make sense or could be implemented here. |
| Comment by Benjamin Eberlei [ 24/Dec/10 ] |
|
Pushed back to 2.x, this feature is probably the largest feature request we have and we'd rather focus on small improvements for 2.1 |
| Comment by Nino Martincevic [ 11/Jan/11 ] |
|
Several thinks to consider/not to oversee here: 1) There are value objects with identity. I know that is not DDD-conform but only at first sight. It means they are technically entities but are treated like VOs. 2) In virtually all (business) cases a collection of VO is an Entity. How else could you reference (add or remove) single elements of that list? @Matthias: OrderLineItems is an example of actually being an Entity. |
| Comment by Ondrej Sibrina [ 03/Jun/11 ] |
|
Hi guys. I face this in my own way. Hope you won't wake up your neighbours with loud laugh. Every @Entity extends my BaseEntity object which provide kind of wrap for value with ValueBase object. So when want to get/set value from entity you call $entity->getData() where you won't get value "data" but wrapping ValueBase for value "data". Then you can get bare value by getValue(). Name of value class is in annotation and would be child of ValueBase. There's also parent class Base for EntityBase and ValueBase. In my case class Base is something like HTML element. So in the end you can use $entity->renderHtml() or $value->renderHtml() no matter if you're rendering value or @Entity. There's more features like validation, filtering and hydration value/entity from HTML forms, but it's extra. Implementation: "Base.php"
/* @MappedSuperclass */
abstract class Base {
/* there're methods like _getParent(), _getPropertyName(), etc. used in code behind */
}
"ValueBase.php" abstract class ValueBase extends Base { public function getValue() { return $this->_getParent()->{$this->_getPropertyName()}; } public function setValue($value) { $this->_getParent()->{$this->_getPropertyName()} = $value; } } "EntityBase.php" /** @MappedSuperclass */ abstract class EntityBase extends Base { public function __call($name, $arguments) { /* get property object */ $pattern = '/^get(.*)$/u'; preg_match($pattern, $name, $matches); if (isset($matches[1])) { $propertyName = lcfirst($matches[1]); return $this->get($propertyName); } /* set entity */ $pattern = '/^set(.*)$/u'; preg_match($pattern, $name, $matches); if (isset($matches[1])) { $propertyName = lcfirst($matches[1]); return $this->set($propertyName, $arguments[0]); } } public function get($propertyName) { $property = $this->_getElementProperty($propertyName); if ($property == null) throw new Exception(sprintf("There isn't property like '%s'.", $propertyName)); /* for collections and entities */ if ($property["type"] == "collection" || $property["type"] == "entity") { $element = $this->{$propertyName}; if ($element != null) { $element->_setParent($this); $element->_setPropertyName($propertyName); } elseif ($property["type"] == "entity") { $element = new $property["class"]; $element->_setParent($this); $element->_setPropertyName($propertyName); $element->_setNullEntity(); $this->{$propertyName} = $element; } return $element; } else { /* for values */ if (!isset($this->_loadedEntities[$propertyName])) { $this->_loadedEntities[$propertyName] = new $property["class"]($this, $propertyName); } return $this->_loadedEntities[$propertyName]; } } public function set($propertyName, $value) { $property = $this->_getElementProperty($propertyName); if ($property == null) throw new Exception(sprintf("There isn't property like '%s'.", $propertyName)); /* for collections and entities */ if ($property["type"] == "collection" || $property["type"] == "entity") { $this->{$propertyName} = $value; } /* for values */ else { throw new Exception(sprintf("Can't call set on value property '%s'.", $propertyName)); } return $this; } } Note that there's something i call "NullEntity". Instead of getting bare "null" you'll get @Entity child of EntityBase, where is set property nullEntity. Then there's posibility to work with null entity (for example renderHtml with empty inputs). It would be nice, if this is support by Doctrine natively, because i have some performace problems with my implementation. If it's interest in my whole code i can send you. But of course there's some security holes so i'll send it privetely. Thanks for understand and for Doctrine of course. |
| Comment by Mathias Verraes [ 13/Jul/11 ] |
|
Note that Roman's workaround presented here does not work. /** @PrePersist @PreUpdate */
function _destructEmbedded() {
// destruct $embedded into $value1, $value2, $value3
}
Doctrine tracks changes and does not perform updates when no changes are found. $embedded is not mapped, so it's not tracked and won't be taken into account by Doctrine when updating. Therefore, if $embedded is the only value that was changed, the PreUpdate event won't be triggered. The easiest thing to do is to simply destruct the VO on every mutation: public function setEmbedded($embedded) { $this->embedded = $embedded; $this->_destructEmbedded(); } The downside is that you need to remember to call the method in every setter, but apart from that, there are no side effects, it always works and it's just one line of code _constructEmbedded() keeps working as is, postLoad will always be triggered. |
| Comment by Benjamin Dulau [ 18/Dec/11 ] |
|
Hi, This feature would be awesome ! If you plan to implement this, please remember that you can have nested VOs. I have no doubts that you've already took this in consideration, but i prefer pointing this out, just in case |
| Comment by Benjamin Eberlei [ 20/Jan/12 ] |
|
work has been started, https://github.com/doctrine/doctrine2/pull/265 |
| Comment by Matthias Pigulla [ 23/Nov/12 ] |
|
Does the new "complex sql types" feature help here - I mean, could that be used to map a value object to more than one column in the database? |
| Comment by songoko songowan [ 10/Feb/13 ] |
|
@Benjamin Eberlei The request seems to be closed in the link you provided! Does that mean that this feature won't be implemented?! |
| Comment by Marco Pivetta [ 10/Feb/13 ] |
|
songoko songowan no, it just probably wasn't the correct way of implementing this |
| Comment by Daniel Pitts [ 11/Apr/13 ] |
|
I'm curious if any effort is currently being put into this. I would really love to have this feature available. |
| Comment by Marco Pivetta [ 11/Apr/13 ] |
|
Daniel Pitts this is being developed in DDC-2374 ( https://github.com/doctrine/doctrine2/pull/634 ) |
[DDC-2381] Pagination query can be simplified when simple joins are applied Created: 31/Mar/13 Updated: 08/Apr/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | 2.3, 2.4 |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Sergey Gerdel | Assignee: | Marco Pivetta |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | paginator | ||
| Attachments: |
|
| Description |
|
Hi. SELECT DISTINCT id0 FROM (SELECT m0_.id AS id0, m0_.title AS title1, m0_.text AS text2, m0_.price AS price3, m0_.originalPrice AS originalPrice4, m0_.condition_type AS condition_type5, m0_.image_1 AS image_16, m0_.image_2 AS image_27, m0_.image_3 AS image_38, m0_.image_4 AS image_49, m0_.image_5 AS image_510, m0_.video AS video11, m0_.contact_email AS contact_email12, m0_.contact_name AS contact_name13, m0_.contact_phone AS contact_phone14, m0_.contact_type AS contact_type15, m0_.published AS published16, m0_.type AS type17, m0_.status AS status18, m0_.highlight AS highlight19, m0_.urgent AS urgent20, m0_.topads AS topads21, m0_.period AS period22, m0_.hits AS hits23, m0_.ip AS ip24, m0_.created_at AS created_at25, m0_.updated_at AS updated_at26 FROM milla_message m0_ INNER JOIN milla_currency m1_ ON m0_.currency_id = m1_.id INNER JOIN milla_category m2_ ON m0_.category_id = m2_.id INNER JOIN milla_region m3_ ON m0_.region_id = m3_.id INNER JOIN milla_city m4_ ON m0_.city_id = m4_.id WHERE m0_.status = 1 ORDER BY m0_.published DESC) dctrn_result LIMIT 20 OFFSET 0 why SELECT DISTINCT %s FROM (%s) dctrn_result ??? |
| Comments |
| Comment by Marco Pivetta [ 31/Mar/13 ] |
|
Not a blocker |
| Comment by Marco Pivetta [ 31/Mar/13 ] |
|
What's the result of `EXPLAIN` on a query without the subquery? |
| Comment by Sergey Gerdel [ 31/Mar/13 ] |
|
explain without the subquery |
| Comment by Marco Pivetta [ 31/Mar/13 ] |
|
Sergey Gerdel that's not the same query. |
| Comment by Marco Pivetta [ 31/Mar/13 ] |
|
Sergey Gerdel this is still using Using index; Using temporary; Using filesort Check your indexes |
| Comment by Sergey Gerdel [ 31/Mar/13 ] |
|
Not in the index problem SELECT DISTINCT id0 FROM (SELECT m0_.id AS id0, m0_.title AS title1, m0_.text AS text2, m0_.price AS price3, m0_.originalPrice AS originalPrice4, m0_.condition_type AS condition_type5, m0_.image_1 AS image_16, m0_.image_2 AS image_27, m0_.image_3 AS image_38, m0_.image_4 AS image_49, m0_.image_5 AS image_510, m0_.video AS video11, m0_.contact_email AS contact_email12, m0_.contact_name AS contact_name13, m0_.contact_phone AS contact_phone14, m0_.contact_type AS contact_type15, m0_.published AS published16, m0_.type AS type17, m0_.status AS status18, m0_.highlight AS highlight19, m0_.urgent AS urgent20, m0_.topads AS topads21, m0_.period AS period22, m0_.hits AS hits23, m0_.ip AS ip24, m0_.created_at AS created_at25, m0_.updated_at AS updated_at26 FROM milla_message m0_ WHERE m0_.status = 1 ORDER BY m0_.published DESC) dctrn_result LIMIT 20 OFFSET 0 Time: 104.614s explain 3 SELECT DISTINCT m0_.id AS id0 FROM milla_message m0_ WHERE m0_.status = 1 ORDER BY m0_.published DESC LIMIT 20 OFFSET 0; Time: 0.001s explain 4 |
| Comment by Marco Pivetta [ 01/Apr/13 ] |
|
Sergey Gerdel the ORM cannot simplify a complex query that way. There may be a conditional on one of the joined results, or generally usage of one of the joined results. Things that could be optimized here are:
The problem I see here is that the chance to spawn random bugs because of the optimization is very high, and you'd have to rewrite `walkSelectStatement` |
| Comment by Marco Pivetta [ 01/Apr/13 ] |
|
Marking as improvement |
| Comment by Sergey Gerdel [ 07/Apr/13 ] |
|
Minor? OK. Programmers may be mistaken in parser reality ORDER BY m0_.published DESC) dctrn_result LIMIT 20 OFFSET 0 |
| Comment by Marco Pivetta [ 07/Apr/13 ] |
|
Sergey Gerdel this problem does not introduce security issues and can be worked around by you while using your own pagination logic. It does not stop you from doing anything, that's why it's minor. |
| Comment by Sergey Gerdel [ 08/Apr/13 ] |
|
ok) |
[DDC-2119] Problem with inheritance type: INHERITANCE_TYPE_NONE and INHERITANCE_TYPE_TABLE_PER_CLASS Created: 03/Nov/12 Updated: 08/Apr/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | DQL, Tools |
| Affects Version/s: | 2.1 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | SergSW | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | dql, schematool | ||
| Attachments: |
|
| Description |
|
I tried to create inheritance entities with save policy table per class. I had found a solution. In Doctrine\ORM\Tools\SchemaTool private function _gatherRelationsSql($class, $table, $schema) { foreach ($class->associationMappings as $fieldName => $mapping) { // if (isset($mapping['inherited'])) { // - old version /** * SSW * It's the solution */ if (isset($mapping['inherited']) && !$class->isInheritanceTypeNone() && !$class->isInheritanceTypeTablePerClass() ) { continue; } $foreignClass = $this->_em->getClassMetadata($mapping['targetEntity']); ... But it was enough. In DQL query a simple query was made wrong. I had found a solution again. public function walkSelectExpression($selectExpression) ... // original => if (isset($mapping['inherited'])){ // It's the solution if (isset($mapping['inherited']) && !$class->isInheritanceTypeNone() && !$class->isInheritanceTypeTablePerClass()) { $tableName = $this->_em->getClassMetadata($mapping['inherited'])->table['name']; } else { $tableName = $class->table['name']; } ... This problems are topical for inheritance type: INHERITANCE_TYPE_NONE and INHERITANCE_TYPE_TABLE_PER_CLASS. I don't know, may be my solutions are wrong. But some programmers want to correctly work with INHERITANCE_TYPE_TABLE_PER_CLASS. Sorry for my english. |
| Comments |
| Comment by Fabio B. Silva [ 05/Nov/12 ] |
|
Hi SergSW Could you try to write a failing test case ? Thanks |
| Comment by SergSW [ 06/Nov/12 ] |
|
SSW/TestBundle with the problem |
| Comment by SergSW [ 07/Nov/12 ] |
|
I install the Symfony v2.0.18. and made small TestBundle. |
| Comment by SergSW [ 07/Nov/12 ] |
|
MySQL dump |
| Comment by Benjamin Eberlei [ 12/Nov/12 ] |
|
Adjusted example formatting, don't apologize for your English, thanks for the report! |
| Comment by Benjamin Eberlei [ 24/Dec/12 ] |
|
What version of 2.1 are you using? We don't actually support 2.1 anymore. Inheritance has always worked as used in hundrets of unit-tests, this changes look quite major a bug to have been missed before. I can't really explain whats happening here. |
| Comment by Marco Pivetta [ 23/Jan/13 ] |
|
SergSW news? |
[DDC-1605] No documentation about the usage of indexes with YAML and XML Created: 16/Jan/12 Updated: 08/Apr/13 |
|
| Status: | In Progress |
| Project: | Doctrine 2 - ORM |
| Component/s: | Documentation |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Documentation | Priority: | Major |
| Reporter: | Christian Stoller | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | documentation | ||
| Description |
|
I am missing documentation about how to handle indexes in YAML and XML definition files. I had to search in the code to learn how to do that. This issue is related to # EDIT:
User:
type: entity
fields:
id:
id: true
type: integer
generator:
strategy: IDENTITY
email:
type: string
length: 150
unique: true
active:
type: boolean
indexes:
indexActiveField: { name: idx_user_active, columns: [ active ] }
indexActiveField is the name of the index used by doctrine and idx_user_active is the name of the index in the database. The rest should be clear. |
| Comments |
| Comment by Christian Stoller [ 27/Sep/12 ] |
|
Hi. I got an email notification that arbuscula has changed the status to "Awaiting Feedback". Do you need any feedback from me? |
[DDC-2390] Remove Parser and SQLWalker dependency on Query Created: 04/Apr/13 Updated: 04/Apr/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 2.4 |
| Security Level: | All |
| Type: | Improvement | Priority: | Major |
| Reporter: | Benjamin Eberlei | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
Query is too powerful to be available in Parser and SQLWalker, because it may lead to accessing data that changes on subsequent runs of a query that is cached. Idea is to introduce a MetadataBag that contains only the values that are allowed to be accessed. |
[DDC-2237] oracle IN statement with more than 1000 values Created: 11/Jan/13 Updated: 02/Apr/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | 2.2.2 |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Critical |
| Reporter: | Marc Drolet | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
If I have a query with a IN statement with more tahn 1000 values I get an sql error. I've try IN with implode: |
| Comments |
| Comment by Marc Drolet [ 11/Jan/13 ] |
|
Here is the way I've implement the solution on my side: (for oracle) into Doctrine/DBAL/Statement.php, I've add this method:
/**
* Binds a parameter value to the statement.
* This is implemented this way for oracle only. Other drivers are redirected to bindValue method.
*
* The value will be bound with to the type provided (that required to be a table type).
*
* @param String $name The name or position of the parameter.
* @param Array $value The value of the parameter.
* @param String $type The name of the type to use to bind.
* @return boolean TRUE on success, FALSE on failure.
*/
public function bindList($name, Array $value, $type)
{
if ('oracle' !== $this->platform->getName())
{
$this->bindValue($name, $value, $type);
}
else
{
return $this->stmt->bindList($name, $value, $type);
}
}
into Doctrine/DBAL/Driver/Statement.php I've add:
/**
* @TODO: docs
*/
function bindList($param, Array $values, $type);
into Doctrine/DBAL/Driver/OCI8/OCI8Statement.php I've add this method:
/**
* {@inheritdoc}
*/
public function bindList($param, Array $value, $type)
{
if (!($list = oci_new_collection($this->_dbh, $type)))
{
//throw new OCI8Exception::fromErrorInfo($this->errorInfo());
}
foreach ($value as $entry)
{
$list->append($entry);
}
if (!oci_bind_by_name($this->_sth, $param, $list, -1, OCI_B_NTY))
{
//throw new OCI8Exception::fromErrorInfo($this->errorInfo());
}
}
// NOTE: we should probably add the bindList to all driver Statement object. into your code you can use it this way:
$sql = "
SELECT *
FROM test
WHERE id IN
(
SELECT *
FROM
(
CAST (: p_ids AS list_int_type)
)
)
";
$stmt = connection->prepare($sql);
$stmt->bindList(': p_ids', $ids, 'list_int_type');
$stmt->execute();
$rs = $stmt->fetchAll(PDO::FETCH_ASSOC);
NOTE: create or replace type list_str_type as table of varchar2(4000); |
| Comment by Benjamin Eberlei [ 01/Apr/13 ] |
|
Hey Marc Drolet thanks for the feedback and the solution, however i would like to have something generic that is working independent of the database driver. This code is very specific. Can you point me to some documentation why oci collection works with more than 1000 elements and how it works in PHP? |
| Comment by Marc Drolet [ 02/Apr/13 ] |
|
Hi Benjamin, The limitation is not from the oci driver, it's an oracle limitation. There are a couple of possible solution/implementation that can be done but the one I've provide is the one that perform better for the test I've done and from what I can found over the blogs I've read. I can't find the exact documentation of oracle. oracle doc is so poor. I don't know if there is similar limitation with other database. With the implementation I've provided, It will be possible to implement the proper solution depending on the database limitation you face otherwise it will execute the generic IN. What's bad, we need to create the type into the database. NOTE: In my case, I can not perform a sub-query, I get the my collection from a web service call. |
[DDC-2385] [GH-640] [Paginator]Add hidden field ordering for postgresql Created: 02/Apr/13 Updated: 02/Apr/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Benjamin Eberlei | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of denkiryokuhatsuden: Url: https://github.com/doctrine/doctrine2/pull/640 Message: In postgresql environment, when some hidden fields are used in orderBy clause, This change fixes above. I'm afraid I'm not sure which branch this will be merged, but anyway here's a patch. |
[DDC-2203] add EntityManager->getFilters()->isEnabled('filterName'') Created: 17/Dec/12 Updated: 01/Apr/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | Git Master |
| Fix Version/s: | 2.4 |
| Security Level: | All |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Enea Bette | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Comments |
| Comment by Paweł Nowak [ 10/Jan/13 ] |
|
My pull request (https://github.com/doctrine/doctrine2/pull/548) contains an implementation of the method. Note that no exception is thrown if you query for the state of a non-existing filter - in such a case, false is returned as for disabled filters. |
[DDC-1149] Optimize OneToMany and ManyToMany without join Created: 12/May/11 Updated: 30/Mar/13 |
|
| Status: | In Progress |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | Git Master |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | New Feature | Priority: | Major |
| Reporter: | Andrey Kolyshkin | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 5 |
| Labels: | None | ||
| Attachments: |
|
| Description |
/** * @Entity * @Table(name="users") */ class User { /** * @Column * @Id */ public $user_id; /** * @Column */ public $email; /** * @OneToMany(targetEntity="Language", mappedBy="user",fetch="EAGER") */ public $languages; } /** * @Entity * @Table(name="user_languages") */ class Language { /** * @Column * @Id */ public $user_language_id; /** * @ManyToOne(targetEntity="User", inversedBy="languages") * @JoinColumn(name="user_id", referencedColumnName="user_id") */ public $user; /** * @Column */ public $user_id; } $users = $em->getRepository('User')->findAll();
Result: SELECT t0.user_id AS user_id1, t0.email AS email2 FROM users t0
SELECT t0.user_language_id AS user_language_id1, t0.user_id AS user_id2, t0.user_id AS user_id3 FROM user_languages t0 WHERE t0.user_id = ?
array(1) {
[0]=>
string(1) "1"
}
array(1) {
[0]=>
NULL
}
SELECT t0.user_language_id AS user_language_id1, t0.user_id AS user_id2, t0.user_id AS user_id3 FROM user_languages t0 WHERE t0.user_id = ?
array(1) {
[0]=>
string(1) "2"
}
array(1) {
[0]=>
NULL
}
SELECT t0.user_language_id AS user_language_id1, t0.user_id AS user_id2, t0.user_id AS user_id3 FROM user_languages t0 WHERE t0.user_id = ?
array(1) {
[0]=>
string(1) "3"
}
array(1) {
[0]=>
NULL
}
...
Need result: SELECT t0.user_id AS user_id1, t0.email AS email2 FROM users t0 SELECT u0_.user_language_id AS user_language_id0, u0_.user_id AS user_id1, u0_.user_id AS user_id2 FROM user_languages u0_ WHERE u0_.user_id IN (1, 2, 3) |
| Comments |
| Comment by Benjamin Eberlei [ 12/May/11 ] |
|
Sure you are on git master? this should be optimized already with fetch=EAGER |
| Comment by Andrey Kolyshkin [ 12/May/11 ] |
|
Attach test file I run git clone git://github.com/doctrine/doctrine2.git git clone git://github.com/doctrine/common.git git clone git://github.com/doctrine/dbal.git and run testDoctrine.php Result
SELECT t0.user_id AS user_id1 FROM users t0
SELECT t0.post_id AS post_id1, t0.user_id AS user_id2 FROM posts t0 WHERE t0.user_id = ?
array(1) {
[0]=>
string(1) "1"
}
array(1) {
[0]=>
NULL
}
SELECT t0.post_id AS post_id1, t0.user_id AS user_id2 FROM posts t0 WHERE t0.user_id = ?
array(1) {
[0]=>
string(1) "2"
}
array(1) {
[0]=>
NULL
}
SELECT t0.post_id AS post_id1, t0.user_id AS user_id2 FROM posts t0 WHERE t0.user_id = ?
array(1) {
[0]=>
string(1) "3"
}
array(1) {
[0]=>
NULL
}
|
| Comment by Guilherme Blanco [ 10/Oct/11 ] |
|
Please instead of using fetch="EAGER", please use fetch="EXTRA_LAZY". It would fix your issue. |
| Comment by Vladimir [ 25/Mar/13 ] |
|
Doctrine ORM 2.3.3 (Symfony2.2) - using LAZY or EXTRA_LAZY fetch mode there are only one query for: $users = $em->getRepository('User')->findAll();
but additional users_count queries for foreach($users as $user) $user->languages->toArray() And if use fetch EAGER - for some reason there are 2 x users_count queries , ie each query SELECT t0.post_id AS post_id1, t0.user_id AS user_id2 FROM posts t0 WHERE t0.user_id = ? with unique user_id executed twice |
[DDC-2217] Return a lazy collection from PersistentCollection::match($criteria) Created: 31/Dec/12 Updated: 28/Mar/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Improvement | Priority: | Major |
| Reporter: | Christophe Coevoet | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 4 |
| Labels: | None | ||
| Description |
|
In 2.3, PersistentCollection::match() has been implemented by doing the query directly. But sometimes, the only meaningful information about the matched collection would be its length. In this case, it would be great to handle it in the same way than extra lazy collections are handled: the matched collection would be initialized lazily, and could do the count in an extra lazy way (if the original collection was extra lazy). |
[DDC-2210] PHP warning in ProxyFactory when renaming proxy file Created: 20/Dec/12 Updated: 28/Mar/13 |
|
| Status: | Reopened |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major |
| Reporter: | Matthieu Napoli | Assignee: | Marco Pivetta |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Windows |
||
| Description |
|
Getting a PHP Warning: rename(**/models/Proxies_CGAF_Model_Component_Group.php.50d2dd2c079bb9.35271255,**/models/Proxies__CG_AF_Model_Component_Group.php): in ProxyFactory line 194. I haven't more information in the warning. This is the moment when the ProxyFactory writes the proxy to a temporary file and then tries to rename the temp file to the correct file. This warning appears randomly, but mostly on pages with lots of concurrent AJAX requests. I guess this happens because several requests try to write the proxy file at the same time. I get this warning but the app works fine. This happens in dev environment, on a Windows machine. I don't know why rename generates a warning, it should just return false... The doc doesn't say anything about warnings (except for long file names, but I checked even with the full path this is around 135 characters, not 255). |
| Comments |
| Comment by Benjamin Eberlei [ 22/Dec/12 ] |
|
Thats why you shouldn't generate proxies at runtime. The problem happens on windows, because the atomic rename operation doesn't work as perfectly there as on linux. We cannot fix this in Doctrine. |
| Comment by Matthieu Napoli [ 24/Dec/12 ] |
|
Benjamin Eberlei What do you mean "you shouldn't generate proxies at runtime"? I'm not in production, this is in dev. And I'm using the default configuration. What I don't understand is why will Doctrine regenerate proxies on every request? The warning is reproductible, and even when no PHP entity has been touched. |
| Comment by Matthieu Napoli [ 27/Dec/12 ] |
|
Benjamin Eberlei To simplify my previous message (I don't want to bury you under questions) I'll sum it up like that: What can I do? Thanks! |
| Comment by Matthieu Napoli [ 28/Feb/13 ] |
|
Benjamin Eberlei ping: what can be done? Can we suppress the error with @rename($tmpFileName, $fileName); ? https://github.com/doctrine/common/blob/master/lib/Doctrine/Common/Proxy/ProxyGenerator.php#L287 I can make a PR if you think that's a valid solution. |
| Comment by Marco Pivetta [ 28/Feb/13 ] |
|
Matthieu Napoli no, if you have warnings, please disable them via ini setting. With error suppression there, we may have further problems identifying more serious issues. About proxy generation: that happens EVERY time in dev environments. Generate them once and disable it afterwards. |
| Comment by Matthieu Napoli [ 28/Feb/13 ] |
|
Marco Pivetta OK I can disable the auto generation then (I'll have to remember to regenerate them when I edit the model). Thanks for the feedback Is that possible to make those proxies generate only if the entity file has been modified since the last generation? (only asking if can and should be done, I can look for implementing it myself if that's the case) |
| Comment by Marco Pivetta [ 28/Feb/13 ] |
|
Matthieu Napoli that would be very obnoxious when changing entities often. I wouldn't do that (generating only if not already available) |
| Comment by Matthieu Napoli [ 28/Feb/13 ] |
|
Marco Pivetta Yes but for now they are regenerated at every request when in dev mode (at least with the default configuration http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/configuration.html#obtaining-an-entitymanager) Which one is worse: generating every proxy class at every request, or generate only those which changed (in dev environment of course, not prod)? If neither of these options are good (i.e. auto generation should be disabled), I don't understand why the docs say to enable auto generation when in dev environment. |
| Comment by Marco Pivetta [ 28/Feb/13 ] |
|
Matthieu Napoli that's because in dev environments you shouldn't care about that one exception (usually happens when you got concurrent requests). It is worse to generate only on changes: that's a lot of additional checks, variables to keep in memory and additional logic that is not needed. Let's keep it as it is (generating at each request) for dev environments: works fine Another (eventual) solution for dev environments would be not to write the proxy file, but to eval it. |
| Comment by Matthieu Napoli [ 28/Feb/13 ] |
|
eval it would be a good solution IMO, no more "woops the directory is not writable" and it's more neutral for the user filesystem (but not as easy to debug). But OK, I see what you mean, it works let's keep it that way. Actually the problem on my setup is that PHP errors are turned into exceptions, so on an (poorly designed) AJAX treeview (lots of nodes to load => lots of requests), I end up with some nodes not loaded because of the exception. And it feels weird to either silently log all PHP warnings or silently ignore the specific warning for the rename. |
| Comment by Marco Pivetta [ 28/Feb/13 ] |
|
Matthieu Napoli I'd go with `eval` then. Needs refactoring of the abstract proxy factory and of the proxy generator (proxy generator should no longer write files). |
| Comment by Marco Pivetta [ 28/Feb/13 ] |
|
Re-opening: the proxy factory could directly `eval()` the produced proxy code. The ProxyGenerator should no longer write the generated files to disk automatically. |
| Comment by Matthieu Napoli [ 28/Mar/13 ] |
|
I've opened a PR: https://github.com/doctrine/common/pull/269 |
[DDC-2372] [GH-632] entity generator - ignore trait properties and methods Created: 26/Mar/13 Updated: 26/Mar/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Benjamin Eberlei | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of Padam87: Url: https://github.com/doctrine/doctrine2/pull/632 Message: Fixes: |
[DDC-2364] [GH-625] [DDC-2363] Duplicated record with orphanRemoval and proxy Created: 22/Mar/13 Updated: 22/Mar/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Benjamin Eberlei | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of mmenozzi: Url: https://github.com/doctrine/doctrine2/pull/625 Message: See http://www.doctrine-project.org/jira/browse/DDC-2363. |
[DDC-2363] Duplicated record with orphanRemoval and proxy Created: 22/Mar/13 Updated: 22/Mar/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | 2.3.2 |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Manuele Menozzi | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | orphanRemoval, proxy | ||
| Environment: |
Tested both Mac OS X and Ubuntu |
||
| Description |
|
There is a problem that causes duplicate records are created when EntityManager has to remove an entity due to orphanRemoval. The problem occurs only with a double flush and referred object is a proxy. I'm trying to submit a pull request for this ticket. Please, stand by. |
[DDC-2354] [GH-617] Wrong UnitOfWork::computeChangeSet() Created: 16/Mar/13 Updated: 16/Mar/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Benjamin Eberlei | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of fchris82: Url: https://github.com/doctrine/doctrine2/pull/617 Message: Sometimes some fields are Proxy when compute "changeSet". If it is Proxy, some listeners - example Gedmo sortable listener - belive the value has changed and this leads to chaos. I check the $actualValue, if it is Proxy, the value didn't change. |
[DDC-2352] [GH-615] Update SqlWalker.php Created: 15/Mar/13 Updated: 15/Mar/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Benjamin Eberlei | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of mikemeier: Url: https://github.com/doctrine/doctrine2/pull/615 Message: Always be sure that only a-z characters are used for table alias, otherwise use generic "t" for "table" |
[DDC-2351] Entity Listener vs. Event Listener Created: 15/Mar/13 Updated: 15/Mar/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | Git Master |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Improvement | Priority: | Major |
| Reporter: | Fabian Spillner | Assignee: | Fabio B. Silva |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
Entity Listener and Event Listener don't get same events. An example is the onFlush event, which Entity Listener doesn't get. Why are both listeners receiving different events and not same events? For consistency I'd like to see that both get same events - if I understand the purpose of Entity Listener correctly: it should be an alternative to Event Listener with same functionality but is bound to an entity. |
| Comments |
| Comment by Benjamin Eberlei [ 15/Mar/13 ] |
|
onFlush and postFlush should be propagated to entity listeners as well |
[DDC-2295] [GH-580] Second cache level POC Created: 14/Feb/13 Updated: 14/Mar/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | New Feature | Priority: | Major |
| Reporter: | Benjamin Eberlei | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of FabioBatSilva: Url: https://github.com/doctrine/doctrine2/pull/580 Message: Hi guys. After a look into some implementations I end up with the following solution for the second level cache.. There is lot of work todo before merge it, but i'd like to get your thoughts before i go any further on this approach.
Collection Caching The most common use case is to cache entities. But we can also cache relationships. Only identifiers will be cached for collection. When a collection is read from the second level cache it will create proxies based on the cached identifiers, if the application needs to access an element, Doctrine will go to the cache to load the element data.
*********************************************************************************************
*********************************************************************************************
*********************************************************************************************
```php <?php /** * @Entity * @Cache("NONSTRICT_READ_WRITE") */ class State { /** * @Id * @GeneratedValue * @Column(type="integer") */ protected $id; /** * @Column */ protected $name; /** * @Cache() * @ManyToOne(targetEntity="Country") * @JoinColumn(name="country_id", referencedColumnName="id") */ protected $country; /** * @Cache() * @OneToMany(targetEntity="City", mappedBy="state") */ protected $cities; } ``` ```php <?php $em->persist(new State($name, $country)); $em->flush(); // Put into cache $em->clear(); // Clear entity manager $state = $em->find('Entity\State', 1); // Retreive item from cache $country = $state->getCountry(); // Retreive item from cache $cities = $state->getCities(); // Load from database and put into cache $state->setName("New Name"); $em->persist($state); $em->flush(); // Update item cache $em->clear(); // Clear entity manager $em->find('Entity\State', 1)->getCities(); // Retreive from cache $em->getCache()->containsEntity('Entity\State', $state->getId()) // Check if the cache exists $em->getCache()->evictEntity('Entity\State', $state->getId()); // Remove an entity from cache $em->getCache()->evictEntityRegion('Entity\State'); // Remove all entities from cache $em->getCache()->containsCollection('Entity\State', 'cities', $state->getId()); // Check if the cache exists $em->getCache()->evictCollection('Entity\State', 'cities', $state->getId()); // Remove an entity collection from cache $em->getCache()->evictCollectionRegion('Entity\State', 'cities'); // Remove all collections from cache ```
|
[DDC-2347] Refresh Uniqueidentifier ID from mssql of inserted Entity in doctrine2.3 Created: 13/Mar/13 Updated: 13/Mar/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | 2.3.2 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor |
| Reporter: | Lucas Senn | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | dql | ||
| Environment: |
Windows Server 2008 R2, Apache 2.2, Doctrine 2.3, PHP 5.4 |
||
| Description |
|
I don't want you to report something that isn't a bug. If it isn't a bug I'm very sorry for this issue report. Issue as reported in |
[DDC-2338] Entity with composite foreign keys identifiers should be persisted after related entities without exception Created: 07/Mar/13 Updated: 07/Mar/13 |
|
| 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: | Alessandro Tagliapietra | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | orm, unitofwork | ||
| Environment: |
Mac OSX 10.8, php 5.4.11, doctrine git master version |
||
| Description |
|
I've seen that when you create an entity with a composite foreign key as identifier it cannot be flushed until the related entities are already flushed to the database and not just persisted. It would be nice to let the user flush all the entities together and just INSERT first the related entities to get the ID and then use that to INSERT the entity with composite foreign keys. I'm going to create a pull request with the failing test. |
| Comments |
| Comment by Alessandro Tagliapietra [ 07/Mar/13 ] |
|
Created pull request https://github.com/doctrine/doctrine2/pull/605 |
[DDC-2337] Allow an entity to use its own persister to take advantage of DB level features if necessary Created: 06/Mar/13 Updated: 06/Mar/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | Mapping Drivers, ORM |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | New Feature | Priority: | Major |
| Reporter: | Nathanael Noblet | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Attachments: |
|
| Description |
|
I have a situation where I wanted a single table to use INSERT DELAYED. Its an audit log table where I expect each http request to generate many inserts for. In an effort to not over tax the system I implemented a custom Entity Persister so that it would work. This obviously doesn't work with all mapping drivers. However if this is a feature that you think is worth integrating I will fork it on github and complete the implementation alongside any changes/improvements requested... |
[DDC-1180] Indexed Associations: foreign key (association) cannot be used as indexBy field Created: 29/May/11 Updated: 02/Mar/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | Mapping Drivers |
| Affects Version/s: | 2.1 |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Improvement | Priority: | Major |
| Reporter: | Petr Sobotka | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 3 |
| Labels: | None | ||
| Environment: |
Using Doctrine ORM 2.1.0BETA1 |
||
| Description |
|
I am trying to index a collection by its entity's column which is also a foreign key (association). It seems to me that it is not possible at the moment. For example: /**
* @Entity
*/
class Hotel
{
// $id column and other stuff
/**
* @oneToMany(targetEntity="Booking", mappedBy="hotel", indexBy="room")
* @var Booking[]
*/
private $bookings;
}
/**
* @Entity
*/
class Booking
{
/**
* @var Hotel
*
* @Id
* @ManyToOne(targetEntity="Hotel", inversedBy="bookings")
* @JoinColumns({
* @JoinColumn(name="hotel_id", referencedColumnName="id")
* })
*/
private $hotel;
/**
* @var Room
*
* @Id
* @ManyToOne(targetEntity="Room")
* @JoinColumns({
* @JoinColumn(name="room_id", referencedColumnName="id")
* })
*/
private $room;
}
Only possible workaround I found is to define another (plain) entity's property mapped to the same table column and index by it: /**
* @Entity
*/
class Hotel
{
// $id column and other stuff
/**
* @oneToMany(targetEntity="Booking", mappedBy="hotel", indexBy="roomId")
* @var Booking[]
*/
private $bookings;
}
/**
* @Entity
*/
class Booking
{
// ...
/**
* @var Room
*
* @Id
* @ManyToOne(targetEntity="Room")
* @JoinColumns({
* @JoinColumn(name="room_id", referencedColumnName="id")
* })
*/
private $room;
/**
* @var integer $roomId
*
* @Column(name="room_id", type="integer", nullable=false)
*/
private $roomId;
}
Wouldn't it be easy to support it? |
| Comments |
| Comment by Benjamin Eberlei [ 05/Jun/11 ] |
|
It is not so easy to implement from the first gimplse and it is not a bug but an improvement/feature request. |
| Comment by Benjamin Morel [ 02/Mar/13 ] |
|
Related PR: https://github.com/doctrine/doctrine2/pull/204 |
[DDC-2321] DbDeploy Support Created: 27/Feb/13 Updated: 27/Feb/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | New Feature | Priority: | Major |
| Reporter: | Benjamin Eberlei | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
[DDC-2283] Paginator with orderBy in joined data retrieve bad result Created: 07/Feb/13 Updated: 26/Feb/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | 2.3.2 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Jean-Philippe THEVENOUX | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | paginator | ||
| Description |
|
entity A have many entity B If DQL is something like "select A, B from A join B order by A.field1, B.field2" so, if a entity A have 20 entity B (and these sub-entity have all a different b.field2) then there's only 1 A retrieved |
[DDC-2287] Getter/Setter: generate "isEnabled()" instead of "getEnabled()" for boolean field in entity classes Created: 08/Feb/13 Updated: 26/Feb/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Sukhrob Khakimov | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
It would be better if doctrine generated "isEnabled()" instead of "getEnabled()" for boolean field in entity classes. Because, it is more meaningful. |
| Comments |
| Comment by Marco Pivetta [ 08/Feb/13 ] |
|
Not sure this kind of check should be handled. Starting to add all this kind of rules makes me think that it is becoming a big ball of mud |
[DDC-2314] getResults with numeric indexes for fields Created: 22/Feb/13 Updated: 26/Feb/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Ninj | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
When executing a simple query with field names in SELECT clause, it is not possible to map field to numeric indexes. This is an example that i would imagine to be useful: SELECT c.id AS 0, c.name AS 1, l.text AS 2 FROM Category c LEFT JOIN c.label l Thus, the resulting results could be numeric indexed array. It is useful for many situations: when working with an API which expects such arrays, or when using list to assign result fields to variables directly. Query::HYDRATE_SCALAR does not achieve this, as one could think at first glance. |
[DDC-2308] Naming Strategy for Reverse Engeneering Created: 21/Feb/13 Updated: 21/Feb/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | Mapping Drivers |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Andreas Prucha | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
Unfortunately DatabaseDriver::getClassNameForTable() is declared as private method, which makes it quite difficult to change the naming strategy for reverse engeneering. IMO this sould be declared protected. An even better way would be to extend the interface of the Naming Strategy objects to support the reverse direction: classToTableName -> tableToClassName This way we would have a consistent name-mapping |
[DDC-2305] [GH-584] QueryBuilder::addCriteria improvements Created: 19/Feb/13 Updated: 19/Feb/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Benjamin Eberlei | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of chEbba: Url: https://github.com/doctrine/doctrine2/pull/584 Message: 1. Fix problem with different comparisons on the same field in QueryExpressonVisitor (now index value is added). |
| Comments |
| Comment by Benjamin Eberlei [ 19/Feb/13 ] |
|
A related Github Pull-Request [GH-584] was opened |
[DDC-2301] Support inheritance in ResultSetMappingBuilder Created: 16/Feb/13 Updated: 16/Feb/13 |
|
| 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: | Ross Masters | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | nativesql, resultsetmapping | ||
| Description |
|
ResultSetMappingBuilder does not support inherited fields. For example, calling ResultSetMappingBuilder::addRootEntityFromClassMetadata($class, $alias) throws an exception to say this. I was wondering if there were any reasons as to why this would be difficult to implement? I haven't had an extensive look at Doctrine's source but it feels like this has been not implemented on purpose. Thanks |
[DDC-585] Create a coding standards document Created: 13/May/10 Updated: 11/Feb/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 2.0 |
| Security Level: | All |
| Type: | Task | Priority: | Major |
| Reporter: | Roman S. Borschel | Assignee: | Jonathan H. Wage |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
We need a new coding standards document for Doctrine 2. |
| Comments |
| Comment by Benjamin Morel [ 29/Jan/13 ] |
|
Has there been any work on a coding standards document yet? |
| Comment by Marco Pivetta [ 29/Jan/13 ] |
|
Benjamin Morel Guilherme Blanco may have a CS ruleset, but it's not ready yet. Perfect timing btw, we really need to automate this to avoid having all these useless CS fix comments in pull requests |
| Comment by Benjamin Morel [ 29/Jan/13 ] |
|
Ok, I'll post my document here once ready, and Guilherme Blanco will be able to compare it with his ruleset! |
| Comment by Benjamin Morel [ 30/Jan/13 ] |
|
Here is a first draft: https://gist.github.com/4676670 Please comment! |
| Comment by Benjamin Morel [ 11/Feb/13 ] |
|
Guilherme Blanco, if you don't have time to compare your ruleset with my draft, maybe you could publish your current ruleset so that others can have a look? |
[DDC-2236] SUM(..) with Pagination gives incorrect result Created: 11/Jan/13 Updated: 10/Feb/13 |
|
| Status: | In Progress |
| Project: | Doctrine 2 - ORM |
| Component/s: | Tools |
| Affects Version/s: | 2.2.3 |
| Fix Version/s: | None |
| Type: | Documentation | Priority: | Minor |
| Reporter: | Oleg | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | paginator | ||
| Environment: |
Linux |
||
| Description |
|
https://github.com/whiteoctober/Pagerfanta/issues/69 <?php $pager = new Pagerfanta(new DoctrineORMAdapter($query)); $result = $pager->getCurrentPageResults(); $result = $query->getQuery()->getResult(); Sql for the above: SELECT DISTINCT id0 FROM (SELECT q0_.id AS id0, SUM(q0_.price) AS sclr36 FROM Q q0_ WHERE q0_.id IN (19, 20, 22) GROUP BY q0_.customer_id) dctrn_result LIMIT 30 OFFSET 0 Sql with fetchJoin = false (new DoctrineORMAdapter($query, false)) SELECT q0_.id AS id0, SUM(q0_.price) AS sclr36 FROM Quote q0_ WHERE q0_.id IN (19, 20, 22) GROUP BY q0_.customer_id LIMIT 30 OFFSET 0 |
| Comments |
| Comment by Alexander [ 09/Feb/13 ] |
|
Can you also test this with doctrine >= 2.3? The pagination code changed quite a lot. |
| Comment by Oleg [ 10/Feb/13 ] |
|
Looks like no change composer.json:
then cleared cache but result is same
$query = $this->getDoctrine()->getEntityManager()->getRepository('MyBundle:Invoice')
->createQueryBuilder('q')
->select('q', 'SUM(q.amount) AS amount')
->groupBy('q.customer')
;
95 Connect root@localhost on ** 95 Query SELECT DISTINCT id0 FROM (SELECT i0_.id AS id0, i0_.invoice_num AS invoice_num1, i0_.date AS date2, i0_.amount AS amount3, i0_.vat_amount AS vat_amount4, i0_.amount_paid AS amount_paid5, i0_.md5 AS md56, i0_.is_exported AS is_exported7, i0_.created AS created8, SUM(i0_.amount) AS sclr9 FROM Invoice i0_ GROUP BY i0_.customer_id) dctrn_result LIMIT 30 OFFSET 0 95 Query SELECT i0_.id AS id0, i0_.invoice_num AS invoice_num1, i0_.date AS date2, i0_.amount AS amount3, i0_.vat_amount AS vat_amount4, i0_.amount_paid AS amount_paid5, i0_.md5 AS md56, i0_.is_exported AS is_exported7, i0_.created AS created8, SUM(i0_.amount) AS sclr9, i0_.customer_id AS customer_id10 FROM Invoice i0_ WHERE i0_.id IN ('2') GROUP BY i0_.customer_id 95 Query SELECT i0_.id AS id0, i0_.invoice_num AS invoice_num1, i0_.date AS date2, i0_.amount AS amount3, i0_.vat_amount AS vat_amount4, i0_.amount_paid AS amount_paid5, i0_.md5 AS md56, i0_.is_exported AS is_exported7, i0_.created AS created8, SUM(i0_.amount) AS sclr9, i0_.customer_id AS customer_id10 FROM Invoice i0_ GROUP BY i0_.customer_id 130210 16:08:25 95 Quit But I understand why that happens, it's due to group by and pagination nature. If I do $pager = new Pagerfanta(new DoctrineORMAdapter($query, false)); I get this sql SELECT i0_.id AS id0, i0_.invoice_num AS invoice_num1, i0_.date AS date2, i0_.amount AS amount3, i0_.vat_amount AS vat_amount4, i0_.amount_paid AS amount_paid5, i0_.md5 AS md56, i0_.is_exported AS is_exported7, i0_.created AS created8, SUM(i0_.amount) AS sclr9, i0_.customer_id AS customer_id10 FROM Invoice i0_ LIMIT 30 OFFSET 0 I think it should be noted somewhere that if you do groupBy you should set fetchJoin to false? |
| Comment by Marco Pivetta [ 10/Feb/13 ] |
|
Updating to Documentation issue. |
[DDC-1825] generate entities with traits Created: 18/May/12 Updated: 09/Feb/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | 2.2.2 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Matthias Breddin | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | None | ||
| Environment: |
php 5.4.3, symfony2.1-dev |
||
| Description |
|
When a trait with included setters and getters is used and generate entities is called, doctrine add another set of getters and setters to the "main" entity where the trait is used. |
[DDC-1630] Get PersistentCollection::getDeleteDiff is empty when collection changes from 1 item to zero items Created: 31/Jan/12 Updated: 09/Feb/13 |
|
| Status: | Awaiting Feedback |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Minor |
| Reporter: | Lee | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 2 |
| Labels: | None | ||
| Environment: |
Symfony2 |
||
| Attachments: |
|
| Comments |
| Comment by Steve Müller [ 09/Feb/12 ] |
|
Same problem here. I wanted to write some unit tests, checking the entity relations and ran into exactly the same problem. Maybe my code can provide some more information (Group entity is the owning side, role entity is the inverse side): WHAT DOES NOT WORK: /**
* Test ArrayCollection
*/
$group = new Group('Group Test');
$em->persist($group);
$em->flush();
$groups = new ArrayCollection();
$groups->add($group);
$this->role->setGroups($groups);
$this->assertEquals($groups, $this->role->getGroups());
/**
* Test PersistentCollection
*/
$em->persist($this->role);
$em->flush();
$groups = $this->role->getGroups();
$groups->removeElement($group); // first remove element before adding a new one
$group = new Group('Group Test 2');
$em->persist($group);
$em->flush();
$groups->add($group);
$this->role->setGroups($groups);
$this->assertEquals($groups, $this->role->getGroups());
WHAT WORKS: /**
* Test ArrayCollection
*/
$group = new Group('Group Test');
$em->persist($group);
$em->flush();
$groups = new ArrayCollection();
$groups->add($group);
$this->role->setGroups($groups);
$this->assertEquals($groups, $this->role->getGroups());
/**
* Test PersistentCollection
*/
$em->persist($this->role);
$em->flush();
$groups = $this->role->getGroups();
$group2 = new Group('Group Test 2');
$em->persist($group2);
$em->flush();
$groups->add($group2); // first adding a new element before removing one
$groups->removeElement($group);
$this->role->setGroups($groups);
$this->assertEquals($groups, $this->role->getGroups());
Hope this helps in any way... I tried figuring it out on my own but I am too drunk right now xD |
| Comment by Benjamin Eberlei [ 10/Feb/12 ] |
|
Thanks for the report, formatted it |
| Comment by Benjamin Eberlei [ 10/Feb/12 ] |
|
Which version is that btw? |
| Comment by Steve Müller [ 16/Feb/12 ] |
|
Occurs in version 2.1.6 |
| Comment by Benjamin Eberlei [ 20/Feb/12 ] |
|
If group is the owning side, why do you only set Role::$groups? This has to be the other way around or not? |
| Comment by Benjamin Eberlei [ 20/Feb/12 ] |
|
@Steve I cannot reproduce your issue. Attached is a test script. Your code is very weird btw, why are you getting and setting groups collection? It is passed by reference so you can just have something like $role->addGroup() and $role->removeGroup() and encapsulate the logic? Also your tests are pretty useless, you check if two variables which are the same reference to the same collection are the same. Which should always be true. @Lee Can you provide more details? I cant verify this without more details. |
| Comment by Alexander [ 09/Feb/13 ] |
|
Can anyone provide us with more feedback? |
[DDC-1494] Query results are overwritten by previous query. Created: 15/Nov/11 Updated: 09/Feb/13 |
|
| Status: | Awaiting Feedback |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | 2.1.2 |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Minor |
| Reporter: | J | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
PHP 5.3 + MySQL 5.5 |
||
| Attachments: |
|
| Description |
|
I am running a query that JOINs three tables, with a simple WHERE: $q = $em->createQuery("
SELECT cat, n, c
FROM Project_Model_NoticeCategory cat
JOIN cat.notices n
JOIN n.chapters c
WHERE
c.id = :chapter_id
");
When I do this: $q->setParameter('chapter_id', 1);
$a = $q->getResult();
$q->setParameter('chapter_id', 2);
$b = $q->getResult();
$b always has the wrong results. Running the following code: $q->setParameter('chapter_id', 1);
$a = $q->getResult();
$q->setParameter('chapter_id', 2);
$b = $q->getResult();
$z = $q->getArrayResult();
BUG Results: $b != $z (getArrayResult IS CORRECT, it refreshes the results) Note: $a==$b (which is wrong) Explanation: There is a chapter table, this has a many-to-many join to notices (these are meta info Data model: /** * @Entity * @Table(name="chapter") */ class Project_Model_Chapter { /** * @Id @Column(type="integer") * @GeneratedValue(strategy="AUTO") */ private $id; /** @Column(type="string") */ private $title; /** * @ManyToMany(targetEntity="Project_Model_Notice", mappedBy="chapters") */ private $notices; .... /lots of code snipped/ .... } /** * @Entity * @Table(name="notice") */ class Project_Model_Notice { /** * @Id @Column(type="integer") * @GeneratedValue(strategy="AUTO") */ private $id; /** @Column(type="string") */ private $title; /** * @ManyToMany(targetEntity="Project_Model_Chapter", inversedBy="notices") * @JoinTable(name="chapter_notice") */ private $chapters; /** * @ManyToOne(targetEntity="Project_Model_NoticeCategory", inversedBy="notices") */ private $notice_category; .... /lots of code snipped/ .... } /** * @Entity * @Table(name="notice_category") */ class Project_Model_NoticeCategory { /** * @Id @Column(type="integer") * @GeneratedValue(strategy="AUTO") */ private $id; /** @Column(type="string") */ private $title; /** * Bidirectional - One-To-Many (INVERSE SIDE) * * @OneToMany(targetEntity="Project_Model_Notice", mappedBy="notice_category", cascade={"persist", "remove"}) */ private $notices; .... /lots of code snipped/ .... } Data fixtures: $tools = new \Project_Model_NoticeCategory; $tools->setTitle('Tools'); $spanner = new \Project_Model_Notice; $spanner->setTitle('spanner'); $tools->addNotice($spanner); $drill = new \Project_Model_Notice; $drill->setTitle('power drill'); $tools->addNotice($drill); $this->em->persist($tools); $this->em->flush(); $tools = new \Project_Model_NoticeCategory; $tools->setTitle('Safety'); $gloves = new \Project_Model_Notice; $gloves->setTitle('gloves'); $tools->addNotice($gloves); $goggles = new \Project_Model_Notice; $goggles->setTitle('goggles'); $tools->addNotice($goggles); $this->em->persist($tools); $this->em->flush(); $chapter1 = new \Project_Model_Chapter; $chapter1->setTitle('Chapter 1'); $this->em->persist($chapter1); $chapter2 = new \Project_Model_Chapter; $chapter2->setTitle('Chapter 2'); $this->em->persist($chapter2); $chapter1->addNotice($spanner); $chapter1->addNotice($gloves); $chapter2->addNotice($spanner); $chapter2->addNotice($gloves); $chapter2->addNotice($drill); $chapter2->addNotice($goggles); // now persist and flush everything Initial investigation: I think it has something to do with HINT_REFRESH ? Stepping through: ObjectHydrator->_hydrateRow when it requests the Project_Model_Category from the unit of work, it |
| Comments |
| Comment by Benjamin Eberlei [ 15/Nov/11 ] |
|
Fixed formatting |
| Comment by Benjamin Eberlei [ 18/Nov/11 ] |
|
are you using result caching? |
| Comment by J [ 21/Nov/11 ] |
|
This is part of my bootstrap $config = new \Doctrine\ORM\Configuration(); $cache = new \Doctrine\Common\Cache\ArrayCache; $config->setMetadataCacheImpl($cache); $config->setQueryCacheImpl($cache); // driver: schema $driver = $config->newDefaultAnnotationDriver( APPLICATION_PATH . '/models' ); $config->setMetadataDriverImpl($driver); |
| Comment by Benjamin Eberlei [ 15/Dec/11 ] |
|
Cannot reproduce it with the script attached. Can you try to modify this to fail or write your own testcase? |
| Comment by Benjamin Eberlei [ 15/Dec/11 ] |
|
Downgraded |
| Comment by Alexander [ 09/Feb/13 ] |
|
Please provide extra feedback. |
[DDC-2290] Infer custom Types from the field for query parameters Created: 08/Feb/13 Updated: 08/Feb/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Improvement | Priority: | Major |
| Reporter: | Matthieu Napoli | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | None | ||
| Description |
|
When using a mapping Type that declares convertToDatabaseValue, the method is not always called in queries. Example: SELECT ... WHERE entity.field = ?1 (with entity.field being of custom type 'the_mapping_type') Type::convertToDatabaseValue() is correctly called when using:
$query->setParameter('1', 'foo', 'the_mapping_type');
But it is not called when using:
$query->setParameter('1', 'foo');
which gives a query that returns invalid results. Like other mapping types in this situation, there is no reason the type is not inferred automatically from the field. I have written a failing test case in Doctrine\Tests\ORM\Functional\TypeValueSqlTest:
public function testQueryParameterWithoutType()
{
$entity = new CustomTypeUpperCase();
$entity->lowerCaseString = 'foo';
$this->_em->persist($entity);
$this->_em->flush();
$id = $entity->id;
$this->_em->clear();
$query = $this->_em->createQuery('SELECT c.id from Doctrine\Tests\Models\CustomType\CustomTypeUpperCase c where c.lowerCaseString = ?1');
$query->setParameter('1', 'foo');
$result = $query->getResult();
$this->assertCount(1, $result);
$this->assertEquals($id, $result[0]['id']);
}
|
| Comments |
| Comment by Matthieu Napoli [ 08/Feb/13 ] |
|
See also http://www.doctrine-project.org/jira/browse/DDC-2224 |
| Comment by Matthieu Napoli [ 08/Feb/13 ] |
|
The test is in this branch: https://github.com/myc-sense/doctrine2/tree/DDC-2290 |
[DDC-2288] Schema Tool doesn't update collation on table level Created: 08/Feb/13 Updated: 08/Feb/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | Mapping Drivers, Tools |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Rickard Andersson | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | collation, schematool | ||
| Description |
|
In Symfony2, when updating the collation option of a table, the schema tool doesn't recognize the change: Changing from: * @ORM\Table() To:
* @ORM\Table(options={"collate"="utf8_swedish_ci"})
Results in: $ php app/console doctrine:schema:update --dump-sql Nothing to update - your database is already in sync with the current entity metadata. |
[DDC-2286] Update documentation for collation Created: 08/Feb/13 Updated: 08/Feb/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | Documentation |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Documentation | Priority: | Minor |
| Reporter: | Rickard Andersson | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | collation, documentation | ||
| Description |
|
The documentation at http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/faq.html#how-do-i-set-the-charset-and-collation-for-mysql-tables clearly states that the collation should be set at database level and then inherited for all tables created. Digging through the code and reading this issue http://www.doctrine-project.org/jira/browse/DDC-2139 it's clear that this is no longer the case. |
[DDC-2275] [GH-568] Fixed plural variable names to singular when generating add or remove methods for entities Created: 04/Feb/13 Updated: 04/Feb/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Benjamin Eberlei | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of alexcarol: Url: https://github.com/doctrine/doctrine2/pull/568 Message: Changed generateEntityStubMethod so that variable names in add or remove methods are singular too Edited tests for EntityGenerator so that variable names are checked too |
[DDC-2264] Add support for custom Oracle SID / Service name in PDO_Oracle driver Created: 29/Jan/13 Updated: 29/Jan/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | 2.0 |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major |
| Reporter: | Michl Schmid | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | oracle | ||
| Description |
|
Some Oracle customer databases are set up having different settings for their "DBNAME" and "SID" / "SERVICE" property. (DBNAME != SID) So, hereing it's currently not possible to connect via the PDO_Oracle driver (Class: Doctrine\DBAL\Driver\PDOOracle\Driver) as it uses the DBNAME value by default as value for SID / SERVICE in the _constructPdoDsn() method. (DBNAME = SID) A solution would be to add an additional config param like "servicename" and pass it's value into _constructPdoDsn(). An updated version of the method could look like: private function _constructPdoDsn(array $params) if (isset($params['port'])) { $dsn .= '(PORT=' . $params['port'] . ')'; }else { $dsn .= '(PORT=1521)'; }if (isset($params['servicename']) && $params['servicename'] != '') { $servicename = $params['servicename']; }else { $servicename = $params['dbname']; }if (isset($params['service']) && $params['service'] == true) { $dsn .= '))(CONNECT_DATA=(SERVICE_NAME=' . $servicename . ')))'; }else { $dsn .= '))(CONNECT_DATA=(SID=' . $servicename . ')))'; }} else { $dsn .= 'dbname=' . $params['dbname']; }if (isset($params['charset'])) { $dsn .= ';charset=' . $params['charset']; } return $dsn; The only workaround for me is right now to use the "standard" PHP OCI / OCI8 functions with the correct SID / Service in it's DSN. |
[DDC-2260] Partial DQL query doesn't respect given order of columns Created: 26/Jan/13 Updated: 27/Jan/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | DQL |
| Affects Version/s: | 2.3.2 |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Alexander Grimalovsky | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
When executing partial DQL queries it may be important to keep given order of columns e.g. for "pairs" hydrator when first column of a pair is used as a key and second - as value. For example query like this: select partial u.{id,name} from my:User u will expect "id" to be first in resulted set and "name" to be second and not vice versa. However Doctrine parses this part of statement via iterating over fields mapping from entity's class metadata (as can be seen in Doctrine\ORM\Query\SqlWalker::walkSelectExpression()): foreach ($class->fieldMappings as $fieldName => $mapping) {
if ($partialFieldSet && ! in_array($fieldName, $partialFieldSet)) {
continue;
}
...
and hence given columns order preserving is not guaranteed. |
| Comments |
| Comment by Marco Pivetta [ 26/Jan/13 ] |
|
What is the advantage in respecting the order given in the DQL query? |
| Comment by Alexander Grimalovsky [ 27/Jan/13 ] |
|
Currently the only practical reason for it that I found is "pairs" hydrator. However it is, of course, possible to implement it without such change too. Generally speaking this behavior (getting result set with same order of columns that was given in a query) is something that is feeling "natural" for operations with database since it is how you normally get results from SQL queries. Maybe it will be enough to mention in documentation for Doctrine that given columns order is not guaranteed to be kept. |
| Comment by Marco Pivetta [ 27/Jan/13 ] |
|
@Alexander Grimalovsky I don't think it's worth mentioning it. Also, including a fix for this is quite complex. If you prefer to document it, go for it! |
[DDC-1938] [GH-406] [WIP] - DCOM-96 - Moving proxy generation and autoloading to common Created: 21/Jul/12 Updated: 26/Jan/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Improvement | Priority: | Major |
| Reporter: | Benjamin Eberlei | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
This issue is created automatically through a Github pull request on behalf of Ocramius: Url: https://github.com/doctrine/doctrine2/pull/406 Message: This PR is related to doctrine/common#168. In this PR, the `ProxyFactory` has been reduced to an object builder and it's public API has been kept intact (While the proxy `Autoloader` has been moved to doctrine/common). It would be interesting to define what this builder could do with the `ProxyFactory` to get its own customizations introduced. |
| Comments |
| Comment by Benjamin Eberlei [ 25/Jan/13 ] |
|
A related Github Pull-Request [GH-247] was opened |
| Comment by Benjamin Eberlei [ 26/Jan/13 ] |
|
A related Github Pull-Request [GH-247] was closed |
[DDC-1803] Paginator usage with a DQL query that is using 2 time the same named binded value failed Created: 30/Apr/12 Updated: 25/Jan/13 |
|
| 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: | Marc Drolet | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
linux, oracle |
||
| Description |
|
I use a dql query where I bind a named parameter 2 time in the same query for different joined fields. The query work but the count query failed saying that there are missing bind variable. ex: , partial ca.{id} , ') $onTheMarket = new Paginator($qb, $fetchJoin = true); To make it work, I've renamed the second usage of the named variable with a 2 at the end. deleted2 and published2. |
| Comments |
| Comment by Marco Pivetta [ 23/Jan/13 ] |
|
This seems to be quite old. Marc Drolet is it still valid with the latest ORM? |
| Comment by Marc Drolet [ 25/Jan/13 ] |
|
I'll try to test this problem on an updated version and I'll let you know. |
| Comment by Marco Pivetta [ 25/Jan/13 ] |
|
Ok, marking as awaiting feedback |
[DDC-1721] LIKE clausule should accept functions on the pattern Created: 21/Mar/12 Updated: 24/Jan/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | 2.1.6 |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Improvement | Priority: | Major |
| Reporter: | Ignacio Larranaga | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | None | ||
| Attachments: |
|
| Description |
|
Example: should be a valid SQL, now is rejected because the walker only accept a variable or an string expression. I'm adding a patch to address this. |
| Comments |
| Comment by Ignacio Larranaga [ 21/Mar/12 ] |
|
Sorry the Parser has to be modified also to allow expressions to be recognized, I'm attaching the necessary patch. |
| Comment by Benjamin Eberlei [ 22/Mar/12 ] |
|
I am sure there is a reason why the walker doesn't accept this such as not all supported vendors allowing functions in right hand side LIKE expressions, but i am not sure about this. |
| Comment by Glen Ainscow [ 03/Oct/12 ] |
|
This is not possible either: WHERE CASE WHEN p.name IS NULL THEN u.username ELSE p.name END LIKE :name |
| Comment by Thomas Mayer [ 24/Jan/13 ] |
|
In my case it worked when using "=" instead of "LIKE". //works: //[Syntax Error] line 0, col 1217: Error: Expected =, <, <=, <>, >, >=, !=, got 'LIKE' So the LIKE operator only needs to be allowed here. I'm wondering which vendor should not be able to handle that: |
[DDC-1010] Crash when fetching results from qb inside postLoad event Created: 01/Feb/11 Updated: 23/Jan/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | 2.0.1 |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Documentation | Priority: | Minor |
| Reporter: | Matevz Jekovec | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | None | ||
| Environment: |
PHP 5.3.3-1ubuntu9.3 |
||
| Description |
|
I registered an event listener to my entity manager and on a postLoad event, I want to prepare some data in a nice way (fetch translations for my library + store into associative array into entity). Here's my snippet: class TranslationListener implements EventSubscriber { public function getSubscribedEvents() { return array(Events::postLoad); } public function postLoad(LifecycleEventArgs $args) { $em = $args->getEntityManager(); $entity = $args->getEntity(); if ($entity instanceof Lib) { $qb = $em->createQueryBuilder(); $qb = $qb->select('T')->from('Translate', 'T')->join('T.locale', 'TT')->where('T.lib = ?1')->setParameter(1, $entity->idLib); $res = $qb->getQuery()->getResult(); foreach ($res as $tr) { $entity->tr[$tr->locale->idLocale] = $tr; } } } } When this code is run (eg. getting the Library objects), I got a crash where getResult() is called:
Fatal error: Call to a member function fetch() on a non-object in /home/thepianoguy/testproject/trunk/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php on line 126
Call Stack
# Time Memory Function Location
1 0.0004 656080 {main}( ) ../index.php:0
2 0.1081 18760176 TApplication->run( ) ../index.php:48
3 0.2637 33817288 TApplication->runService( ) ../TApplication.php:382
4 0.2637 33817288 TPageService->run( ) ../TApplication.php:1095
5 0.2698 34788448 TPageService->runPage( ) ../TPageService.php:444
6 0.2715 34986768 TPage->run( ) ../TPageService.php:498
7 0.2716 34989128 TPage->processNormalRequest( ) ../TPage.php:198
8 0.3383 42770128 TControl->loadRecursive( ) ../TPage.php:215
9 0.3383 42770208 ContactUserAddEdit->onLoad( ) ../TControl.php:1286
10 0.3383 42771912 ContactUserAddEdit->loadData( ) ../ContactUserAddEdit.php:56
11 0.3452 43436904 Doctrine\ORM\AbstractQuery->getResult( ) ../ContactUserAddEdit.php:124
12 0.3452 43437296 Doctrine\ORM\AbstractQuery->execute( ) ../AbstractQuery.php:366
13 0.4160 47009328 Doctrine\ORM\Internal\Hydration\AbstractHydrator->hydrateAll( ) ../AbstractQuery.php:537
14 0.4160 47011504 Doctrine\ORM\Internal\Hydration\ObjectHydrator->_hydrateAll( ) ../AbstractHydrator.php:99
If I comment the line 137 in Doctrine/ORM/Internal/Hydration/AbstractHydrator in _cleanup(), my code works fine: I think there is a problem when using alredy used entity manager and query builder inside the postLoad event. |
| Comments |
| Comment by Benjamin Eberlei [ 02/Feb/11 ] |
|
The hydrator is reused internally, this is potentially dangerous as I figure from your use-case. |
| Comment by Benjamin Eberlei [ 02/Feb/11 ] |
|
A workaround is to re-registr the object hydrator under a new name $configuration->setHydrationMode("object2", "Doctrine\ORM\Internal\Hydration\ObjectHydrator"); and use it in your query. $query->setHydrationMode("object2");
|
| Comment by Marco Pivetta [ 23/Jan/13 ] |
|
Marking as documentation issue, since the user has to be warned that `postLoad` has to use a dedicated hydrator to execute more load operations. |
[DDC-1614] On OneToOne mappings with Primary Key same as Foreign Key, using @Id in the foreign association does not carry over when running "generate-entities" with --generate-annotations=1 Created: 22/Jan/12 Updated: 23/Jan/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | Mapping Drivers, ORM, Tools |
| Affects Version/s: | 2.1.1 |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Improvement | Priority: | Trivial |
| Reporter: | Ryan Fink | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Fedora 15, php 5.3.8 |
||
| Description |
|
When having a OneToOne mapping that has a primary key that is the same as the foreign key, using the @Id attribute does not carry over when generating entities. Example code: class User
/**
class User_ExtraAttrs
When running "doctrine orm:generate-entities --regenerate-entities=1 --generate-annotations=1", the @Id in User_ExtraAttrs does not carry over. It must be manually inserted. |
[DDC-1879] Orphans are neither nulled nor removed when merging a graph of detached entities Created: 18/Jun/12 Updated: 23/Jan/13 |
|
| Status: | Awaiting Feedback |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | 2.2.2 |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Philippe Van Eerdenbrugghe | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Doctrine 2.2.2 |
||
| Description |
|
When merging a graph of detached entities, the created entitied are created and the updated entities are updated but the non-present entities (which exist in the database but are not in the graph) are neither removed nor have them their association column nullified. Example : In my code I have 2 entities : Parent and Child. There is a OneToMany(cascade= {"all"}, orphanRemoval=true) relation defined in Parent. In my database I have a Parent row with an id of 1, which has 3 Children with ids 1,2,3. When I write the following code, I expect the Parent with id 1 and the Child with id 2 to be updated, a new Child to be created and the Child with id 1 and 3 to be deleted. $parent = new Parent(); $parent->id = 1 // detached entity $existing_child = new Child(); $child->id = 2 // detached entity $new_child = new Child(); // new entity $dinner->addChild($existing_child); $dinner->addChild($new_child); $em->merge($dinner); $em->flush(); The objects I expect to be created and updated have the correct behaviour but the old children are not touched, they are still present in the database. |
| Comments |
| Comment by Marco Pivetta [ 23/Jan/13 ] |
|
I don't think this is valid. Orphan removal scheduling is handled only when an unit of work is available. What's the state of `$dinner` before your example? Can you `var_dump` it? |
[DDC-2213] Paginator does not work with composite primary key entity Created: 25/Dec/12 Updated: 23/Jan/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM, Tools |
| Affects Version/s: | 2.3.1 |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | New Feature | Priority: | Major |
| Reporter: | Stanislav Anisimov | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | composed, key, paginator | ||
| Environment: |
php 5.4 |
||
| Description |
|
Paginator does not work with composed primary key. "Single id is not allowed on composite primary key in entity" exception is thrown here Only first column values are fetched while retrieving primary keys here |
| Comments |
| Comment by Marco Pivetta [ 23/Jan/13 ] |
|
Limitation was confused by issue reporter and considered bug |
[DDC-1785] Paginator problem with SQL Server around DISTINCT keyword. Created: 18/Apr/12 Updated: 19/Jan/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | 2.1 |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Benjamin Eberlei | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
PDOException: SQLSTATE[42000]: [Microsoft][SQL Server Native Client 10.0][SQL Server]Incorrect syntax near the keyword 'DISTINCT'. (uncaught exception) |
| Comments |
| Comment by Craig Mason [ 18/Oct/12 ] |
|
There are four major issues with this: 1: SQLServerPlatform.php modifies the query to prepend 'SELECT ROW_NUMBER() OVER ($over)', which is inserted before the DISTINCT keyword. 2: The order needs to be placed inside the OVER($over) block. At this point, the regex is using the exact column name rather than the alias, so the outer query cannot ORDER. 3: The DISTINCT queries select only the ID columns - as OVER() required the sort column to be available in the outer query, IDs alone will not work. 4: SQL Server cannot DISTINCT on TEXT columns. 2005,2008 and 2012 recommend using VARCHAR(MAX) instead, which does support it. That doesn't help us with 2003. We work around that with a custom TEXT type that casts as varchar. Incidentally, 2012 supports LIMIT, which gets rid of this issue altogether. Edit: Added #3 |
| Comment by Craig Mason [ 18/Oct/12 ] |
|
I have a (very hacky) implementation working that uses regexes to correct the query so that it will execute. This also required modification in the ORM paginator, to select all columns instead of just IDs. https://github.com/CraigMason/dbal/commit/4ecd018c73e387904f78d81f1d327e34e905c5f1 This is certainly not a patch - more guidance. One interesting point... I had to wrap the whole query in a second SELECT *, as the WHERE IN confusingly returns non-distinct rows when part of the first inner query. No idea why this happens, but moving it out one layer makes it operate correctly. |
| Comment by Craig Mason [ 25/Oct/12 ] |
|
Updated, view all commits for this experimental branch here: |
| Comment by Craig Mason [ 29/Oct/12 ] |
|
This got waaaay too messy with regex alone due to the complicated nesting. As such, I have written the basis of a new SqlWalker class which can be used to create DISTINCT queries based on the root identifiers. It's not proper DISTINCT support, but it's a step forward. https://github.com/CraigMason/DoctrineSqlServerExtensions I've also added a Paginator (which was the original issue I had!) The current SqlWalker always sticks the ORDER BY on the end of the query, which just doesn't work properly with SqlServer. Is a vendor-specific walker breaking the DQL abstraction? Should this type of code be on the Platform object in the DBAL? Anyway, this repo fixes our immediate problem, and it would be good to revisit this in a wider context. Hopefully we can get some good SQL server support - there are plenty of other issues to deal with (UTF-8/UCS2, nvarchar etc) |
| Comment by Benjamin Eberlei [ 19/Jan/13 ] |
|
Craig Mason We don't have an SQL Server expert on the team, so if you want really good support you should join and help us with it. |
[DDC-2249] Default value sequence Created: 19/Jan/13 Updated: 19/Jan/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Task | Priority: | Major |
| Reporter: | Maria | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Symfony 2, linux |
||
| Description |
|
I want to have a column on a table that by default it takes the value from a sequence. I've tried to do something like this:
But this doesn't work, it creates de sequence but not the link between the table column and the sequence. Is there any possibility to do something like this? Or any autoincrement default value instead? Thanks! |
[DDC-2248] Expire result cache functionality not implemented Created: 19/Jan/13 Updated: 19/Jan/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | 2.3, 2.3.1, 2.3.2 |
| Fix Version/s: | None |
| Type: | Documentation | Priority: | Major |
| Reporter: | Piotr Niziniecki | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
According to documentation expireResultCache, should force cache to update but it's not working... Why? Because functionality is not implemented. You can set _expireResultCache variable, but there is no place where this variable is being checked. |
| Comments |
| Comment by Marco Pivetta [ 19/Jan/13 ] |
|
A cache profile can be set and cleaned. I suppose that `expireResultCache` is an old piece of code that survived the refactoring. Should just be removed and documented accordingly |
[DDC-265] Possibility for Nested Inheritance Created: 21/Jan/10 Updated: 16/Jan/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | New Feature | Priority: | Major |
| Reporter: | Michael Fürmann | Assignee: | Roman S. Borschel |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||
| Description |
|
It would be great if Doctrine had the possibility to define a further inharitance in a subclass. Example: I'd like to use a single table inheritance to map all information of |
| Comments |
| Comment by Benjamin Eberlei [ 21/Jan/10 ] |
|
The DataObject you describe is a no-go for Doctrine 2. Its just a very bad practice. Inheritance Mapping is for REAL inheritance only, otherwise you shouldnt go with a relational database in the first place. You should use the Event system for such changes, it offers you roughly the same possibilities and keeps you from having to use inheritance mapping. You could still create an abstract data object and define the fields that will be used in each "implementation" and then in events do something like: if ($entity instanceof DataObject) { $entity->updated(); $archiver->makeSnapshot($entity); } |
| Comment by Jonathan H. Wage [ 20/Mar/10 ] |
|
With this patch I think you could setup a nice similar model where you can introduce new children of this parent class and have it added to the discriminator map from the child instead of having to modify the parents mapping information. |
[DDC-2239] Allow dynamic modification of select queries (either filter the AST or query) Created: 11/Jan/13 Updated: 11/Jan/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Improvement | Priority: | Major |
| Reporter: | Nathanael Noblet | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
I had built and used the following for doctrine 1: http://web.archive.org/web/20110705035547/http://www.doctrine-project.org/projects/orm/1.2/docs/cookbook/record-based-retrieval-security-template/en#record-based-retrieval-security-template I'd like to build something similar for D2 based projects. ocramius in IRC suggested a bug report/Improvement request. Figured that perhaps a custom event "dql_parse" or "ast_render" passing the AST or Query as a parameter. I'm under a tight timeline and am willing to pay for aid/feature implementation. |
[DDC-1285] Select by multiple ids Created: 22/Jul/11 Updated: 11/Jan/13 |
|
| Status: | In Progress |
| Project: | Doctrine 2 - ORM |
| Component/s: | Mapping Drivers, ORM |
| Affects Version/s: | None |
| Fix Version/s: | 2.x |
| Security Level: | All |
| Type: | Improvement | Priority: | Major |
| Reporter: | Serge Smertin | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | None | ||
| Description |
|
How do you look at adding findByIds(array $ids) to EntityManager and UnitOfWork? This would allow fetching multiple entities from a database at one request and would be very useful for caching - there would be even some kind of IdentityMap kept in memcached or any other caching engine, that supports multiple id retrieval: i've been using such an architecture in multiple projects and it turned out to be very effective. There were two basic methods - findIdsByFilter(array $filter) and findEntitiesByIds(array $ids). The latter one had a caching proxy, replicating entities to a cache storage. If this idea proceeds - I'd be glad to cover it with more details. This topic on StackOverflow could also help: |
| Comments |
| Comment by Guilherme Blanco [ 20/Dec/11 ] |
|
Updating fix version |
[DDC-2227] Add details about developer being responsible of inverse side of an association Created: 09/Jan/13 Updated: 09/Jan/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | Documentation, ORM |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Documentation | Priority: | Minor |
| Reporter: | Marco Pivetta | Assignee: | Marco Pivetta |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
As far as I know, docs don't explain that it is up to the developer to keep the object graph consistent instead of relying on Doctrine ORM for everything. For example, for many to many, examples like following may be used: |
[DDC-1986] findBy hydration with limit and offset with Oracle database (oci8 driver) Created: 17/Aug/12 Updated: 08/Jan/13 |
|
| Status: | Awaiting Feedback |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | 2.3 |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Bug | Priority: | Major |
| Reporter: | Benjamin Grandfond | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | oracle | ||
| Environment: |
composer.json require : "php": ">=5.3.3", |
||
| Description |
|
I tried to use the findBy method with limit and offset parameters against an Oracle database using oci8 driver. The query seems to executed successfully but the hydrator fails when hydrating data as there is a DOCTRINE_ROWNUM column appending the "limit" clause. Here is the exception thrown : "Notice: Undefined index: DOCTRINE_ROWNUM in [...]/vendor/doctrine/orm/lib/Doctrine/ORM/Internal/Hydration/SimpleObjectHydrator.php line 183" I was thinking about something like this to fix this issue
Maybe there is a better approach, what are your thoughts? |
| Comments |
| Comment by Benjamin Grandfond [ 17/Aug/12 ] |
|
I implemented it in my forks : https://github.com/benja-M-1/doctrine2/commit/c8d899b14446accf869ddc0043f4235284375755 It works for me, but I didn't write unit tests. |
| Comment by Benjamin Grandfond [ 24/Aug/12 ] |
|
Hi, Did you have time to have a look at this issue? Thanks |
| Comment by Christophe Coevoet [ 24/Aug/12 ] |
|
Please send a pull request when you submit a fix. It is the proper way to submit them for review. When we want to see things waiting for review, we look at the list of pending PRs, not at all comments of the issue tracker to find links in them. And I can tell you that this change has a big issue: it introduces a state in the database platform whereas it is currently stateless. This is likely to cause some issues when using more than 1 query (which is a common use case). |
| Comment by Benjamin Grandfond [ 29/Aug/12 ] |
|
Hi Christophe thank you for your feedback. I didn't send a PR because I wanted someone sharing his thoughts about what I suggested in this current issue. However I don't really understand the stateless argument, can you explain a bit more? Otherwise how would do you proceed to tell Doctrine not to hydrate platform-specific columns? |
| Comment by Christophe Coevoet [ 29/Aug/12 ] |
|
If you run several queries, they will be affected by the extra columns of previous requests, which is wrong |
| Comment by Benjamin Eberlei [ 29/Aug/12 ] |
|
I think the ObjectHydrator catches this by skipping undefined columns, i think we might just have overoptimized the SimpleObjectHydrator a little bit. |
[DDC-2219] computeChangeSets array_merging for associationMappings problem ? Created: 02/Jan/13 Updated: 07/Jan/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Documentation | Priority: | Major |
| Reporter: | yohann.poli | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | unitofwork | ||
| Description |
|
Is this normal that when i call "$changeset = $unitOfWork->getEntityChangeSet($myObject);", it only return changes of root Object, all changes in sub collection (OneToMany) are less (not merging in the changeset) ? Is there an issue for that? |
| Comments |
| Comment by Marco Pivetta [ 02/Jan/13 ] |
|
Changesets of collections are computed separately from those of entities. |
| Comment by yohann.poli [ 02/Jan/13 ] |
|
Have to call the compute method for each collection of the entity ? |
| Comment by Benjamin Eberlei [ 06/Jan/13 ] |
|
Yes you have to, but this kind of operation seems weird. What are you trying to achieve. |
| Comment by yohann.poli [ 07/Jan/13 ] |
|
I manage a complex entity who have a collection entity (each entity in this collection have another collection entity) attributes and i need to now if the flush method has "really" execute an update. For example if the level 3 entity is update, i have to know in the root entity all changes apply in child... |
[DDC-2093] Doctrine Criteria does not support sorting by relationed field Created: 20/Oct/12 Updated: 06/Jan/13 |
|
| Status: | Open |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | Git Master |
| Fix Version/s: | None |
| Security Level: | All |
| Type: | Improvement | Priority: | Major |
| Reporter: | Bogdan Yurov | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
// Here I call Criteria filter
public function getWalletsActive() {
$criteria = Criteria::create()
->where(Criteria::expr()->eq("isRemoved", "0"))
->orderBy(array("currency.id" => "ASC"));
return $this->wallets->matching($criteria);
}
// Relation
/**
* @var Currency
*
* @ORM\ManyToOne(targetEntity="Currency")
* @ORM\JoinColumns({
* @ORM\JoinColumn(name="id_currency", referencedColumnName="id")
* })
*/
protected $currency;
// File BasicEntityPersister.php
// This cause the problem:
if ( ! isset($this->_class->fieldMappings[$fieldName])) {
throw ORMException::unrecognizedField($fieldName);
}
// There are no relations in $this->_class->fieldMappings at all!
|
| Comments |
| Comment by Benjamin Eberlei [ 06/Jan/13 ] |
|
Mark as improvement. |
[DDC-1698] Inconsistent proxy file name & namespace result in __PHP_Incomplete_Class when unserializing entities Created: 13/Mar/12 Updated: 06/Jan/13 |
|
| Status: | Reopened |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | 2.2, 2.2.1 |
| Fix Version/s: | 2.2.2 |
| Security Level: | All |
| Type: | Documentation | Priority: | Major |
| Reporter: | Benjamin Morel | Assignee: | Benjamin Eberlei |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Irrelevant |
||
| Description |
|
Starting with Doctrine 2.2, the Proxy classes have inconsistent naming with their file name, which raises problems with class autoloading. Application\Proxy\__CG__\Application\Model\User This class is located in the following file: Application/Proxy/__CG__ApplicationModelUser.php But whe we serialize such an entity, then unserialize it in another session, the framework autoloader expects the class to be located in: Application/Proxy/__CG__/Application/Model/User.php But it is not. I'm not sure whether this is an intended behavior, but I would assume this is a bug. |
| Comments |
| Comment by Benjamin Morel [ 13/Mar/12 ] |
|
It looks like there is an even broader problem with the new _CG_ prefix; the PSR-0 standard for autoloading states that the underscores should be handled this way: \namespace\package\Class_Name => {...}/namespace/package/Class/Name.php
Which means that in the above example, it could even expect the file to be located in: Application/Proxy///CG///Application/Model/User.php ... which is far away from the actual location. |
| Comment by Benjamin Eberlei [ 14/Mar/12 ] |
|
Proxy classes do not follow PSR-0. For the case unserializing objects we should provide an extra autoloader i guess. See here how symfony does it https://github.com/doctrine/DoctrineBundle/blob/master/DoctrineBundle.php#L57 |
| Comment by Benjamin Eberlei [ 14/Mar/12 ] |
|
See https://github.com/doctrine/doctrine2/commit/9b4d60897dfc7e9b165712428539e694ec596c80 and https://github.com/doctrine/orm-documentation/commit/01381fae1ff3d4944086c7cfe46721925bf6ca15 |
| Comment by Benjamin Morel [ 14/Mar/12 ] |
|
Thanks for the quick fix, Benjamin. You mentioned in the doc that the proxies are not PSR-0 compliant "for implementation reasons"; as this was working fine before 2.2, could you please explain what requirement prevents Doctrine from keeping the previous naming convention? |
| Comment by Benjamin Eberlei |