[DDC-3295] Detection of reserved words in DQL Created: 02/Sep/14  Updated: 02/Sep/14  Resolved: 02/Sep/14

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

Type: Bug Priority: Major
Reporter: James Murray Assignee: Marco Pivetta
Resolution: Can't Fix Votes: 0
Labels: dql, lexer, parser


 Description   

I don't know if the summary really explains much...

I wrote a query in DQL (using the query builder but I doubt that matters). The query is:

SELECT club FROM Domain\Groups\Roster roster INNER JOIN Domain\Club\Club club WITH club.roster = roster INNER JOIN Domain\Groups\GroupMember member WITH member.group = roster

This results in the error:

line #, col ###: Error: Expected Doctrine\ORM\Query\Lexer::T_MEMBER, got '='

It wasn't until I looked deep into the documentation that I can't name my entity "member" because it's a reserved word (I guess) in DQL for the MEMBER OF clause.

Is it possible to detect that the usage of it is as an entity name, not a comparison operator?
Is there anyway around this?

I could only imagine that I'm not the first person to have this issue, and I'm sure that there are other people out there with user systems that would like to use the word 'member'

Maybe the documentation should have a page that covers what words are 'reserved words'? (if there is a page that mentions them, I haven't seen it)



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

We have an EBNF at http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/dql-doctrine-query-language.html#ebnf, where all DQL symbols are listed.

We can't solve this sort of issue in 2.x as it would require a rewrite of the parser/lexer.





[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-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... Open

 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-3292] [GH-1127] Document embeddables column prefixing Created: 01/Sep/14  Updated: 01/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

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.






[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-3290] OneToOne relation with composite primary key and nullable value Created: 01/Sep/14  Updated: 01/Sep/14

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

Type: Bug Priority: Major
Reporter: Sandor Farkas Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

i've a problem with a composite primary key on a OneToOne relation in doctrine.
When one object has no relation (which is normally possible) i got the following error message:

Doctrine\Common\Proxy\Exception\OutOfBoundsException: Missing value for
primary key idEngine on Farkas\CoreBundle\Entity\Engine

I've found the problem directly in doctrine:

vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php Line 2116

    // TODO: Is this even computed right in all cases of composite keys?
    foreach ($assoc['targetToSourceKeyColumns'] as $targetColumn => $srcColumn) {
        $joinColumnValue = isset($data[$srcColumn]) ? $data[$srcColumn] : null;
        if ($joinColumnValue !== null) {
            if ($targetClass->containsForeignIdentifier) {
                $associatedId[$targetClass->getFieldForColumn($targetColumn)] = $joinColumnValue;
            } else {
                $associatedId[$targetClass->fieldNames[$targetColumn]] = $joinColumnValue;
            }
        }
    }

$joinColumnValue is null when the foreign key is empty because the array $data which includes the row data doesn't have the array key for the relation field.
The todo comment tells me that something is wrong with composite keys?

Here my two Entities (Just a small test, don't think about the logic of my entities^^):

1st

    /**
     * Car
     *
     * @ORM\Table()
     * @ORM\Entity(repositoryClass="Farkas\CoreBundle\Entity\CarRepository")
     */
    class Car
    {
        /**
         * @var integer
         *
         * @ORM\Column(name="id_car", type="integer")
         * @ORM\Id
         * @ORM\GeneratedValue(strategy="NONE")
         */
        private $idCar;


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

        /**
         * @var string
         *
         *
         * @ORM\OneToOne(targetEntity="Engine", mappedBy="car")
         * @ORM\JoinColumns(
         *    @ORM\JoinColumn(name="engine", referencedColumnName="id_engine"),
         *    @ORM\JoinColumn(name="country", referencedColumnName="country")
         * )
         */
        private $engine;

        /**
         * @var integer
         * @ORM\Id
         * @ORM\Column(name="country", type="integer")
         */
        private $country;
    }

2nd

    /**
     * Engine
     *
     * @ORM\Table()
     * @ORM\Entity(repositoryClass="Farkas\CoreBundle\Entity\EngineRepository")
     */
    class Engine
    {
        /**
         * @var integer
         *
         * @ORM\Column(name="id_engine", type="integer")
         * @ORM\Id
         * @ORM\GeneratedValue(strategy="NONE")
         */
        private $idEngine;

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

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

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

        /**
         * @var integer
         *
         * @ORM\OneToOne(targetEntity="Car", inversedBy="engine")
         * @ORM\JoinColumns(
         *    @ORM\JoinColumn(name="car_id", referencedColumnName="id_car"),
         *    @ORM\JoinColumn(name="country", referencedColumnName="country")
         * )
         */
        private $car;
    }

When i try to execute findAll() i got the error message above.
When i execute the generated sql directly in mysql, everything looks fine:

    SELECT t0.id_car AS id_car1, t0.brand AS brand2, t0.country AS country3, 
    t0.engine AS engine4, t0.country AS country5 FROM Car t0

It means, the hydration can't work with an empty oneToOne relation.

I uploaded my testproject on github: https://github.com/sfarkas1988/DoctrineOneToOneIssue
Hopefully somebody can help me because it's somehow urgent for my real project.
Thank you very much.






[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-3288] [GH-1126] Fixed new line in docblock Created: 30/Aug/14  Updated: 30/Aug/14  Resolved: 30/Aug/14

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

Type: Bug Priority: Trivial
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed 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/1126

Message:

Fixes docblock generation for ```set```, ```get```, ```add``` and ```remove``` methods (change introduced in #1067 247803715bd7e5ded75e25dbbb4eb2c5b7fbd2f2):

Before:
```php
/**

  • Set myProp.

*

  • @param integer $myProp
    *
  • @return MyEntity
    */
    ```

After:
```php
/**

  • Set myProp.
    *
    *
  • @param integer $myProp
    *
  • @return MyEntity
    */
    ```


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

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

Comment by Doctrine Bot [ 30/Aug/14 ]

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





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

Status: Open
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 PreUpdateEventArgs don't allow for creating event listeners that fit both ORM- and MongoDB-driven applications.

While defining a listener with

use Doctrine\Common\Persistence\LifecycleEventArgs;

// ...

public function preUpdate(LifecycleEventArgs $args) { ... }

works fine, using

use Doctrine\Common\Persistence\PreUpdateEventArgs;

// ...

public function preUpdate(PreUpdateEventArgs $args) { ... }

will not work with ORM-dispatched events - and probably not with MongoDB events either (I did not test this).






[DDC-3286] Error: Expected Literal, got ')' Created: 29/Aug/14  Updated: 30/Aug/14  Resolved: 30/Aug/14

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: bilou gagou Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

Hello there,

I'm having this bug when running a query on my view:

[Syntax Error] line 0, col 68: Error: Expected Literal, got ')'

And I know where it comes from and why but I couldn't fix it so far.
Actually, my query on my view has this condition

$qb->andwhere($qb->expr()->eq(
'view.someColumn',
$qb->expr()->literal('hi')
))

Sometimes, my views doesn't contain the column "someColumn" at all, in which case I got the bug below.
How can I do to fix it?



 Comments   
Comment by bilou gagou [ 29/Aug/14 ]

Ooops, the problem isn't as I said I just realized it. Sorry about that





[DDC-3285] \Doctrine\ORM\Event\PreUpdateEventArgs::getOldValue and ::getNewValue return wrong values for ManyToMany association Created: 29/Aug/14  Updated: 29/Aug/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: 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-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-3283] [GH-1125] Update improving-performance.rst Created: 29/Aug/14  Updated: 30/Aug/14  Resolved: 30/Aug/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: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

Add change tracking policies chapter



 Comments   
Comment by Doctrine Bot [ 29/Aug/14 ]

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





[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-3281] Error: Expected Doctrine\ORM\Query\Lexer::T_CLOSE_PARENTHESIS, got 'S' Created: 28/Aug/14  Updated: 29/Aug/14  Resolved: 28/Aug/14

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: David Soussan Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: dql, orm
Environment:

Windows 7, WAMPP, PHP 5.4, Symfony 2.3.3, SonataAdminBundle


Attachments: File composer.lock    

 Description   

Twig_Error_Runtime: An exception has been thrown during the rendering of a template ("[Syntax Error] line 0, col 545: Error: Expected Doctrine\ORM\Query\Lexer::T_CLOSE_PARENTHESIS, got 'S'") in SonataAdminBundle:CRUD:base_list.html.twig at line 33.

QueryException: SELECT o FROM TLF\PortalBundle\Entity\Company o WHERE o.name IN ('EWEN MACRAE (WEST END GARAGE) LIMITED','F.A.M. ENGINEERING LTD','FIFE ACCIDENT REPAIR CENTRE LIMITED','FORREST RESCUE','FOURWINDS GARAGE','FRED HENDERSON LIMITED','FURNESS CARS & COMMERCIALS LTD','FYLINGDALES SERVICE STATION','G BANNERMAN (TAIN) LIMITED','GALLOWS WOOD SERVICE STATION LIMITED','GLENDINNING BROS.','GLENGYLE GARAGE LTD','GRAHAMS VEHICLE REPAIRS','GREENPARK GARAGE LIMITED','GRIFFIN`S RESCUE LIMITED','GWALIA RECOVERY LIMITED','H K MOTORS (WALES) LIMITED','HARDY\'S RECOVERY LIMITED','HIGHFIELD GARAGE & RECOVERY LIMITED','HINTON RESCUE','HORNE PARK GARAGE LIMITED','Independent Inspections','J & J CAMPSIE LIMITED','J D MACADAM & SON (RESCUE) LIMITED','J.H HENDERSON & SONS LIMITED') ORDER BY o.name ASC

This error is generated by the SonataAdminBundle when fetching entities for display in the admin list. The query is generated by the bundle and one can see the escape character in the query: ,'HARDY\'S RECOVERY LIMITED', but the Lexer is not escaping the apostrophe but rather sees it as the string terminator. Hence the error.

My composer.lock is attached.



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

Quote escaping in DQL strings is done by doubling the quote, not by prepending a backslash. So you are not escaping it

Comment by David Soussan [ 29/Aug/14 ]

Thanks Chris. Since this DQL is produced by SonataAdminBundle, not me, then this is a bug in that bundle and I will raise it with them.





[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-3279] [GH-1124] Removed PHP warning when iterating over filtering joins Created: 27/Aug/14  Updated: 28/Aug/14  Resolved: 28/Aug/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of timb-pt:

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

Message:

Using the Query::iterate() function with a filtering join can cause a PHP warning in ObjectHydrator::hydrateRowData().



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

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





[DDC-3278] [GH-1123] Fixed the structure of the reverse-engineered mapping Created: 27/Aug/14  Updated: 30/Aug/14  Resolved: 30/Aug/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: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

when using the DatabaseDriver, the field mapping being generated does not match the field mapping expected by all other drivers or the SchemaTool. This means that these mapping settings get ignored.

See https://github.com/doctrine/migrations/issues/184 for the initial report and DDC-3277



 Comments   
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





[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-3276] [GH-1122] Support arithmetic expressions in `COUNT()` Created: 26/Aug/14  Updated: 27/Aug/14  Resolved: 27/Aug/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


 Description   

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

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

Message:

tl;dr:

Following is now allowed

```sql
SELECT COUNT(DISTINCT CONCAT(u.name, u.surname)) FROM User u
```

I am not aware of RDBMS implementations that do not support this. Ping @guilhermeblanco



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

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

Comment by Doctrine Bot [ 27/Aug/14 ]

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





Generated at Tue Sep 02 23:59:35 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.