[DDC-3319] Get the converted value in convertToDatabaseValueSQL() Created: 23/Sep/14  Updated: 01/Feb/15

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

Type: Bug Priority: Minor
Reporter: Benjamin Morel Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: mapping


 Description   

I have a use case where it would be useful to get the value being converted in the convertToDatabaseValueSQL() method, not just in convertToDatabaseValue().

Take the following mapping for a Geometry type:

    public function convertToDatabaseValue($value, AbstractPlatform $platform)
    {
        return $value->asBinary();
    }

    public function convertToDatabaseValueSQL($sqlExpr, AbstractPlatform $platform)
    {
        return sprintf('ST_GeomFromWkb(%s, %s)', $sqlExpr, 4326);
    }

In GIS-enabled databases, ST_GeomFromWkb() takes two parameters: the WKB binary representation of the geometry, and an integer representing the SRID (coordinate system) of the geometry, in this example the hardcoded value 4326.

I would be nice to have access to the value being converted in the convertToDatabaseValueSQL() as well, to be able to get the SRID from the geometry object itself, and replace the above code with something like:

    public function convertToDatabaseValueSQL($sqlExpr, AbstractPlatform $platform, $value)
    {
        return sprintf('ST_GeomFromWkb(%s, %s)', $sqlExpr, $value->srid());
    }

I don't think there is currently a technical way to do this (please correct me if I'm wrong).

Could we find a BC way to pass the value being converted to the convertToDatabaseValueSQL() method to add support for this use case?



 Comments   
Comment by Michael Lucas [ 25/Jan/15 ]

The use case which you described above would be a great addition to the convertToDatabaseValueSQL() or in the convertToDatabaseValue() be able to return an array of values which could be used in the convertToDatabaseValueSQL().

    public function convertToDatabaseValue($value, AbstractPlatform $platform)
    {
        return array('geometry' => $value->asBinary(), 'srid'=>$value->getSRID());
    }

    public function convertToDatabaseValueSQL($sqlExpr, AbstractPlatform $platform)
    {
        return sprintf('ST_GeomFromWkb(%s, %s)', ':geometry', ':srid');
    }
Comment by Benjamin Morel [ 25/Jan/15 ]

Michael Lucas It's an interesting idea, it would work as well, although I think it might be much more complicated to implement!

Comment by Paolo Agostinetto [ 01/Feb/15 ]

It there a workaround for this? I'm probably going to use a native query.

My use case is pretty common among Postgres full-text users: I need to insert a record
using the ts_vector() function with both parameters, eg: ts_vector('english', 'This is a test'),
and both parameters has to be passed on record creation.





[DDC-3552] Code generation throws exceptions when embeddables are used Created: 30/Jan/15  Updated: 30/Jan/15

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

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


 Description   

I've created a gist showing the code you can use to reproduce the issue
https://gist.github.com/v3labs/d02244c99a87444be709

I've also included the composer.json file.

When I run php app/console doctrine:generate:entities AppBundle -v, I get the following exception:

[Symfony\Component\Debug\Exception\ContextErrorException]
Notice: Trying to get property of non-object

Exception trace:
() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php:3251
Symfony\Component\Debug\ErrorHandler->handleError() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php:3251
Doctrine\ORM\Mapping\ClassMetadataInfo->inlineEmbeddable() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php:201
Doctrine\ORM\Mapping\ClassMetadataFactory->doLoadMetadata() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php:332
Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->loadMetadata() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php:78
Doctrine\ORM\Mapping\ClassMetadataFactory->loadMetadata() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php:225
Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->getMetadataFor() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php:115
Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->getAllMetadata() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/doctrine-bundle/Mapping/DisconnectedMetadataFactory.php:201
Doctrine\Bundle\DoctrineBundle\Mapping\DisconnectedMetadataFactory->getAllMetadata() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/doctrine-bundle/Mapping/DisconnectedMetadataFactory.php:164
Doctrine\Bundle\DoctrineBundle\Mapping\DisconnectedMetadataFactory->getMetadataForNamespace() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/doctrine-bundle/Mapping/DisconnectedMetadataFactory.php:54
Doctrine\Bundle\DoctrineBundle\Mapping\DisconnectedMetadataFactory->getBundleMetadata() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/doctrine-bundle/Command/GenerateEntitiesDoctrineCommand.php:96
Doctrine\Bundle\DoctrineBundle\Command\GenerateEntitiesDoctrineCommand->execute() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/symfony/symfony/src/Symfony/Component/Console/Command/Command.php:253
Symfony\Component\Console\Command\Command->run() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:882
Symfony\Component\Console\Application->doRunCommand() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:195
Symfony\Component\Console\Application->doRun() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Console/Application.php:96
Symfony\Bundle\FrameworkBundle\Console\Application->doRun() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:126
Symfony\Component\Console\Application->run() at /Users/vladislav/Sites/doctrine2.5_tests/app/console:27

If I add columnPreffix to the @Embed annotation the exception is different:

[Symfony\Component\Debug\Exception\ContextErrorException]
Catchable Fatal Error: Argument 1 passed to Doctrine\ORM\Mapping\ReflectionEmbeddedProperty::__construct() must be an instance of ReflectionP
roperty, null given, called in /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php on
line 952 and defined

Exception trace:
() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ReflectionEmbeddedProperty.php:61
Symfony\Component\Debug\ErrorHandler->handleError() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ReflectionEmbeddedProperty.php:61
Doctrine\ORM\Mapping\ReflectionEmbeddedProperty->__construct() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php:952
Doctrine\ORM\Mapping\ClassMetadataInfo->wakeupReflection() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php:721
Doctrine\ORM\Mapping\ClassMetadataFactory->wakeupReflection() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php:343
Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->loadMetadata() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php:78
Doctrine\ORM\Mapping\ClassMetadataFactory->loadMetadata() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php:225
Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->getMetadataFor() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php:115
Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->getAllMetadata() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/doctrine-bundle/Mapping/DisconnectedMetadataFactory.php:201
Doctrine\Bundle\DoctrineBundle\Mapping\DisconnectedMetadataFactory->getAllMetadata() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/doctrine-bundle/Mapping/DisconnectedMetadataFactory.php:164
Doctrine\Bundle\DoctrineBundle\Mapping\DisconnectedMetadataFactory->getMetadataForNamespace() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/doctrine-bundle/Mapping/DisconnectedMetadataFactory.php:54
Doctrine\Bundle\DoctrineBundle\Mapping\DisconnectedMetadataFactory->getBundleMetadata() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/doctrine-bundle/Command/GenerateEntitiesDoctrineCommand.php:96
Doctrine\Bundle\DoctrineBundle\Command\GenerateEntitiesDoctrineCommand->execute() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/symfony/symfony/src/Symfony/Component/Console/Command/Command.php:253
Symfony\Component\Console\Command\Command->run() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:882
Symfony\Component\Console\Application->doRunCommand() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:195
Symfony\Component\Console\Application->doRun() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Console/Application.php:96
Symfony\Bundle\FrameworkBundle\Console\Application->doRun() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:126
Symfony\Component\Console\Application->run() at /Users/vladislav/Sites/doctrine2.5_tests/app/console:27

doctrine:generate:entities [--path="..."] [--no-backup] name

I don't think it's a Symfony specific issue. I tried using the built-in CLI tool and got the same results.



 Comments   
Comment by Marco Pivetta [ 30/Jan/15 ]

Yeah, this can't really work with code-gen, because embeddables require reflection to be initialized in order to operate, whereas the codegen cli-tools operate with a DisconnectedMetadataFactory, which skips reflection on purpose (it assumes that the class does not exist, therefore it does not start up reflection).

I think it's a can't fix for now.

Comment by Vladislav Veselinov [ 30/Jan/15 ]

Sorry for the formatting. I had never used jira before.

Comment by Marco Pivetta [ 30/Jan/15 ]

Vladislav Veselinov fixed the formatting, no big deal

Comment by Vladislav Veselinov [ 30/Jan/15 ]

Btw:

Changing line 947 in ClassMetadataInfo to:

if (isset($mapping['declaredField']) && $parentReflFields[$mapping['declaredField']]) {

seems to bypass the problem and the generation runs fine, but I don't know if it breaks something else. Doesn't seem like it but ... I'm not sure

Comment by Vladislav Veselinov [ 30/Jan/15 ]

Just figured out with it won't work in all cases. I'll keep digging. Thanks for the feedback!





[DDC-3549] [GH-1292] Mark getSelectConditionStatementColumnSQL method as private Created: 28/Jan/15  Updated: 29/Jan/15  Resolved: 29/Jan/15

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: bc, persister


 Description   

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

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

Message:

The `Doctrine/\ORM\Persisters\BasicEntityPersister::getSelectConditionStatementColumnSQL` method has been marked as `private`.

The current `protected` mark is a bit unuseful since everything is already handled into the public method `getSelectConditionStatementSQL`.



 Comments   
Comment by Doctrine Bot [ 29/Jan/15 ]

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





[DDC-2988] Notice: Undefined index: joinColumns in BasicEntityPersister.php Created: 19/Feb/14  Updated: 29/Jan/15

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

Type: Bug Priority: Major
Reporter: Dennis Væversted Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None

Attachments: Text File undefined-joinColumn.patch    
Issue Links:
Duplicate
duplicates DDC-2808 Notice: Undefined index: joinColumns ... Resolved

 Description   

When trying to use findBy on a ManyToMany field i receive the error:

Notice: Undefined index: joinColumns in lib/Doctrine/ORM/Persisters/BasicEntityPersister.php

It seems to be caused internally by the code expecting 'joinColumns' to be directly on the association, however it is found under 'joinTable'.
I have attached a patch that atleast fixes my case, hopefully it can be used to pin-point what the error is.



 Comments   
Comment by Dennis Væversted [ 19/Feb/14 ]

Might be related to this one: http://www.doctrine-project.org/jira/browse/DDC-2808

Comment by Litz Ouille [ 28/May/14 ]

Doctrine ORM 2.4.2 Here.

Here are my annotations
https://gist.github.com/LitzOuille/3cf2e73e169c032147ea

The thing I'm trying to do is
$questionRepository->findBy(array('contacts' => $ids)); // $ids = array(1,2,3, ...)

Comment by Marco Pivetta [ 30/May/14 ]

Calin Pristavu did you validate your mappings?

Comment by Calin Pristavu [ 30/May/14 ]

I failed, sorry.
The error came from the many-to-many condition in the entity.
Sorry for generating confusion, comment deleted !

The many-to-one works just fine !

Comment by Litz Ouille [ 03/Jun/14 ]

A little feedback? Is this a bug? Can it be fixed?
Thanks

Comment by Marco Pivetta [ 03/Jun/14 ]

Litz Ouille that particular repository call cannot work. How are we supposed to find an entity from a list of associated IDs? It would have to be the exact match...

Assuming that API would work as I envision it, it looks like a missing feature.

Dennis Væversted in order to accept a patch, we first need a failing test case demonstrating the failing scenario.

Comment by Litz Ouille [ 03/Jun/14 ]

EDIT: Ok my bad.

I am using findBy(array('id', $arrayIds)) and it is working. I thought I was using on a ManyToOne relationship, but no.

EDIT2: @ocramius In fact I would like to find all questions for which the contacts' list contains at least one id. Something like
SELECT q.*
FROM Question q, QuestionContact qc //qc = jointable
WHERE q.id = qc.question_id
AND qc.contact_id IN ($ids)

EDIT3: Actually when I try to findBy('ManyToMany', $id), it does not work either. I think I will have to use a repository for every query using a ManyToMany relationship.

EDIT4: Ok, so, as said in the original post, findBy does not work with many-to-many.
Notice: Undefined index: joinColumns (BasicEntityPersister.php line 1666)
Dump($this->class->associationMappings[$field]): https://gist.github.com/LitzOuille/51929fdc3eda5576ed31

Comment by Xander ten Boden [ 13/Jun/14 ]

I've got the same issue, also running doctrine 2.4.2:

multiple users can have multiple departments:

/**
 * @ORM\ManyToMany(targetEntity="CartelAuthDepartment", inversedBy="users")
 * @ORM\JoinTable(name="cartel_auth_user_has_cartel_auth_department",
 *		joinColumns={@ORM\JoinColumn(name="cartel_auth_user_id", referencedColumnName="id")},
 *		inverseJoinColumns={@ORM\JoinColumn(name="cartel_auth_department_id", referencedColumnName="id")}
 * )
 */
private $departments;

/**
 * @ORM\ManyToMany(targetEntity="\Cartel\AuthBundle\Entity\CartelAuth\CartelAuthUser", mappedBy="departments")
 */
private $users;

Then I want to find all the users that are within the departments that the current user has:

$aAuthUsers = $oEm->getRepository('CartelAuthBundle:CartelAuth\CartelAuthUser')->findByDepartments($aAuthDepartments);

This results in this error:

Notice: Undefined index: joinColumns in .../vendor/doctrine/orm/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php line 1665

Comment by Alexander [ 29/Jan/15 ]

I have same problem with doctrine 2.4.7:

Acme\ProjectBundle\Entity\Employee:
  manyToMany:
    projectbag:
      targetEntity: ProjectBag
      mappedBy: bagemployee
Acme\ProjectBundle\Entity\ProjectBag:
  manyToMany:
    bagemployee:
          targetEntity: Employee
          inversedBy: projectbag
          joinTable:
            name: ProjectBag_Employee
            joinColumns:
              ProjectBag_id:
                referencedColumnName: id
            inverseJoinColumns:
              Employee_id:
                referencedColumnName: id

$em->getRepository('AcmeProjectBundle:ProjectBag')->findBy(array('bagemployee'=>$em->getRepository('AcmeProjectBundle:Employee')->find(828)));

Notice: Undefined index: joinColumns in vendor/doctrine/orm/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php at line 1670





[DDC-3551] [GH-1294] Avoid Connection error when calling ClassMetadataFactor::getAllMetadata() Created: 29/Jan/15  Updated: 29/Jan/15

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

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


 Description   

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

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

Message:

Hi guys!

When you pair the ORM with DBAL 2.5.0, then getting the `targetPlatform` means that a connection will be made to the database. For that reason, it's really important to not get the `targetPlatform` unless it's absolutely needed. Currently, if you call `ClassMetadataFactor::getAllMetadata()`, it will try to determine `targetPlatform` (in `initialize()`), which will make a connection. And if that connection fails (e.g. no db yet), it will blow up - even though `getAllMetadata()` doesn't need the `targetPlatform`.

This fixes that, and in an absolutely BC way, since `targetPlatform` is private (yay!). This should fix a number of issues in userland, like symfony/symfony-standard#748 and symfony/symfony-standard#774.

This is a PR to master (per the guidelines), but the real target is 2.4, since it's the latest stable. The patch won't apply cleanly, but it's simple: remove from initialize, then replace all references to the new private method.

Thanks in advance! More details are on the commit message.






[DDC-3550] [GH-1293] EntityManager::__cosntruct() as public method Created: 28/Jan/15  Updated: 28/Jan/15

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

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


 Description   

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

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

Message:






[DDC-3321] [GH-1145] Minor performance tweaks Created: 23/Sep/14  Updated: 28/Jan/15  Resolved: 23/Sep/14

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

Type: Improvement Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

Function calls are expensive in PHP, this PR just removes unnecessary calls to `call_user_func()` when a direct `$variable()` call is possible.



 Comments   
Comment by Doctrine Bot [ 23/Sep/14 ]

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

Comment by Doctrine Bot [ 23/Sep/14 ]

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

Comment by Doctrine Bot [ 28/Jan/15 ]

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





[DDC-3548] [GH-1291] Conversion to PHP 5.4's short array syntax Created: 28/Jan/15  Updated: 28/Jan/15

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

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


 Description   

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

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

Message:

Now that the minimum PHP version is 5.4, it would be good to encourage the use of the short array syntax `[]`.
Converting the existing codebase to this syntax will promote this good practice and encourage everyone to follow it.

I have converted the codebase with [a tool](https://gist.github.com/BenMorel/6994483) I wrote for personal projects:

find doctrine2 -type f -name '*.php' -exec php short-array-syntax-converter.php {} \;

The number of changes is quite large, but I'm confident that nothing is broken, and the passing tests confirm this.



 Comments   
Comment by Doctrine Bot [ 28/Jan/15 ]

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

Comment by Doctrine Bot [ 28/Jan/15 ]

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





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

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

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


 Description   

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

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

Message:

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

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

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



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

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

Comment by Doctrine Bot [ 26/Jan/15 ]

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

Comment by Doctrine Bot [ 28/Jan/15 ]

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

Comment by Doctrine Bot [ 28/Jan/15 ]

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





[DDC-3517] [GH-1265] Fix error undefined index "targetEntity" in persister Created: 18/Jan/15  Updated: 28/Jan/15  Resolved: 18/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: inheritance, one-to, onetoone, persister, sti


 Description   

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

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

Message:



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

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

Comment by Doctrine Bot [ 18/Jan/15 ]

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





[DDC-3544] [GH-1288] Hotfix - #1169 - extra lazy one to many must be no-op when not doing orphan removal Created: 27/Jan/15  Updated: 28/Jan/15  Resolved: 28/Jan/15

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

Type: Bug Priority: Blocker
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: collection, extra-lazy, lazy-loading, onetomany, orphanRemoval

Issue Links:
Dependency
is required for DDC-3343 `PersistentCollection::removeElement`... Resolved
is required for DDC-3536 [GH-1281] Hotfix/#1169 extra lazy one... Resolved

 Description   

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

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

Message:

See https://github.com/doctrine/doctrine2/pull/1281#issuecomment-71403668



 Comments   
Comment by Doctrine Bot [ 28/Jan/15 ]

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

Comment by Doctrine Bot [ 28/Jan/15 ]

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

Comment by Doctrine Bot [ 28/Jan/15 ]

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





[DDC-3346] findOneBy returns an object with partial collection for the properties with mapping oneToMany/Fetch Eager Created: 10/Oct/14  Updated: 28/Jan/15  Resolved: 25/Jan/15

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

Type: Bug Priority: Critical
Reporter: Adrien Russo Assignee: Marco Pivetta
Resolution: Fixed Votes: 2
Labels: collection, eager, fetch, lazy-loading, many-to-many, onetomany, persister

Issue Links:
Dependency
depends on DDC-3534 [GH-1280] [DDC-3346] #1277 find one w... Open
depends on DDC-3531 [GH-1277] [DDC-3346] Failing test for... Resolved

 Description   

findOneBy returns an object with partial collection for the properties with mapping oneToMany/Fetch Eager. This bug appear only for entities without inheritance.

Mapping
       
Test\Bar:
    type: entity
    table: bar
    fields:
        code:
            type: string
    oneToMany:
        posts:
            targetEntity: Test\Post
            fetch: EAGER
            mappedBy: bar
            cascade: ['all']
    
Test\Post:
    type: entity
    table: post
    fields:
        content:
            type: text
    manyToOne:
        bar:
            targetEntity: Test\Bar
            cascade: []
            joinColumn:
                name: bar_id
                referencedColumnName: id
Data
    
$bar = new \Test\Bar('foo');
$bar->addPost(
  new Test\Post('toto')
);
$bar->addPost(
  new Test\Post('tata')
);
 
$bar->getPosts()->count(); #value is 2
$manager->persist($bar);
$manager->flush();
FindOneBy with fetch eager
$bar = $repository->findOneBy(['code' => 'foo']);
$bar->getPosts()->count(); #value is 1
FindOneBy with fetch Lazy
$bar = $repository->findOneBy(['code' => 'foo']);
$bar->getPosts()->count(); #value is 2

I think this bug is due to the LIMIT 1 clause happening on findOneBy which also applies on joins generated here.

For instance, the generated SQL statement generated might look like

Sql Statement
SELECT
	t0. ID AS id_1,
	t0.code AS code_2,
	t1. ID AS id_3,
	t1.content AS content_4,
	t1.bar_id AS bar_id_5
FROM
	bar t0
LEFT JOIN post t1 ON t1.bar_id = t0. ID
WHERE
	t0. code = 'foo'
LIMIT 1


 Comments   
Comment by Pavel Batanov [ 22/Jan/15 ]

Still expiriencing it at 2.5.0-alpha (b889e18a9a15c36eac7349b06cb4b0f955a9da57). findOneBy cuts many-to-many association with fetch eager by 'LIMIT 1'

Comment by Marco Pivetta [ 22/Jan/15 ]

Pavel Batanov yeah, we don't have a fix for it yet: I suggest providing a PR with the failing test first, and if we can't get to it, trying to patch it yourself, or at least find out which code bit affects this behavior.

Comment by Pavel Batanov [ 22/Jan/15 ]

I'm finishing such PR now. Will supply it to github soon

Comment by Pavel Batanov [ 22/Jan/15 ]

here it is
https://github.com/doctrine/doctrine2/pull/1277
http://www.doctrine-project.org/jira/browse/DDC-3531

Here is the failed travis build
https://travis-ci.org/scaytrase/doctrine2/jobs/47921568

Comment by Doctrine Bot [ 23/Jan/15 ]

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

Comment by Doctrine Bot [ 23/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 25/Jan/15 ]

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

Comment by Marco Pivetta [ 25/Jan/15 ]

Handled in DDC-3534

Comment by Matteo Beccati [ 28/Jan/15 ]

FYI the test is failing on: https://revive.beccati.com/bamboo/browse/PHP-DOCTR-PHP54-249/test/case/18357533

As far as I can tell from https://www.sqlite.org/lang_select.html SQLite doesn't support OFFSET w/o LIMIT.

Doctrine\Tests\ORM\Functional\Ticket\DDC3346Test::testFindWithEagerFetchAndOffsetWillNotHydrateLimitedCollection
Exception: [Doctrine\DBAL\Exception\SyntaxErrorException] An exception occurred while executing 'SELECT t0.id AS id_1, t0.username AS username_2 FROM ddc3346_users t0 WHERE t0.username = ? OFFSET 0' with params ["bwoogy"]:

SQLSTATE[HY000]: General error: 1 near "OFFSET": syntax error

With queries:
6. SQL: '"COMMIT"' Params: 
5. SQL: 'INSERT INTO ddc3346_articles (user_id) VALUES (?)' Params: '1'
4. SQL: 'INSERT INTO ddc3346_articles (user_id) VALUES (?)' Params: '1'
3. SQL: 'INSERT INTO ddc3346_users (username) VALUES (?)' Params: 'bwoogy'
2. SQL: '"START TRANSACTION"' Params: 

Trace:
/home/atlassian/bamboo/xml-data/build-dir/PHP-DOCTR-PHP54/vendor/doctrine/dbal/lib/Doctrine/DBAL/DBALException.php:116
/home/atlassian/bamboo/xml-data/build-dir/PHP-DOCTR-PHP54/vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php:838
/home/atlassian/bamboo/xml-data/build-dir/PHP-DOCTR-PHP54/lib/Doctrine/ORM/Persisters/Entity/BasicEntityPersister.php:875
/home/atlassian/bamboo/xml-data/build-dir/PHP-DOCTR-PHP54/lib/Doctrine/ORM/EntityRepository.php:181
/home/atlassian/bamboo/xml-data/build-dir/PHP-DOCTR-PHP54/tests/Doctrine/Tests/ORM/Functional/Ticket/DDC3346Test.php:53
/home/atlassian/bamboo/xml-data/build-dir/PHP-DOCTR-PHP54/vendor/phpunit/phpunit/src/Framework/TestCase.php:860
/home/atlassian/bamboo/xml-data/build-dir/PHP-DOCTR-PHP54/vendor/phpunit/phpunit/src/Framework/TestCase.php:737
/home/atlassian/bamboo/xml-data/build-dir/PHP-DOCTR-PHP54/vendor/phpunit/phpunit/src/Framework/TestResult.php:609
/home/atlassian/bamboo/xml-data/build-dir/PHP-DOCTR-PHP54/vendor/phpunit/phpunit/src/Framework/TestCase.php:693
/home/atlassian/bamboo/xml-data/build-dir/PHP-DOCTR-PHP54/vendor/phpunit/phpunit/src/Framework/TestSuite.php:716
/home/atlassian/bamboo/xml-data/build-dir/PHP-DOCTR-PHP54/vendor/phpunit/phpunit/src/Framework/TestSuite.php:716
/home/atlassian/bamboo/xml-data/build-dir/PHP-DOCTR-PHP54/vendor/phpunit/phpunit/src/TextUI/TestRunner.php:398
phar:///home/atlassian/bin/phpunit.phar/phpunit/TextUI/Command.php:179
phar:///home/atlassian/bin/phpunit.phar/phpunit/TextUI/Command.php:132
/home/atlassian/bin/phpunit.phar:584
Comment by Steve Müller [ 28/Jan/15 ]

Matteo Beccati I believe this is fixed already by https://github.com/doctrine/dbal/pull/782

Comment by Matteo Beccati [ 28/Jan/15 ]

My mistake. The build wasn't cleaning up the vendor dir before running composer update, so it was still using an old dbal.





[DDC-2093] Doctrine Criteria does not support sorting by relationed field Created: 20/Oct/12  Updated: 28/Jan/15

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

Type: Improvement Priority: 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.

Comment by Liverbool [ 28/Jan/15 ]

How about this?

Comment by Marco Pivetta [ 28/Jan/15 ]

Liverbool give it a try and open a PR





[DDC-3547] [GH-1290] [Doc] [Reference] [Second Level Cache] Created: 27/Jan/15  Updated: 27/Jan/15  Resolved: 27/Jan/15

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

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


 Description   

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

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

Message:

Updated reference for Second Level Cache (fixed some typos and docblocks).



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

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

Comment by Doctrine Bot [ 27/Jan/15 ]

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





[DDC-3540] [GH-1285] travis: remove unnecessary database creation Created: 25/Jan/15  Updated: 27/Jan/15  Resolved: 27/Jan/15

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: ci, performance, setup, travis

Issue Links:
Duplicate
duplicates DDC-3546 [GH-1289] Improve test suite Resolved
Reference
relates to DDC-3532 [GH-1278] travis: remove unnecessary ... Resolved
is referenced by DDC-3546 [GH-1289] Improve test suite Resolved

 Description   

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

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

Message:

Ref: #1278



 Comments   
Comment by Doctrine Bot [ 25/Jan/15 ]

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

Comment by Doctrine Bot [ 25/Jan/15 ]

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

Comment by Doctrine Bot [ 27/Jan/15 ]

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





[DDC-3546] [GH-1289] Improve test suite Created: 27/Jan/15  Updated: 27/Jan/15  Resolved: 27/Jan/15

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

Type: Improvement Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: ci, performance, phpunit, testing, travis

Issue Links:
Duplicate
is duplicated by DDC-3540 [GH-1285] travis: remove unnecessary ... Resolved
Reference
relates to DDC-3540 [GH-1285] travis: remove unnecessary ... Resolved

 Description   

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

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

Message:

This PR adopts DBAL's latest test suite improvements from https://github.com/doctrine/dbal/pull/597/files, https://github.com/doctrine/dbal/pull/643/files, https://github.com/doctrine/dbal/pull/779 and https://github.com/doctrine/dbal/pull/758/files
Supersedes https://github.com/doctrine/doctrine2/pull/1285



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

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

Comment by Doctrine Bot [ 27/Jan/15 ]

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

Comment by Doctrine Bot [ 27/Jan/15 ]

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





[DDC-2693] Attribute/association overrides should be ignored when generating entities Created: 19/Sep/13  Updated: 27/Jan/15

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

Type: Bug Priority: Minor
Reporter: Joris van de Sande Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 9
Labels: command

Issue Links:
Duplicate
is duplicated by DDC-3109 [Doctrine\ORM\Mapping\MappingExceptio... Open

 Description   

The "orm:generate-entities" command fails when doctrine attribute and/or association overrides are used. So from the moment that you use an attribute/association override, it is implossible to use the generate entities command. I think that the solution to this problem is to ignore the overrides when generating entities.

The exception given in case of an attribute override is (this is executed within a Symfony2 project doctrine:generate:entities):

Generating entity "My\AppBundle\Entity\Job"

  [Doctrine\ORM\Mapping\MappingException]
  Invalid field override named 'value' for class 'My\AppBundle\Entity\Job'.

Exception trace:
 () at /path/to/project/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/MappingException.php:89
 Doctrine\ORM\Mapping\MappingException::invalidOverrideFieldName() at /path/to/project/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php:1922
 Doctrine\ORM\Mapping\ClassMetadataInfo->setAttributeOverride() at /path/to/project/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/Driver/YamlDriver.php:564
 Doctrine\ORM\Mapping\Driver\YamlDriver->loadMetadataForClass() at /path/to/project/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/Driver/MappingDriverChain.php:104
 Doctrine\Common\Persistence\Mapping\Driver\MappingDriverChain->loadMetadataForClass() at /path/to/project/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php:113
 Doctrine\ORM\Mapping\ClassMetadataFactory->doLoadMetadata() at /path/to/project/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php:302
 Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->loadMetadata() at /path/to/project/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php:212
 Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->getMetadataFor() at /path/to/project/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php:112
 Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->getAllMetadata() at /path/to/project/vendor/doctrine/doctrine-bundle/Doctrine/Bundle/DoctrineBundle/Mapping/MetadataFactory.php:196
 Doctrine\Bundle\DoctrineBundle\Mapping\MetadataFactory->getAllMetadata() at /path/to/project/vendor/doctrine/doctrine-bundle/Doctrine/Bundle/DoctrineBundle/Mapping/MetadataFactory.php:176
 Doctrine\Bundle\DoctrineBundle\Mapping\MetadataFactory->getMetadataForClass() at /path/to/project/vendor/doctrine/doctrine-bundle/Doctrine/Bundle/DoctrineBundle/Mapping/MetadataFactory.php:76
 Doctrine\Bundle\DoctrineBundle\Mapping\MetadataFactory->getClassMetadata() at /path/to/project/vendor/doctrine/doctrine-bundle/Doctrine/Bundle/DoctrineBundle/Command/GenerateEntitiesDoctrineCommand.php:106
 Doctrine\Bundle\DoctrineBundle\Command\GenerateEntitiesDoctrineCommand->execute() at /path/to/project/vendor/symfony/symfony/src/Symfony/Component/Console/Command/Command.php:242
 Symfony\Component\Console\Command\Command->run() at /path/to/project/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:200
 Symfony\Component\Console\Application->doRun() at /path/to/project/vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Console/Application.php:83
 Symfony\Bundle\FrameworkBundle\Console\Application->doRun() at /path/to/project/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:106
 Symfony\Component\Console\Application->run() at /path/to/project/app/console:19


 Comments   
Comment by Rein Baarsma [ 27/Feb/14 ]

I have the same issue and it's easy to reproduce with a clean Symfony 2 setup with FOSUserBundle.
Once you add

 * @ORM\AttributeOverrides({
 *      @ORM\AttributeOverride(name="usernameCanonical",
 *          column=@ORM\Column(
 *              name     = "username_canonical",
 *              type     = "string",
 *              length   = 255,
 *              unique   = false
 *          )
 *      )
 * })

It will properly do doc:schema:update --force
But it will fail on doc:gen:entities (YourEntity)

Comment by Andy Waterman [ 13/Aug/14 ]

Not sure I agree this is minor - might not affect many users, but it's pretty blocking if you do run into it. Any ideas on a fix?

Comment by Marco Pivetta [ 13/Aug/14 ]

Andy Waterman you are supposed to manually edit generated entities anyway

Comment by Andy Waterman [ 19/Aug/14 ]

" you are supposed to manually edit generated entities anyway"

This applies to creating new entities as well as adapting old ones. Ie. Once you use an AttributeOverride anywhere in your project, you then cannot use generate:entities anywhere else.

Comment by Marco Pivetta [ 19/Aug/14 ]

Andy Waterman yes, and you are supposed to avoid the generator after the first run.

Comment by Andy Waterman [ 20/Aug/14 ]

You really cannot use the generate:entities command to generate method stubs in ANY of your entities or new entities after the first time you run it??

If this use case works as designed without AttributeOverride in the project, but not with AttributeOverrides, then it's a bug not us doing it wrong.

Comment by Cliff Odijk [ 20/Aug/14 ]

I agree with Andy Waterman that this is a bug if it works al the time and not when you use AttributeOverrides.

Now we just temporary remove the AttributeOverrides and then generate our stubs.

Comment by Cliff Odijk [ 12/Sep/14 ]

I tried to debug the issue and found that during the gatering of the class metadata you will get the DisconnectedClassMetadataFactory which gives the StaticReflectionService for the getParentClasses it returns an empty array which should be al the parent classes of an entity. Because of this the mapping information of the parent class does not exists and can't be overwritten.

Comment by Cliff Odijk [ 12/Sep/14 ]

If I implement the following code in the getParentClasses of the StaticReflectionService it work's like a charm

if ( ! class_exists($class)) {
            throw MappingException::nonExistingClass($class);
        }

        return class_parents($class);
Comment by Enrico Schultz [ 27/Jan/15 ]

This bug has been fixed by fixing DDC-1379. If you use protected variables in your base class, the schema is created correctly and the entity generator also does not generate properties twice. When using Symfony2, just set "doctrine/orm" to "2.4@dev" in "composer.json" or wait for an upcoming release.





[DDC-3545] Persist new object failed when it works with optimistic lock Created: 27/Jan/15  Updated: 27/Jan/15

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

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

PHP 5.5



 Description   

When I was trying to persist a new object, Doctrine reported a exception:

An exception occurred while executing 'SELECT version FROM wallet WHERE user_id = ?' with params [{}]:

Catchable Fatal Error: Object of class XXXBundle\Entity\User could not be converted to string in /Users/XXX/WebSite/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php line 91

From the stack trace information, I found the original exception is:

Catchable Fatal Error: Object of class XXXBundle\Entity\User could not be converted to string

The reason is that the entity Wallet has a OneToOne mapping to entity User, and user property is also marked as primary key. When the wallet object persists, Doctrine try to fetch the new version id and use user property to find object. But Doctrine doesn't handle the primary key is an object, not a basic type. So PDO can't use a object as a query parameter.

My Entity:

class Wallet
{
    /**
     * ID
     * @var User
     *
     * @ORM\Id
     * @ORM\OneToOne(targetEntity="XXXBundle\Entity\User")
     * @ORM\JoinColumn(name="user_id", referencedColumnName="id")
     */
    private $user;

    /**
     * @var int
     *
     * @ORM\Version()
     * @ORM\Column(name="version", type="integer")
     */
    private $version;
}

I hope Doctrine team can solve this problem. My temporary solution is to override __toString method in User object. It is not elegant, doesn't it?



 Comments   
Comment by Marco Pivetta [ 27/Jan/15 ]

What exact version of the ORM is affected? Is master also behaving like this?

Comment by Max Liu [ 27/Jan/15 ]

It works well before I add version field. I didn't try with master version.





[DDC-3343] `PersistentCollection::removeElement` schedules an entity for deletion when relationship is EXTRA_LAZY, with `orphanRemoval` false. Created: 09/Oct/14  Updated: 27/Jan/15  Resolved: 25/Jan/15

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

Type: Bug Priority: Blocker
Reporter: Andrea Sprega Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: mapping, orm

Issue Links:
Dependency
depends on DDC-3536 [GH-1281] Hotfix/#1169 extra lazy one... Resolved
depends on DDC-3544 [GH-1288] Hotfix - #1169 - extra lazy... Resolved
depends on DDC-3537 [GH-1282] Hotfix/#1169 extra lazy one... Resolved

 Description   

Given the following entity for which I only report the relevant association:

class Group
{
    /**
     * @ORM\OneToMany(targetEntity="User", mappedBy="group", fetch="EXTRA_LAZY")
     */
    protected $users;
    //...
}

and its inverse

class User
{
    /**
     * @ORM\ManyToOne(targetEntity="Group", inversedBy="users")
     * @ORM\JoinColumn(name="group_id", onDelete="SET NULL")
     */
    protected $group;
    //...
}

I experience a weird issue when, inside Group, I call $this->users->removeElement($user): Doctrine schedules the $user entity for deletion, no matter what (it doesn't check for the orphanRemoval attribute). Also, even re-adding the entity to a new Group before the flush() occurs doesn't prevent it from being deleted.

I believe this is a bug, since I do not see any special mention of this behavior in the documentation for extra lazy associations:
http://doctrine-orm.readthedocs.org/en/latest/tutorials/extra-lazy-associations.html.

The workaround for me has been to remove fetch="EXTRA_LAZY" from the relationship.

After digging a little bit into the source code, this seems to be the commit (and the line) that introduced this behavior:

https://github.com/doctrine/doctrine2/commit/356f5874bf81ca4e37681c233e24cc84d16e7a39#diff-108586f774fc8acb02163ed709e05e86R403

I also found this on Google:

https://groups.google.com/forum/#!topic/doctrine-user/cx_yBuoqiAE

which basically didn't help much, except for suggesting that it should be a feature when there is an orphanRemoval and/or a cascade operation in place (and that makes perfectly sense).

I set this to "critical" since (as it occurred to me) it can lead to irrecoverable data loss.

Is this effectively a bug?



 Comments   
Comment by Marco Pivetta [ 25/Jan/15 ]

Fixed via DDC-3536 and DDC-3537





[DDC-3536] [GH-1281] Hotfix/#1169 extra lazy one to many should not delete referenced entities Created: 24/Jan/15  Updated: 27/Jan/15  Resolved: 25/Jan/15

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

Type: Bug Priority: Blocker
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: delete, extra-lazy, onetomany, update

Issue Links:
Dependency
depends on DDC-3544 [GH-1288] Hotfix - #1169 - extra lazy... Resolved
is required for DDC-3343 `PersistentCollection::removeElement`... Resolved

 Description   

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

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

Message:

This is an alternate fix for #1169 (DDC-3343 http://www.doctrine-project.org/jira/browse/DDC-3343)



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

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

Comment by Doctrine Bot [ 25/Jan/15 ]

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





[DDC-3461] [GH-1229] Identity in onetoone association builder Created: 23/Dec/14  Updated: 26/Jan/15

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

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


 Description   

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

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

Message:



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

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 26/Jan/15 ]

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

Comment by Doctrine Bot [ 26/Jan/15 ]

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





[DDC-3542] [GH-1287] Typo fix Created: 25/Jan/15  Updated: 26/Jan/15  Resolved: 26/Jan/15

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

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


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 26/Jan/15 ]

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

Comment by Doctrine Bot [ 26/Jan/15 ]

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





[DDC-3543] How to map and use a DB View from Doctrine2 Created: 26/Jan/15  Updated: 26/Jan/15  Resolved: 26/Jan/15

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

Type: Bug Priority: Major
Reporter: Reynier Perez Mira Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

I have a view on nomencladores schema called obtenerPaisesPorFabricanteProductoSolicitud. This is the content for the view:

    SELECT
    	ps.id AS psid,
    	ps.nombre,
    	fps.id AS fpsid
    FROM
    	(
    		(
    			nomencladores.pais ps
    			JOIN nomencladores.pais_fabricante_producto_solicitud pfps ON ((pfps.pais_id = ps.id))
    		)
    		JOIN negocio.fabricante_producto_solicitud fps ON (
    			(
    				pfps.fabricante_producto_solicitud_id = fps.id
    			)
    		)
    	);

I'm trying to map the view as follow:

    use Doctrine\ORM\Mapping as ORM;
    
    /**
     * @ORM\Entity
     * @ORM\Table(name="nomencladores.obtenerPaisesPorFabricanteProductoSolicitud", schema="nomencladores")
     */
    class ObtenerPaisesPorFabricanteProductoSolicitud
    {
        /**
         * @ORM\Id
         * @ORM\Column(name="psid", type="integer", nullable=false, unique=true)
         */
        protected $ps;
    
        /**
         * @ORM\Column(name="fpsid", type="integer")
         */
        protected $fps;
    
        /**
         * @ORM\Column(name="nombre", type="string")
         */
        protected $nombre;
    
        public function getPs()
        {
            return $this->ps;
        }
    
        public function getFps()
        {
            return $this->fps;
        }
    
        public function getNombre()
        {
            return $this->nombre;
        }
    }

But any time I run this code on it:

    $ent = $em->getRepository("AppBundle:ObtenerPaisesPorFabricanteProductoSolicitud")->findBy(
        array(
            "fps" => $entF->getId()
        )
    );

I got this result:

An exception occurred while executing 'SELECT t0.psid AS psid1,
t0.fpsid AS fpsid2, t0.nombre AS nombre3 FROM
nomencladores.obtenerPaisesPorFabricanteProductoSolicitud t0 WHERE
t0.fpsid = ?' with params [22]:
SQLSTATE[42P01]: Undefined table: 7 ERROR: relation "nomencladores.obtenerpaisesporfabricanteproductosolicitud" does not
exist LINE 1: ...d1, t0.fpsid AS fpsid2, t0.nombre AS nombre3 FROM
nomenclado...

If I remove the annotations then the error transform on this:

Class "AppBundle\Entity\ObtenerPaisesPorFabricanteProductoSolicitud" is not a valid entity or mapped super class."

Why Doctrine2 or Symfony tries to execute the query instead go through the view? How I can execute the view from Symfony2/Doctrine2 side?



 Comments   
Comment by Marco Pivetta [ 26/Jan/15 ]

Nothing wrong here: the SQL generated by the ORM is correct, but your view definition is wrong: try running the select in console, manually.





Generated at Sun Feb 01 19:59:06 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.