[DDC-2726] EventSubscriber PreUpdate Error Bug? Created: 06/Oct/13  Updated: 29/Sep/14

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: Nelson Ford Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: orm

Attachments: PNG File caca.png    

 Description   

Should this:

public function preUpdate(PreUpdateEventArgs $eventArgs)
{
    $entity = $eventArgs->getEntity();
    $em = $eventArgs->getEntityManager();
    $uow = $em->getUnitOfWork();

    if ($entity instanceof User) {
        if ($eventArgs->hasChangedField('finalStatus')) {
            $entity->setFinalStatusDate(new \DateTime('now'));
            $uow->recomputeSingleEntityChangeSet(
                $em->getClassMetadata("MyAdminBundle:User"),
                $entity
            );
        }
        if ($eventArgs->hasChangedField('membershipCode')) {
            $entity->setMembershipCodeDate(new \DateTime('now'));
            $uow->recomputeSingleEntityChangeSet(
                $em->getClassMetadata("MyAdminBundle:User"),
                $entity
            );
        }
    }
}

...result in this?

Catchable Fatal Error: Argument 3 passed to Doctrine\ORM\Event\PreUpdateEventArgs::__construct() must be an array, null given, called in /var/www/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php on line 995 and defined in /var/www/vendor/doctrine/orm/lib/Doctrine/ORM/Event/PreUpdateEventArgs.php line 47

I'm just setting a time stamp for two updated values. Dumping the 3rd argument in PreUpdateEventArgs.php on line 47 reveals an array of changes. I'm not sure if this is a bug or if I'm performing this simple operation incorrectly.



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

Can you write an integration test around it? Looks like the changeset is removed in a particular edge case, but it's hard to figure it out without a test.

Comment by Florin [ 29/Sep/14 ]

here, solve it





[DDC-3331] DQL parsing fail when using COUNT with "Simple Derived Identity" primary key Created: 29/Sep/14  Updated: 29/Sep/14

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

Type: Bug Priority: Major
Reporter: Mickael Zhu Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: bidirectional, count, onetoone, parser
Environment:

Mac osx Maverick
PHP 5.5.13
Nginx 1.6.0
Mysql 5.6.19



 Description   
Member.php

namespace DoctrineOrmTest\Assets\Entity;

use Doctrine\ORM\Mapping as ORM;

/**
 * @ORM\Entity
 * @ORM\Table(name="member")
 */
class Member
{
    /**
     * @ORM\Id
     * @ORM\Column(type="integer");
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;

    /**
     * @ORM\Column(type="string", nullable=true)
     */
    protected $name;

    /**
     * @var Student
     *
     * @ORM\OneToOne(targetEntity="DoctrineOrmTest\Assets\Entity\Student", mappedBy="member")
     */
    protected $student;

}

Student.php

namespace DoctrineOrmTest\Assets\Entity;

use Doctrine\ORM\Mapping as ORM;

/**
 * @ORM\Entity
 * @ORM\Table(name="student")
 */
class Student
{
    /**
     * @var Member
     *
     * @ORM\Id
     * @ORM\OneToOne(targetEntity="DoctrineOrmTest\Assets\Entity\Member")
     * @ORM\JoinColumn(name="id", referencedColumnName="id", nullable=false)
     */
    private $member;
}

When I use a oneToOne relation as primary key, the following dql request fail :

SELECT COUNT(a) FROM DoctrineOrmTest\Assets\Entity\Student a

I have the following message :

[Semantical Error] line 0, col 13 near 'a) FROM DoctrineOrmTest\Assets\Entity\Student': Error: Invalid PathExpression. Must be a StateFieldPathExpression

I can fix it with this workaround

SELECT COUNT(a.member) FROM DoctrineOrmTest\Assets\Entity\Student a

But it mess with one of my auto-generation script.






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

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

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

Ubuntu 12.04, PHP 5.5.3


Attachments: File DDC3330Test.php    

 Description   

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

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

See the failing unit test I joined to this ticket.






[DDC-3329] Comment on clumn is passed when creating self-reference association Created: 28/Sep/14  Updated: 28/Sep/14

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

Type: Bug Priority: Minor
Reporter: Steve Todorov Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm
Environment:

PostgreSQL 9.1, possibly other databases as well.



 Description   

The example below will pass the comment from the column group_id to parent_id. Unfortunately that is not what I would like because the comment would confuse that parent_id has the same purpose as group_id which is not the case.

Group.php
class Group {

    /**
     * @var integer
     *
     * @ORM\Id
     * @ORM\Column(name="group_id", type="integer", options={"comment" = "This column is a relation to atable.z, btable.y, rtable.k, or whatever long comment we have here."})
     * @ORM\GeneratedValue(strategy="IDENTITY")
     */
    private $id;

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

    /**
     * @var integer
     *
     * @ORM\JoinColumn(name="parent_id", referencedColumnName="group_id", nullable=true)
     * @ORM\ManyToOne(targetEntity="Acme\MyBundle\Entity\Group")
     */
    private $parent;

    /**
     * Get id
     *
     * @return integer
     */
    public function getId() {
        return $this->id;
    }

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

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

        return $this;
    }

    /**
     * Get parent
     *
     * @return Group
     */
    public function getParent() {
        return $this->parent;
    }

    /**
     * Set parent
     *
     * @param Group $parent
     *
     * @return Group
     */
    public function setParent( Group $parent ) {
        $this->parent = $parent;

        return $this;
    }
}





[DDC-3328] [GH-1150] Improve Comparison::CONTAINS: allow to use custom position for % and _ wildcard characters Created: 28/Sep/14  Updated: 28/Sep/14

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

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


 Description   

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

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

Message:

This pull prevent forced wrapping of the value in to `%`
and allow to use the custom position for `%` and `_` wildcard characters in case `Comparison::CONTAINS`

Allow to build the `contains` expressions like:
```php
Criteria::expr()->contains('myField', 'some string%');
Criteria::expr()->contains('myField', '%some string');
Criteria::expr()->contains('myField', '10%');
Criteria::expr()->contains('myField', 's_m_ string');
```






[DDC-3326] [GH-1148] [DWEB-118] Fixed small typo in documentation about extra lazy associations Created: 26/Sep/14  Updated: 27/Sep/14

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

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


 Description   

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

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

Message:

Fixed small documentation issue http://www.doctrine-project.org/jira/browse/DWEB-118



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

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





[DDC-3327] [GH-1149] Update Composite.php for HHVM compatibility Created: 26/Sep/14  Updated: 26/Sep/14

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

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


 Description   

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

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

Message:

Not sure, why this issue is not founded in unittests, but I got HHVM crushed with message
```
Fatal error: Stack overflow in ...../vendor/doctrine/orm/lib/Doctrine/ORM/Query/Expr/Composite.php on line 58
```
The same issue is being reported here
https://github.com/facebook/hhvm/issues/1747

@LinuxDoku proposed quick patch, which works great for me and its in this PR.

Just in case, if you wonder what trigger this error - here is my repository function, which trigger it
```
public function findOpenTeamTimeEntry($user)
{
$r = $this->createQueryBuilder("t")
->join("t.owner","u")
->where("t.dateEnd IS NULL")
->andWhere("u.id = :user_id")
>setParameter(":user_id",$user>getId())
->getQuery()
->getResult();
if(is_array($r) && count($r))

{ return $r[0]; }

else

{ return false; }

}
```






[DDC-3325] No exception thrown when passing invalid option to mapXToY() in ClassMetadataInfo Created: 25/Sep/14  Updated: 25/Sep/14

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

Type: Bug Priority: Minor
Reporter: Thomas Konrad Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mapping, orm
Environment:

Symfony2, Windows 7, PHP 5.4



 Description   

I recently ran into the problem that I wrongly specified the `joinColumn` option passed to the method `mapManyToOne` in the `ClassMetadataInfo` class:

    $metadata->mapManyToOne(array(
        // ...
        'joinColumn'   => array(
            'name' => 'column_id',
        )
    ));

This would be the intuitive way to define that mapping, as with Annotations it is also called `JoinColumn` (but yeah I know, there could possibly be multiple `JoinColumn` definitions). The right way to do it is:

    $metadata->mapManyToOne(array(
        // ...
        'joinColumns'   => array(array(
            'name' => 'column_id',
        ))
    ));

The actual bad experience that I had as a developer here is that no exception was through even though I had definitely passed a wrong configuration option to the mapping function. In fact, nothing happended, the `joinColumn` option was just ignored. It would be great in this case if an exception would be thrown so that it is clear to the developer that there is something wrong.

Thanks!






[DDC-3324] [GH-1147] Extended the docs for mapping attributes precision and scale Created: 25/Sep/14  Updated: 25/Sep/14

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

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


 Description   

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

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

Message:

I for myself am always confused about precision and scale and have to lookup what is the numer of maximum digits and what is the number for digits right of the decimal point. Other people seem to have the same [problem](http://stackoverflow.com/questions/14940574/what-do-scale-and-precision-mean-when-specifying-a-decimal-field-type-in-doctrin).

So I have extended the docs to make it more clear.






[DDC-3323] Add user managed parameters bag to UnitOfWork Created: 24/Sep/14  Updated: 24/Sep/14

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

Type: Improvement Priority: Trivial
Reporter: Krzysztof Lechowski Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

User Story:
1. User has Article:Tags entities.
2. There is sort order attribute of a tag.
3. after any tag is removed, sort orders should be recalculated.

The intuitive place for it is postRemove, but technically we don't want to do any flushes in LifeCycle event. Below suggested solution is pass the handling of sort orders update to postFlush. For this sake postFlush needs to receive information from postRemove.

No global state is good idea I have 2 candidates:
1. Passet around event args
2. Unit of Work.

I'd prefer UnitOfWork because it's of more general use and more logical. This kind of information is unit-of-work context related. I'd like to call $unitOfWork->setParam('param_name', $value); and $unitOfWork->getParam('param_name');

Another person who stumbled upon the same situation, not sure how he handled it:

http://stackoverflow.com/questions/13095083/symfony2-doctrine2-throwing-index-error-when-flushing-the-entity-manager#answer-16701360






[DDC-3322] [GH-1146] Allow orderBy to reference associations Created: 23/Sep/14  Updated: 23/Sep/14

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

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


 Description   

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

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

Message:

If I specify an order-by clause on a to-many association, e.g. `@OrderBy(

{"foo" = "ASC"}

)`, where foo is a to-one-association on the target entity, the collection is sorted by foo_id (this behaviour is implemented in BasicEntityPersister::getOrderBySQL()).

This works fine. However, Doctrine\ORM\Tools\SchemaValidator complains that foo is not a field.

This change makes the validator accept order-by clauses on associations where the target entity is the owning side, and the association is single-valued (AFAICT this is the same restrictions that BasicEntityPersister uses).






[DDC-3287] PreUpdateEventArgs need to extend Doctrine\Common\PreUpdateEventArgs Created: 29/Aug/14  Updated: 23/Sep/14

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

Type: Improvement Priority: Trivial
Reporter: Sebastian Kuhlmann Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: inheritance, orm


 Description   

Currently the inheritance tree of the EventArgs don't allow for creating event listeners that fit both ORM- and MongoDB-driven applications.

Doctrine\Common defines base classes for Lifecycle event arguments. Doctrine\ORM uses the common library and extends it's classes. So does MongoDB. If you wanted to write something that suits both ORM and MongoDB you should be able to rely on the Common-implementations.

The provided classes to extend:

  • Doctrine\Common\Persistence\Event\LifecycleEventArgs
  • Doctrine\Common\Persistence\Event\LoadClassMetadataEventArgs
  • Doctrine\Common\Persistence\Event\ManagerEventArgs
  • Doctrine\Common\Persistence\Event\OnClearEventArgs
  • Doctrine\Common\Persistence\Event\PreUpdateEventArgs

Checking the Github repository there is no common ground for the inheritance mechanism.

  • Doctrine\ORM\Event\LifecycleEventArgs extends Doctrine\Common\Persistence\Event\LifecycleEventArgs
  • Doctrine\ORM\Event\PreUpdateEventArgs extends Doctrine\ORM\Event\LifecycleEventArgs
  • Doctrine\ORM\Event\PreFlushEventArgs extends Doctrine\Common\EventArgs
  • Doctrine\ORM\Event\PostFlushEventArgs extends Doctrine\Common\EventArgs
  • Doctrine\ORM\Event\OnFlushEventArgs extends Doctrine\Common\EventArgs
  • Doctrine\ORM\Event\OnClearEventArgs extends Doctrine\Common\EventArgs

This needs to change and ORM\PreUpdateEventArgs as well as ORM\OnClearEventArgs need to extend the respective events from Doctrine\Common.



 Comments   
Comment by Sebastian Kuhlmann [ 23/Sep/14 ]

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





[DDC-3320] [GH-1144] [DDC-3287] Change parent classes of some Events Created: 23/Sep/14  Updated: 23/Sep/14

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

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


 Description   

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

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

Message:

Following my <a href="http://doctrine-project.org/jira/browse/DDC-3287">issue report</a> in Jira find attached the necessary changes.






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

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: 0
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?






[DDC-3314] Error with AttributeOverride when upgrading schema Created: 19/Sep/14  Updated: 23/Sep/14

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

Type: Bug Priority: Major
Reporter: JB Blanchon Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: orm


 Description   

I want to override an attribute from FOSuserBundle:User class with annotations.

My class extends BaseUser

SiteCustomer.php
class SiteCustomer extends BaseUser

My use statement is like this

SiteCustomer.php
use FOS\UserBundle\Model\User as BaseUser;

When I put the annotations on my entity

SiteCustomer.php
 /*
 * @ORM\AttributeOverrides({
 *     @ORM\AttributeOverride(name="emailCanonical",
 *         column=@ORM\Column(
 *             name="email_canonical",
 *             type="string",
 *             length=255,
 *             unique=false
 *         )
 *     )
 * })
 */

I get this error message :


MappingException: Invalid field override named 'emailCanonical' for class SiteCustomer.

I got the same error message, for usernameCanonical.
I need to override this field in order to remove the uniqness of the field
I use Doctrine v2.4.4 what is wrong with my annotation ? Why do I get this error when trying to upgrade my schema

Thank you



 Comments   
Comment by Marco Pivetta [ 22/Sep/14 ]

Did you try reaching where the exception is thrown? It typically says more about the specific failure.

Comment by JB Blanchon [ 23/Sep/14 ]
Stack Trace 1
  */
    public static function invalidOverrideFieldName($className, $fieldName)
    {
        return new self("Invalid field override named '$fieldName' for class '$className'.");
    }
    /**
[1] Doctrine\ORM\Mapping\MappingException: Invalid field override named 'emailCanonical' for class 'Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer'.
    at n/a
        in /home/jaybe/www/yProx/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/MappingException.php line 129

    at Doctrine\ORM\Mapping\MappingException::invalidOverrideFieldName('Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer', 'emailCanonical')
        in /home/jaybe/www/yProx/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php line 2032

    at Doctrine\ORM\Mapping\ClassMetadataInfo->setAttributeOverride('emailCanonical', array('fieldName' => 'emailCanonical', 'type' => 'string', 'scale' => '0', 'length' => '255', 'unique' => false, 'nullable' => false, 'precision' => '0', 'columnName' => 'email_canonical'))
        in /home/jaybe/www/yProx/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/Driver/AnnotationDriver.php line 415

    at Doctrine\ORM\Mapping\Driver\AnnotationDriver->loadMetadataForClass('Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer', object(ClassMetadata))
        in /home/jaybe/www/yProx/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/Driver/MappingDriverChain.php line 103

    at Doctrine\Common\Persistence\Mapping\Driver\MappingDriverChain->loadMetadataForClass('Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer', object(ClassMetadata))
        in /home/jaybe/www/yProx/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php line 117

    at Doctrine\ORM\Mapping\ClassMetadataFactory->doLoadMetadata(object(ClassMetadata), object(ClassMetadata), true, array('Ylly\CrmBundle\Entity\User'))
        in /home/jaybe/www/yProx/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php line 318

    at Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->loadMetadata('Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer')
        in /home/jaybe/www/yProx/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php line 211

    at Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->getMetadataFor('Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer')
        in /home/jaybe/www/yProx/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php line 295

    at Doctrine\ORM\EntityManager->getClassMetadata('Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer')
        in /home/jaybe/www/yProx/vendor/doctrine/orm/lib/Doctrine/ORM/Repository/DefaultRepositoryFactory.php line 67

    at Doctrine\ORM\Repository\DefaultRepositoryFactory->createRepository(object(EntityManager), 'Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer')
        in /home/jaybe/www/yProx/vendor/doctrine/orm/lib/Doctrine/ORM/Repository/DefaultRepositoryFactory.php line 50

    at Doctrine\ORM\Repository\DefaultRepositoryFactory->getRepository(object(EntityManager), 'Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer')
        in /home/jaybe/www/yProx/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php line 759

    at Doctrine\ORM\EntityManager->getRepository('Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer')
        in /home/jaybe/www/yProx/src/Ylly/CmsBundle/Controller/CmsBaseController.php line 93

    at Ylly\CmsBundle\Controller\CmsBaseController->getRepo('Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer')
        in /home/jaybe/www/yProx/src/Ylly/Extension/SiteCustomerBundle/Controller/AdminController.php line 79

    at Ylly\Extension\SiteCustomerBundle\Controller\AdminController->getSiteCustomerRepo()
        in /home/jaybe/www/yProx/src/Ylly/Extension/SiteCustomerBundle/Controller/AdminController.php line 15

    at Ylly\Extension\SiteCustomerBundle\Controller\AdminController->indexAction()
        in  line 

    at call_user_func_array(array(object(AdminController), 'indexAction'), array())
        in /home/jaybe/www/yProx/apps/bootstrap.php.cache line 2952

    at Symfony\Component\HttpKernel\HttpKernel->handleRaw(object(Request), '1')
        in /home/jaybe/www/yProx/apps/bootstrap.php.cache line 2924

    at Symfony\Component\HttpKernel\HttpKernel->handle(object(Request), '1', true)
        in /home/jaybe/www/yProx/apps/bootstrap.php.cache line 3063

    at Symfony\Component\HttpKernel\DependencyInjection\ContainerAwareHttpKernel->handle(object(Request), '1', true)
        in /home/jaybe/www/yProx/apps/bootstrap.php.cache line 2331

    at Symfony\Component\HttpKernel\Kernel->handle(object(Request))
        in /home/jaybe/www/yProx/web/admin_dev.php line 14

Here is the stack trace of my error.
If this is not what you need, tell me what do you want and how to get it.
Thank you.





[DDC-3318] [GH-1143] Fixed a bug so that a versioned entity with a oneToOne id can be created Created: 23/Sep/14  Updated: 23/Sep/14

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

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


 Description   

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

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

Message:

  • Fixed the basic entity persister so that versioned OneToOne entities can be created
  • Created an IdentifierConverter utility class
  • Moved the logic for the flatten identifier method into the new utility class
  • Replaced calls for private flattenIdentifier to use new utility
  • Added appropriate unit tests





[DDC-3316] [GH-1141] Always allow proxies on ToOne associations Created: 22/Sep/14  Updated: 22/Sep/14

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

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


 Description   

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

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

Message:

Hi!
This patch combined with https://github.com/doctrine/common/pull/338 will allow to have proxies for long chains of ToOne associations:

```
User

{ private $id; // @id private $city; private $name; }

City

{ private $id; // @id private $region; // @id private $name; }

Region

{ private $id; // @id private $country; // @id private $name; }

Country

{ private $id; // @id private $name; }

```

```php
$user = $repo->find(1);

// the current implementation must load the city, region
$user->getCity()>getRegion()>getCountry();
// the current implementation must load the city, region and the country
$user->getCity()>getRegion()>getCountry()->getName();

//with this patch
// here no queries will be executed
$user->getCity()>getRegion()>getCountry();
// here only will be loaded
$user->getCity()>getRegion()>getCountry()->getName();
```
Of course this patch will require some unit test, but can be acceptable as idea?






[DDC-3311] Add ESCAPE clause support after LIKE pattern, in Expr class Created: 17/Sep/14  Updated: 20/Sep/14

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

Type: Improvement Priority: Minor
Reporter: Vincent Bories-Azeau Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Actually, it is not possible to specify an ESCAPE character in a LIKE clause.
The Expr::like method only takes two arguments, and an optional third one shall be added.
Behaviour in common databases shall be checked, but I guess ESCAPE belongs to the ISO specification



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

Can you add a few usage examples? What APIs are affected?

Comment by Vincent Bories-Azeau [ 20/Sep/14 ]

Sorry, I don't understand what kind of information you're missing.
The API is the Doctrine\ORM\Query\Expr class, in the ORM.
The need is to improve the like method by addind a third optional parameter, that would allow to push an escape character, which seems to me "standard" SQL.
See LIKE specs in vendors documentation, for usage examples:

Comment by Marco Pivetta [ 20/Sep/14 ]

Vincent Bories-Azeau this is exactly what the kind of feedback I was asking for. As of http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/dql-doctrine-query-language.html#ebnf, the ESCAPE char is actually supported:

LikeExpression           ::= StringExpression ["NOT"] "LIKE" StringPrimary ["ESCAPE" char]

I suppose it just needs to be added to the query builder.

Comment by Vincent Bories-Azeau [ 20/Sep/14 ]

Sure, that's it , using direct DQL for requests, it is possible to write such conditions. However, as you notice it, using the QueryBuilder and the Expr methods, it is not possible to generate such queries. Thanks Marco!





[DDC-3315] [GH-1140] [DDC-2704] merge throughout entity hierarchy Created: 19/Sep/14  Updated: 19/Sep/14

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

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


 Description   

This issue is created automatically through a Github pull request on behalf of tiger-seo:

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

Message:






[DDC-3313] [GH-1139] Single entity flush Created: 18/Sep/14  Updated: 18/Sep/14

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

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


 Description   

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

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

Message:

The current `flush` behavior seems to be inconsistent or not well documented.






[DDC-3224] getResult(HYDRATE_OBJECT) with joined query is returning reduced number of rows Created: 23/Jul/14  Updated: 17/Sep/14

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

Type: Bug Priority: Major
Reporter: gondo Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm
Environment:

osx, PHP-FPM 5.5.13, nginx/1.6.0, mysql 5.6.19 Homebrew



 Description   

given that i have these 2 entities (pseodocode):

/**
 * @ORM\Table(name="entity1", options={"collate"="utf8_unicode_ci", "charset"="utf8"})
 * @ORM\Entity(repositoryClass="Entity1Repository")
 */
class Entity1 {
    /**
     * @var integer
     * @ORM\Column(name="id", type="integer")
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;

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

    /**
     * @var Entity2[]
     * @ORM\OneToMany(targetEntity="Entity2", mappedBy="entity1")
     */
    protected $entity2;
}

/**
 * @ORM\Table(name="entity2", options={"collate"="utf8_unicode_ci", "charset"="utf8"})
 * @ORM\Entity()
 */
class Entity2 {
    /**
     * @var integer
     * @ORM\Column(name="id", type="integer")
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;

    /**
     * @var \DateTime
     * @ORM\Column(name="date", type="datetime")
     */
    protected $date;

    /**
     * @var Entity1
     * @ORM\ManyToOne(targetEntity="Entity1", inversedBy="entity2", fetch="EAGER")
     */
    protected $entity1;
}

tables and data

entity1:

id name
1 Jhon
2 Clare

entity2:

id date entity1_id
1 2011-01-01 00:00:01 1
2 2012-02-02 00:00:02 1
3 2013-03-03 00:00:03 2
4 2014-04-04 00:00:04 2

my query builder

use Doctrine\ORM\EntityRepository;

class Entity1Repository extends EntityRepository
{
    public function getData()
    {
        $qb = $this
            ->createQueryBuilder('Entity1')
            ->select('Entity1, Entity2.date')
            ->join('Entity1.entity2', 'Entity2', Join::WITH, 'Entity2.date > :date')
            ->setParameter('date', '2000-01-01 00:00:01')
        ;
        $result1 = $qb->getQuery()->getArrayResult(); // HYDRATE_ARRAY
        $result = $qb->getQuery()->getResult(); // HYDRATE_OBJECT
        
//        return $result1;
//        return $result2;
    }
}

proper result is this:

id name date
1 Jhon 2011-01-01 00:00:01
1 Jhon 2012-02-02 00:00:02
2 Clare 2013-03-03 00:00:03
2 Clare 2014-04-04 00:00:04

what is happening

$result1 = $qb->getQuery()->getArrayResult(); // HYDRATE_ARRAY

is really returning proper number of rows

BUT and here comes the BUG finally:

$result2 = $qb->getQuery()->getResult(); // HYDRATE_OBJECT

is returning just 2 rows:

id name date
1 Jhon 2011-01-01 00:00:01
2 Clare 2013-03-03 00:00:03

this is because somehow entities are made unique.

my workaround

as a workaround, what i have to do is, to exectute 2 queries. 1st to get just Entity1.ids joined with Entity2.dates by using `getArrayResult()`
and second query to get Entity1 objeces by unique ids from 1st query.
and than manualy join those results in php.



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

I see that you are using Join::WITH, but not providing a conditional in the example. Are you filtering a fetch-joined association?

Comment by gondo [ 23/Jul/14 ]

sorry i've tried to simplify my structure as much as it was possible, there are actually real conditions, one of them is date condition (among many others). i've updated my code

Comment by Marco Pivetta [ 23/Jul/14 ]

There are still some inconsistencies in the issue - where is that query parameter used, for example?

Comment by gondo [ 23/Jul/14 ]

im using it in EntityRepository (sorry, didnt know thats important) i ll update my code
and the whole code is in Symfony2 project (web and command line applications)

Comment by Marco Pivetta [ 23/Jul/14 ]

What I mean is that in

->setParameter('date', new \DateTime('last month'))

, parameter :date does not exist in the DQL.

Comment by gondo [ 23/Jul/14 ]

i see, sorry its part of JOIN condition, i've updated the code





[DDC-3310] [GH-1138] Join column index names Created: 15/Sep/14  Updated: 15/Sep/14

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

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


 Description   

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

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

Message:

@Ocramius recommended I open this up to discuss the issue I am seeing.

I am trying to explicitly name the index on a column which is used in a join. I've attempted to add two functional tests in this PR to demonstrate what I am seeing. Please forgive me if these tests are not correctly, this is the first time I've attempted to submit a PR like this.

There are two situations I am encountering...

First, I explicitly name the index in the ```@Table``` annotation on the column used in the join - but the SQL generated from ```SchemaTool``` appears to be a random hash.

Second, when I have an existing database table with an existing index and it's named properly (in this example, idx_maker_id) and then I run ```SchemaTool->updateSchema()``` it drops the index with the proper name and creates a new randomly hashed name.

Is there a different way of accomplishing what I am trying to do here, or is this a bug?

Thanks for your help and assistance!






[DDC-2406] Merging of new detached entities with PrePersist lifecycle callback breaks Created: 19/Apr/13  Updated: 14/Sep/14

Status: Awaiting Feedback
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: 1
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.
But overall, should $em->detach() trigger @PrePersist events ?

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?

Comment by Cory Close [ 28/Nov/13 ]

I can confirm that this bug has not been fixed while using doctrine 2.4

Exactly as Oleg Namaka has described, my organization is trying to use @PrePersist callbacks to enforce validation on new entities.

However, we use an extensive client side framework that sends json back to our server. Our workflow is then:

deserializeJson into detached entity
merge detached entity to get it managed (this will apply our edits to an existing entity, or create a new one if this one is new)
persist

However, some entities run into the above problem while using this workflow, so our validation is not run. I can provide more code samples if required.

Comment by Oleg Namaka [ 29/Apr/14 ]

Whose feedback is it awaiting for?

Comment by Romaric Drigon [ 30/May/14 ]

I can confirm this issue.

My use case (which I guess is pretty standard):

  • I deserialize a new entity (with relationships to already existing ones)
  • I merge it to attach existing entities
  • I persist it

PrePersist is called on an entity with all properties set to null. Any modifications made inside this entity won't be saved to the DB.

Comment by Cory Close [ 30/May/14 ]

Is there any reason the proposed solution can't be implemented? I've patched a local version of Doctrine with the proposed changes and ran it through my application's tests without any issues, so I believe this would fix the problem.

Comment by Chris Johnson [ 14/Sep/14 ]

+ on this one. I also have a similar situation where I get a detached entity from an API and use merge to update any changed elements. Obviously there is a workaround (trigger the lifecycle's function manually), but would be great not to have to do this.





[DDC-3308] Cross platform support for DQL "WHERE ... IN" with multiple fields/columns Created: 13/Sep/14  Updated: 14/Sep/14

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

Type: New Feature Priority: Minor
Reporter: Markus Wößner Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dql, mysql, sqlite


 Description   

DQL does not support "WHERE ... IN" statements which refer to more than one field.

Example: While

... WHERE e.id IN (1, 2) ...

is valid DQL

... WHERE (e.id, e.name) IN ((1, "amy"), (2, "fred")) ...

is not.

This was discussed some years ago here https://groups.google.com/forum/#!msg/doctrine-user/bE9RfiF4ZGk/vaiEvsX5_rwJ and it appears that it is not SQL-99. Sqlite does not support it, MySQL does.

As http://sqlfiddle.com/#!7/6169b/1 shows it is not a big deal to transform such a query into an equal query which prevents the usage of "WHERE ... IN" constraints at all. I guess the case "pair(a,b) is not unique" can be safely ignored if redundant pairs are skipped on temp table insertion.



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

This looks everything but trivial to me, especially considering that it introduces usage of UNION, which we also do not support because of portability rules.

Comment by Markus Wößner [ 14/Sep/14 ]

As far as I understand the UNION statement would only be needed when doing an "inline table" approach.

Isn't it a usual technique in Doctrine "AST to SQL output walking" to write temp tables?

Comment by Marco Pivetta [ 14/Sep/14 ]

Yes, we use subqueries in a lot of places, but the paginator walkers are already a real mess from a maintenance PoV, so I don't think we want to go down that route.





[DDC-1756] Allow for master table only models on joined subclass inheritance Created: 03/Apr/12  Updated: 13/Sep/14

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

Type: Improvement Priority: Major
Reporter: Markus Wößner Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Think of a joined subclass inheritance setup where abstract base class A has many concrete child classes C1 ... CN. For each child class a table necessarily has to created. Yet if there are many child classes not defining any additional fields you will get many "id only" child tables. This leads to unnecessary join and insert overhead on database operations as well as a bunch of quite senseless tables in your schema that need to be maintained.

While there are already tickets requesting support for mixed inheritance mapping (e.g. DDC-138) I want to propose another - obviously easy to implement - solution that addresses the "id only table" problem. The basic idea is to extend ClassMetadata by a flag "hasOwnTable" which is true by default and applicable for child classes of a joined subclass tree. Setting this flag to <false> would lead to...
1.) no child table creation for corresponding model
2.) no joins to this table while rendering SQL from DQL statements
3.) no INSERT, UPDATE and DELETE statements for this table in methods executeInserts(), update() and delete() on Doctrine\ORM\Persisters\JoinedSubclassPersister.

(3) can easily be implemented since the mentioned methods all loop on ClassMetadata::parentClasses. For those classes which set the flag "hasOwnTable" to false the operation will be skipped. On the other hand (2) doesn't seem to a big deal either. Extending SqlWalker::_generateClassTableInheritanceJoins() by means of a flag test seems to be enough. Of course setting the flag to <false> while defining additional fields on child class level must be rejected.

If you go for this feature I would be pleased to provide an implementation.






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

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: 7
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);




[DDC-3305] [GH-1133] [Embeddables] Improved exception message Created: 12/Sep/14  Updated: 12/Sep/14

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

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

Message:

Improved exception message when embeddable definition is missing 'class' attribute.
Instead of:
```
The class '' was not found in the chain configured namespaces ...
```
It shows:
```
The embed mapping 'embeddedname' misses the 'class' attribute.
```






[DDC-1817] Allowing to specify MySQL Collation on Field Basis Created: 08/May/12  Updated: 11/Sep/14

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

Type: Improvement Priority: Major
Reporter: Johannes Schmitt Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

It would be nice to be able to specify which collation to use on a field basis.

This would for example be useful when you have case-sensitive (utf8_bin), and case-insensitive (utf8_general_ci) values. Right now, this needs to be manually added to migration files (which is ok for projects, but it is not so nice for distributable libraries).



 Comments   
Comment by Steve Müller [ 26/Nov/13 ]

See the following PRs:

https://github.com/doctrine/dbal/pull/274
https://github.com/doctrine/dbal/pull/245
https://github.com/doctrine/dbal/pull/282

This will be available via column's customSchemaOptions.

Comment by Doctrine Bot [ 11/Feb/14 ]

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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





[DDC-3303] @ORM\Embedded does not work with extending classes Created: 10/Sep/14  Updated: 10/Sep/14

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

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

Linux, Symfony 2.5 ORM 2.5.*@dev
doctrine/annotations = "v1.2.0",



 Description   

I update my symfony 2.5 with ORM 2.5. to try out the Embedded function.
I currently does not work correctly with extending class

/**
 * @ORM\Entity
 * @ORM\Table(name="A", uniqueConstraints={@UniqueConstraint(name="id", columns={"id"})})
 */
class A extends B {}
abstract class Item {

    /**
     * @var $bonus
     * @ORM\Embedded(class="Bonus")
     *
     */
    private $bonus;
}

it only works if i put the definition of the Embedded properties directly in class A ( but it works with all normal properties defined in the Abstract )






[DDC-3007] ManyToMany does not respect all column attributes for the jointable Created: 03/Mar/14  Updated: 10/Sep/14

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

Type: Bug Priority: Major
Reporter: Michael Kühn Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Given following 2 entities:

<?php
class Role {
    /**
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="UUID")
     * @ORM\Column(name="id", type="guid", nullable=false, unique=true, length=36, options={"fixed"=true})
     */
    protected $id;

    /**
     * @ORM\ManyToMany(targetEntity="User", mappedBy="roleList")
     */
    private $userList;
}
<?php
class User {
    /**
     * @ORM\Column(name="id", type="guid", nullable=false, unique=true, length=36, options={"fixed"=true})
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="UUID")
     */
    protected $id;

    /**     *
     * @ORM\ManyToMany(targetEntity="Role", inversedBy="userList")
     * @ORM\JoinTable(name="user_role")
    protected $roleList;
}

It should create a table "user_role" with 2 columns which are CHAR(36).

But it ignores the Column-Attributes and creates a table "user_role" with 2 CHAR(255) columns.

This has various downsides:

  • It's unusable when using MyISAM, because of limited index size. (CREATE TABLE fails, see DBAL-423)
  • If using GUID-Type (see DBAL-423 with the changes from the linked ull request) and specify "length=36" and "fixed=true" on the Column-Annotation, no changes for the entity-tables itself are generated when running orm:schema-tool:update. However, there are still changes for the many-to-many-table generated (because internal "fixed" is false and length is unset) which represent the current state of the columns. These changes are always generated.


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

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





[DDC-3285] \Doctrine\ORM\Event\PreUpdateEventArgs::getOldValue and ::getNewValue return wrong values for ManyToMany association Created: 29/Aug/14  Updated: 10/Sep/14

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

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

Linux 64 bit, PHP 5.4



 Description   

For most entities the $entityChangeSet[$field] contains an array of
[
0 => old_value
1 => new_value
]
however, for ManyToMany associations it contains a \Doctrine\ORM\PersistentCollection with the current (new) value of the association.

The getOldValue function relies on the other behaviour and simply returns $this->entityChangeSet[$field][0] which will be the first element in the PersistentCollection.

The getNewValue function does likewise but with the second element.

I'd be inclined to alter it to check if $entityChangeSet[$field] instanceof PersistentCollection and return the collection for newValue and throw some kind of Exception for oldValue but don't want to send a patch without checking how you guys would like this to react.



 Comments   
Comment by Reuben Thompson [ 29/Aug/14 ]

I guess this might be related to DDC-3033





[DDC-3301] [GH-1131] Use repository class Created: 09/Sep/14  Updated: 09/Sep/14

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

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


 Description   

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

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

Message:

Now we can use custom repository find() method






[DDC-3300] [GH-1130] [WIP] Added resolve entities support in discrim. map Created: 09/Sep/14  Updated: 09/Sep/14

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

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


 Description   

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

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

Message:

This PR is WIP. I just wanted to know if what I am doing is wrong or I can go on with tests and documentation.

This is what happens.

I have nicely the ability to define a relation using just the interfaces, and then, resolve these relations overriding the interfaces with the implementations. This resolves a big problem: Multiple implementations of one interface.

But, when you define a discriminatorMap, you *Must* define it using specific implementations, so all this flexibility gained in the relations is lost at this point.

Using a new listener, its easy to override this interfaces.

What do you think?






[DDC-3298] Persisting one to one not nullable relational entity Created: 08/Sep/14  Updated: 08/Sep/14

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

Type: Bug Priority: Major
Reporter: Bil Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: onetoone, persist
Environment:

Use with Symfony 2.5



 Description   

When having a not nullable onetoone unidirectional relation and trying to persist the parent entityn sql throws this exception : SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'deliveryMode_id' cannot be null.

Scheme is Shop has a deliveryMode :

class Shop{

...

/**

  • @ORM\OneToOne(targetEntity="acme\Bundle\DeliveryBundle\Entity\DeliveryMode", cascade= {"all"}

    , orphanRemoval=true)

  • @ORM\JoinColumn(nullable=false)
  • @Assert\Valid
    */
    private $deliveryMode;
    ...
    }

When I do a :

$shop=new Shop();
$deliveryMode=new DeliveryMode();
$shop->setDeliveryMode($deliveryMode);
...
$entityManager->persist($shop);
$entityManager->flush();

Then, above exception is thrown

BUT: When I put in on a doctrine transaction, it works perfectly, and it also works when I remove the "not nullable" constraint, deliveryMode is perfectly persisted.

It seems to me there a bug with the order of executing the inserts, the deliveryMode should be inserted, then the shop, I think that is not the case






[DDC-3297] Refreshing and locking entities ignores deleted records Created: 07/Sep/14  Updated: 07/Sep/14

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

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


 Description   

If you refresh or lock an entity that has been deleted elsewhere, no exception is thrown, so it appears as if the record still exists.

Example:

    $blogId = 1;

    $em = (get em from somewhere);

    $blog = $em->find('App_Model_Blog', $blogId);

    var_dump($blog->getTitle());

    // This could be part of a separate request or transaction.
    $em->getConnection()->exec(sprintf('DELETE FROM blogs WHERE id = %d', $blogId));

    $stmt = $em->getConnection()->query(sprintf('SELECT * FROM blogs b WHERE b.id = %d', $blogId));

    var_dump($stmt->rowCount() === 0 ? 'DELETED' : 'NOT DELETED');

    //$em->beginTransaction();

    //$em->lock($blog, LockMode::PESSIMISTIC_WRITE);

    //$em->commit();

    $em->refresh($blog);

    var_dump($blog->getTitle());





[DDC-740] Mantain a list of DQL reserved keywords Created: 09/Aug/10  Updated: 05/Sep/14

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

Type: Improvement Priority: Minor
Reporter: Guilherme Blanco Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 1
Labels: None


 Description   

We should keep a list of DQ reserved keywords, so users can check out what they can use or not.



 Comments   
Comment by Manasi [ 07/Aug/13 ]

Here is the list of reserved keywords for MySQL: http://dev.mysql.com/doc/refman/5.0/en/reserved-words.html
The documentation does not clearly mention that the backticks for a column with a reserved keyword in the ORM mapping file. This file could be in xml, yaml or php.
So,the right way to apply backticks is: <field name="group" type="string" column="`group`" length="32" nullable="false"/>

Comment by Luiz Oliveira [ 05/Sep/14 ]

Here is the list of reserved keywords for PostgreSQL

http://www.postgresql.org/docs/7.3/static/sql-keywords-appendix.html





[DDC-3296] JoinColumns seems to only populate one JoinColumn Created: 04/Sep/14  Updated: 04/Sep/14

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

Type: Bug Priority: Major
Reporter: Daniel Platt Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm
Environment:

Symfony 2.3.19



 Description   

I have two entities that are linked via two properties (trackingClickId and trackingSiteId).

However it seems to miss the second JoinColumn.

[Mapping] FAIL - The entity-class '...\Entity\SaleData' mapping is invalid:

  • The join columns of the association 'click' have to match to ALL identifier columns of the target entity '..\Entity\SaleData', however 'tracking_site_id' are missing.
TrackingData.php
class TrackingData
{

    /**
     * @ORM\Column(name="tracking_click_id", type="integer")
     * @ORM\Id
     */
    private $trackingClickId;

    /**
     * @ORM\Column(name="tracking_site_id", type="integer")
     * @ORM\Id
     * @Assert\NotBlank
     */
    private $trackingSiteId;

    /**
     * @ORM\OneToMany(targetEntity="SaleData", mappedBy="click")
     * @ORM\JoinColumns=({
     *      @ORM\JoinColumn(name="tracking_click_id", referencedColumnName="tracking_click_id"),
     *      @ORM\JoinColumn(name="tracking_site_id", referencedColumnName="tracking_site_id"), 
     * })
     */
    private $sales;
    
}
SaleData.php
class SaleData
{

    /**
     * @ORM\Column(name="tracking_site_id", type="integer")
     * @ORM\Id
     * @Assert\NotBlank
     */
    private $trackingSiteId;

    /**
     * @ORM\Column(name="tracking_click_id", type="integer")
     * @ORM\Id
     * @Assert\NotBlank
     */
    private $trackingClickId;

    /**
     * @ORM\ManyToOne(targetEntity="TrackingData", inversedBy="sales")
     * @ORM\JoinColumns=({
     *      @ORM\JoinColumn(name="tracking_click_id", referencedColumnName="tracking_click_id"),
     *      @ORM\JoinColumn(name="tracking_site_id", referencedColumnName="tracking_site_id")
     * })
     */
    private $click;
}

I have been poking around in Doctrine\ORM\Tools\SchemaValidator (L:215).

var_dump($identifierColumns, $assoc['joinColumns']);

array(2) {
  [0] =>
  string(17) "tracking_click_id"
  [1] =>
  string(16) "tracking_site_id"
}
array(1) {
  [0] =>
  array(6) {
    'name' =>
    string(17) "tracking_click_id"
    'unique' =>
    bool(false)
    'nullable' =>
    bool(true)
    'onDelete' =>
    NULL
    'columnDefinition' =>
    NULL
    'referencedColumnName' =>
    string(17) "tracking_click_id"
  }
}





[DDC-2462] [GH-674] Shortcut for force Created: 20/May/13  Updated: 03/Sep/14

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

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



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

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

Comment by Doctrine Bot [ 03/Sep/14 ]

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

Comment by Doctrine Bot [ 03/Sep/14 ]

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





[DDC-3294] [GH-1129] Allow inheritance of FilterCollection Created: 02/Sep/14  Updated: 02/Sep/14

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

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


 Description   

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

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

Message:

I need to inherit this class and now I have to pretty much copy the whole mechanism, because methods in inherited class cannot reach private properties. This would solve the issue.






[DDC-3291] Cannot use eq expression for comparison of DateTime Created: 01/Sep/14  Updated: 02/Sep/14

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

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


 Description   

When I use return ArrayCollection::matching() with criteria defined with eq expression like that:

Criteria::create()->where(Criteria::expr()->eq('day', $day))

I get no results since equality operator uses === comparison which will almost always return false for objects. The only way I found to get around this is to use in operator instead

Criteria::create()->where(Criteria::expr()->in('day', array($day)))





[DDC-3293] XML Mappings disallow disabling column prefix for embeddables Created: 01/Sep/14  Updated: 01/Sep/14

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

Type: Bug Priority: Minor
Reporter: Marco Pivetta Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Reference
relates to DDC-3292 [GH-1127] Document embeddables column... Resolved

 Description   

As of DDC-3292, it is not possible to disable the column prefix for embeddables in XML mappings. This example shows that "false" is used as column prefix:

<embedded name="address" class="Address" column-prefix="false" />

A possible solution is to use something like:

<embedded name="address" class="Address" use-column-prefix="false" />

or

<embedded name="address" class="Address" use-column-prefix="true" />





[DDC-3277] Yaml convert-mapping bug Created: 27/Aug/14  Updated: 01/Sep/14

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

Type: Bug Priority: Major
Reporter: Vladimir Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mapping, orm, yaml, yml
Environment:

Windows+XAMPP, PHP5.3, Zend Framework 2



 Description   

I use yaml mapping in my project for better migration management. For example, I use

    orm:convert-mapping yml ./yml --from-database --namespace="User\Entity\\" --filter="User\Entity\User"

To make yml entites for my User module. In my yml I have smth like this:

      password:
            type: string
            nullable: false
            length: 256
            fixed: false
            comment: ''
        email:
            type: string
            nullable: false
            length: 64
            fixed: false
            comment: ''
        status:
            type: smallint
            nullable: false
            unsigned: false
            comment: ''

I can write a comment to column

         status:
                type: smallint
                nullable: true
                unsigned: false
                comment: '%some comment%'
                column: status

And when I perform migration comment disappears. Here https://github.com/doctrine/migrations/issues/184 I was adviced to use such construction:

    status:
        type: smallint
        nullable: true
        column: status
        options:
            unsigned: false
            comment: '%some comment%'

And It works! But convert-mapping generates wrong code. Does anyone know any way to generate a correct one with convert-mapping?



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

Seems like Christophe Coevoet started working on this: https://github.com/doctrine/doctrine2/pull/1123

Comment by Vladimir [ 29/Aug/14 ]

Thank you very much! Will with feature be available with update through composer?

Comment by Doctrine Bot [ 30/Aug/14 ]

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

Comment by Doctrine Bot [ 30/Aug/14 ]

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

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

Vladimir there is no release date scheduled for 2.5 yet. If you want to use the patch you will have to use "dev-master" version in your composer.json





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

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

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

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



 Description   

Is there any way to comment my tables and table relations with yml schema?
I can comment plain field like this
prediction:
type: text
nullable: true
length: null
fixed: false
options:
comment: 'program prediction'

But for relation:

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

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

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



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

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

Comment by Vladimir [ 29/Aug/14 ]

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

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

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





[DDC-3289] Better exception description on some mapping errors Created: 31/Aug/14  Updated: 01/Sep/14

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

Type: Improvement Priority: Minor
Reporter: Luciano Mammino Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mapping, orm, schematool


 Description   

Mapping problems does not always throw very explicit exceptions.

I had this feeling with a very common error:

This behaviour is (currently) not supported by Doctrine 2"

I essentially forgot to add a "mapped-by" attribute in my mappings and, given this generic message, I admit I had to spend a bit of time before being able to spot the mistake.

That's the code that detected the problem and triggered the proper exception.

Doctrine/ORM/Tools/SchemaTool.php
} elseif ($mapping['type'] == ClassMetadata::ONE_TO_MANY && $mapping['isOwningSide']) {
                //... create join table, one-many through join table supported later
                throw ORMException::notSupported();

Within the $mapping variable I see we have a lot of useful information about the problem. Why don't use them to create a very helpful exception message that reports the exact mapped entity and field that raised the error?

IMHO this will grant a better developer experience, especially for doctrine newcomers!



 Comments   
Comment by Marco Pivetta [ 01/Sep/14 ]

Hey Luciano Mammino, could you come up with an exception message that makes sense to you? This kind of improvement is trivial to implement, so it should be quick...

Comment by Luciano Mammino [ 01/Sep/14 ]

Hi Marco Pivetta
I think something like:

One to Many relationships without "mapped-by" attribute are not allowed. (Found in "\Foo\Bar\SomeEntity", field "somefield")

Will be good enough to give developers some clue about where the problem lies. Anyway I'm not sure it covers all the possible cases for this exception and that it is consistent with other error messages within the codebase.





[DDC-3147] [GH-1045] Fix the "Erroneous data format for unserializing" error message Created: 30/May/14  Updated: 30/Aug/14

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

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


 Description   

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

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

Message:

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



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

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

Comment by Doctrine Bot [ 27/Aug/14 ]

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

Comment by Doctrine Bot [ 28/Aug/14 ]

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

Comment by Doctrine Bot [ 30/Aug/14 ]

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

Comment by Doctrine Bot [ 30/Aug/14 ]

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





[DDC-3265] Incorrect Docblock return type in CacheConfiguration Created: 21/Aug/14  Updated: 30/Aug/14

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

Type: Bug Priority: Trivial
Reporter: James Murray Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: None


 Description   

In CacheConfiguation.php line #88 (at the time of writing)

The docblock for the method getRegionsConfiguration specifies the return type of "QueryCacheValidator" however it's actually returning "RegionsConfiguration"



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

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

Comment by Doctrine Bot [ 30/Aug/14 ]

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

Comment by Doctrine Bot [ 30/Aug/14 ]

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





[DDC-3282] Pagination class CountOutputWalker has poor performance with MySQL Created: 28/Aug/14  Updated: 28/Aug/14

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

Type: Improvement Priority: Major
Reporter: Frédéric Rocheron Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

GNU/Linux CentOS 6.5, Php 5.4.32, MySQL 5.5.39, Symfony 2.5.3



 Description   

When the CountOutputWalker is used for pagination, it creates a count query of this type :

    SELECT %s AS dctrn_count
    FROM (
        SELECT DISTINCT "here are the identifiers from the original query"
        FROM (
            "here is the original query"
        ) dctrn_result
    ) dctrn_table

The problem is that the original query inside the count query is executed without limiting the results number each time the pagination has to count the total number of rows. And when the total number of rows returned by the original query is large and/or with big selected rows, it can hurt badly the performance, even kill the server.
Maybe I don't understand something but in my opinion this count query does exactly what we try to avoid with pagination : load all data at one time !
So I don't understand why things are done this way. Again, I'm not a db specialist so I'm almost sure I'm missing something.

But the thing is I've met these performance issues with big select queries on a medium amount of rows (~35000) on MySQL (using knp-components Pager).
The ugly solution I found was to use the CountWalker instead of the CountOutputWalker except when the query has a "HAVING" clause. That was because the CountWalker produce a better count query for performance but cannot handle well "HAVING" clauses (as far as I know).
Finally I think the solution is to modify the CountWalker so it can take care of more complex queries and/or improve the CountOutputWalker to preserve performance.

Here are some discussions related to this problem :
Removed use of CountOutputWalker
Count Performance of DoctrineORMAdapter COUNT query and large record sets
Doctrine ORM pagination improvements

Thanks a lot for your time



 Comments   
Comment by Christophe Coevoet [ 28/Aug/14 ]

Well, the issue is that the CountWalker cannot count stuff using a GROUP BY or HAVING clause by design. It is simply impossible to write the given SQL without ending up on what the CountOutputWalker is doing,(maybe a bit simpler in some cases thanks to a complete knowledge of what the query is doing, but not much and not in a general case).

The solution is indeed to tell the Paginator not to use the output walker when you know it is not necessary. This is precisely why there are 2 implementations of the pagination with a boolean flag to switch between them

Comment by Christophe Coevoet [ 28/Aug/14 ]

And the output walker actually perform better than the tree walker in many platforms according to Benjamin Eberlei (not MySQL though), which is why it is hard to choose the best walker for queries being supported by both of them (a project can do it better than the core, as it knows which platform it uses)

Comment by Frédéric Rocheron [ 28/Aug/14 ]

Thank you for your very clear explanations !
I assumed I was missing something but I did not think it was just impossible to solve this problem "automatically" . That's a bit annoying but ok.
The solution for MySQL seems to use the CountWalker for queries without GROUP BY or HAVING clause and CountOutputWalker for other queries. A better solution would be to create a custom hand-made count query for queries with GROUP BY or HAVING clause. This is possible in "knp-components Pager" and, I suppose, in the other pagination libraries using doctrine-orm Tools.

But as "knp-components Pager" does not use the "doctrine-orm Tools Paginator" but only the walkers from doctrine-orm, it doesn't have the boolean flag to switch between CountWalker and CountOutputWalker. The CountOutputWalker is used if doctrine-orm version is 2.3.0 or more and that's it.
I've made a pull request to activate the use of CountWalker for queries without HAVING clause but I think now it's a bad idea. The solution should be to add the same boolean flag to the "knp-components Pager" library. I will talk to them about that.

Thanks again for your time

Comment by Christophe Coevoet [ 28/Aug/14 ]

See https://github.com/KnpLabs/knp-components/issues/114

Comment by Frédéric Rocheron [ 28/Aug/14 ]

great





[DDC-3280] ObjectHydrator does not support iteration over non-distinct result sets Created: 27/Aug/14  Updated: 27/Aug/14

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

Type: Bug Priority: Major
Reporter: Timothy Michael Bradley Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm


 Description   

ObjectHydrator attempts to retrieve previously created objects during iteration (i.e. Query::iterate()). It needs to create an entirely new object because the previous one is not available.

This may also be a performance/scalability issue, and it may be a matter of setting default behavior.

Note that calling Query::useResultCache(false) does not fix this issue.

This part of the code causes a warning because of this issue.

// Update result pointer
$index = $this->identifierMap[$dqlAlias][$id[$dqlAlias]];
$this->resultPointers[$dqlAlias] = $result[$index];
$resultKey = $index

Here is the warning:

Notice: Undefined offset: 0 in [basedir]/vendor/doctrine/orm/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php on line 519





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

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

Type: Bug Priority: Major
Reporter: Grégoire Pineau Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None
Environment:

Linux / Mint 15
php 5.5.*



 Description   

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

Stack trace:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

at PHPUnit_TextUI_TestRunner->doRun(object(PHPUnit_Framework_TestSuite), array('listGroups' => false, 'loader' => null, 'useDefaultConfiguration' => true, 'configuration' => '/project/app/phpunit.xml.dist', 'filter' => 'testDashboardWithCriticalIgnoredRules', 'testSuffixes' => array('Test.php', '.phpt')))
in /opt/dotfiles/vendor/phpunit/phpunit/PHPUnit/TextUI/Command.php line 176

at PHPUnit_TextUI_Command->run(array('/usr/local/bin/phpunit', 'c', 'app/', '-filter', 'testDashboardWithCriticalIgnoredRules', 'src/SensioLabs/Bundle/MyBundle/Tests/Acceptance/ViolationCommentsTest.php'), true)
in /opt/dotfiles/vendor/phpunit/phpunit/PHPUnit/TextUI/Command.php line 129

at PHPUnit_TextUI_Command::main()
in /opt/dotfiles/vendor/phpunit/phpunit/composer/bin/phpunit line 63

I fails in this code

    private function executeUpdates($class)
    {
        $className          = $class->name;
        $persister          = $this->getEntityPersister($className);
        $preUpdateInvoke    = $this->listenersInvoker->getSubscribedSystems($class, Events::preUpdate);
        $postUpdateInvoke   = $this->listenersInvoker->getSubscribedSystems($class, Events::postUpdate);

        foreach ($this->entityUpdates as $oid => $entity) {
            if ($this->em->getClassMetadata(get_class($entity))->name !== $className) {
                continue;
            }

            if ($preUpdateInvoke != ListenersInvoker::INVOKE_NONE) {
// => this line
                $this->listenersInvoker->invoke($class, Events::preUpdate, $entity, new PreUpdateEventArgs($entity, $this->em, $this->entityChangeSets[$oid]), $preUpdateInvoke);
                $this->recomputeSingleEntityChangeSet($class, $entity);
            }

            if ( ! empty($this->entityChangeSets[$oid])) {
                $persister->update($entity);
            }

            unset($this->entityUpdates[$oid]);

            if ($postUpdateInvoke != ListenersInvoker::INVOKE_NONE) {
                $this->listenersInvoker->invoke($class, Events::postUpdate, $entity, new LifecycleEventArgs($entity, $this->em), $postUpdateInvoke);
            }
        }
    }


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

Requires a test case

Comment by Victor [ 26/Aug/14 ]

I have same bug when call flush() method from entity manager in my few event listeners in Symfony.

P.S. If I call flush() only from one listener - it works well, but when call flush() in first, and then in second - it fails. And it does not matter in which order listeners are called.

Comment by Grégoire Pineau [ 26/Aug/14 ]

yeah, the bug occurs in the same circumstance as described by victor.
(sorry for the delay, and sorry to not provider a test case)

Comment by Christophe Coevoet [ 26/Aug/14 ]

Calling flush() inside a Doctrine listener is not a supported Doctrine usage. it means you are trying to nest several flushes inside each other, which can indeed break the unit of work

Comment by Grégoire Pineau [ 26/Aug/14 ]

I refactored this part of our code base, to remove all flush from the listener. Everything works right now.
But I did not know this was not possible. (And it's not me the guy who created this **** in our codebase )

Comment by Victor [ 26/Aug/14 ]

So, for example, if I use postUpdate Doctrine event to modify the entity after save them to DB, I can't save additional changes to DB again with flush() in my listener?
Is it will be fixed or it's a normal behavior of Doctrine?





[DDC-3273] EntityGenerator writes @ORM\Table annotation for mapped superclass Created: 26/Aug/14  Updated: 26/Aug/14

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

Type: Bug Priority: Major
Reporter: Jakab Adam Balazs Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: generation, orm, tools
Environment:

not relevant



 Description   

file /doctrine/orm/lib/Doctrine/ORM/Tools/EntityGenerator.php method: generateTableAnnotation returns @ORM\Table annotation even for mapped superclass entities. Since classes with annotation @ORM\MappedSuperclass are only to be extended and will NOT have a database table associated to them they should not have '@ORM\Table' annotation at all.
It would be enough to wrap the method body with `if ($metadata->isMappedSuperclass)

{ ... }

`.






[DDC-3271] Impossible to set-up Two relations one-to-one which share the same target Created: 25/Aug/14  Updated: 25/Aug/14

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

Type: Bug Priority: Major
Reporter: Grégoire Pineau Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I reproduced my issue in a SF2 standard edition.

https://github.com/lyrixx/symfony-standard/blob/doctrine-many/test.php

So basically:

I have a "dude" table, with 2 FK: "delivery_address" and "billing_address".
But I'm not able to set-up doctrine to make it work, because when I set-up
the "Address" Entity, doctrine add a "unique" constraint on this table.
So I can insert one of the two addresses, but not two addresses.






[DDC-3270] abstract class database entity generation Created: 23/Aug/14  Updated: 23/Aug/14

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

Type: Bug Priority: Minor
Reporter: Yan Ni Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mysql, orm
Environment:

WAMP symfony2



 Description   

I create an abstract class A using @ORM annotations, then create class B which is a subclass of class A. When I use these to update the mysql database, however, a table for class A was also generated, which shouldn't have happened(because class A is an abstract class).






[DDC-3269] [GH-1120] [DDC-3205] Metadata info Created: 23/Aug/14  Updated: 23/Aug/14

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

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


 Description   

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

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

Message:

This PR adds support for showing the metadata for a single entity to the `orm:info` command.

  • The output is formatted using the `TableHelper` if it is available (Symfony 2.4+). If the TableHelper is not available
    it will format simply with `field: value`.
  • Partial regex matches are accepted, e.g. `mapping:info Attraction`, `mapping:info Attraction.*`

E.g.:

````bash
$ php app/console doctrine:mapping:info "Sulu\Bundle\ContactBundle\Entity\Count"
----------------------------------------------------------------------------------------------------------------------------+

Field Value

----------------------------------------------------------------------------------------------------------------------------+

Name Sulu\Bundle\TagBundle\Entity\Tag
Root entity name Sulu\Bundle\TagBundle\Entity\Tag
Custom generator definition None
Custom repository class Sulu\Bundle\TagBundle\Entity\TagRepository
Mapped super class? Empty
Embedded class? Empty
Parent classes Empty
Sub classes Empty
Embedded classes Empty
Named queries Empty
Named native queries Empty
SQL result set mappings Empty
Identifier ["id"]
Inheritance type 1
Discriminator column None
Discriminator value None
Discriminator map Empty
Generator type 4
Table {"name":"ta_tags"}
Composite identifier? Empty
Foreign identifier? Empty
Sequence generator definition None
Table generator definition None
Change tracking policy 1
Versioned? None
Version field None
Read only? Empty
Entity listeners Empty
Association mappings:  
creator  
fieldName creator
targetEntity Sulu\Bundle\SecurityBundle\Entity\User
joinColumns [{"name":"idUsersCreator","referencedColumnName":"id","nullable":true,"onDelete":"SET NULL"}]
type 2
mappedBy Null
inversedBy Null
isOwningSide 1
sourceEntity Sulu\Bundle\TagBundle\Entity\Tag
fetch 2
cascade Empty
isCascadeRemove Empty
isCascadePersist Empty
isCascadeRefresh Empty
isCascadeMerge Empty
isCascadeDetach Empty
sourceToTargetKeyColumns {"idUsersCreator":"id"}
joinColumnFieldNames {"idUsersCreator":"idUsersCreator"}
targetToSourceKeyColumns {"id":"idUsersCreator"}
orphanRemoval Empty
Field mappings:  
name  
fieldName name
type string
columnName name
unique 1
created  
fieldName created
type datetime
columnName created

----------------------------------------------------------------------------------------------------------------------------+






[DDC-3268] [GH-1118] Use the new Docker queue on Travis Created: 22/Aug/14  Updated: 22/Aug/14

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

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


 Description   

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

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

Message:

faster better stronger

let's see how it copes with this test suite






[DDC-3267] [GH-1117] QueryBuilder - replace deprecated getAlias() by getAliases()[0] Created: 22/Aug/14  Updated: 22/Aug/14

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

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


 Description   

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

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

Message:






[DDC-3264] setFetchMode Signature and Documentation Created: 21/Aug/14  Updated: 21/Aug/14

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

Type: Improvement Priority: Minor
Reporter: Andreas Dyballa Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

The signature in AbstractQuery should be boolean for fetchmode and the documentation on
http://docs.doctrine-project.org/en/2.1/reference/dql-doctrine-query-language.html
setFetchMode(...,"EAGER"); is not according to the signature.
This is confusing.






[DDC-3263] setFetchmode for ClassMetaData temorarily instead of Query Created: 21/Aug/14  Updated: 21/Aug/14

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

Type: Improvement Priority: Minor
Reporter: Andreas Dyballa Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

SetFetchmode is now woriking in AbstractQuery.

Why dont implement setFetchMode and perhaps further temporarily changes in an ClassMetadata-managing Object. Perhaps to work with a temporarily copy to allow a reset after some action.






[DDC-3261] Bad link in 34.3 Advanced Configuration - Connection Options Created: 20/Aug/14  Updated: 20/Aug/14

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

Type: Bug Priority: Minor
Reporter: Matthew Turland Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: documentation, orm


 Description   

The link to the DBAL section from 34.3 Advanced Configuration - Connection Options results in a 404 HTTP response. This line appears to be responsible.

Link URL as it appears in the current documentation:
http://docs.doctrine-project.org/dbal/2.0/docs/reference/configuration/en






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

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

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


 Description   

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

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

https://github.com/ptlis/DoctrineTestcase



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

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

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

Comment by brian ridley [ 20/Aug/14 ]

Hi,

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





[DDC-3234] Empty properties when filtering collections Created: 30/Jul/14  Updated: 20/Aug/14

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

Type: Bug Priority: Major
Reporter: Diogo Domanski de Souza Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: Collection, Criteria, orm
Environment:

PHP 5.5.9, Nginx 1.4.6, PHP FPM, Zend Framework 2.3.1, Linux Ubuntu 14.04



 Description   

I'm facing some troubles when filtering an entity association (ArrayCollection) by using Criteria.

The scenario is the following: I have 3 entities:

User.php
<?php

namespace Entity;

use Doctrine\ORM\Mapping as ORM;
use \Doctrine\Common\Collections\Criteria;
use Zend\Stdlib\Hydrator;

/**
 * User
 *
 * @ORM\Table(name="user")
 * @ORM\Entity(repositoryClass="Entity\UserRepository")
 * @ORM\HasLifecycleCallbacks
 * @author domanski
 */
class User implements \Serializable {
	/**
	 *
	 * @ORM\Id
	 * @ORM\Column(name="id", type="integer", nullable=false)
	 * @ORM\GeneratedValue(strategy="AUTO")
	 * @var integer
	 */
	private $id;

	/**
	 * @ORM\Column(name="delete_date", type="datetime")
	 * @var \DateTime
	 */
	private $deleteDate;
	
	public function __construct(array $options = array()) {
		if (!empty($options))
			$this->hydrate($options);
	}

	public function hydrate(array $options = array(), \Doctrine\ORM\EntityManager $em = null) {
		$hydrator = new Hydrator\ClassMethods();
		$hydrator->hydrate($options, $this);
	}

	/**
	 * 
	 * @return int
	 */
	public function getId() {
		return $this->id;
	}

	/**
	 * 
	 * @param int $id
	 * @return \Entity\User
	 */
	public function setId($id) {
		$this->id = $id;
		return $this;
	}

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

	/**
	 * @param \DateTime|null $deleteDate
	 * @return \Entity\User
	 */
	public function setDeleteDate($deleteDate = null) {
		$this->deleteDate = $deleteDate;
		return $this;
	}

	/**
	 * 
	 * @return array
	 */
	public function toArray() {
		$result = array(
			'id' => $this->getId(),
			'delete_date' => $this->getDeleteDate()
		);

		return $result;
	}

}
FieldWorker.php
<?php

namespace Entity;

use Doctrine\ORM\Mapping as ORM;
use \Doctrine\Common\Collections\Criteria;

use Zend\Stdlib\Hydrator;

/**
 * Description of FieldWorker
 *
 * @ORM\Entity(repositoryClass="Entity\FieldWorkerRepository")
 * @ORM\Table(name="field_worker")
 * @ORM\HasLifecycleCallbacks
 * @author domanski
 */
class FieldWorker {
	
	/**
	 * This attribute must exist so the inverse join with any other entity can work
	 * 
	 * @ORM\Id
	 * @ORM\Column(type="integer", name="user_id")
	 * @var string
	 */
	protected $id;
	
	/**
	 * 
	 * @ORM\OneToOne(targetEntity="Entity\User")
	 * @ORM\JoinColumn(name="user_id", referencedColumnName="id")
	 * @var \Entity\User
	 */
	protected $user;
	
	public function __construct($options = array()) {		
		if(!empty($options))
			$this->hydrate($options);
	}
	
	public function hydrate(array $options = array(), \Doctrine\ORM\EntityManager $em = null) {
		if(!empty($em)) {
			// user
			if(isset($options['user']))
				$options['user'] = $em->getReference('Entity\User', $options['user']);
			else if(isset($options['user_id']))
				$options['user'] = $em->getReference('Entity\User', $options['user_id']);
						
		}
		
		$hydrator = new Hydrator\ClassMethods();
		$hydrator->hydrate($options, $this);
	}

	/**
	 * 
	 * @return \Entity\User
	 */
	public function getUser() {
		return $this->user;
	}

	/**
	 * 
	 * @param \Entity\User $user
	 * @return \Entity\FieldWorker
	 */
	public function setUser(\Entity\User $user) {
		$this->user = $user;
		$this->id = $user->getId();
		return $this;
	}
	
	/**
	 * 
	 * @return array
	 */
	public function toArray() {
		return $this->getUser()->toArray();
	}
}
Stage.php
<?php

namespace Obra\Entity;

use Doctrine\ORM\Mapping as ORM;
use Zend\Stdlib\Hydrator;
use Doctrine\Common\Collections\Criteria;

/**
 * Description of Stage
 *
 * @ORM\Table(name="stage")
 * @ORM\Entity(repositoryClass="Entity\StageRepository")
 * @ORM\HasLifecycleCallbacks
 * @author domanski
 */
class Stage {

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

	/**
	 * @ORM\ManyToMany(targetEntity="Entity\FieldWorker")
	 * @ORM\JoinTable(name="stage_field_worker",
	 * 		joinColumns={@ORM\JoinColumn(name="stage_id", referencedColumnName="id")},
	 * 		inverseJoinColumns={@ORM\JoinColumn(name="field_worker_id", referencedColumnName="user_id")}
	 * 	)
	 * @var \Doctrine\Common\Collections\ArrayCollection
	 */
	private $fieldWorkers;

	public function __construct(array $options = array()) {
		$this->fieldWorkers = new \Doctrine\Common\Collections\ArrayCollection();

		if (!empty($options))
			$this->hydrate($options);
	}

	public function hydrate(array $options = array(), \Doctrine\ORM\EntityManager $em = null) {
		$hydrator = new Hydrator\ClassMethods();
		$hydrator->hydrate($options, $this);
	}

	/**
	 * 
	 * @return int
	 */
	public function getId() {
		return $this->id;
	}

	/**
	 * 
	 * @param int $id
	 * @return \Entity\Stage
	 */
	public function setId($id) {
		$this->id = $id;
		return $this;
	}

	/**
	 * 
	 * @return \Doctrine\Common\Collections\ArrayCollection
	 */
	public function getFieldWorkers() {
		$criteria = Criteria::create()
				->where(Criteria::expr()->isNull("user.deleteDate"))
				->orderBy(array("user.name" => Criteria::ASC));

		return $this->fieldWorkers->matching($criteria);
	}

	/**
	 * 
	 * @return \Entity\Stage
	 */
	public function clearFieldWorkers() {
		$this->fieldWorkers->clear();
		return $this;
	}

	/**
	 * 
	 * @param \Entity\FieldWorker $fieldWorker
	 * @return \Entity\Stage
	 */
	public function addFiscal(\Entity\FieldWorker $fieldWorker) {
		$this->fieldWorkers->add($fieldWorker);
		return $this;
	}

	/**
	 * 
	 * @return array
	 */
	public function toArray() {
		$result = array(
			"id" => $this->getId(),
			"field_workers" => array()
		);

		foreach ($this->getFieldWorkers() as $fieldWorker) {
			$result['field_workers'][] = $fieldWorker->toArray();
		}

		return $result;
	}
}

The problem is that whenever the Stage::getFieldWorkers() method is invoked, the list of associated field workers is returned correctly, however if I try to retrieve the respective user of any field worker, it is NULL.

For example:

$stageEntity = $em->getRerefence('Entity\Stage', 1);
$fieldWorkers = $stageEntity->getFieldWorkers();

foreach($fieldWorkers as $fieldWorker) {
   $userId = $fieldWorker->getUser()->getId(); // This throws an error message saying that the result of getUser() is NULL
}

Another example would be if I try to call $stageEntity->toArray() (because it does the same thing as show above).

The database tables are as following:

Database tables creation
CREATE TABLE `user` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `delete_date` datetime DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE `field_worker` (
  `user_id` int(10) unsigned NOT NULL,
  PRIMARY KEY (`user_id`),
  CONSTRAINT `fk_field_worker_user1` FOREIGN KEY (`user_id`) REFERENCES `user` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;


CREATE TABLE `stage` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;


CREATE TABLE `stage_field_worker` (
  `stage_id` int(10) unsigned NOT NULL,
  `field_worker_id` int(10) unsigned NOT NULL,
  PRIMARY KEY (`stage_id`,`field_worker_id`),
  KEY `fk_stage_field_worker_stage_idx` (`stage_id`),
  KEY `fk_stage_field_worker_field_worker_idx` (`field_worker_id`),
  CONSTRAINT `fk_stage_field_worker_field_worker` FOREIGN KEY (`field_worker_id`) REFERENCES `field_worker` (`user_id`) ON DELETE CASCADE ON UPDATE CASCADE,
  CONSTRAINT `fk_stage_field_worker_stage` FOREIGN KEY (`stage_id`) REFERENCES `stage` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

INSERT INTO `user` SET `id` = 1;
INSERT INTO `field_worker` SET `user_id` = 1;
INSERT INTO `stage` SET `id` = 1;
INSERT INTO `stage_field_worker` SET `stage_id` = 1, `field_worker_id` = 1;

After hours trying to understand what was wrong, I decided to make a test and modify the Stage::getFieldWorkers() method by removing the filtering Criteria:

public function getFieldWorkers() {
    return $this->fieldWorkers;
}

By simply doing that, the getUser() method started to return an entity of type User (as expected).

I am not a Doctrine ORM expert, but there seems to be something wrong with ArrayCollection filtering (matching() method)



 Comments   
Comment by Diogo Domanski de Souza [ 30/Jul/14 ]

The same problem occurs with QueryBuilder. For example:

StageRepository.php
<?php

namespace Entity;

use Doctrine\ORM\EntityRepository;

/**
 * Description of StageRepository
 *
 * @author domanski
 */
class StageRepository extends EntityRepository 
{

	public function findByFieldWorkerId($fieldWorkerId) {
		$qb = $this->getEntityManager()->createQueryBuilder()
			->select('s')
			->from('Entity\Stage', 's')
			->innerJoin('s.fieldWorkers', 'f')
			->innerJoin('f.user', 'u', \Doctrine\ORM\Query\Expr\Join::WITH, "u.deleteDate IS NULL AND u.id = :field_worker_id")
				->setParameter('field_worker_id', $fieldWorkerId);

		return $qb->getQuery()->getResult();
	 }
}

If I try to iterate over the result of StageRepository::findByFieldWorkerId() and call toArray() of any element, I get the same error. I've even tried to remove the inner join with User entity from query:

	public function findByFieldWorkerId($fieldWorkerId) {
		$qb = $this->getEntityManager()->createQueryBuilder()
			->select('s')
			->from('Entity\Stage', 's')
			->innerJoin('s.fieldWorkers', 'f');

		return $qb->getQuery()->getResult();
	 }
Comment by Marco Pivetta [ 30/Jul/14 ]

I suspect that something is wrong in your mappings then...

Comment by Diogo Domanski de Souza [ 31/Jul/14 ]

Hi Marco,

The mappings are shown above. The only thing I did was to omit some entities/tables properties/columns that don't have to see with the associations - except the field worker (table and Entity) and stage_field_worker table, that are fully presented.

Maybe is important to notice that the field_worker table has only one column (user_id) that is primary key and foreign key (referencing user.id).

Thanks for you support

Comment by Marco Pivetta [ 31/Jul/14 ]

Diogo Domanski de Souza we can't debug this as it is. We'd need a functional test case to be added to https://github.com/doctrine/doctrine2/tree/0650bb954f5e8d05776f99abd04c81948413299f/tests/Doctrine/Tests/ORM/Functional/Ticket first, in order to see the failure

Comment by Diogo Domanski de Souza [ 31/Jul/14 ]

Marco Pivetta is there any documentation (tutorial, instructions, guide, etc) that I can use to learn how to write the functional test cases that I need?

Comment by Marco Pivetta [ 31/Jul/14 ]

Diogo Domanski de Souza you need to look at the existing ones.

For running the test suite:

git clone git@github.com:doctrine/doctrine2.git
cd doctrine2 
curl -s https://getcomposer.org/installer | php --
./composer.phar install
./vendor/bin/phpunit
Comment by Diogo Domanski de Souza [ 20/Aug/14 ]

I solved the problem by removing the property $id from FieldWorker entity and add annotation @ORM\Id to $user property (in this same entity).

I didn't understand why the previous definition of FieldWorker entity was not working. I have another similar relationship scenario, between 3 different entities, and the error does not occur.

Thanks to all for the support





[DDC-2701] Collections in originalEntityData gets over written Created: 23/Sep/13  Updated: 20/Aug/14

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


 Description   

I was trying to use the UnitOfWork::getOriginalEntityData method and i noticed that if there is a collection in that object, it changes in the uow original datas when i change it on my original object

In my case the collection is ManyToMany unidirectional

I think this happens because both the uow and the object work with the same reference to the collection
maybe adding a clone of the collection instead of the real one, i don't know if it is possible

Thank you for taking a look and for Doctrine!

Tom



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

This issue needs a test case in order to be reproduced.

Comment by Thomas Klein [ 20/Aug/14 ]

Here is how i get to this bug:

2 entities with a many to many unidirectional relation:

class Conversation
{
    // ...........

    /**
     * @ORM\ManyToMany(targetEntity="User")
     * @ORM\JoinTable(name="Conversations_To_Users",
     *      joinColumns={@ORM\JoinColumn(name="conversation_id", referencedColumnName="id")},
     *      inverseJoinColumns={@ORM\JoinColumn(name="user_id", referencedColumnName="id")}
     * )
     *
     * @var ArrayCollection
     */
    private $users;

    public function getUsers()
    {
        return $this->users();
    }

    // .....
}

class User
{
    // .....
}

Load the Conversation entity joined with the associated users: you get a Conversation entity with the users property filled with a PersistentCollection initialized. You can find this object in the originalEntityData property of the unit of work.

Then do:

$users = $conversation->getUsers();
$users->remove(0);

In the conversation object, the first user of the collection has been removed. In the unit of work, find the corresponding object in the originalEntityData array and you'll see that the first user has been removed from the collection too. It is then not possible to use the originalEntityData on joined collection to check for changes

Comment by Marco Pivetta [ 20/Aug/14 ]

Thomas Klein still not sure what the problem is:

$user         = new User();
$conversation = new Conversation();

$conversation->addUser($user);

$em->persist($user);
$em->persist($conversation);
$em->flush();
$em->clear();

$conversation1   = $em->find('Conversation', $conversation->id);
$usersCollection = $conversation->getUsers();

$usersCollection->remove(0);

var_dump($em->getUnitOfWork()->getOriginalEntityData($conversation1));

// what is failing after this point?

This is also how a test case should look like when thrown at the ORM functional test suite: https://github.com/doctrine/doctrine2/tree/v2.4.4/tests/Doctrine/Tests/ORM/Functional/Ticket

Comment by Thomas Klein [ 20/Aug/14 ]

Sorry i'll try to write a real test case asap ...

What is failing after this point ?

$origConversationData = $em->getUnitOfWork()->getOriginalEntityData($conversation1);
var_dump(count($origConversationData['users'])); // should be equal to 1, i get 0 ...

The only diff i can see with your example is that i'm not using find but a query with the relation fetched-joined in it so the collection is initialized

Comment by Marco Pivetta [ 20/Aug/14 ]

Collections are not tracked within entity data, but separately in the UoW

Comment by Thomas Klein [ 20/Aug/14 ]

Ok so i guess we can close this ticket if this is an expected behavior ...

In your last comment, did you mean:
Collections are not tracked within entity data, but each element of the collection is tracked separately in the UoW ?

Anyway thanks for your help





[DDC-3029] DISTINCT , ORDER BY AND Limit in SQL Server Created: 14/Mar/14  Updated: 20/Aug/14

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

Type: Bug Priority: Major
Reporter: Michał Banaś Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Attachments: File SQLServerPlatform.php    

 Description   

I don't know if I should report it here , becouse error is in SQLServerPlatform.php file.
basicaly Distinct includes ROWNUM()
So if you add distinct in DQL it will be translated to "select distinct ...... , Rownum()" - which is always distinct offcource.

Here is original version

    protected function doModifyLimitQuery($query, $limit, $offset = null)
    {
        if ($limit > 0) {
            if ($offset == 0) {
                $query = preg_replace('/^(SELECT\s(DISTINCT\s)?)/i', '\1TOP ' . $limit . ' ', $query);
            } else {
                $orderby = stristr($query, 'ORDER BY');

                if ( ! $orderby) {
                    $over = 'ORDER BY (SELECT 0)';
                } else {
                    $over = preg_replace('/\"[^,]*\".\"([^,]*)\"/i', '"inner_tbl"."$1"', $orderby);
                }

                // Remove ORDER BY clause from $query
                $query = preg_replace('/\s+ORDER BY(.*)/', '', $query);
                $query = preg_replace('/^SELECT\s/', '', $query);

                $start = $offset + 1;
                $end = $offset + $limit;

                $query = "SELECT * FROM (SELECT ROW_NUMBER() OVER ($over) AS doctrine_rownum, $query) AS doctrine_tbl WHERE doctrine_rownum BETWEEN $start AND $end";
            }
        }

        return $query;
    }

In Attachenment there is a fixed version of this file.



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

Can you provide a failing test case and an expected result as well?

Comment by Michał Banaś [ 20/Aug/14 ]

Well I'm not working with PHP anymore for now, but i will try:
it's easy and when you look at the code closer you will see the problem:

Test Case: use Query Builder and genearate query with DIstinct and Order BY And Liimit ( top , skip or something )
Expected result would be to get distinct set of data ordered by key and with limit.
Unfortunately - as the result query will be something:
select distinct .... top ....
from .........
SELECT ROW_NUMBER() OVER ($over) AS doctrine_rownum ... rest of the qurery

so from inner query you will get

doctrine_rownum;column1;column2;column3
1;example;example;example
2;example;example;example
3;example;example;example

I think you can clearly see that each row will be diiffrent. That's why DISTINCT will not work.
What happens next:
At some point doctrine will treat identical entities as one object, so for example if you limit Your query to 10 and all objects will be identical You will get only one Row.

I hope thats clear now

And we have a solution for that. It's probably in attached file. I will try to attach final version

My team is woried that after updating Doctrine ( symfony ) we will have to face the problem again.

Comment by Michał Banaś [ 20/Aug/14 ]

well. For some reason i can't attach final version of the file :/
I can paste it as a comment or You can contact me directly and i will send it to You.

Comment by Marco Pivetta [ 20/Aug/14 ]

Ah, I see now what the problem is. ROWNUM() will basically always make the row unique, making DISTINCT useless.

The problem is clear, but it needs an SQL generation test first.

Michał Banaś can you eventually send the patch as a pull request to https://github.com/doctrine/dbal ? Consider that the code for the SQLServerPlatform changed a lot since 2.4.x

Comment by Michał Banaś [ 20/Aug/14 ]

Well I could do that in private time, but it can take a while since i have no spare time right now and i would have to prepare some basic PPH dev environment with MSSQL.otherwise i would send untested code which is not a good idea.

Comment by Marco Pivetta [ 20/Aug/14 ]

We all do develop these tools in private time, so nobody is forcing anyone to do anything





[DDC-3259] Second level & UnitOfWork inconsistencies Created: 19/Aug/14  Updated: 19/Aug/14

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

Type: Improvement Priority: Major
Reporter: Asmir Mustafic Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: second-level-cache


 Description   

Hi!

I have a lot of entities with entity associations as keys and I'm trying to use second level cache.

Looking at the method: UnitOfWork::createEntity($className, array $data, &$hints = array())

  • $className: contains the class name
  • $data: contains the raw data (the row coming from the database)

Enabling the second level cache, DefaultQueryCache::get calls the createEntity method passing a $data that contains object entities and some raw data (https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Cache/DefaultQueryCache.php#L155).

I think that DefaultQueryCache should not introduce a variant of $data and should create a compatible version of $data.



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

Asmir Mustafic do you have any example of where this may be happening?

Comment by Asmir Mustafic [ 19/Aug/14 ]

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

This is the same branch of https://github.com/doctrine/doctrine2/pull/1113, plus this commit (https://github.com/goetas/doctrine2/commit/bfbbb9123fd28f7fa053b76895eaa77e00095aa6) that simply involves the second level cache too.
Travis should fail soon.

Comment by Doctrine Bot [ 19/Aug/14 ]

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

Comment by Asmir Mustafic [ 19/Aug/14 ]

Here the failure https://travis-ci.org/doctrine/doctrine2/jobs/32972996#L402





[DDC-2901] entity-listeners are not propagated to children of mapped superclasses Created: 09/Jan/14  Updated: 19/Aug/14

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

Type: Bug Priority: Major
Reporter: Stuart Carnie Assignee: Fabio B. Silva
Resolution: Unresolved Votes: 0
Labels: mapping


 Description   

If I have event-listeners set on the subclass and mapped superclass, event-listeners will not be propagated, per this code. Conversely, lifecycle events are, per this



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

Stuart Carnie I lost the code references that you linked, since the code changed and the line numbers don't match anymore.

Any chance that you can provide a failing test for this issue, as well as update the links to reference a fixed commit hash or tag?

Comment by Stuart Carnie [ 19/Aug/14 ]

Marco Pivetta, I've updated the URIs in the description to the right tree

Comment by Marco Pivetta [ 19/Aug/14 ]

The code explicitly forbids inheriting listeners when the child class does not have any.

Fabio B. Silva can you provide any insight on why this decision was made?





[DDC-3258] [GH-1113] Added support for composite primary key on findBy methods and Criteria Created: 18/Aug/14  Updated: 19/Aug/14

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

Issue Links:
Duplicate
is duplicated by DDC-3260 [GH-1114] Composite pk break test Resolved

 Description   

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

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

Message:

Hi!
I tried to implement the matching of entities that uses composite primary keys...

Any suggestion?






[DDC-3117] [GH-1027] Support for Partial Indexes for PostgreSql and Sqlite Created: 07/May/14  Updated: 19/Aug/14

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: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mapping, postgresql, sqlite

Issue Links:
Dependency
depends on DBAL-900 [GH-600] Support for Partial Indexes ... Resolved

 Description   

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

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

Message:

Support for Partial Indexes was available in Doctrine 1 following
http://www.doctrine-project.org/jira/browse/DC-82. This commit
reintroduce support for Doctrine 2. We use the same syntax with an
optionnal "where" attribute for Index and UniqueConstraint.

It is unit-tests covered and documented in manual. This Pull Request depends on https://github.com/doctrine/dbal/pull/600. So they should both be merged or rejected together.

Thanks for your time !



 Comments   
Comment by Adrien Crivelli [ 07/May/14 ]

This patch depends on DBAL-900. So they should both be merged or rejected together.

Comment by Doctrine Bot [ 16/May/14 ]

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

Comment by Doctrine Bot [ 02/Aug/14 ]

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

Comment by Doctrine Bot [ 19/Aug/14 ]

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





[DDC-2695] Order by clause left in subquery when using MSSQL and Paginator Created: 20/Sep/13  Updated: 18/Aug/14

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

Windows, Microsoft SQL Server



 Description   

When using the Doctrine paginator and Fetch Join Collections = true and when the original query has an "ORDER BY" clause in it - the subquery created is something like "SELECT DISTINCT FROM (.... ORDER BY ....) as dctrn_result" - when using Microsoft SQL server having the "ORDER BY" clause in a subquery throws an error. This is a similar problem to http://doctrine-project.org/jira/browse/DDC-2282 but that was for the Count Walker - this is for the LimitSubqueryOutputWalker. The fix is the same.



 Comments   
Comment by Paul Mansell [ 20/Sep/13 ]

Problem still occurs in 2.4 - but different error message,

Query :

SELECT * FROM (SELECT DISTINCT id0, ROW_NUMBER() OVER (ORDER BY c1_.iccid ASC) AS doctrine_rownum FROM (SELECT w0_.id AS id0, w0_.batch_id AS batch_id1, c1_.id AS id2, c1_.iccid AS iccid3, c2_.id AS id4, c2_.msisdn AS msisdn5, c3_.id AS id6, c3_.name AS name7, c4_.id AS id8, c5_.id AS id9, c5_.name AS name10, w6_.id AS id11, w6_.created AS created12, w7_.id AS id13, w7_.ident AS ident14, w8_.id AS id15, w8_.ident AS ident16, c9_.id AS id17, c10_.id AS id18, c10_.contract_length AS contract_length19, c10_.rental AS rental20, w11_.id AS id21, w11_.ident AS ident22 FROM workflow_request w0_ WITH (NOLOCK) INNER JOIN core_sim c1_ ON w0_.sim = c1_.id LEFT JOIN core_connection c2_ ON c1_.active_connection_id = c2_.id INNER JOIN core_billing_account c3_ ON c1_.billing_account_id = c3_.id INNER JOIN core_mno_account c4_ ON c1_.mno_account_id = c4_.id INNER JOIN core_mno c5_ ON c4_.mno_id = c5_.id INNER JOIN workflow_request_log w6_ ON w0_.id = w6_.request INNER JOIN workflow_action w7_ ON w0_.action = w7_.id INNER JOIN workflow_request_status w8_ ON w0_.status = w8_.id INNER JOIN core_customer_solution c9_ ON w0_.customer_solution = c9_.id INNER JOIN core_customer_tariff c10_ ON c9_.customer_tariff_id = c10_.id INNER JOIN workflow_request_action w11_ ON w6_.request_action = w11_.id WHERE w7_.ident IN (?) AND w8_.ident = ? AND w11_.ident = ?) dctrn_result) AS doctrine_tbl WHERE doctrine_rownum BETWEEN 1 AND 25' with params ["activate", "network", "approved"]

Error :

SQLSTATE[42000]: [Microsoft][SQL Server Native Client 11.0][SQL Server]The multi-part identifier "c1_.iccid" could not be bound.





[DDC-2835] No Lock Hint on Joins Created: 03/Dec/13  Updated: 18/Aug/14

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

Microsoft SQL Server 2008/2012



 Description   

There seems to be no lock hits added to the joins on a query. For example, take the following query :

SELECT w0_.name AS name0, w1_.name AS name1, c2_.name AS name2, count(w3_.id) AS sclr3 FROM workflow_request w3_ WITH (NOLOCK) INNER JOIN workflow_request_status w1_ ON w3_.status_id = w1_.id INNER JOIN workflow_action w0_ ON w3_.action_id = w0_.id LEFT JOIN workflow_transition w4_ ON w3_.transition_id = w4_.id INNER JOIN core_mno_account c5_ ON w4_.mno_account_id = c5_.id INNER JOIN core_mno c2_ ON c5_.mno_id = c2_.id LEFT JOIN workflow_state w6_ ON w3_.current_state_id = w6_.id WHERE w1_.ident IN (?) GROUP BY w0_.name, w1_.name, c2_.name ORDER BY w0_.name ASC, w1_.name ASC, c2_.name ASC [["waiting"]]

the with(nolock) is only added to the FROM clause .... it should be added after each join too






[DDC-2881] [GH-895] Fix for no dot on Class Names Created: 04/Jan/14  Updated: 18/Aug/14

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

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


 Description   

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

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

Message:

If you work with PostgreSQL Schemas, You should filter the names of table to generate Correct name for PHP Classes. This way allow not write dots (.) as part of the Class Name.

Additionally, there is a variable ($schema) that must be contained in the class "Doctrine\DBAL\Schema\Table" on an $schema possible property but this is not available. (recomended)






[DDC-2922] Flushing new Entities reachable over several paths that do not all "cascade persist" Created: 17/Jan/14  Updated: 18/Aug/14

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

Type: Bug Priority: Major
Reporter: Matthias Pigulla Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None


 Description   

Please consider the following associations:

  A <>--> B <-- C  

A is an "aggregate" type object w/ a OneToMany collection of Bs. This association is set to cascade persist operations.

C has a unidirectional OneToOne association to B as well.

Adding a new B to A's collection and flushing the EntityManager works - B is persisted (persistence by reachability).

However, when also creating a new C and pointing it to the new B, adding C to the EntityManager and then flushing leads to an exception because B is discovered as a new Entity through a relationship not set to cascade persist operations.

Obviously the problem here is that there are two paths through which we can discover new Entities. The UoW currently starts search from newly (explicitly) added Entities first before it walks through collections of already-managed entities.

I am unsure if it is just a documentation issue or a deeper problem?

If the UoW worked the other way round, the same problem would occur if the cascade persist was on the other association.

A solution would probably require the UoW to first collect all offending (new) Entities and the link they were discovered through, but later on remove Entities from this list if they are found through another association with the cascade persist option. The exception must not be thrown unless the whole reachability graph has been traversed.



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

Can this be factored into a failing test case? I'm not sure if we can support it, but the code would make it much easier to track down the issue into something fixable.





[DDC-2945] [GH-925] [DDC-2310] [DDC-2675] [2.4] Fix SQL generation on table lock hint capable platforms Created: 31/Jan/14  Updated: 18/Aug/14

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

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


 Description   

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

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

Message:

Backport of PR https://github.com/doctrine/doctrine2/pull/910 for 2.4 branch.






[DDC-2953] ArrayHydrator: Not all items hydrated while orderBy Created: 05/Feb/14  Updated: 18/Aug/14

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

Type: Bug Priority: Critical
Reporter: Mariusz Jaskółka Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: array, hydration
Environment:

Linux and Windows, PHP5


Attachments: File ArrayHydrator.php     File Array_Hydrator_4.2.php     File Array_hydrator_4.2_bugfix.php    
Issue Links:
Dependency
depends on DDC-2955 [GH-933] [WIP] DDC-2953 Resolved

 Description   

I will explain the problem using example and pseudo-code:

I have query like that:
SELECT (...) FROM order LEFT JOIN person LEFT JOIN identifier (...) order by (...)

The rows returned by query are following (the order is very important):
order_id|person_id|identifier_id|
12 |21 |33 |
12 |21 |34 |
11 |21 |35 |
11 |21 |33 |
11 |21 |34 |
12 |21 |35 |

After hydration the result is like:
result[0][person][identifier][0][id]=33
result[0][person][identifier][0][id]=34
result[1][person][identifier][0][id]=35
result[1][person][identifier][0][id]=34

But it should be:
result[0][person][identifier][0][id]=33
result[0][person][identifier][0][id]=34
result[0][person][identifier][0][id]=35
result[1][person][identifier][0][id]=35
result[1][person][identifier][0][id]=34
result[1][person][identifier][0][id]=33

The reason is that ArrayHydrator::_identifierMap contains only object id and parents object id. In may example there is difference in parents parent (grandparent) id.



 Comments   
Comment by Marco Pivetta [ 05/Feb/14 ]

I've started work on this at https://github.com/doctrine/doctrine2/pull/933

Comment by Mariusz Jaskółka [ 06/Feb/14 ]

This is how I temporary solved the issue, maybe it can help (attachment).

Comment by Marco Pivetta [ 06/Feb/14 ]

Mariusz Jaskółka can you provide a diff with current master? This seems to be based off 2.3 or previous versions...

Comment by Mariusz Jaskółka [ 06/Feb/14 ]

Version 2.4.2 oryginal file and bugfix

Comment by Mariusz Jaskółka [ 06/Feb/14 ]

Oh sorry it is version 2.4.1 (composer downloaded that version for me).
I hope it will be ok.

Comment by Marco Pivetta [ 06/Feb/14 ]

Mariusz Jaskółka thanks! I'm trying it right now

Comment by Mariusz Jaskółka [ 06/Feb/14 ]

I added one dimention to $this->_identifierMap to be sure that all object's children's keys will be mapped separately.

Comment by Marco Pivetta [ 06/Feb/14 ]

Mariusz Jaskółka, I've applied your hotfix at https://github.com/doctrine/doctrine2/commit/c05921032ff6947daca2d7275031e5cde4700634 and the tests seem to pass on my system and on travis. You may want to check it out and see if it works for your use case.

Comment by Mariusz Jaskółka [ 06/Feb/14 ]

It works for my use case correctly. You apparently forgot to remove/comment line 82 which is not necessary now.

Comment by Marco Pivetta [ 06/Feb/14 ]

Mariusz Jaskółka fixed, thanks!

Comment by Marco Pivetta [ 14/Jul/14 ]

I don't think we'll have a fix for this issue for 2.5, as it will probably require a complete rewrite of the array hydrator

Comment by Guilherme Blanco [ 14/Jul/14 ]

... and introducing BC breaks.

Comment by Doctrine Bot [ 18/Aug/14 ]

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





[DDC-3005] Events::postLoad fires without filled associations Created: 02/Mar/14  Updated: 18/Aug/14

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

Type: Bug Priority: Major
Reporter: Artur Eshenbrener Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Dependency
depends on DDC-3070 [GH-1001] [DDC-3005] Defer invoking o... Open

 Description   

When we load entities throw one dql query like this:

SELECT e, joined_link FROM Entity LEFT JOIN e.link joined_link

In event subscriber, subscribed to postLoad event for instances of Entity property "link" of entity does not contains fetched in same query joined entity, and does not contains proxy object.

Tell me if failing test case needed.



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

The postLoad event is fired without warranty that association entities/proxies will be set:

http://docs.doctrine-project.org/en/latest/reference/events.html#lifecycle-events

Comment by Artur Eshenbrener [ 03/Mar/14 ]

But why? This shounds like involuntary restriction, and I think it can be fixed. Will my PR with fix accepted, or collaborators don't want to change this behaviour?

Comment by Marco Pivetta [ 03/Mar/14 ]

Artur Eshenbrener triggering `postLoad` in the correct moment in time (when all dependencies are loaded) requires a lot of additional complexity to be inserted in various locations of the ORM.

Since `postLoad` is supposed to be used like `__wakeup` and in general for simple tasks, this kind of refactoring/rewrite would be an overkill.

Comment by Artur Eshenbrener [ 04/Mar/14 ]

> requires a lot of additional complexity to be inserted in various locations of the ORM.
Sounds like "It is very hard to implement, and no one want to do this"

> and in general for simple tasks, this kind of refactoring/rewrite would be an overkill.
Disagree with this. Why only simple? I need to deal with associations in this event. Without this I should inject whole EntityManager to my entity, but I dont want to do this.

And I forced to repeat the question: will PR with fix accepted or not?

Comment by Marco Pivetta [ 04/Mar/14 ]

Sounds like "It is very hard to implement, and no one want to do this"

Not really, the main problem here is performance, since hydration would have to be completely redesigned.
Yes, "too hard" is a good reason for something that is an edge case.

And I forced to repeat the question: will PR with fix accepted or not?

Sure thing! Just needs to avoid a massive rewrite though.

Comment by Marco Pivetta [ 04/Mar/14 ]

To give you some hints, Doctrine\ORM\Events::postLoad is triggered in https://github.com/doctrine/doctrine2/blob/15432fc55f83c2d6ce8d9b86fd3139dd2a4fc328/lib/Doctrine/ORM/UnitOfWork.php#L2788, and Doctrine\ORM\UnitOfWork#createEntity() is used by all the various hydrators internally.

To ensure that Doctrine\ORM\Events::postLoad is triggered after an entity is fully loaded, the various hydrators must trigger the events after being sure that all data has been set, and that the entity is "ready" for use. That's some copy-paste work :\

Comment by Artur Eshenbrener [ 04/Mar/14 ]

I think the entry point is here: https://github.com/doctrine/doctrine2/blob/15432fc55f83c2d6ce8d9b86fd3139dd2a4fc328/lib/Doctrine/ORM/Internal/Hydration/AbstractHydrator.php#L140,
so, copy-paste work is not needed )

Comment by Artur Eshenbrener [ 05/Apr/14 ]

PR is ready: https://github.com/doctrine/doctrine2/pull/1001





[DDC-3070] [GH-1001] [DDC-3005] Defer invoking of postLoad event to the end of hydration cycle. Created: 04/Apr/14  Updated: 18/Aug/14

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

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

Issue Links:
Dependency
is required for DDC-3005 Events::postLoad fires without filled... Reopened

 Description   

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

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

Message:

This feature makes guarantee, that postLoad event fires after all associations are populated.
Test case also provided.






[DDC-3025] Mapping drivers do not honor scale or precision for identifier fields Created: 12/Mar/14  Updated: 18/Aug/14

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

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


 Description   

FYI. I don't use doctrine but with symfony2, and only use .yml or .xml mapping. Not yet try with annotation.

These commands :

php app\console doctrine:schema:update
php app\console doctrine:schema:create

Will not generate id's precision and scale for this kind of mapping :

<doctrine-mapping .....>
  <entity name="Namespace\MyBundle\Entity\MyData" table="my_data">
    <id name="id" type="decimal" column="id" precision="x" scale="y">
      <generator strategy="IDENTITY"/>
    </id>
    <field ... />
  </entity>
</ ....>

Suggested changes :

  • Doctrine\ORM\Mapping\Driver\YamlDriver.php
  • Doctrine\ORM\Mapping\Driver\XmlDriver.php





[DDC-3044] [GH-986] Add last modified time for metadata Created: 22/Mar/14  Updated: 18/Aug/14

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

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

Message:

This patch improves performance during development and does not affect production performance.

Currently, enabling the metadata cache during development gives a remarkable performance boost, but it requires that you manually flush the metadata cache when the metadata has been changed. When running console commands such as ``console orm:schema-tool:update`` (see #979).

With this change, metadata entries fetched from cache are checked for freshness using a quick last modified check. This is much faster than loading the actual metadata using the metadata driver. This allows you to enable the metadata cache during development without the need for manually flushing the metadata cache.

This PR is part 1 of 2. Part 2 is for the doctrine/common repository.

If this PR is accepted, it allows us to optimize the auto-generate proxy classes feature by comparing the last modified time for the metadata with the modified timestamp of the generated file.






[DDC-3088] EntityManager::clear doesn't working with inserting Created: 16/Apr/14  Updated: 18/Aug/14

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

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

PHP 5.4.25-1+sury.org~precise+2 (cli) (built: Feb 12 2014 10:45:30)
Symfony version 2.4.2 - app/dev/debug



 Description   

It looks like EntityManager's clear() method doesn't remove objects that was persisted during script execution.

Bellows are two functions. First one insert 10.000 records and use clear after each flush that should remove objects from memory, but instead of that memory usage growths in each iteration. There isn't any other reference for this objects.

I've checked how it works for reading and with clearing it works perfectly - script uses only constant memory.

 
    private function testInserting($em, $entityClass, $batchSize, $startMemoryUsage)
    {
        for ($i = 1; $i <= 10000; ++$i) {

            $item = new $entityClass();
            $item->setName($i);
            $item->setPresentation($i);
            $em->persist($item);

            if ($i % $batchSize == 0) {
                $em->flush();
                $em->clear();

                $currentMemoryUsage = memory_get_usage();
                printf("%d:\n\t%.2f MB (%.2f MB)\n", $i, $currentMemoryUsage /1024 / 1024, ($currentMemoryUsage - $startMemoryUsage) / 1024 / 1024);
            }
        }
    }
    
    
private function testReading($em, $entityClass, $batchSize, $startMemoryUsage)
    {
        $q = $em->createQuery("select i from $entityClass i");
        $iterableResult = $q->iterate();

        $i = 0;
        while (($row = $iterableResult->next()) !== false) {
            $em->clear();
            if ($i % $batchSize == 0) {
                $currentMemoryUsage = memory_get_usage();
                printf("%d:\n\t%.2f MB (%.2f MB)\n", $i, $currentMemoryUsage /1024 / 1024, ($currentMemoryUsage - $startMemoryUsage) / 1024 / 1024);
            }

            $i++;
        }
    }
    

My results:

1) Reading without clearing ($em->clear(); removed)

0:
22.89 MB (2.63 MB)
1000:
33.41 MB (13.15 MB)
2000:
44.04 MB (23.78 MB)
3000:
53.50 MB (33.24 MB)
4000:
65.13 MB (44.86 MB)
5000:
74.81 MB (54.55 MB)
6000:
84.27 MB (64.01 MB)
7000:
97.96 MB (77.69 MB)
8000:
107.40 MB (87.14 MB)
9000:
117.17 MB (96.91 MB)
10000:
126.61 MB (106.35 MB)

2) Reading with using clear

0:
22.89 MB (2.63 MB)
1000:
26.25 MB (5.99 MB)
2000:
24.74 MB (4.48 MB)
3000:
26.72 MB (6.46 MB)
4000:
24.79 MB (4.52 MB)
5000:
26.76 MB (6.50 MB)
6000:
24.81 MB (4.55 MB)
7000:
26.77 MB (6.51 MB)
8000:
24.83 MB (4.57 MB)
9000:
26.81 MB (6.54 MB)
10000:
24.86 MB (4.60 MB)

3) Inserting without clearing

1000:
29.50 MB (9.24 MB)
2000:
37.76 MB (17.50 MB)
3000:
45.12 MB (24.86 MB)
4000:
54.34 MB (34.07 MB)
5000:
61.79 MB (41.53 MB)
6000:
69.09 MB (48.82 MB)
7000:
76.40 MB (56.13 MB)
8000:
83.75 MB (63.48 MB)
9000:
95.64 MB (75.37 MB)
10000:
102.98 MB (82.71 MB)

4) Inserting with using clear

1000:
27.90 MB (7.63 MB)
2000:
34.64 MB (14.37 MB)
3000:
40.43 MB (20.17 MB)
4000:
48.20 MB (27.93 MB)
5000:
54.12 MB (33.85 MB)
6000:
59.89 MB (39.63 MB)
7000:
65.67 MB (45.40 MB)
8000:
71.43 MB (51.16 MB)
9000:
81.51 MB (61.25 MB)
10000:
87.29 MB (67.02 MB)



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

Would be useful to see what the entity class looks like.

Additionally, the ORM version being affected is also needed.





[DDC-3231] [GH-1089] Entity repository generator default repository Created: 27/Jul/14  Updated: 18/Aug/14

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

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


 Description   

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

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

Message:

1) I set default repository class in configuration to MyApp\Doctrine\DefaultRepository
2) I created entity class MyApp\Entity\TestEntity and generated repository class for it
3) Actually the repository class "MyApp\Entity\TestEntityRepository" turned out to be a descendant of "Doctrine\ORM\EntityRepository" when I expected "MyApp\Doctrine\DefaultRepository" as default.

Related pull request https://github.com/doctrine/DoctrineBundle/pull/315






[DDC-3238] GROUP BY does not work as expected in MS SQL Server Created: 31/Jul/14  Updated: 18/Aug/14

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

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

MS SQL Server 2012



 Description   

Running the query taken from this page: <http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/dql-doctrine-query-language.html>

$query = $em->createQuery('SELECT u, count(g.id) FROM FundAsset u JOIN u.locations g GROUP BY u.id');

I receive the following error from MS SQL Server:

SQLSTATE[42000]: [Microsoft][SQL Server Native Client 11.0][SQL Server]Column 'fund_assets.active' is invalid in the select list because it is not contained in either an aggregate function or the GROUP BY clause.

It appears that Doctrine's GROUP BY clause does not work correctly in Microsoft SQL Server.



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

Needs a failing test case.





[DDC-3246] [GH-1103] Update Expr.php Created: 09/Aug/14  Updated: 18/Aug/14

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

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


 Description   

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

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

Message:

adding NOT EXISTS statement



 Comments   
Comment by Doctrine Bot [ 18/Aug/14 ]

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





[DDC-3251] Segmentation fault in ClassMetadataInfo.php Created: 12/Aug/14  Updated: 18/Aug/14

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

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

Linux dev1 3.9.9-302.fc19.x86_64 #1 SMP Sat Jul 6 13:41:07 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Fedora release 19 (Schrödinger’s Cat)

PHP 5.5.14 (cli) (built: Jul 16 2014 11:41:07)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies
with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2014, by Zend Technologies
with Xdebug v2.2.5, Copyright (c) 2002-2014, by Derick Rethans

Doctrine Command Line Interface version 2.3.6-DEV



 Description   

I'm seeing a segfault when doing a EntityManager->merge(). Specifically, when on this line in ClassmetadataInfo.php. Details below.

$value = $this->reflFields[$this->identifier[0]]->getValue($entity);

/var/log/messages

Aug 12 08:39:01 dev1 kernel: [62152.629221] php[3539]: segfault at f434172bd1 ip 00007ff432c3aae9 sp 00007fffa060b1b0 error 4 in php[7ff4329e7000+38c000]

strace

--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xc4f1053d11} ---
+++ killed by SIGSEGV ++

gdb backtrace:

(gdb) bt
#0  0x00007f8c8f5ceae9 in zend_std_read_property ()
#1  0x00007f8c8f5b61d7 in zend_read_property ()
#2  0x00007f8c8f4ab66e in zim_reflection_property_getValue ()
#3  0x00007f8c8f59a4ab in dtrace_execute_internal ()
#4  0x00007f8c8abb9a46 in xdebug_execute_internal () from /usr/lib64/php/modules/xdebug.so
#5  0x00007f8c8f65a895 in zend_do_fcall_common_helper_SPEC ()
#6  0x00007f8c8f5d45c8 in execute_ex ()
#7  0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#8  0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#9  0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#10 0x00007f8c8f5d45c8 in execute_ex ()
#11 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#12 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#13 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#14 0x00007f8c8f5d45c8 in execute_ex ()
#15 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#16 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#17 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#18 0x00007f8c8f5d45c8 in execute_ex ()
#19 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#20 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#21 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#22 0x00007f8c8f5d45c8 in execute_ex ()
#23 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#24 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#25 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#26 0x00007f8c8f5d45c8 in execute_ex ()
#27 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#28 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#29 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#30 0x00007f8c8f5d45c8 in execute_ex ()
#31 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#32 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#33 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#34 0x00007f8c8f5d45c8 in execute_ex ()
#35 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#36 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#37 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#38 0x00007f8c8f5d45c8 in execute_ex ()
#39 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#40 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#41 0x00007f8c8f659852 in ZEND_INCLUDE_OR_EVAL_SPEC_VAR_HANDLER ()
#42 0x00007f8c8f5d45c8 in execute_ex ()
#43 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#44 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#45 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#46 0x00007f8c8f5d45c8 in execute_ex ()
#47 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#48 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#49 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#50 0x00007f8c8f5d45c8 in execute_ex ()
#51 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#52 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
---Type <return> to continue, or q <return> to quit---
#53 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#54 0x00007f8c8f5d45c8 in execute_ex ()
#55 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#56 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#57 0x00007f8c8f659852 in ZEND_INCLUDE_OR_EVAL_SPEC_VAR_HANDLER ()
#58 0x00007f8c8f5d45c8 in execute_ex ()
#59 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#60 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#61 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#62 0x00007f8c8f5d45c8 in execute_ex ()
#63 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#64 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#65 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#66 0x00007f8c8f5d45c8 in execute_ex ()
#67 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#68 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#69 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#70 0x00007f8c8f5d45c8 in execute_ex ()
#71 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#72 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#73 0x00007f8c8f659852 in ZEND_INCLUDE_OR_EVAL_SPEC_VAR_HANDLER ()
#74 0x00007f8c8f5d45c8 in execute_ex ()
#75 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#76 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#77 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#78 0x00007f8c8f5d45c8 in execute_ex ()
#79 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#80 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#81 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#82 0x00007f8c8f5d45c8 in execute_ex ()
#83 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#84 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#85 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#86 0x00007f8c8f5d45c8 in execute_ex ()
#87 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#88 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#89 0x00007f8c8f659852 in ZEND_INCLUDE_OR_EVAL_SPEC_VAR_HANDLER ()
#90 0x00007f8c8f5d45c8 in execute_ex ()
#91 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#92 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#93 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#94 0x00007f8c8f5d45c8 in execute_ex ()
#95 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#96 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#97 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#98 0x00007f8c8f5d45c8 in execute_ex ()
#99 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#100 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#101 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#102 0x00007f8c8f5d45c8 in execute_ex ()
#103 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#104 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#105 0x00007f8c8f5abed0 in zend_execute_scripts ()
---Type <return> to continue, or q <return> to quit---
#106 0x00007f8c8f54bc65 in php_execute_script ()
#107 0x00007f8c8f65c8a8 in do_cli ()
#108 0x00007f8c8f436420 in main ()

xdebug trace:

   54.4457   16731856                                           -> Tekelec\DVAT\Service\TagService->createTag() /home/vagrant/dvat/library/Tekelec/DVAT/Service/TagService.php:51
   54.4457   16731856                                             -> Doctrine\ORM\EntityManager->merge() /home/vagrant/dvat/library/Tekelec/DVAT/Service/TagService.php:28
   54.4457   16731904                                               -> is_object() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php:632
   54.4457   16731856                                               -> Doctrine\ORM\EntityManager->errorIfClosed() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php:636
   54.4457   16731856                                               -> Doctrine\ORM\UnitOfWork->merge() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php:638
   54.4458   16731992                                                 -> Doctrine\ORM\UnitOfWork->doMerge() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1701
   54.4458   16732136                                                   -> spl_object_hash() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1744
   54.4458   16732448                                                   -> get_class() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1752
   54.4458   16732496                                                   -> Doctrine\ORM\EntityManager->getClassMetadata() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1752
   54.4458   16732496                                                     -> Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->getMetadataFor() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php:268
   54.4458   16732448                                                   -> Doctrine\ORM\UnitOfWork->getEntityState() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1760
   54.4458   16732496                                                     -> spl_object_hash() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1367
   54.4458   16732400                                                   -> Doctrine\ORM\Mapping\ClassMetadataInfo->getIdentifierValues() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1766
   54.4458   16732448                                                     -> ReflectionProperty->getValue() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php:672

The reproducing steps are complicated and require propriety code, but this happens most of the time (80+ percent).

Here is the php bug for this: https://bugs.php.net/bug.php?id=67828



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

Did you try clearing your opcode caches? Is this reproducible in insulated environment?

Comment by Kshitij Parajuli [ 12/Aug/14 ]

Yes, I tried clearing the opcode caches (and clearing proxies and restarting the server). This was also reproducible in multiple servers (one production and one development).

It is not yet reproducible in isolated environment, but I am looking at it. Will update the ticket if I find easy reproducing steps.

Comment by Benjamin Eberlei [ 12/Aug/14 ]

Please try without xdebug, this is enabled according to stacktrace.





[DDC-3146] Hydrator memory leak when using iterator Created: 30/May/14  Updated: 14/Aug/14

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

Type: Bug Priority: Major
Reporter: Emiel Nijpels Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: hydrator, leak, memory
Environment:

PHP 5.4.21, OS X 10.9.3; PHP 5.3.28, OS X 10.9.4



 Description   

When the hydrator iterate() function is invoked, a new event is added to the event manager with a reference to the current hydrator object. This reference is never cleared which causes the hydrator object to never be cleared from memory by the PHP garbage collection.

/doctrine/orm/lib/Doctrine/ORM/Internal/Hydration/AbstractHydrator.php
$evm = $this->_em->getEventManager();
$evm->addEventListener(array(Events::onClear), $this);

The effects of this bug are best visible when creating multiple iterator objects after each other in a repository:

// Loop through test code 10 times
for ($f = 0; $f < 10; $f++) {
    // Create test query
    $query = $this->createQueryBuilder('p')->getQuery();

    // Create IterableResult object
    $iterableResult = $query->iterate();

    // Loop through the iterator
    foreach ($iterableResult as $row) {}

    // Print out memory usage
    print(memory_get_usage() . PHP_EOL);
}

This results in the following output:

10536552
10549920
10563288
10576664
10590040
10603416
10616792
10630168
10643608
10656984

Notice how the used memory increases by about 13KB after each iteration.
To stop this memory leak the following code can be added to the end of the cleanup() function in the AbstractHydrator class:

$evm = $this->_em->getEventManager();
$evm->removeEventListener(array(Events::onClear), $this);

The output is now:

10537920
10537048
10537048
10537048
10537048
10537048
10537048
10537048
10537048
10537048

The reference to the event manager is now automatically removed in the cleanup function which allows the hydrator object to be cleaned up by the garbage collection function in PHP.



 Comments   
Comment by Jeremiah Johnson [ 12/Aug/14 ]

I'm experiencing the same problem on 2.3.2

Comment by Jeremiah Johnson [ 14/Aug/14 ]

Tested latest of 2.3.x (2.3.5) and problem still exists.

Comment by Marco Pivetta [ 14/Aug/14 ]

Jeremiah Johnson can you provide a PR with the fix and a test?





[DDC-3248] PreUpdateEventArgs::setNewValue() does not update Entity state Created: 11/Aug/14  Updated: 11/Aug/14

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

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


 Description   

see https://github.com/doctrine/doctrine2/commit/bc6714c2c8d015cb2e3ae198fcb1b98b3bbe35e0#commitcomment-7329820

as well as https://github.com/doctrine/phpcr-odm/pull/539#discussion_r16027731






[DDC-1695] SQLs for PostgreSQL case sensite tables/fields are wrongly generated Created: 09/Mar/12  Updated: 06/Aug/14

Status: Reopened
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: 2.1.6, 2.4.2
Fix Version/s: 2.1.7, 2.2.2
Security Level: All

Type: Bug Priority: Major
Reporter: Ignacio Larranaga Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: None
Environment:

PostgreSQL 9.x, Symfony 2


Attachments: Text File doctrine-2.1.6.patch     Text File SqlWalker.patch    

 Description   

The SQLs for case sensitive schemas in postgreSQL are wronly generated.

Example:
Schema:

CREATE TABLE "News" (
  "IdNews" serial NOT NULL,
  "IdUser" bigint NOT NULL,
  "IdLanguage" integer NOT NULL,
  "IdCondition" integer,
  "IdHealthProvider" integer,
  "IdSpeciality" integer,
  "IdMedicineType" integer,
  "IdTreatment" integer,
  "Title" character varying,
  "SmallText" character varying,
  "LongText" character varying,
  "PublishDate" timestamp with time zone,
  "IdxNews" tsvector,
  "Highlight" boolean NOT NULL DEFAULT false,
  "Order" integer NOT NULL DEFAULT 0,
  "Deleted" boolean NOT NULL DEFAULT false,
  "Active" boolean NOT NULL DEFAULT false,
  "UpdateToHighlighted" boolean DEFAULT false,
  CONSTRAINT "News_pkey" PRIMARY KEY ("IdNews" ));

Object (I added quotes trying to generate the SQLs quoted.:

<?php

namespace GlobalTreatments\ApplicationBundle\Entity;

use Doctrine\ORM\Mapping as ORM;

/**
 * @ORM\Table(name="""News""")
 * @ORM\Entity
 */
class News
{
    /**
     * @var integer $idNews
     *
     * @ORM\Column(name="""IdNews""", type="integer", nullable=false)
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="SEQUENCE")
     * @ORM\SequenceGenerator(sequenceName="""News_IdNews_seq""", allocationSize="1", initialValue="1")
     */
    private $idNews;

    /**
     * @var bigint $iduser
     *
     * @ORM\Column(name="""IdUser""", type="bigint", nullable=false)
     */
    private $idUser;

    /**
     * @var integer $idLanguage
     *
     * @ORM\Column(name="""IdLanguage""", type="integer", nullable=false)
     */
    private $idLanguage;

    /**
     * @var integer $idCondition
     *
     * @ORM\Column(name="""IdCondition""", type="integer", nullable=true)
     */
    private $idCondition;

    /**
     * @var integer $idHealthProvider
     *
     * @ORM\Column(name="""IdHealthProvider""", type="integer", nullable=true)
     */
    private $idHealthProvider;

    /**
     * @var integer $idSpeciality
     *
     * @ORM\Column(name="""IdSpeciality""", type="integer", nullable=true)
     */
    private $idSpeciality;

    /**
     * @var integer $idMedicineType
     *
     * @ORM\Column(name="""IdMedicineType""", type="integer", nullable=true)
     */
    private $idMedicineType;

    /**
     * @var integer $idTreatment
     *
     * @ORM\Column(name="""IdTreatment""", type="integer", nullable=true)
     */
    private $idTreatment;

    /**
     * @var string $title
     *
     * @ORM\Column(name="""Title""", type="string", nullable=true)
     */
    private $title;

    /**
     * @var string $smallText
     *
     * @ORM\Column(name="""SmallText""", type="string", nullable=true)
     */
    private $smallText;

    /**
     * @var string $longText
     *
     * @ORM\Column(name="""LongText""", type="string", nullable=true)
     */
    private $longText;

    /**
     * @var datetimetz $publishDate
     *
     * @ORM\Column(name="""PublishDate""", type="datetimetz", nullable=true)
     */
    private $publishDate;

    /**
     * @var tsvector $idxNews
     *
     * @ORM\Column(name="""IdxNews""", type="tsvector", nullable=true)
     */
    private $idxNews;

    /**
     * @var boolean $highlight
     *
     * @ORM\Column(name="""Highlight""", type="boolean", nullable=false)
     */
    private $highlight;

    /**
     * @var integer $order
     *
     * @ORM\Column(name="""Order""", type="integer", nullable=false)
     */
    private $order;

    /**
     * @var boolean $deleted
     *
     * @ORM\Column(name="""Deleted""", type="boolean", nullable=false)
     */
    private $deleted;

    /**
     * @var boolean $active
     *
     * @ORM\Column(name="""Active""", type="boolean", nullable=false)
     */
    private $active;

    /**
     * @var boolean $updateToHighlighted
     *
     * @ORM\Column(name="""UpdateToHighlighted""", type="boolean", nullable=true)
     */
    private $updateToHighlighted;

    /**
     * @var condition
     *
     * @ORM\ManyToOne(targetEntity="Condition")
     * @ORM\JoinColumns({
     *   @ORM\JoinColumn(name="""IdCondition""", referencedColumnName="""IdCondition""")
     * })
     */
    private $condition;

    /**
     * @var healthProvider
     *
     * @ORM\ManyToOne(targetEntity="HealthProvider")
     * @ORM\JoinColumns({
     *   @ORM\JoinColumn(name="""IdHealthProvider""", referencedColumnName="""IdHealthProvider""")
     * })
     */
    private $healthProvider;

    /**
     * @var language
     *
     * @ORM\ManyToOne(targetEntity="Language")
     * @ORM\JoinColumns({
     *   @ORM\JoinColumn(name="""IdLanguage""", referencedColumnName="""IdLanguage""")
     * })
     */
    private $language;

    /**
     * @var medicineType
     *
     * @ORM\ManyToOne(targetEntity="MedicineType")
     * @ORM\JoinColumns({
     *   @ORM\JoinColumn(name="""IdMedicineType""", referencedColumnName="""IdMedicineType""")
     * })
     */
    private $medicineType;

    /**
     * @var speciality
     *
     * @ORM\ManyToOne(targetEntity="Speciality")
     * @ORM\JoinColumns({
     *   @ORM\JoinColumn(name="""IdSpeciality""", referencedColumnName="""IdSpeciality""")
     * })
     */
    private $speciality;

    /**
     * @var treatment
     *
     * @ORM\ManyToOne(targetEntity="Treatment")
     * @ORM\JoinColumns({
     *   @ORM\JoinColumn(name="""IdTreatment""", referencedColumnName="""IdTreatment""")
     * })
     */
    private $treatment;

    /**
     * @var user
     *
     * @ORM\ManyToOne(targetEntity="User")
     * @ORM\JoinColumns({
     *   @ORM\JoinColumn(name="""IdUser""", referencedColumnName="""IdUser""")
     * })
     */
    private $user;

    ....

}

DQL:

'SELECT n.smallText, n.publishDate ' .
'FROM News n ' .
	'INNER JOIN n.language la ' .
'WHERE la.languageCode = :languageCode ' .
'ORDER BY n.publishDate DESC'

Generated SQL:

SELECT "0_."SmallText" AS "SmallText"0, "0_."PublishDate" AS "PublishDate"1 FROM "News" "0_ INNER JOIN "Language" "1_ ON "0_."IdLanguage" = "1_."IdLanguage" WHERE "1_."LanguageCode" = ? ORDER BY "0_."PublishDate" DESC LIMIT 6

Notice there are unmattched " in the SQL.



 Comments   
Comment by Ignacio Larranaga [ 09/Mar/12 ]

If there is another approach to specify the table/column names are case sensitive in PGSQL please let me know.

Comment by Ignacio Larranaga [ 09/Mar/12 ]

Just to comment. I also tried the normal quoting.

Example: @ORM\Column(name="`IdNews`", type="integer", nullable=false)

And does not work too because of the same reason.

Comment by Ignacio Larranaga [ 09/Mar/12 ]

Hi, I generate this patch and seems to be working for me (at least what I'm testing right now).

I used ´ to quote tables and single attributes (not relationships) and the SQLs are correctly generated.

Comment by Ignacio Larranaga [ 09/Mar/12 ]

Adding a new patch for another files I need to change.

Comment by Benjamin Eberlei [ 11/Mar/12 ]

Formatted code

Comment by Benjamin Eberlei [ 11/Mar/12 ]

Fixed and merged into 2.1.x and 2.2 branches

Comment by Julian Aicardo [ 05/Aug/14 ]

This bug still unresolved for version 2.3.6-DEV included in Symfony 2.3.18.

The patches does not work with this version.

Generated query:

SELECT "0_.id AS id0, "0_."verFirmware" AS verfirmware1, "0_."idEstacion" AS idestacion2, "0_."fechaHora" AS fechahora3, "0_.global AS global4, "0_.directa AS directa5, "0_.difusa AS difusa6, "0_."tempSensDirecta" AS tempsensdirecta7, "0_.vbat1 AS vbat18, "0_.vbat2 AS vbat29, "0_.flags AS flags10, "0_."Estacion" AS estacion11 FROM "RegistroRS" "0_ WHERE "0_."idEstacion" = '1' AND "0_."fechaHora" >= '2014-02-01 03:00:00' AND "0_."fechaHora" <= '2014-08-01 03:00:00'

Notice there are unmattched " in the SQL.

Comment by Marco Pivetta [ 05/Aug/14 ]

Julian Aicardo why are you using 2.3.6-DEV? Shouldn't you use a stable version? Is the bug reproducible also with later versions?

Comment by Julian Aicardo [ 06/Aug/14 ]

After changing to version 2.4.2 the bug still there. The same SQL query was generated.

Comment by Julian Aicardo [ 06/Aug/14 ]

The error occurs when try to get an alias based on case sensitive table name, because the alias is generated with the first character of table's name which is ".
Ex:
Table: car Alias: c0_
Table: "Car" Alias: "0_

Is in file SqlWalker.php line 295 in Doctrine 2.4.4:

SqlWalker.php
public function getSQLTableAlias($tableName, $dqlAlias = '')
{
    $tableName .= ($dqlAlias) ? '@[' . $dqlAlias . ']' : '';
        
    if ( ! isset($this->tableAliasMap[$tableName])) {
        $this->tableAliasMap[$tableName] = strtolower(substr($tableName, 0, 1)) . $this->tableAliasCounter++ . '_';
    }

    return $this->tableAliasMap[$tableName];
}




[DDC-3241] object type fails to save serialized class to postgresql Created: 05/Aug/14  Updated: 05/Aug/14

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

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

Issue Links:
Reference
relates to DBAL-964 [GH-653] Update docs to include warni... Resolved

 Description   

Doctrine 2 fails to properly store data from serialize() into postgresql.
This happens because the postgresql pdo driver truncates text on NULL bytes when escaping values. This leads to truncated serialized objects being inserted into the database.

A ugly but working workaround for us is to call json_encode(serialize()) when saving to the database and unserialize(json_decode()) when reading the value back because json_encode properly serializes the NULL bytes of the serialize() output to readable text.

This is pretty ugly though and it would help if doctrine would provide a minimal encoding/decoding function for postgresql that converts all NULL bytes to something else to not break the object type on postgresql.



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

I'm fairly sure that we don't want to invent our own serialization format. Instead, base64_encode could work.

Due to BC compat, we can't introduce it for 2.x, so it would have to be a completely new type.

Comment by Reno Reckling [ 05/Aug/14 ]

Agreed, we'll just go with base64_encode for now.
Maybe someone should update the documentation that using the object type on postgresql is not working as well as that using binary strings containing a NULL byte in any varchar/text column on postgresql is not working either.

Comment by Marco Pivetta [ 05/Aug/14 ]

Reno Reckling just open a pull request against the doctrine/doctrine2 repository

Comment by Reno Reckling [ 05/Aug/14 ]

Marco Pivetta Here you go: https://github.com/doctrine/dbal/pull/653
http://www.doctrine-project.org/jira/browse/DBAL-964

Thanks for the reply.

Comment by Doctrine Bot [ 05/Aug/14 ]

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

Comment by Marco Pivetta [ 05/Aug/14 ]

Merged DBAL-964, but the issue persists here.





[DDC-3239] [GH-1097] `expandParameters`/`getType` in BasicEntityPersister seems to really cover just few cases Created: 01/Aug/14  Updated: 01/Aug/14

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

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


 Description   

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

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

Message:

The test case below seems fairly simple, but I believe that it might uncover a bigger issue.

It seems odd that [`getType` (and, hence, `expandParameters`)](https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php#L1731-1795) in BasicEntityPersister clearly expects field name but often gets different things.

Just set a breakpoint there and watch values through the test suite. There might be not just field name, but a column with alias as well. This works:
![screenshot from 2014-08-01 14 03 44](https://cloud.githubusercontent.com/assets/231518/3778796/c5cc3e66-1979-11e4-9279-5c322b7e8402.png)

But this, apparently, doesn't:
![screenshot from 2014-08-01 14 07 29](https://cloud.githubusercontent.com/assets/231518/3778816/20da192c-197a-11e4-90b4-4c37ee454fb6.png)

There are multiple places (more than one) that call `expandParameters` with criteria that can't be resolved with `getType`. Is this situation expected or worth further investigation/fixing?






[DDC-3236] Quote table names Created: 31/Jul/14  Updated: 31/Jul/14

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


 Description   

Different dbs have different reserved words. I started my project with mysql where i couldnt name my table as "order". After changing to postgre it turned out that "user" is reserved. Although

ALTER TABLE "member" RENAME TO "user";

works.

I know i could use prefixes in yml eg

Com\ApiBundle\Entity\User:
    type: entity
    table: prefix_user

but
-i build my db
-automatically generate my yaml files from it
-then i generate the entities

If i have prefixed table names my entities will have them too.
Besides doctrine is a layer on top of different dbs, it would be nice not to worry about reserved words when i naming my tables.

What is your opinion on this feature.



 Comments   
Comment by Steve Müller [ 31/Jul/14 ]

Benjamin Horn this looks more like a DBAL related issue. Can you please give more details how the broken SQL is created by you? Also please provide information about which DBAL and/or ORM version you are referring to as we have fixed a lot of quotation problems with DDL statements in current DBAL master over the last few months. So please also try using the latest master and see if you can reproduce the issue.
If the issue still persists it would be helpfult to know which database vendor and which version you are using (as different vendors and versions have different reserved keywords).





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

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

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

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



 Description   

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

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

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

Trace:

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

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

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

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






[DDC-3229] Error when running the tests Created: 24/Jul/14  Updated: 24/Jul/14

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

Type: Bug Priority: Major
Reporter: Jeroen De Dauw Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Fresh clone at 089cca636e0e44a70dd9167b7d813762ea80daca.

php -v
PHP 5.5.9-1ubuntu4.3 (cli) (built: Jul 7 2014 16:36:58)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies
with Zend OPcache v7.0.3, Copyright (c) 1999-2014, by Zend Technologies
with Xdebug v2.2.3, Copyright (c) 2002-2013, by Derick Rethans

j@wd42:~/workspace/doctrine2$ phpunit
PHPUnit 4.3-ge243de0 by Sebastian Bergmann.

Configuration read from /home/j/workspace/doctrine2/phpunit.xml.dist

............................................................. 61 / 2500 ( 2%)
........S.................................................... 122 / 2500 ( 4%)
............................................................. 183 / 2500 ( 7%)
............................................................. 244 / 2500 ( 9%)
............................................................. 305 / 2500 ( 12%)
............................................................. 366 / 2500 ( 14%)
.........................S...SSSS.S.......................... 427 / 2500 ( 17%)
............................................................. 488 / 2500 ( 19%)
....................................................SS....... 549 / 2500 ( 21%)
............................................................. 610 / 2500 ( 24%)
............................................................. 671 / 2500 ( 26%)
............................................................. 732 / 2500 ( 29%)
............................................................. 793 / 2500 ( 31%)
........................................................S.SSS 854 / 2500 ( 34%)
SSSSSSSSS.................................................... 915 / 2500 ( 36%)
..........................................SS................. 976 / 2500 ( 39%)
.............S...S...........S..............................S 1037 / 2500 ( 41%)
........PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 65552 bytes) in /home/j/workspace/doctrine2/vendor/doctrine/common/lib/Doctrine/Common/Proxy/ProxyGenerator.php on line 280
PHP Stack trace:
PHP 1.

{main}

() /usr/bin/phpunit.phar:0
PHP 2. PHPUnit_TextUI_Command::main() /usr/bin/phpunit.phar:586
PHP 3. PHPUnit_TextUI_Command->run() phar:///usr/bin/phpunit.phar/phpunit/TextUI/Command.php:132
PHP 4. PHPUnit_TextUI_TestRunner->doRun() phar:///usr/bin/phpunit.phar/phpunit/TextUI/Command.php:179
PHP 5. PHPUnit_Framework_TestSuite->run() /home/j/workspace/doctrine2/vendor/phpunit/phpunit/src/TextUI/TestRunner.php:423
PHP 6. PHPUnit_Framework_TestSuite->run() /home/j/workspace/doctrine2/vendor/phpunit/phpunit/src/Framework/TestSuite.php:715
PHP 7. PHPUnit_Framework_TestCase->run() /home/j/workspace/doctrine2/vendor/phpunit/phpunit/src/Framework/TestSuite.php:715
PHP 8. PHPUnit_Framework_TestResult->run() /home/j/workspace/doctrine2/vendor/phpunit/phpunit/src/Framework/TestCase.php:672
PHP 9. PHPUnit_Framework_TestCase->runBare() /home/j/workspace/doctrine2/vendor/phpunit/phpunit/src/Framework/TestResult.php:654
PHP 10. PHPUnit_Framework_TestCase->runTest() /home/j/workspace/doctrine2/vendor/phpunit/phpunit/src/Framework/TestCase.php:734
PHP 11. ReflectionMethod->invokeArgs() /home/j/workspace/doctrine2/vendor/phpunit/phpunit/src/Framework/TestCase.php:859
PHP 12. Doctrine\Tests\ORM\Functional\Ticket\DDC1436Test->testIdentityMap() /home/j/workspace/doctrine2/vendor/phpunit/phpunit/src/Framework/TestCase.php:859
PHP 13. Doctrine\ORM\AbstractQuery->getOneOrNullResult() /home/j/workspace/doctrine2/tests/Doctrine/Tests/ORM/Functional/Ticket/DDC1436Test.php:42
PHP 14. Doctrine\ORM\AbstractQuery->execute() /home/j/workspace/doctrine2/lib/Doctrine/ORM/AbstractQuery.php:766
PHP 15. Doctrine\ORM\AbstractQuery->executeIgnoreQueryCache() /home/j/workspace/doctrine2/lib/Doctrine/ORM/AbstractQuery.php:923
PHP 16. Doctrine\ORM\Internal\Hydration\AbstractHydrator->hydrateAll() /home/j/workspace/doctrine2/lib/Doctrine/ORM/AbstractQuery.php:977
PHP 17. Doctrine\ORM\Internal\Hydration\ObjectHydrator->hydrateAllData() /home/j/workspace/doctrine2/lib/Doctrine/ORM/Internal/Hydration/AbstractHydrator.php:147
PHP 18. Doctrine\ORM\Internal\Hydration\ObjectHydrator->hydrateRowData() /home/j/workspace/doctrine2/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php:160
PHP 19. Doctrine\ORM\Internal\Hydration\ObjectHydrator->getEntity() /home/j/workspace/doctrine2/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php:432
PHP 20. Doctrine\ORM\UnitOfWork->createEntity() /home/j/workspace/doctrine2/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php:268
PHP 21. Doctrine\Common\Proxy\AbstractProxyFactory->getProxy() /home/j/workspace/doctrine2/lib/Doctrine/ORM/UnitOfWork.php:2714
PHP 22. Doctrine\Common\Proxy\AbstractProxyFactory->getProxyDefinition() /home/j/workspace/doctrine2/vendor/doctrine/common/lib/Doctrine/Common/Proxy/AbstractProxyFactory.php:119
PHP 23. Doctrine\Common\Proxy\ProxyGenerator->generateProxyClass() /home/j/workspace/doctrine2/vendor/doctrine/common/lib/Doctrine/Common/Proxy/AbstractProxyFactory.php:218
PHP 24. strtr() /home/j/workspace/doctrine2/vendor/doctrine/common/lib/Doctrine/Common/Proxy/ProxyGenerator.php:280






[DDC-3228] ORM\Tools\Export\Driver\PhpExporter.php does not properly export manyToOne associations Created: 24/Jul/14  Updated: 24/Jul/14

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

Type: Bug Priority: Major
Reporter: Dan V Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mapping, orm, schematool
Environment:

PHP 5.5.9-1ubuntu4 (cli)



 Description   

PhpExporter.php fails to check the association for manyToOne/oneToOne and exports all associations as oneToOne.

See https://github.com/doctrine/doctrine2/tree/master/lib/Doctrine/ORM/Tools/Export/Driver/PhpExporter.php#L116 where oneToOne is hardcoded if the bitmask matches either manyToOne or oneToOne.

As opposed to YamlExporter.php:

https://github.com/doctrine/doctrine2/tree/master/lib/Doctrine/ORM/Tools/Export/Driver/YamlExporter.php#L165

Which does roughly the same thing, but then properly sets the association type by checking the actual association on lines 186 through one 190:

https://github.com/doctrine/doctrine2/tree/master/lib/Doctrine/ORM/Tools/Export/Driver/YamlExporter.php#L186-L190






[DDC-3223] Failing test (get id return string type) Created: 22/Jul/14  Updated: 22/Jul/14

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

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

Linux Ubuntu 13.10 / PHP 5.5.3 / Mysql 5.5.x



 Description   

I found an issue in a specific case, when you find a child entity (JOINED) which is linked to another child entity.

If I clone the linked child entity and call getId(), it gives the value as 'string' rather than 'integer'. If I set the property id as public, there is no problem.

If I call getId on the child entity rather than the clone, it gives 'integer' as expected. So it's weird...

See failing test here: https://github.com/doctrine/doctrine2/pull/1086






[DDC-3221] Invalid binding for primary key of entity relation Created: 21/Jul/14  Updated: 21/Jul/14

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

Type: Bug Priority: Major
Reporter: Alexandr Smaga Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm


 Description   

Hello.

We use doctrine2 ORM with doctrine/doctrine-bundle in our symfony2 based project. We developed functionality which is similar to some kind of import process.

And we have an issue that appears from time to time in different points during the import.

Issue is following:
Lets imagine we have 3 entities Account, Contact, Contact Address.
Account has many to one relation on contact and contact has one to many relation on contact address.

Our import creates all 3 entities and persist only Account, contact and address are persisted via cascade persist.
We have writer that contains following code

    public function write(array $items)
    {
        try {
            $this->entityManager->beginTransaction();
            foreach ($items as $item) {
                $this->entityManager->persist($item);
            }
            $this->entityManager->commit();
        } catch (\Exception $exception) {
            $this->entityManager->rollback();

            throw $exception;
        }
        $this->entityManager->flush();
        $this->entityManager->clear();
    }

So we clear EntityManager for each batch in order to avoid high memory consumption.
Import fails during different entities insert, but errors are very similar.
Example of error is

> [error] An exception occurred while executing 'INSERT INTO ... VALUES (?, ?, ?, ?, ?)' with params ["__start__", "2014-07-21 00:55:35", 0, null, 21]:
>
> SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (`DB`.`account`, CONSTRAINT `FK_B3D57B301023C4EE` FOREIGN KEY (`contact_id`) REFERENCES `contact` (`id`) ON DELETE CASCADE)

After debugging I found that problem is in BasicEntityPersister#prepareUpdateData

$uow->getEntityIdentifier($newVal);


returns oid that is real one, but UOW contains not the same ID as in $newVal entity. It seems like spl_object_hash duplicates oid.

Any help is appreciated.
Thanks in advance.






[DDC-3220] Association mappings of embedded class not loaded into entity classMetadata Created: 21/Jul/14  Updated: 21/Jul/14

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

Type: Bug Priority: Major
Reporter: Anatolie Marinescu Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None


 Description   

method inlineEmbeddable from Doctrine\ORM\Mapping\ClassMetadataInfo mapped only columns, but relations is omitted






[DDC-3219] Ensure PersistentCollection->count() is of type int Created: 21/Jul/14  Updated: 21/Jul/14

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

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

SQL Server 2012



 Description   

https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/PersistentCollection.php#L566-L577 does not always return an int. How do i know this? because i compare this count with a php count() with strict checking.

If ($collection->count() !== count($somethingElse))

{ throw new Exception($collection->count() . ' is different then ' . count($somethingElse)); }

and at one time this message showed: 3 is different then 3



 Comments   
Comment by Flip [ 21/Jul/14 ]

My colleague told me that it was his mistake somehow, so i don't know how valid this really is !!!





[DDC-3215] wrong quotation Created: 16/Jul/14  Updated: 17/Jul/14

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

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


 Description   

when doctrine build query´s, for example when you doing

$entitity->getTest()->clear();

following queries are generated (test_id is integer in mysql):

DELETE FROM test WHERE test_id = '6'

Is this right?
For me the right query would be:

DELETE FROM test WHERE test_id = 6

as in http://dev.mysql.com/doc/refman/5.5/en/type-conversion.html
6 will be converted to float, this can be an issue, or?

Comparisons that use floating-point numbers (or values that are converted to floating-point numbers) are approximate because such numbers are inexact. This might lead to results that appear inconsistent:

mysql> SELECT '18015376320243458' = 18015376320243458;
        -> 1
mysql> SELECT '18015376320243459' = 18015376320243459;
        -> 0

this also happens in dql sometimes, why doctrine does this not automatic right due to description in the entities?

     /**
     * @ORM\Id @ORM\Column(type="integer")
     * @ORM\GeneratedValue
     */


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

Could you please convert this to a failing test case? Doctrine doesn't quote integers as strings by default.

Comment by revrev [ 16/Jul/14 ]

i try to describe what i have done

i have an Entity with:

    /**
     * @ORM\ManyToMany(targetEntity="Messen", inversedBy="vertrag_messen")
     * @ORM\JoinTable(name="vertrag_messen")
     **/
    private $vertrag_messen;

    public function __construct()
    {
        $this->vertrag_messen = new \Doctrine\Common\Collections\ArrayCollection();
    }

    public function getMessen()
    {
        return $this->vertrag_messen;
    }

when i now clear the Data

$entitity->getMessen()->clear();

following query is created
DELETE FROM vertrag_messen where messe_id = '6'

Should here not set the value 6 as integer (param_int) (DELETE FROM test vertrag_messen where messe_id = 6) that mysql doesn´t have to cast the value? (http://dev.mysql.com/doc/refman/5.5/en/type-conversion.html) or is this not an problem?

Comment by Marco Pivetta [ 16/Jul/14 ]

is messe_id in your entity an integer or a string at the moment in time when that query is being executed?

Comment by revrev [ 16/Jul/14 ]

the value comes automatic
$entitity = $em->getRepository('Base\Entities\Vertrag')>find(intval($data["id"]));

i don´t set messe_id here

Comment by Marco Pivetta [ 16/Jul/14 ]

Can you var_dump the Base\Entities\Messe instance?

Comment by revrev [ 16/Jul/14 ]

object(stdClass)#1014 (64) {
["__CLASS__"]=>
string(24) "Base\Entities\Vertrag"
["id"]=>
int(6)
[„vertrag_messen"]=>
array(1)

Unknown macro: { [0]=> string(20) "BaseEntitiesMessen" }


["erstellungsdatum"]=>
object(stdClass)#1210 (3)

Unknown macro: { ["__CLASS__"]=> string(8) "DateTime" ["date"]=> string(25) "2013-09-28T00}

["zeitraumvon"]=>
NULL
["zeitraumbis"]=>
NULL
["jahr"]=>
int(2014)
["created"]=>
object(stdClass)#1178 (3)

Unknown macro: { ["__CLASS__"]=> string(8) "DateTime" ["date"]=> string(25) "2013-09-28T19}

["updated"]=>
object(stdClass)#1177 (3)

Unknown macro: { ["__CLASS__"]=> string(8) "DateTime" ["date"]=> string(25) "2014-07-16T17}

["uuid"]=>
string(36) "52470c58-4288-45eb-b75f-0c41c0a81437"
}

Comment by Marco Pivetta [ 17/Jul/14 ]

yeah, integer identifier there.
Could you verify if the problem also comes up with current master? I think this issue is related with another one that was fixed some months ago in 2.5.x-dev





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

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

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


 Description   

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

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

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

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

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



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

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





[DDC-2767] ID property of MayToOne association has wrong type Created: 30/Oct/13  Updated: 14/Jul/14

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


 Description   

I'm seeing the following behaviour in some Doctrine code I'm writing:

$entity = array_pop($qb->getQuery()->getResult());
echo gettype($entity->getId()) . ' ' . $entity->getId();
// prints: integer 123

$association = $entity->getAssociation(); // unidirectional ManyToOne link to some other entity
echo gettype($association->getId()) . ' ' . $association->getId();
// prints: string 345

When I load the associated entity directly (via find() f.x.), it's ID has the integer type as expected, and the database structure looks correct, too.

I'm not entirely sure if this is a problem in my code or some issue in QueryBuilder or some other Doctrine component, but if someone could point me into the right direction, that would really be helpful.

I guess normally the type of the ID is not so important because you're not supposed to access it directly anyways, but I need to provide backward compatibility for a lot of code written against a different ORM API that provided exactly this behaviour.



 Comments   
Comment by flack [ 07/Nov/13 ]

After some research, the problem sounds kind of similar to

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

only that in my case, it's not a custom type, but a builtin one that is not working. But AFAICT, in both cases it's getting the ID from a proxy that is problematic

Comment by Doctrine Bot [ 14/Jul/14 ]

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





[DDC-3211] Annotation @ORM\Table(name="schema.table") don't generate sql using OCI8 Created: 09/Jul/14  Updated: 12/Jul/14

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

Type: Bug Priority: Major
Reporter: Jorge Potosme Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: cli, mapping, oci8, oracle, orm, symfony
Environment:

OS: Fedora 20
Web Server: Apache
DBMS: Oracle 12c
Framework: Symfony2
PHP version: 5.5.14
DBMS Driver: OCI8



 Description   

Using Symfony and "doctrine/orm": "2.4.@dev", "doctrine/doctrine-bundle": "1.3.@dev", with OCI8(Oracle Call Interface)
I have an entity
/**
* @ORM\Entity
* @ORM\Table(name="rrhh.usuario")
*/
class Usuario implements UserInterface

{ ... }

When i use de CLI (php app/console doctrine:schema:create --dump-sql) this don't show nothing, the output is empty.

If i change (name="rrhh.usuario") to (name="usuario", schema="rrhh") the CLI show the sql query but without the schema.



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

Duplicates this issue





[DDC-1988] Add Any and ManyToAny annotations Created: 18/Aug/12  Updated: 10/Jul/14

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

Type: New Feature Priority: Minor
Reporter: Stefano Rodriguez Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None


 Description   

It would be really nice to have @Any and @ManyToAny relations/annotations implemented like on Hibernate.
http://docs.jboss.org/hibernate/orm/4.1/javadocs/org/hibernate/annotations/ManyToAny.html
Right now I've implemented these in a Symfony2 bundle (that I'd be happy to share once it's ready and a bit documented), using listeners on postLoad, preFlush and prePersist
However I think this is a very common use case that anyone will encounter at least once/twice in every middle/big-sized project, and for this reason I think this should be implemented as a core feature.






[DDC-3062] [GH-997] [FIX] Allow to use ManyToMany with all operators Created: 31/Mar/14  Updated: 08/Jul/14

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

Type: Bug Priority: Critical
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 bakura10:

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

Message:

Hi,

ping @guillhermoblanco : I think this may be blocking for 2.5

I introduced not so long ago support for ManyToMany for Criteria. However, I realized my implementation was really incomplete, because I hard-coded the "=" operator (https://github.com/doctrine/doctrine2/pull/885/files#diff-982b7374bbe9d5f4b6b71f4869a446eaR575). This means that it fails in a lot of cases when you use something different than "eq" for Criteria.

This PR fixes that, however it's a bit hacky. The SqlExpressionVisitor was made by type hinting for a BasicEntityPersister, preventing us from using us for a collection persister. Therefore I added a new interface to keep BC.

There is also a lot of code duplication (the whole "getSelectConditionSQL" was copied from the BasicEntityPersister), but without trait or BC, I have no idea about how to solve it.

All tests pass, test were added for other operators.






[DDC-2332] [UnitOfWork::doPersist()] The spl_objact_hash() generate not unique hash! Created: 05/Mar/13  Updated: 08/Jul/14

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: 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: Text File hashlogs.txt    

 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.

Comment by Marco Pivetta [ 26/Jun/14 ]

One possible issue here is that a listener registers an entity as managed while a proxy is being loaded.

The given data is still insufficient to actually verify the problem.





[DDC-3206] Possible to remove inversedBy (use only mappedBy)? Created: 05/Jul/14  Updated: 07/Jul/14

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


 Description   

Hi guys!

This is another developer experience situation. Here is the flow:

1. I setup the owning side of a relationship (let's use ManyToMany, the hardest one for this)

2. Later, I decide to setup the inverse side of the relationship. When I do this, I of course add the `mappedBy` attribute so that it points to the exact property/relationship we're dealing with

3. Then, I also need to go back to the owning side and add `inversedBy`.

Why is step 3 (inversedBy) needed? Isn't this redundant information, since the `mappedBy` fully maps out that these 2 associations form different sides of the same relationship? I would love to remove this, I hate explaining to people starting with relationships to now go back to the main entity to add this key. It feels like duplication, which I think people sense.

Of course, I very well may be wrong and it may be needed .

Thanks!



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

I'd suggest doing the opposite: dropping mappedBy.

I'm not sure why JPA introduced this sort of bidirectional mapping, but for practical purposes, it makes it possible for us to load metadata for associations on both sides of the associations. Without having both mappedBy and inversedBy we'd be forced to scan through all existing mappings to find which pieces of the jigsaw fit together.

I don't think we have a good solution for this except for a "build mappings" step that warms up a cache, and that's a very radical architectural change that we can only introduce in 3.x

Comment by Maxime Veber [ 07/Jul/14 ]

Hi, please excuse me if what I say is wrong and do not hesitate to correct me, it's my first immertion in Doctrine code .

So I checked a little bit the situation in the code. I don't see the problem dropping inversedBy. It's easier understandable for the final user.
In facts right now the ManyToMany work very well with only `mappedBy` options so the `invertedBy` is clearly a duplicated information.

The problem for the implementation of this feature is that the ownerSide is decided by a single method for every mappings, so she's quite complexe. So the method decide only on using `mappedBy` and `invertedBy`. This behavior should be modifiable without too much troubles.

https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php#L1353

But another problem here is that should be discuss is that it's a big BC Break.





[DDC-3164] [GH-1057] Add failing test for DDC-3160 Created: 12/Jun/14  Updated: 06/Jul/14

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

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


 Description   

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

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

Message:

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



 Comments   
Comment by Doctrine Bot [ 06/Jul/14 ]

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

Comment by Doctrine Bot [ 06/Jul/14 ]

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





[DDC-3197] [GH-1074] [DDC-3160] Alternate fix for DDC-2996 bug Created: 26/Jun/14  Updated: 06/Jul/14

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

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


 Description   

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

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

Message:

The fix implemented for DDC-2996 seems to have broken quite a bit of code outside of Doctrine (for instance, the popular DoctrineExtensions project).

I'm not too well versed in Doctrine internals, but looking at the fix, I found it odd that an entity would live in both the insertion and update tracking in the unit of work.

This implementation should fix the case described in DDC-2996, while not creating any side effects with objects that are scheduled to be inserted.

I've ran this test with the Doctrine test suite and have also tested this change with the DoctrineExtensions project; unless I'm doing something wrong, it seems to have good results.

Again, I'm not too well versed in the inner workings of Doctrine, but I did a little research, poked around some code, and came up with this.



 Comments   
Comment by Doctrine Bot [ 06/Jul/14 ]

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

Comment by Doctrine Bot [ 06/Jul/14 ]

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





[DDC-3205] [DX] Interactive Management Command Created: 05/Jul/14  Updated: 06/Jul/14

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

Type: New Feature Priority: Minor
Reporter: Ryan Weaver Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Hi guys!

This is part of the Symfony Developer Experience Initiative, which I hope can help Doctrine as well . This is a vision for a console tool to help visualize and manage your Doctrine entities. There are so many options and configuration that I think sometimes either (A) people don't even realize what options are available to them or (B) it's difficult to set everything up correctly (especially with relationships).

Imagine an interactive command that did things like:

  • listed your entities
  • listed fields in your entities (and their options, nullable, unique, etc)
  • Allowed you to change field options (e.g. change a field from nullable true to false
  • Allowed you to see your relationships and change options (cascade, JoinColumn stuff, etc)
  • Allowed you to setup relationships or setup the inverse side of a one-sided relationship
  • Added getters/setters
  • Generated helper methods into repositories (e.g. a method to create a query builder that joins a Product over to ProductImages after creating that relationship).

Does anyone see any issues with this? Obviously, this is HUGE, but it wouldn't need to start huge - it could start simply with some visualization and move from there. I think this could bring down the barrier to entry tremendously, and offer (via generation and visualization) some of the benefits of AR magic without that darn magic .

Thanks!



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

TL;DR: dumping details, yes please! modifying files/mappings, no-go.

A couple of things here:

  • listing entities is already available, see orm:info
  • listing all fields and additional details may be useful as an addition to orm:info via a flag. Implementation is also trivial
  • changing mappings via CLI - I'm really against this proposal. I've already tried getting rid of anything codegen-related from the symfony documentation, and I would not want codegen to land in the ORM. Mappings may come from annotations, from xml configs, from yaml or plain PHP files. They may also be processed by listeners and look completely different from the file counterparts. No, let's stay away from any ORM-driven mapping modification.
  • adding getters/setters, generating repositories, adding fields/associations: Doctrine's codegen is actually ONLY meant to provide an easy migration from a legacy DB to ORM entities+mappings, and we're also trying to get away from it in core.

Note that for mappings there's http://www.pulpo18.com/, which eases the path for newcomers. I also developed something for the ZF2 packages (which I must move to a separate library), see http://stackoverflow.com/a/14574952/347063





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

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

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

Latest ZendFramework2, latest ZF2 DoctrineModule and latest ZF2 DoctrineORMModule



 Description   

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

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

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

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

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

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






[DDC-3202] Hydration fails with inhereted overload Created: 01/Jul/14  Updated: 01/Jul/14

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

Type: Bug Priority: Minor
Reporter: Evgen Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: hydration
Environment:

mysql



 Description   

When i use single column with different types hydration not work. No error thrown, but in enity fields wrong data:

Class A

{ /** * @ORM\Column(name="str", type="string") */ protected $value; ... }

Class B extends A

{ /** * @ORM\Column(name="str", type="simple_array") */ protected $value; ... }

column in database created with type tinytext

after query:
SELECT b FROM A;

Entity of class B contain unparsed string in value property, not hydrated as simple_array. But to store B entities i need to parse this strng into array.
in hydrator i see 2 columns str3 and str4 that mapped to "value" propery and to "str" column in database.






[DDC-3201] Add "option" attribute in JoinTable annotation Created: 01/Jul/14  Updated: 01/Jul/14

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

Type: Improvement Priority: Minor
Reporter: Desjardins Jérôme Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Hello,

In my project, i try to use Doctrine 2 with all table in MyISAM because there is an existing project structure.

But when i create Many To Many association, i can't specify the MySQL's engine.

I think this option can be add in @JoinTable

I speak "annotation" (because I use annotations) but I suggest, of course, for all formats

Thanks






[DDC-3200] [GH-1077] Support filter parameters in Configuration Created: 01/Jul/14  Updated: 01/Jul/14

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

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


 Description   

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

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

Message:

Based on work done in doctrine/mongodb-odm#908

My understanding is that this makes it easier to setup filters at boot time, instead of having to fetch them from the collection later on.

For added context, the related PR from MongoDB ODM's Symfony bundle is doctrine/DoctrineMongoDBBundle#255






[DDC-1970] DiscriminatorMap recursion when using self-reference Created: 06/Aug/12  Updated: 01/Jul/14

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: 2
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
(in this example $sponsor), ignoring LAZY or EXTRA_LAZY fetch mode - it executes numerous queries.

/**
 * @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.

Comment by Kevin Bond [ 01/Jul/14 ]

I have also run into this.





[DDC-2364] [GH-625] [DDC-2363] Duplicated record with orphanRemoval and proxy Created: 22/Mar/13  Updated: 30/Jun/14

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

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

Issue Links:
Duplicate
duplicates DDC-2363 Duplicated record with orphanRemoval ... Awaiting Feedback

 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.



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

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





[DDC-3188] Call to a member function getValue() on a non-object in vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php Created: 24/Jun/14  Updated: 27/Jun/14

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

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

PHP 5.4.11
opensuse
apache2



 Description   

This is the line that causes the fatal error: https://github.com/doctrine/doctrine2/blob/v2.4.2/lib/Doctrine/ORM/UnitOfWork.php#L678

This is the association that is breaking it (i.e. reflFields[ 'user' ] is a non-object):

Tweet.php
/**
 * @ManyToOne(targetEntity="User")
 * @JoinColumn(name="user_id", referencedColumnName="id")
 *
 * @var User
 */
protected $user;

This is the pk of the referenced entity.

User.php
/**
 * @Id
 * @Column(name="id", type="bigint", nullable=false)
 *
 * @var int
 */
protected $id;

If an exception was thrown due to missing metadata information, I could catch it, but fatal errors due to this bug have been crashing our scripts and they've had to be manually restarted.

Let me know what other information is needed.

Full stack trace:

PHP 5. Doctrine\ORM\EntityManager->flush() our_code.php
PHP 6. Doctrine\ORM\UnitOfWork->commit() vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php:389
PHP 7. Doctrine\ORM\UnitOfWork->computeChangeSets() vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:297
PHP 8. Doctrine\ORM\UnitOfWork->computeScheduleInsertsChangeSets() vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:703
PHP 9. Doctrine\ORM\UnitOfWork->computeChangeSet() vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:404
PHP Fatal error: Call to a member function getValue() on a non-object in vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php on line 678



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

Did you actually validate your mappings?

Comment by Daniel Imhoff [ 24/Jun/14 ]

I did not validate the mapping. I did not know about the orm:validate-schema until just now. I will fix these errors and resubmit if there is still an issue.

Sorry about that, thanks.

Comment by Daniel Imhoff [ 24/Jun/14 ]

The tweet and user relationship is not in the list of invalid mappings.

Comment by Marco Pivetta [ 26/Jun/14 ]

Are User and Tweet in the same namespace?

Comment by Daniel Imhoff [ 27/Jun/14 ]

Yes, and I've since then used the FQNS. I would get a class not found error when validating schema.
This is something that I know can't really be debugged by you guys, I was just hoping for a little direction. We are using memcache to store our metadata, and we are clearing and regenerating the metadata during every deploy (it is not autogenerated). I'm now using a commit hash as the namespace of the metadata, so we'll see if this fixes the issue.

Comment by Marco Pivetta [ 27/Jun/14 ]

It looks like a typo (CasESensiTIViTy issue) to me.





[DDC-213] Persist order of collections Created: 15/Dec/09  Updated: 27/Jun/14

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

Type: New Feature Priority: Major
Reporter: Roman S. Borschel Assignee: Roman S. Borschel
Resolution: Unresolved Votes: 15
Labels: None

Issue Links:
Duplicate
is duplicated by DDC-181 Order of many-to-many relationship Resolved
Reference
is referenced by DDC-250 ArrayCollection Key Column @indexBy Resolved

 Description   

A Collection is like a php array, an ordered map. Hence there should be the possibility to persist this order.



 Comments   
Comment by Christian Heinrich [ 21/May/10 ]

Roman, I'd like to do this one as I have currently a use case for this. Do you have any idea of how to do this? What I'm wondering is whether it is possible to implement this without user intervention. (This would simply mean "store the entities as they were added"). But this would need another column in DB that we'd have to add within oneToMany / manyToMany relationships, but in this case one could save a serialized array holding "entityId => position" key / value pairs.

Afterwards, one could easily rebuild / reorder the collection via $collection->set($entity, $order[$entity->identifier]);

If you've got another thought about this, please don't hesitate to point me into the right direction!

Comment by Benjamin Eberlei [ 22/May/10 ]

this won't be implemented until 2.1, since its a pretty complex feature.

Changes are probably required in:

1. CollectionPersister - Add a new collection persister that takes the position into account
2. SchemaTool - Add a 'col_position' column to either the many-to-many or the one-to-many tables.
3. EntityPersister - Use and extend current order-by support to make the sorting happen

You can implement this already though with some performance hit in update scenarios. If you use the ORDER BY support and implement an API around your entity that abstracts those changes and always sets a "position" field on the many entity that is supposed to be sorted.

Comment by Roman S. Borschel [ 22/May/10 ]

I don't think we necessarily need a new collection persister. Simply adjusting the ManyToManyPersister to be able to deal with it might be sufficient.

For OneToMany, that is always persisted from the "many" side, thus there is no collection persister, we would need to adjust the normal persisters.

They key element for the user should be a new annotation (or corresponding xml/yaml element) @OrderColumn. By default the order should not be persistent, only when an @OrderColumn annotation is present. The name of the order column can have a default, i.e. "position". Thus this enhancement of persisting the order should be fully backwards compatible.

Comment by Roman S. Borschel [ 22/May/10 ]

On another note, the getInsertDiff/getDeleteDiff methods of PersistentCollection should already be "ready" for this. That is, when an element in the collection changed only its position, this is already tracked as a change. However the ManyToManyPersister issues no "UPDATE" queries, it simply deletes and inserts. A position change may be more effectively persisted with an UPDATE.

Comment by Benjamin Eberlei [ 30/Sep/10 ]

From a mailinglist entry, required check/changepoints:

1. ClassMetadata of Many-To-Many associations have to be extended to publish the required datastructure to the ORM.
2. All Metadata Mapping Drivers have to be extended
3. Persisters\ManyToManyCollectionPersister has to be extended to save the key in the many to many table if desired by the user.
4. Schema-Tool has to be extended to create the additional column.
5. PersistentCollection has to be extended so that lazy loading of collections with additional key works.
6. Array- and ObjectHydrator have to be extended to allow fetch join of collections with key column.
7. Discuss wheather to support this for One-To-Many also with the key-column on the many side. This is much more tricky internally though.

Comment by Benjamin Eberlei [ 24/Dec/10 ]

Push back to 2.x, we will have support for DDC-250 first and for this at a later release.

Comment by Thomas Tourlourat - Armetiz [ 07/Feb/12 ]

Hi there,
I'm looking for this feature.

Benjamin Eberlei said that : "You can implement this already", but I don't understand the "how to".

Also,
The problem should be solve if RDBMS had a "natural" order. An order based on item position inside table.

To get this feature without any change on Doctrine, I have remplace the PK defined by the target & mapped field identifier. The new PK is a new field with type "integer" and with auto-increment enable.
In this configuration, Doctrine use the "natural" order of the RDBMS. And I can change order of my item inside Collection and persist it.

It's an very bad solution, but It work before an official support.

Waiting for advices, and solutions,

Thomas.

Comment by Thomas Tourlourat - Armetiz [ 08/Feb/12 ]

Answering to Benjamin Eberlei on the "7. Discuss wheather to support this for One-To-Many also with the key-column on the many side. This is much more tricky internally though.".

I think that for One-To-Many relations, if user want to store the collection order, Doctrine can store the One-To-Many as Many-To-Many with a "model" limitation.
In that case, if storing order collection for Many-To-Many work, it should work for One-To-Many.

What do you think about it ?

Comment by Nicolas [ 29/Feb/12 ]

I think that it must be possible to have two keys ordering : the order isn't obligatory reversible.

For exemple with user and group :

  • You can order groups for one user : with preference by exemple, or importance.
  • And with a different order, users for a group : rank by example.

And maybe more, if you decide to add multi-order : an user show group by his rank in it, if his rank is identical, the order is make by love preference, and after by the importance given by the user (not necessary a number, if we imagine filter on them).

So a default order can be choice with parametized fields and could be :

 
@ManyToMany(targetEntity="Group")
...
@JoinFields ( rank: { type: int} , preference:{type:int}, importance:{type: string, length: 40} )
@OrderByJoinFields({"rank" = "ASC", "preference"="ASC", "importance"="ASC" } )

In this case the order must be optional and would be clean if another order appears in the same scope (DQL...). And manytomany became virtual entities act as other entities except they don't appears permetting in the same time a better conception.

So if the solution take in DDC-181 will become the only solution. This would a good idea to document this. Because, this seems to me a very important point.

My last point is even an unique ordering field created in the join table will be a big and usefull improvement.

Thank a lot for your beautiful work.

Comment by Thomas Tourlourat - Armetiz [ 29/Feb/12 ]

In my point of view, a collection can be order in a single way only.
If you want to add more than one order between User & Group, it's a new collection, a new relation.
Like :

  • User.memberOf() : Group[]
  • Group.members() : User[]
  • Group.importantMembers() : User[]

And it's your role to keep a consistency between members & importantMembers array.

Because ManyToMany join table is the reflection of a state of an ArrayCollection. It's not a usefull feature to be able to store all of the state of an ArrayCollection, even the order of this Array. It's just a normal feature that is really missing

Thomas.

Comment by Nicolas [ 29/Feb/12 ]

I don't think:

If you have three collection, you duplicate one relation 3 times and it's easy in consequence to lost the data integrity and unicity.

By example :

  • Thomas have rank 10 in Admin
  • Thomas think the admin group has importance noted 3 on all of his groups.
  • If a responsable of admin group decide to delete Thomas from it.
  • Thomas, in his ordered list of groups, think always to be in group admin.

So in my idea, the many to many relation isn't just an array collection, but should be an virtual entity. In UML or in Merise method this is a common problem to have a parametized relation. I think an orm should just implement this.

Comment by Thomas Tourlourat - Armetiz [ 29/Feb/12 ]

Hum,
I agree with you.. In a SQL Schema, it's a good choice to add many fields in a ManyToMany join table to description "order".

Comment by Thomas Tourlourat - Armetiz [ 07/Mar/12 ]

I just want to add a piece of Doctrine ORM Document :

"When working with collections, keep in mind that a Collection is essentially an ordered map (just like a PHP array). That is why the remove operation accepts an index/key. removeElement is a separate method that has O ( n) complexity using array_search, where n is the size of the map."

Comment by Thomas Tourlourat - Armetiz [ 23/Mar/12 ]

Hi there,
After several discussions. on IRC, I have changed my point of view.

Doctrine Documentation says : "When working with collections, keep in mind that a Collection is essentially an ordered map (just like a PHP array)".
So, I think that Doctrine have to be able to store or not the order of a Collection. By adding a new field on the Joined table to store the position of each elements.

But I not agree with @Nicolas. Because in his case, he's talking about Association Class : http://etutorials.org/Programming/UML/Chapter+6.+Class+Diagrams+Advanced+Concepts/Association+Class/
Because he's talking of a business logic, he's talking of a dedicated Entity class.

What do you think about it ?

Thomas;

Comment by Thomas Tourlourat - Armetiz [ 31/Aug/12 ]

Any news ?

Comment by Matthieu Napoli [ 16/Oct/12 ]

Hi, any news on this?

If I may add any info to this feature request, maybe something like JPA/Hibernate could be a good start?

See http://docs.oracle.com/javaee/6/api/javax/persistence/OrderColumn.html or http://docs.jboss.org/hibernate/core/3.6/reference/en-US/html/collections.html#collections-indexed

The idea in Hibernate is that you persist the order of the list in an extra column. This column is not a field of the entity however.

Comment by Albert Casademont [ 27/Jun/14 ]

+1, this would be indeed a very nice thing. We are using the @OrderBy annotation as a workaround but it's not quite the same thing

Comment by Marco Pivetta [ 27/Jun/14 ]

Moved to 3.x





[DDC-3195] indexBy implementation on containsKey of PersistentCollection in EXTRA LAZY mode uses property name as column name instead of column name Created: 26/May/14  Updated: 26/Jun/14

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

Type: Bug Priority: Major
Reporter: jos de witte Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None
Environment:

Any



 Description   

indexBy implementation on containsKey (and possibly other EXTRA LAZY implemented methods) of PersistentCollection in EXTRA LAZY mode uses property name as column name instead of column name for OneToMany collections

For example property = fieldName, column name field_name.
Set indexBy on OneToMany annotation to fieldName (as it should be ) and it tries to use fieldName in backend instead of field_name






[DDC-3189] blob doctrine2 not inserting file in mysql Created: 24/Jun/14  Updated: 26/Jun/14

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

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

Linux Ubuntu 12.04, Mysql 5


Attachments: PNG File a.png     Zip Archive testedoctrineupload.zip    

 Description   

I have an entity mapped as:

/**
 * @Entity @Table(name="Upload")
**/
class Upload
{
/** @Id @Column(type="integer") @GeneratedValue **/
protected $id;

/** @Column(type="string") **/
protected $nome;

/** @Column(type="blob") **/
protected $arquivo;

When I use this (WORKS)

 $query = "INSERT INTO Upload1 (name, size, type, content ) "."VALUES ('$fileName', '$fileSize', '$fileType', '$content')";

 mysql_query($query)

When I use this doctrine way (NOT WORKING, if you try to get this file from mysql, return a corrupted or empty file)

$upload = new Upload();

$upload-> setContent($content);
$upload-> setName($fileName);
$upload-> setSize($fileSize);
$upload-> setType($fileType);

$entityManager->persist($upload);
$entityManager->flush();

My html file:

<form method="post" enctype="multipart/form-data">
<table width="350" border="0" cellpadding="1" cellspacing="1" class="box">
<tr> 
<td width="246"> 
<input type="hidden" name="MAX_FILE_SIZE" value="2000000">
<input name="userfile" type="file" id="userfile"> 
</td>
<td width="80"><input name="upload" type="submit" class="box" id="upload" value=" Upload    "></td>
</tr>
</table>
</form>


 Comments   
Comment by Gustavo Monti Rocha [ 24/Jun/14 ]

trying to insert this image

Comment by Gustavo Monti Rocha [ 24/Jun/14 ]

Using:
$entityManager->getConnection()>getConfiguration()>setSQLLogger( new Doctrine\DBAL\Logging\EchoSQLLogger());

Getting:
"START TRANSACTION" INSERT INTO Upload (name, type, size, content) VALUES (?, ?, ?, ?) array(4) { [1] => string(5) "a.png" [2] => string(9) "image/png" [3] => int(264547) [4] => string(270342) "‰PNG  \0\0\0 IHDR\0\0@\0\0„\0\0\0v/jõ\0\0\0sBITÛáOà\0\0\0tEXtSoftware\0gnome-screenshotï¿>\0\0 \0IDATxœìw|TÅöÀÏܲ{·$›^I¥“Лҫ€ QPô©`

{êÏγ÷^ŸýYÀ‚ˆ\"¢ô %½m’í햙ߛ,›mÙe¾>š½÷Ι™3gæÎœ;]3ÿR P( …B¡P( …\0\0³X¾Ÿ†X]ŸÞ]ÿÂôP(\0àÜnñ¯N…B¡P( …B¡P(„B\0\0\\.÷ñ’ÊüünݺÇøîÚl¶m;æçfh4\0@BUR)”3®©šR( …B¡P( …ræa2Y+«ëV\0@4……}

Y–<¸§×KEÙ±ãHaaßâ¢#n·\0Ãf¦§ÄÇÇþÅé¦PÎ0¨‹B¡P( …B¡P(g(„ÙttTJ5\"\0< g§æefe¥ú?3rd¿Š £V.W7ì&\0˜âF+‰ø%9uÆF\0HINø«pôx…ZÅuÉL¥“Ô(‘Ù³¯\0ú÷í}ã¶9°A‡Óãr¥Åé¯n"... } array(4)

{ [1] => string(6) "string" [2] => string(6) "string" [3] => string(7) "integer" [4] => string(4) "blob" }

"COMMIT"

Comment by Steve Müller [ 26/Jun/14 ]

This looks more like a DBAL issue. Can you please provide the error/exception message that you receive from the driver/database server? Also do you use PDOMySQL or mysqli driver?

Comment by Gustavo Monti Rocha [ 26/Jun/14 ]

Steve,

I'm not getting any error/expection. Table looks like insert the blob file but when I try to download it is corrupted. You could see at getting .zip file and executing it.

I'm using PDOMysql.

Comment by Marco Pivetta [ 26/Jun/14 ]

This would probably need a data sample to reproduce the issue.

Comment by Gustavo Monti Rocha [ 26/Jun/14 ]

Marco,

you could use project attached and image in order to reproduce.

Comment by Marco Pivetta [ 26/Jun/14 ]

Gustavo Monti Rocha you should actually provide a functional test for this in case, see https://github.com/doctrine/dbal/tree/master/tests/Doctrine/Tests/DBAL

For example, the zip file you uploaded fails on various includes, and doesn't show the failures to me.





[DDC-274] Class and namespace naming inconsistency Created: 24/Jan/10  Updated: 26/Jun/14

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

Type: Improvement Priority: Major
Reporter: Glen Ainscow Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 1
Labels: None


 Description   

There are inconsistencies with some class and namespace names that include acronyms.

Examples:

Classes with upper-casing:
ORMException, DBALException, OCI8Connection, etc.

Classes with proper-casing:
RunDqlTask, CliException, MySqlPlatform, etc.

Namespaces with upper-casing:
DBAL, ORM, Doctrine\DBAL\Driver\PDOMsSql, etc.

Namespaces with proper-casing:
Doctrine\Common\Cli, Doctrine\DBAL\Tools\Cli\, Doctrine\ORM\Id, etc.

There is more proper-casing than upper-casing. IMHO, proper-casing is better as it's easier to read "SqlException" than it is to read "SQLException" (the "E" looks like part of the acronym), and things like "CLITask" can be avoided.

I discussed this a bit with Benjamin and Guilherme, and they were unsure and said that the whole team needed to reach consensus.

I'm leaving the priority as "Major" because this should probably be fixed sooner rather than later to prevent compatibility breaks.



 Comments   
Comment by Guilherme Blanco [ 25/Jan/10 ]

Increasing the severity and adding a fix version since this MUST be fixed before next release.

Comment by Roman S. Borschel [ 25/Jan/10 ]

I find this to be of rather minor importance. You're talking of compatibility breaks, but thats only the case if we intend to start being very nitpicky about the naming in the future. We are currently not, and we wont be, so not much risk of later breakage.

We have a rule of thumb already: Acronyms up to 4 characters all uppercase, otherwise normal camelcase.

Now, it is often a matter of taste what is an acronym and what not and also not all acronyms have a clear casing, prime example mysql.

Being too nit-picky here is just a pain in the ass and we won't reach a common consensus anyway.

Comment by Roman S. Borschel [ 25/Jan/10 ]

Oh and we better dont start arguing about whats better to read because there is no chance of agreement. If you ask me I find SQLException better than SqlException. So here we go. Lets better not run down this path.

Comment by Glen Ainscow [ 25/Jan/10 ]

No need to get upset, I'm only trying to help.

I just thought that consistency is usually a good idea, either way.

I have to disagree in that an acronym is an acronym, it's not a matter of taste, the letters either stand for something, or they don't.

As for "mysql", only the SQL part is an acronym. So, MySQL or MySql.

Close if you disagree.

Comment by Roman S. Borschel [ 25/Jan/10 ]

I'm not upset. What made you think so? Maybe I should introduce a every now and then.

There's just no point in arguing about readability.

Like I said, we do have a naming standard even if its not adhered everywhere. The standard is also not something we've made up ourselves because we try to avoid that. When we introduced namespaces, we talked about adopting either the Java or .NET naming standards. We opted for the .NET standards. And there its recommended to write acronyms with up to 4 characters all uppercase.

I dont think there are too many violations of that in the code, probably Cli => CLI and some others but most of it looks ok to me.

UPDATE: Maybe we can gather a list here in this ticket of violations? Cli => CLI would be one. MySql => MySQL another. "Id" is rather an abbreviation of Identifier and not an acronym, to me at least.

Comment by Guilherme Blanco [ 25/Jan/10 ]

It's not a case of getting anyone upset...

But we should fix it and keep consistency of our codebase.

@romanb We should all talk and reach a common sense.
That's our last chance (last alpha) to get this consistency in.

Comment by Roman S. Borschel [ 25/Jan/10 ]

@Guilherme: We do have a naming standard since a year. You want to change the standard now?

Comment by Glen Ainscow [ 25/Jan/10 ]

@Roman,

Just a feeling I got.

This issue was more about consistency (indicated in the title) than moving to proper-case naming.

I think it might be up to 3 characters in .NET, HtmlElement, System.Linq, etc. Anyway, not important.

I agree that Id. is an abbreviation.

There are some more violations. If you decide you want to change them, let me know and I'll compile a list.

Comment by Roman S. Borschel [ 25/Jan/10 ]

@Glen: Yes, a list would be great. I find it hard to be 100% consistent sometimes though because my taste conflicts with the rule. For example, I would prefer "Id" over "ID", especially since it comes directly after ORM "Doctrine\ORM\ID\..." would be a bit too much. But I would not like "Orm" or "Dbal" either. But I think in most cases we can clearly fix the inconsistency. Like CLI or MySQL or MSSQL (or should it be MsSQL?).

Thanks for your help!

We should probably create updated coding standards for Doctrine 2 also, since they differ quite some from Doctrine 1 due to the introduction of namespaces and such. I'll create a ticket for that.

Comment by Glen Ainscow [ 25/Jan/10 ]

I'll do the list for you by tomorrow at the latest, just running out of time ATM.

Id is correct, as mentioned above, so that would be fine. MsSQL is correct (Ms = Microsoft = abbreviation).

Comment by Glen Ainscow [ 25/Jan/10 ]

Found some time ...

Doctrine\Common\Cache\ApcCache -> APCCache
Doctrine\Common\Cli -> CLI
Doctrine\Common\Cli\Printers\AnsiColorPrinter -> ANSIColorPrinter
Doctrine\Common\Cli\CliController -> CLIController
Doctrine\Common\Cli\CliException -> CLIException

Doctrine\DBAL\Driver\PDOMsSql -> PDOMsSQL
Doctrine\DBAL\Driver\PDOMySql -> PDOMySQL
Doctrine\DBAL\Driver\PDOPgSql -> PDOPgSQL
Doctrine\DBAL\Driver\PDOSqlite -> PDOSQLite
Doctrine\DBAL\Logging\EchoSqlLogger -> EchoSQLLogger
Doctrine\DBAL\Logging\SqlLogger -> SQLLogger
Doctrine\DBAL\Platforms\MsSqlPlatform -> MsSQLPlatform
Doctrine\DBAL\Platforms\MySqlPlatform -> MySQLPlatform
Doctrine\DBAL\Platforms\PostgreSqlPlatform -> PostgreSQLPlatform
Doctrine\DBAL\Platforms\SqlitePlatform -> SQLitePlatform
Doctrine\DBAL\Schema\Visitor\CreateSchemaSqlCollector -> CreateSchemaSQLCollector
Doctrine\DBAL\Schema\Visitor\DropSchemaSqlCollector -> DropSchemaSQLCollector
Doctrine\DBAL\Schema\MsSqlSchemaManager -> MsSQLSchemaManager
Doctrine\DBAL\Schema\MySqlSchemaManager -> MySQLSchemaManager
Doctrine\DBAL\Schema\PostgreSqlSchemaManager -> PostgreSQLSchemaManager
Doctrine\DBAL\Schema\SqliteSchemaManager -> SQLiteSchemaManager
Doctrine\DBAL\Tools\Cli -> CLI
Doctrine\DBAL\Tools\Cli\Tasks\RunSqlTask -> RunSQLTask

Doctrine\ORM\Mapping\Driver\PhpDriver -> PHPDriver
Doctrine\ORM\Mapping\Driver\XmlDriver -> XMLDriver
Doctrine\ORM\Mapping\Driver\YamlDriver -> YAMLDriver
Doctrine\ORM\Query\Exec\AbstractSqlExecutor -> AbstractSQLExecutor
(Should Doctrine\ORM\Query\Expr\Andx and Orx be AndX and OrX?)
Doctrine\ORM\Query\SqlWalker -> SQLWalker
Doctrine\ORM\Tools\Cli -> CLI
Doctrine\ORM\Tools\Cli\Tasks\RunDqlTask -> RunDQLTask
Doctrine\ORM\Tools\Export\Driver\PhpExporter -> PHPExporter
Doctrine\ORM\Tools\Export\Driver\XmlExporter -> XMLExporter
Doctrine\ORM\Tools\Export\Driver\YamlExporter -> YAMLExporter

... I think that's it. More than you expected? I did say: "There is more proper-casing than upper-casing."

Comment by Roman S. Borschel [ 25/Jan/10 ]

No, not more than I expected. It's mostly SQL and CLI basically. Thanks for the list!

We should try to go through that list before beta.

Comment by Roman S. Borschel [ 05/Mar/10 ]

Methods should be adjusted accordingly also (even though they're case insensitive). I already started with that. More to come.

Comment by Roman S. Borschel [ 28/Mar/10 ]

Most of the Cli => CLI changes seem to be complete now.

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

Pushing the rest of the name changes towards beta2.

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

More renamings have been done but still more to do. Pushing remaining work to beta3.

Comment by Roman S. Borschel [ 30/Aug/10 ]

Final name changes should be done prior to going into RC1.

Comment by Benjamin Eberlei [ 31/Oct/10 ]

there is much to be done yet, however most of it is also public API class names and might cause quite some BC breaks (i.e. DBAL Platforms and Schema Manager, Mapping Driver Names). I am not sure how to proceed here.

Comment by Roman S. Borschel [ 31/Oct/10 ]

Since PHP is mostly case-insensitive on class and method names it shouldn't be much of an issue.

Comment by Guilherme Blanco [ 16/Apr/14 ]

Scheduled to 3.0 as this may potentially create BC breaks





[DDC-2800] Something wrong with documentation generation Created: 18/Nov/13  Updated: 26/Jun/14

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

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


 Description   

The ArrayCollection has a matching() function, but it does not show in the API docs. http://www.doctrine-project.org/api/common/2.4/class-Doctrine.Common.Collections.ArrayCollection.html



 Comments   
Comment by Steve Müller [ 01/Apr/14 ]

Flip The collection API has moved to its own repo anyways now and there currently is no API generation for this, aswell as other subprojects like annotations etc. But the matching() method exists in 2.3 branch, where the repos were not separated, yet.

http://www.doctrine-project.org/api/common/2.3/source-class-Doctrine.Common.Collections.ArrayCollection.html#463-498

Do we need to keep this ticket open?

Comment by Flip [ 02/Apr/14 ]

I think so because no new documentation is generated for subprojects.

Expected: http://www.doctrine-project.org/api/collections/2.4/ (or any other latest version if the subprojects have seperate versioning)





[DDC-3109] [Doctrine\ORM\Mapping\MappingException] Invalid field override named 'xxx' for class 'Entity\xxx' Created: 30/Apr/14  Updated: 26/Jun/14

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

Type: Bug Priority: Major
Reporter: david pichsenmeister Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None
Environment:

kubuntu 14.04, php 5.5.9, MySQL 5.5


Attachments: File Organization.php     File User.php    
Issue Links:
Duplicate
duplicates DDC-2693 Attribute/association overrides shoul... Open

 Description   

Subclass should override association, but on generating entities, error:

[Doctrine\ORM\Mapping\MappingException]
Invalid field override named 'settings' for class 'Entity\Organization'.

is thrown. also, when updating schema, the assocations in the subclass are ignored (means are not present in the database).



 Comments   
Comment by Alexandre PAIXAO [ 23/May/14 ]

I think it is a duplicate of this bug : http://www.doctrine-project.org/jira/browse/DDC-2693





[DDC-3191] [GH-1072] Fix attempt of traversing bool in FileLockRegion Created: 26/Jun/14  Updated: 26/Jun/14

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

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


 Description   

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

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

Message:

Minor fix: on some platforms (i.e. ArchLinux) `glob()` returns `false` when nothing matched even though no errors occurred. As docs for `glob` say, such behavior is expected (see ‘Note’ at http://php.net/glob)

This made 1 existing test fail:

./vendor/bin/phpunit 
PHPUnit 4.3-g58f3a0e by Sebastian Bergmann.

Configuration read from /home/alex/git/doctrine2/phpunit.xml.dist

.............................................................   61 / 2495 (  2%)
........S.............E......................................  122 / 2495 (  4%)
.............................................................  183 / 2495 (  7%)
.............................................................  244 / 2495 (  9%)
.............................................................  305 / 2495 ( 12%)
.............................................................  366 / 2495 ( 14%)
.........................S...SSSS.S..........................  427 / 2495 ( 17%)
.............................................................  488 / 2495 ( 19%)
....................................................SS.......  549 / 2495 ( 22%)
.............................................................  610 / 2495 ( 24%)
.............................................................  671 / 2495 ( 26%)
.............................................................  732 / 2495 ( 29%)
.............................................................  793 / 2495 ( 31%)
.......................................................S.SSSS  854 / 2495 ( 34%)
SSSSSSSS.....................................................  915 / 2495 ( 36%)
.........................................SS..................  976 / 2495 ( 39%)
............S...S...........S..............................S. 1037 / 2495 ( 41%)
............................................................. 1098 / 2495 ( 44%)
..................S.......................................... 1159 / 2495 ( 46%)
.................................................SS.......... 1220 / 2495 ( 48%)
.......................S..................................... 1281 / 2495 ( 51%)
............................................................. 1342 / 2495 ( 53%)
............................................................. 1403 / 2495 ( 56%)
............................................................. 1464 / 2495 ( 58%)
............................................................. 1525 / 2495 ( 61%)
............................................................. 1586 / 2495 ( 63%)
.........S.................................................S. 1647 / 2495 ( 66%)
............................................................. 1708 / 2495 ( 68%)
............................................................. 1769 / 2495 ( 70%)
............................................................. 1830 / 2495 ( 73%)
............................................................. 1891 / 2495 ( 75%)
............................................................. 1952 / 2495 ( 78%)
............................................................. 2013 / 2495 ( 80%)
............................................................. 2074 / 2495 ( 83%)
............................................................. 2135 / 2495 ( 85%)
............................................................. 2196 / 2495 ( 88%)
............................................................. 2257 / 2495 ( 90%)
............................................................. 2318 / 2495 ( 92%)
............................................................S 2379 / 2495 ( 95%)
.......S......S.......S.....................S...........S.... 2440 / 2495 ( 97%)
.......................................................

Time: 14.37 seconds, Memory: 164.50Mb

There was 1 error:

1) Doctrine\Tests\ORM\Cache\FileLockRegionTest::testEvictAll
Invalid argument supplied for foreach()

/home/alex/git/doctrine2/lib/Doctrine/ORM/Cache/Region/FileLockRegion.php:204
/home/alex/git/doctrine2/tests/Doctrine/Tests/ORM/Cache/AbstractRegionTest.php:80

Traversing bool is no good and casting to array wouldn't hurt there as far as I can tell.






[DDC-3184] Invalid hydration of entities using ManyToOne relation via queryBuilder Created: 23/Jun/14  Updated: 23/Jun/14

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

Type: Bug Priority: Major
Reporter: Dmitry Korotovsky Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: None

Attachments: File DDC3184Test.php    

 Comments   
Comment by Dmitry Korotovsky [ 23/Jun/14 ]

In master branch all works perfect

Comment by Dmitry Korotovsky [ 23/Jun/14