[DDC-1958] pager produces wrong results on postgresql Created: 30/Jul/12  Updated: 16/Sep/14  Resolved: 12/Nov/12

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

Type: Bug Priority: Major
Reporter: Miha Vrhovnik Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 1
Labels: paginator
Environment:
  • Postgres 9.1, 9.2
  • PHP 5.4

Sub-Tasks:
Key
Summary
Type
Status
Assignee
DDC-2593 Same bug occurs in MariaDB 5.5 Sub-task Resolved Marco Pivetta  
DDC-2729 Same bug affects SQLServer2008Platform Sub-task Open Benjamin Eberlei  

 Description   

The query build by pager to get the subset of PKs to fetch produces wrong results on potgresql (and probably any database), that conforms to the SQL standard. The standard says, that if you wish to have the results in specific order, then you have to specify that by using an ORDER BY clause. If such a clause is not present the database can return the results in whatever order it sees fit.

Testcase fixtures:

CREATE TABLE test (
    id integer,
    name text
);

INSERT INTO test VALUES (1, 'c');
INSERT INTO test VALUES (2, 'a');
INSERT INTO test VALUES (3, 'e');
INSERT INTO test VALUES (4, 'b');
INSERT INTO test VALUES (5, 'd');
INSERT INTO test VALUES (6, 'a');
INSERT INTO test VALUES (7, 'g');
INSERT INTO test VALUES (8, 'h');
INSERT INTO test VALUES (9, 'e');
INSERT INTO test VALUES (10, 'j');

Passing f.e.

$qb = $this->repository
    ->createQueryBuilder('t')
    ->select('t')
    ->setFirstResult(0)
    ->setMaxResults(5)
    ->addOrderBy('t.name', 'ASC')

to pager produces SQL like this modified for readability

SELECT DISTINCT id FROM (
    SELECT id, name FROM test ORDER BY name
  ) dctrn_result
  LIMIT 5 OFFSET 0

Now there is nothing wrong with this modified query per se, but there is no ORDER BY clause in the outer query so according to the standard the DB can choose whatever order it seems fit. Now mysql chooses the same order, but postgresql does not and it's probably not the only DB doing so.

If you are interested in the results, this is the output I'm seeing:

  • postgresql: 8,4,1,5,3
  • mysql : 2,6,4,1,5

I and my coworker came to the standard compliant solution it was also tested on the dataset above on both postgresql and mysql and it produced equal results. We have found only one corner case this won't work and IMHO that can't be fixed. The problem is when you do a sort on a field from a table that is in 1:n relation to the main table.. e.g tables posts and tags, where one post can have a multiple tags and you want your results sorted by a tag.

Recipe for a correct query is:

  • remember the ORDER BY fields from original query and then remove them
  • wrap the original query with a DISTINCT query, but add the fields from ORDER BY to the SELECT part of that query and add the whole ORDER BY to the end of it, also add the PK to the order by clause, and add the LIMIT clause
  • wrap the resulting query into another query and select just the id.

so if I take the example from above the SQL should look like this:

SELECT id FROM (
  SELECT DISTINCT id, name FROM (
    SELECT id, name FROM test
  ) dctrn_result_inner
  ORDER BY name, id LIMIT 5 OFFSET 0
) dctrn_result


 Comments   
Comment by Jean-Philippe THEVENOUX [ 08/Nov/12 ]

I reproduce same problem with Postgres 7.4, Doctrine 2.3 whereas with doctrine 2.2, all is fine
Hope there'll a fix in next doctrine version

Comment by Raymond Kolbe [ 09/Apr/13 ]

http://www.doctrine-project.org/jira/browse/DDC-1800 This relates.

I just published a PR for an Oracle fix, but your solution appears to work for Oracle as well (issue is the same).

Comment by Bojidar Hristov [ 06/Aug/13 ]

Same bug occurs in MariaDB 5.5.

I commented out check for PostgreSQL and it works fine. Can you fix it for MariaDB too? Thanks

Comment by Guilherme Santos [ 21/Aug/14 ]

I make a ORDER BY with a HIDDEN field and this still happen to me! Like this:
$qb->addSelect('CASE WHEN p.description LIKE :description THEN 0 ELSE 1 END HIDDEN relevance')->addOrderBy('relevance');

This order by is ignored causing the same error!

In this line https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Query/SqlWalker.php#L1310
you don't add to ResultSetMapping so when you verifying in function preserveSqlOrdering the field doesn't exists!

Comment by Liam O'Boyle [ 16/Sep/14 ]

I've just been bitten by the "corner case" described above, "the problem is when you do a sort on a field from a table that is in 1:n relation to the main table.. e.g tables posts and tags, where one post can have a multiple tags and you want your results sorted by a tag.".

This is a pretty significant bug, as the end result is that data that should come back from the query doesn't. While there probably isn't a good universal workaround, the MySQL behaviour before this was already correct because the outer query was returning the ids in the same order as the internal query (even though it isn't required to by the standard). Is it possible to avoid having this apply to MySQL so that it doesn't introduce an additional bug in an attempt to fix an issue that doesn't apply to that platform anyway?

Comment by Miha Vrhovnik [ 16/Sep/14 ]

@Liam As you can se above the same applies to mariadb and if you look at the issues on the githubs doctrine project page you'll see that there is the same problem with newer mysql releases. AS I've written above. this corner case cannot be solved.

Comment by Liam O'Boyle [ 16/Sep/14 ]

Thanks Miha. I couldn't find this on the github page so didn't realise that it was affecting some newer MySQL releases (it didn't seem to affect mine, 5.5). If that's the case, then as you point out it can't even be fixed for MySQL.

Perhaps the lack of support could be more explicit instead? If you attempt to use the paginator with two FROM tables then a RuntimeException is thrown, if we did the same when the ORDER BY conditions applied to tables joined via a 1:m relationship then at least users would know that things were going wrong rather than getting strangely unpredictable results.





[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-3309] [GH-1136] add option to skip specific namespace Created: 14/Sep/14  Updated: 14/Sep/14  Resolved: 14/Sep/14

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

Type: New Feature Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Incomplete Votes: 0
Labels: None


 Description   

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

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

Message:

to EntityGenerator and GenerateEntitiesCommand

gives ability to create and update entities, that are stored by psr-4 standard



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

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





[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-3304] [EntityGenerator] Embeddables properties and methods are broken Created: 11/Sep/14  Updated: 13/Sep/14  Resolved: 12/Sep/14

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

Type: Improvement Priority: Major
Reporter: Phansys Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: embeddables, entityGenerator, generation, mapping, orm

Issue Links:
Dependency
depends on DDC-3307 [GH-1135] [DDC-3304] Add support for ... Resolved

 Description   

EntityGenerator creates broken properties for embeddables. Given the example classes exposed in http://docs.doctrine-project.org/en/latest/tutorials/embeddables.html (User, Address), EntityGenerator creates wrong associations in User entity. Instead of this:

```php
/**

  • Address
    *
  • @var Address
    */
    private $address;
    ```

I get this:
```php
/**

  • Address.street
    *
  • @var string
    */
    private $address.street;
    /**
  • Address.postalCode
    *
  • @var string
    */
    private $address.postalCode;
    /**
  • Address.city
    *
  • @var string
    */
    private $address.city;
    /**
  • Address.country
    *
  • @var string
    */
    private $address.country;
    ```

And the same for its getters and setters.
I'll try to do a PR when I found a way to solve this.



 Comments   
Comment by Steve Müller [ 11/Sep/14 ]

Phansys which version of ORM are you using? If you are using latest master, this might be related to PR: https://github.com/doctrine/doctrine2/pull/1105
It looks like it broke the EntityGenerator. Can you confirm?

Comment by Phansys [ 11/Sep/14 ]

Confirmed @deeky666, on rev d9b43dc6492b163fc46f40c0555e2a7015ef5b68 (https://github.com/doctrine/doctrine2/tree/d9b43dc6492b163fc46f40c0555e2a7015ef5b68).
Thank you!

Comment by Phansys [ 11/Sep/14 ]

I've tried with rev 8a3def097f9ebd773ee298f5611ce8bf7007fa7e (previous to PR#1105) and the result is the same broken structure.

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

Phansys thanks for your feedback. I will see if I have time tomorrow to look into this issue.

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

Had a quick look into the issue and recognized that embeddables are not taken into account at all at the moment. Working on a solution...

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

Patch provided in PR: https://github.com/doctrine/doctrine2/pull/1135

Comment by Doctrine Bot [ 12/Sep/14 ]

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

Comment by Doctrine Bot [ 12/Sep/14 ]

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

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

Fixed in commit: https://github.com/doctrine/doctrine2/commit/f12c311a795b69a5f4853b079b3f8ad2c9867181

Comment by Phansys [ 13/Sep/14 ]

Thanks Steve Müller.





[DDC-3299] Possibility to define Entities in separate Bounded Context Created: 09/Sep/14  Updated: 13/Sep/14  Resolved: 10/Sep/14

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

Type: Improvement Priority: Major
Reporter: Piotr Deszyński Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: schematool


 Description   

It would be great to have a possibility to define two entities in different Bounded Context. For now it's possible without a problem to use such an Entities but it's impossible to use schema tools, when two separate Entities map to the same table.



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

This feature would break a very important invariant existing in the ORM: only one entity for a particular identifier existing in memory at any time.

This cannot be implemented, and actually goes against the rules imposed by the ORM.

The only solution to this problem would be to have a writable view, and mapping an entity to it, and an entity to the actual table: that's still making some of the transactions in your application very risky.

Comment by Piotr Deszyński [ 12/Sep/14 ]

But wouldn't it be possible to implement it really similar to single table inheritance but without a DiscriminatorColumn? Which instance would be returned would depend on the repository used.

Comment by Marco Pivetta [ 13/Sep/14 ]

Piotr Deszyński that wouldn't prevent having two instances of the same entity in memory, which is a problem.





[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: 6
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-3307] [GH-1135] [DDC-3304] Add support for embeddables in entity generator Created: 12/Sep/14  Updated: 12/Sep/14  Resolved: 12/Sep/14

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Dependency
is required for DDC-3304 [EntityGenerator] Embeddables propert... Resolved

 Description   

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

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

Message:

Currently the entity generator does not respect embeddables and therefore generates wrong entity classes.
This PR adds support for generating embeddables and embedded properties in entities.
It also introduces a new option to decide whether embeddable classes should be mutable or immutable. Mutable embeddables (default) are generated like entities (getters and setters but no constructor). Immutable embeddables however do not provide setters but instead have a constructor that takes all defined properties as arguments.



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

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

Comment by Doctrine Bot [ 12/Sep/14 ]

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





[DDC-3306] [GH-1134] Export tests for downstream packaging Created: 12/Sep/14  Updated: 12/Sep/14  Resolved: 12/Sep/14

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

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


 Description   

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

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

Message:

It would be very helpful to run tests when packaging this library for Fedora/EPEL. This cannot currently be done because tests are ignored on export (which is how RPM packaging downloads this library from GitHub).






[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-2182] [GH-529] Options join columns Created: 01/Dec/12  Updated: 11/Sep/14  Resolved: 04/Dec/12

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

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


 Description   

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

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

Message:

When a columns as the options with unsigned at true, this options is not passed to the joinColumn.
This PR fix this.



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

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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





[DDC-2463] [GH-675] Implementation for 'IsNot'-Comparison Created: 20/May/13  Updated: 11/Sep/14  Resolved: 26/May/13

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

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


 Description   

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

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

Message:

See PR (https://github.com/doctrine/collections/pull/11)

This is the required implementation for 'IsNotNull'-Filters in Collection-Filtering.



 Comments   
Comment by Alexander [ 26/May/13 ]

Already fixed with:
http://www.doctrine-project.org/jira/browse/DDC-2471

Comment by Doctrine Bot [ 30/Jun/13 ]

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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





[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-2445] [GH-665] oo Add Null in ScalarExpression Created: 12/May/13  Updated: 11/Sep/14  Resolved: 26/May/13

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

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


 Description   

This issue is created automatically through a Github pull request on behalf of vahid-sohrabloo:

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

Message:



 Comments   
Comment by Doctrine Bot [ 22/May/13 ]

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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





[DDC-2209] [GH-540] [DDC-2208] Fix DDC-2208 Created: 20/Dec/12  Updated: 11/Sep/14  Resolved: 22/Dec/12

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

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


 Description   

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

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

Message:

This patch fix DDC-2208

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



 Comments   
Comment by Benjamin Eberlei [ 22/Dec/12 ]

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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





[DDC-2400] [GH-648] Add a AddParameters method in the QueryBuilder Created: 13/Apr/13  Updated: 11/Sep/14  Resolved: 14/Apr/13

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

Hi,

On doctrine 2.2, when we were calling the method `setParameters` to set a bunch of parameters on the QueryBuilder, each parameters were added or modified if they were already existing.

That is not the case since doctrine 2.3 : each calls to `setParameters` will wipe out the other already setted parameters. I think it is logic, but still is a huge BC break, which is not really mentionned in the UPGRADE file (only the once regarding the use of an ArrayCollection is mentionned).

With this PR, I added a `addParameters` which allows to add several parameters in several calls. Here is a use case :

```php
<?php
// ... A repository
class UserRepository extends EntityRepository
{
public function getUserWithSomething($criteriaA, $criteriaB, DateTime $since = null)
{
$qb = $this->createQueryBuilder('u');
$qb->where($qb->expr()>andX($qb>expr()->eq('u.criteriaA', ':criteriaA'),
$qb->expr()->eq('u.criteriaB', ':criteriaB')));

// wanna search for objects since a specific date
if (null !== $since)

{ $qb = $this->addSince($qb, $since); }

$qb->addParameters(new ArrayCollection(['criteriaA' => $criteriaA,
'criteriaB' => $criteriaB]));

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

public function addSince(QueryBuilder $qb, DateTime $since)

{ $qb = $qb->andWhere($qb->expr()->gte('u.date', ':since')); return $qb->setParameter('since', $since); }

}
```

So, as I was saying, until 2.2, you could use `setParameters` in the main method (`getUserWithSomething`) which was calling (or not) the submethod `addSince`, which could set parameters before calling the `setParameters` method. Now, you can't do that anymore : either you need to make several calls to `setParameter` :

```php
<?php
// ....
$qb = $qb->setParameter('criteriaA', $criteriaA)
->setParameter('criteraB', $criteriaB);
//...
```

Either, I guess, you need to first retrieve all the parameters and then add them by hand :

```php
<?php
// ....
$parameters = $qb->getParameters();
$parameters->add(new Parameter('criteriaA', $criteriaA);
$parameters->add(new Parameter('criteriaB', $criteriaB);

$qb = $qb->setParameters($parameters);
//...
```

So that's why I propose this new method in the QueryBuilder. if I'm wrong anywhere, or need more information please feel free to comment.

Cheers.



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

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

Comment by Doctrine Bot [ 04/Aug/14 ]

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

Comment by Doctrine Bot [ 04/Aug/14 ]

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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





[DDC-357] Lazy-loading in OneToOne-bidirectional associations not working for inverse side Created: 21/Feb/10  Updated: 11/Sep/14  Resolved: 21/Feb/10

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

Type: Bug Priority: Minor
Reporter: Marcel Walter Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 0
Labels: None
Environment:

XAMPP 1.7.3


Attachments: File getRelation.php    
Issue Links:
Reference
is referenced by DDC-3011 [GH-970] [DDC-357] Effective toOne joins Resolved

 Description   

I am referring to the following situation:
http://www.doctrine-project.org/documentation/manual/2_0/en/association-mapping#one-to-one,-bidirectional

In this example: if I fetch an object of type "Customer" from my database, a second query is executed immediately that fetches the corresponding "Cart" even if I do not access the $cart property of "Customer". Annotating fetch="LAZY" to the $cart property does not make any difference. This is even worse in case of self-referencing objects, e.g. those having at most one parent object and at most one child object. Here, all associations are created by single database queries at once (e.g. fetching the child object, then the child of the child object and so forth).

By contrast, OneToMany associations are lazy-loaded from the inverse side (as expected).

Perhaps I should add, that I am using annotation mappings for my entities (no YAML, no XML).



 Comments   
Comment by Roman S. Borschel [ 21/Feb/10 ]

This is expected behavior. Inverse sides of one-to-one associations can not be lazy, technically. There is no foreign key on the inverse side, hence it is impossible to decide whether to proxy it or not. We must query for the associated object or join it. Note that this only affects inverse sides of single-valued associations, that is, really only the inverse side of bidirectional one-to-one associations.

In the future, you can use fetch="EAGER" to automatically load the associated objects in a join whenever the inverse side object is loaded. That is a planned enhancement.
So when fetch="EAGER" is used on a single-valued association, it is automatically fetch-joined, even when you just do ->find('Object', 1).

Right now, you can use an eager fetch join in DQL to avoid the extra query. Fetch-joins on single-valued associated are usually very cheap, compared to collections.

Note that you need a join anyway, because the foreign key is on the other side, thus it doesnt make much sense to join just for the sake of getting the foreign key. If we join we can as well grab the associated object completely.

The "fetch" mode is a "hint", that means, Doctrine tries to do that when possible. Its not always possible.

If you have a suggestion, feel free to speak up.

Comment by Roman S. Borschel [ 21/Feb/10 ]

If you have an example of a self-referential association that causes extreme ripple-loading of the whole hierarchy, can you please file a new jira issue for that?

Thanks!

Comment by Roman S. Borschel [ 21/Feb/10 ]

Here some other ways to get around the extra queries:

1) $query->setHint(Query::HINT_FORCE_PARTIAL_LOAD, true);

2) $query->getArrayResult() / ->getScalarResult()

Just for the sake of completeness.

Comment by Konstantin [ 13/Mar/12 ]

Why we cannot create proxy without FK?

Comment by Christian Stoller [ 10/Dec/12 ]

Hi. I have a problem with this solution.

I have an entity "Document" with an one-to-one association to an entity called "File". In the database table of the File entity I store the content of a file. So if I load for example 20 Documents I do not want the associated Files to be loaded, because this leads to memory problems.

I do not understand the explanation

There is no foreign key on the inverse side, hence it is impossible to decide whether to proxy it or not.


In a one-to-many association there is no foreign key on the inverse side, too. Why not always load a proxy like in a one-to-many association?

Plus: There is no documentation about this, neither on http://docs.doctrine-project.org/en/latest/reference/association-mapping.html nor http://docs.doctrine-project.org/en/latest/reference/unitofwork-associations.html

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

It is pretty simple, in a one-to-many association where the one-side is the inverse side, it holds a collection. The collection may be empty or not but there can always be a collection so it easy and correct to always put a proxy collection there.

If you have a single-valued side that is the inverse side, how can you decide whether to put a proxy object there or not? Without seeing the foreign key you have no way to distinguish between: There is no associated object (and thus putting a proxy object in place would by simply wrong) or there is one and of which type it is, if inheritance is involved (since putting a proxy of the wrong type in is also wrong).

This is as far as I recall, maybe Benjamin knows more on the current state.

Comment by Christian Stoller [ 10/Dec/12 ]

Okay, I see the problem. But it would be nice if this behaviour could be documented.

Isn't it possible to always put a special proxy object there and if it get's accessed via lazy loading and Doctrine detect's that there is no associated entity, then the proxy will be replaced by a NULL value?

Comment by Hernan Rajchert [ 26/Feb/13 ]

Hi, I've been faced with this issue some times. I tent to solve this by doing two unidirectional one-to-one. Then I deal with the non existing relationship using a method called getRelation that I defined in a BaseModel.
I have created this method because Doctrine filled up with a Proxy when I fetch the entity without its relationship (then accesing the object would throw an Exception), and filled up with null when the object was eagerly fetched (left join) but no relationship was found.
I think we could add this getRelation in the entitymanager or a trait after php 5.4.

Comment by Martin Štekl [ 10/Nov/13 ]

Hi,
I think that idea of special proxy object is not so bad. However if you do not want to create special proxy object and build some logic around it then why do you not want to satisfy at least one of two (currently unsupported) cases?
I mean the case in which the object type is used in inheritance. This case is easier to solve in my opinion (similar to @OneToMany) and usually wanted. It is better to support at least one possibility then none.

Comment by Filip Procházka [ 05/Mar/14 ]

I'm proposing a solution to this "Won't Fix" that I disagree with https://github.com/doctrine/doctrine2/pull/970

Comment by Doctrine Bot [ 23/Mar/14 ]

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

Comment by Misha Bosiy [ 11/Sep/14 ]

My solution:
Two entities with one-to-one reference Site and Url:

*********************************

Site

/**

  • @var Url
    *
  • @ORM\OneToOne(targetEntity="Url", cascade= {"persist"}

    )

  • @ORM\JoinColumns( { * @ORM\JoinColumn(name="url_id", referencedColumnName="url_id") * }

    )
    */
    private $url;

/**

  • @return Url
    */
    public function getUrl() { return $this->url; }

*********************************

Url

/**

  • @var \Doctrine\ORM\PersistentCollection
    *
  • @ORM\OneToMany(targetEntity="Site", mappedBy="url")
    */
    private $site;

/**

  • @return Site|null
    */
    public function getSite() { return ($this->site->first() !== false) ? $this->site->first() : null; }

*********************************

Queries:

$url = $urlRepo->createQueryBuilder('u')
>where('u.url_id = :url_id')>setParameter('url_id', 19518)
->getQuery()
->getOneOrNullResult();

We have only 1 query to DB.

When call:
$url->getSite();

One more query appears. So lazy load work perfect!

********************************

If with join:
$url = $urlRepo->createQueryBuilder('u')
->select('u', 's')
->join('u.site', 's')
>where('u.url_id = :url_id')>setParameter('url_id', 19518)
->getQuery()
->getOneOrNullResult();

When call:
$url->getSite();

Only 1 query to DB.

Comment by Filip Procházka [ 11/Sep/14 ]

That is not a solution but a workaround which we are also using.

Comment by Misha Bosiy [ 11/Sep/14 ]

I wrote it for people who has such problem and don't know what to do with not necessary subqueries.





[DDC-3084] Native query removes duplicate root entities Created: 14/Apr/14  Updated: 10/Sep/14  Resolved: 14/Apr/14

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

Type: Bug Priority: Major
Reporter: Przemyslaw Wrobel Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

I have a query like that:

        $rsm = new ResultSetMappingBuilder($this->_em);
        $rsm->addScalarResult('rank', 'rank');
        $rsm->addRootEntityFromClassMetadata('Application\Entity', 'e');

		$query = $this->_em->createNativeQuery('
            SELECT
            	r.rank, ' . $rsm->generateSelectClause(array('e')) . '
            FROM ...
	    ', $rsm);

        return $query->getResult();

When I issue it at the mysql side it returns 3 rows but doctrine returns only 2 - I have tried getArrayResults() with the same results

The query could return the same entity multiple times for different values of the "rank" scalar value but it seems that doctrine removes those duplicates



 Comments   
Comment by Przemyslaw Wrobel [ 14/Apr/14 ]

the result should be like this: ("rank", "entity")
1, entity1
2, entity2
3, entity2

Comment by Marco Pivetta [ 14/Apr/14 ]

Doctrine ORM groups the values of the root of the selection by identifier during hydration: this is the expected result.

Comment by Przemyslaw Wrobel [ 15/Apr/14 ]

If it is really grouping than I shoud have something like that
entity1, 1
entity2, array(2,3)

Now the problem is that I am losing data - the row: 3, entity2 is missing and I have to resort to DBAL query or do not map to entities but than I cannot use my model logic

Comment by Marco Pivetta [ 06/May/14 ]

The resultset you proposed doesn't make sense to me, as it contains inhomogeneous data.

I'd just suggest skipping over adding a root entity to the RSM.

Comment by Francisco Facioni [ 10/Sep/14 ]

How do you hydrate the entities without setting a root entity to the RSM?

Comment by Francisco Facioni [ 10/Sep/14 ]

It looks like there is some commented code that would fix this issue => https://github.com/doctrine/doctrine2/blob/2.4/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php#L569





[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-2060] [GH-465] Fixed a typo in ConcatFunction Created: 08/Oct/12  Updated: 10/Sep/14  Resolved: 25/Oct/12

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

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


 Description   

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

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

Message:



 Comments   
Comment by Benjamin Eberlei [ 08/Oct/12 ]

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

Comment by Fabio B. Silva [ 25/Oct/12 ]

Merged : https://github.com/doctrine/doctrine2/commit/65fabc20c9e807c7b5f86741d60d4a0cecab7ebc

Comment by Doctrine Bot [ 10/Sep/14 ]

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





[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-2460] [GH-672] Simplification example Created: 17/May/13  Updated: 10/Sep/14  Resolved: 26/May/13

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

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


 Description   

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

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

Message:

Remove doctrine class loader, one bootstrap file



 Comments   
Comment by Doctrine Bot [ 26/May/13 ]

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

Comment by Doctrine Bot [ 10/Sep/14 ]

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





[DDC-3302] [GH-1132] DDC-3272 entity generator mapped superclass casing Created: 10/Sep/14  Updated: 10/Sep/14  Resolved: 10/Sep/14

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

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

Issue Links:
Dependency
is required for DDC-3272 EntityGenerator writes 'MappedSuperCl... Resolved

 Description   

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

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

Message:

See DDC-3272 (http://www.doctrine-project.org/jira/browse/DDC-3272)






[DDC-3272] EntityGenerator writes 'MappedSuperClass' instead of 'MappedSuperclass' Created: 26/Aug/14  Updated: 10/Sep/14  Resolved: 10/Sep/14

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

Type: Bug Priority: Minor
Reporter: Jakab Adam Balazs Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: mappedsuperclass, orm, tools
Environment:

not relevant


Issue Links:
Dependency
depends on DDC-3302 [GH-1132] DDC-3272 entity generator m... Resolved

 Description   

In file doctrine/orm/lib/Doctrine/ORM/Tools/EntityGenerator.php, method: generateEntityDocBlock at line: 826, we have

$lines[] = ' * @' . $this->annotationsPrefix . 'MappedSuperClass';

but we do NOT have an annotation in Doctrine\ORM\Mapping called 'MappedSuperClass' but 'MappedSuperclass. (Notice the lowercase "c"!).

When using the generator, this generates the mapped superclass with wrong annotation resulting in

AnnotationException ::semanticalError ('The annotation "@Doctrine\ORM\Mapping\MappedSuperClass" in class Jab\Bundle\PlatformBundle\Entity\JabEntity does not exist, or could not be auto-loaded.')
in /home/data/WWW/localServer/test.bradipo/vendor/doctrine/annotations/lib/Doctrine/Common/Annotations/DocParser.php at line 706



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

Marked as minor issue: the entity generator is not the primary focus of the project.

Comment by Marco Pivetta [ 10/Sep/14 ]

Provided a hotfix at https://github.com/doctrine/doctrine2/pull/1132

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

Fixed in commit: https://github.com/doctrine/doctrine2/commit/b249aa9f652efdd36992ea542ccbd8e82f1b75be





[DDC-3292] [GH-1127] Document embeddables column prefixing Created: 01/Sep/14  Updated: 10/Sep/14  Resolved: 10/Sep/14

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

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

Issue Links:
Reference
is referenced by DDC-3293 XML Mappings disallow disabling colum... Open

 Description   

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

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

Message:

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

Documents column prefixing for embeddables. Adds headings.

I can't use XML or YAML configuration, so I'm not sure if those are correct.



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

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

Comment by Doctrine Bot [ 10/Sep/14 ]

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





[DDC-3120] Warning: Erroneous data format for unserializing PHP5.6+ Created: 11/May/14  Updated: 10/Sep/14  Resolved: 27/Aug/14

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

Type: Bug Priority: Critical
Reporter: Cornelis Brouwers Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: mapping, orm
Environment:

Webserver Apache/2.4.7 (Win32) OpenSSL/1.0.1e PHP/5.6.0beta2

and

PHP-CLI (Win32) PHP/5.6.0beta2


Issue Links:
Duplicate
is duplicated by DDC-3252 [GH-1109] DDC-3120 - PHP 5.6-RC3 comp... Resolved
Reference
is referenced by DDC-3156 [GH-1050] DDC-3120 -- Catch Reflectio... Resolved

 Description   

Hi all,

There seems to be something strange going on in the method newInstance() of the class \Doctrine\ORM\Mapping\ClassMetadataInfo.

The original class method looks like this:

\Doctrine\ORM\Mapping\ClassMetadataInfo#newInstance()

    {
        if ($this->_prototype === null) {
            $this->_prototype = unserialize(sprintf('O:%d:"%s":0:{}', strlen($this->name), $this->name));
        }

        return clone $this->_prototype;
    }

What happens now when a class that implements \Serializable is that a "Warning: Erroneous data format for unserializing" shows up and the function unserialize() returns false.

That is because a class that implements \Serializable is expected to have the letter 'C' in the serialize string instead of the letter 'O'.

I've made a quick work-around like this:

\Doctrine\ORM\Mapping\ClassMetadataInfo#newInstance()

    {
        if ($this->_prototype === null) {
            $this->_prototype = @unserialize(sprintf('O:%d:"%s":0:{}', strlen($this->name), $this->name));
            if ($this->_prototype === false) {
                $this->_prototype = unserialize(sprintf('C:%d:"%s":0:{}', strlen($this->name), $this->name));
            }
        }

        return clone $this->_prototype;
    }

That seems to work in my isolated tests and with Symfony2 and Doctrine2 and FOSUserBundle together.

I've noticed this because the Model\User class from FOSUserBundle implements \Serializable.

I had to implement a check in Model\User class because when using 'C:%d:"%s":0:{}' the $serialized parameter of the unserialize method in the Model\User class is a empty string then.

That warning seems only to happen with PHP5.6+. PHP5.5.12 and below doesn't show that warning.

I hope someone can shine some light on this, thank you,

Cornelis.



 Comments   
Comment by Marco Pivetta [ 11/May/14 ]

Indeed, for PHP 5.4+ we should use

ReflectionClass#newInstanceWithoutConstructor()
Comment by Cornelis Brouwers [ 11/May/14 ]

Just tested it. That works as expected, far more better then the dirty hacks I did, thanks a lot!

Any idea when this would be implemented into the code?

Comment by Marco Pivetta [ 11/May/14 ]

Send a pull request and I'll merge it later today (we could also need a failing test with an entity implementing the Serializable interface)

Comment by Evert Harmeling [ 30/May/14 ]

Seems to be a problem in the latest PHP 5.4 version too.

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

Comment by Doctrine Bot [ 30/May/14 ]

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

Comment by Julian Reyes Escrigas [ 02/Jun/14 ]

I am facing this same error i have PHP 5.5.13, I'm using Symfony, Doctrine ORM and FOSUserBUndle

Comment by Marco Pivetta [ 02/Jun/14 ]

Julian Reyes Escrigas the patch landed in master (2.5.x) for now.

Comment by Marco Pivetta [ 02/Jun/14 ]

Merged via DDC-3147

Comment by Thomas Buhk [ 04/Jun/14 ]

When can we expect the version with this bugfix?

Comment by Anthony Rey [ 08/Jun/14 ]

Why don't you tag 2.4.3 version with this fix ? Because the error is already present in PHP 5.5.13 which is a stable version and it's a blocking issue when you're using FOSUserBundle for example. There is also no opened issue refering this version and the due date is in april.

Comment by Jovan Perovic [ 19/Jun/14 ]

I'm still seeing this bug, although my PHP_VERSION_ID is 50600

So, version based condition is no good...

Comment by Marco Pivetta [ 19/Jun/14 ]

The approach to be taken for 50600 is still under discussion in php-internals.

Comment by Cornelis Brouwers [ 20/Jun/14 ]

Hi all,

I've just downloaded PHP5.6RC1 and updated doctrine and the error is back indeed.

A little peek at the code starting on line 866 of file Doctrine\ORM\Mapping\ClassMetadataInfo.php shows this:

    public function newInstance()
    {
        if ($this->_prototype === null) {
            if (PHP_VERSION_ID === 50429 || PHP_VERSION_ID === 50513) {
                $this->_prototype = $this->reflClass->newInstanceWithoutConstructor();
            } else {
                $this->_prototype = unserialize(sprintf('O:%d:"%s":0:{}', strlen($this->name), $this->name));
            }
        }

        return clone $this->_prototype;
    }

As can be seen, PHP5.6 is out of the picture, it only checks for the exact versions 5.4.29 and 5.5.13.

So for the code to work correctly on PHP5.6 one can add PHP5.6 to the test condition, or just skip the test all together if you don't mind the old PHP5.3. According to PHP, ReflectionClass::newInstanceWithoutConstructor is available since PHP >= 5.4.0.

Greetings, Cornelis.

Comment by Marco Pivetta [ 21/Jun/14 ]

As I already pointed out, this is still being discussed in php internals. See http://news.php.net/php.internals/75009

This won't be dealt with in 5.6 until there's either a stable release or internals decides what has to be done.

Comment by Marco Pivetta [ 21/Jun/14 ]

Also, ReflectionClass#newInstanceWithoutConstructor() still doesn't cover the pre-existing "hack" using unserialize, so we're still waiting for a reliable API from PHP core.

Comment by Chase Noel [ 23/Jul/14 ]

Using PHP 5.6RC2 and ORM 2.4.4 I am still experiencing this issue. I have also tested with PHP 5.5.15 and I am still getting the issue. Do i need to be using a different build of ORM to have the fix applied?

Comment by pascall [ 23/Jul/14 ]

Hi,
I'm using 5.6.0beta3 and ORM 2.4.4 and i have the same probleme
Warning: Erroneous data format for unserializing .. in orm/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php line 872

and in current code in ClassMetadataInfo.php line 872 is :

public function newInstance()
{
if ($this->_prototype === null) {
if (PHP_VERSION_ID === 50429 || PHP_VERSION_ID === 50513)

{ $this->_prototype = $this->reflClass->newInstanceWithoutConstructor(); }

else {
$this->_prototype = unserialize(sprintf('O:%d:"%s":0:{}', strlen($this->name), $this->name));
}
}

return clone $this->_prototype;
}

Comment by Evert Harmeling [ 23/Jul/14 ]

As stated by Marco Pivetta; "This won't be dealt with in 5.6 until there's either a stable release or internals decides what has to be done.". And besides that 5.6 still is in development, not stable.
If you still want to use 5.6 you can fork the code and extend the 5.4 / 5.5 check to support 5.6.

Comment by Chase Noel [ 23/Jul/14 ]

5.6 has an RC which should mean a stable API, and that only bugs will be fixed before an official stable release?

Comment by Evert Harmeling [ 23/Jul/14 ]

Looking at http://news.php.net/php.internals/75966 it's still being discussed, and they are planning to have it fixed in RC3.

Comment by Marco Pivetta [ 23/Jul/14 ]

Internals still didn't get to a clear decision. Until then, we won't support 5.6 officially.

Comment by Ronan [ 24/Jul/14 ]

Same error encountered with PHP 5.5.13 (cli) (built: May 30 2014 10:43:29)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies
with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2014, by Zend Technologies
with Xdebug v2.2.3, Copyright (c) 2002-2013, by Derick Rethans

(PHP 5.5 installed via http://php-osx.liip.ch/)

Comment by Marco Pivetta [ 24/Jul/14 ]

Ronan what D2 version? We fixed it for 2.4.x (temporarily)

Comment by Ronan [ 24/Jul/14 ]

My bad: reading my composer.lock: doctrine/orm, v2.4.2, ref 0363a5548d9263f979f9ca149decb9cfc66419ab, "time": "2014-02-08 16:35:09"... Well.. this is was an old one !

`composer update` fixed it. Sorry for disturbing.

Comment by Chase Noel [ 12/Aug/14 ]

Im still getting this error running php 5.6RC2 and the dev-master(6ac19b04bfbd7a97aad5ed8c2abd6279ff5e0022) build of D2/orm. Am i missing something?

Comment by Marco Pivetta [ 12/Aug/14 ]

This was semi-fixed in PHP5.6-RC3, and it will be patched into ORM once doctrine/instantiator is out

Comment by Chase Noel [ 12/Aug/14 ]

Ok good to know. Thanks

Comment by Marco Pivetta [ 13/Aug/14 ]

Not yet fixed for PHP 5.6

Comment by Marco Pivetta [ 14/Aug/14 ]

Provided a hotfix proposal at https://github.com/doctrine/doctrine2/pull/1109 - please check it out with PHP 5.6.0-RC3 or later

Comment by Doctrine Bot [ 27/Aug/14 ]

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

Comment by Marco Pivetta [ 27/Aug/14 ]

Due to a new introduced dependency, this issue will only be solved for PHP 5.6 in 2.5.0 and later.

Comment by Doctrine Bot [ 28/Aug/14 ]

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

Comment by Dominik Zogg [ 10/Sep/14 ]

@ocramius would be great if there where backports for 2.4 and 2.3





[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





Generated at Wed Sep 17 03:36:00 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.