[PHPCR-94] Implement ->iterate on Query object Created: 19/Feb/13  Updated: 15/Feb/14  Resolved: 15/Feb/14

Status: Closed
Project: Doctrine PHPCR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: Daniel Leech Assignee: Lukas Kahwe
Resolution: Duplicate Votes: 0
Labels: query


 Description   

Implement the Query->iterate method which will return an IteratableResultSet as per the ORM.



 Comments   
Comment by David Buchmann [ 02/Oct/13 ]

is this done? if not, is it trivial?

Comment by David Buchmann [ 15/Feb/14 ]

moved to github https://github.com/doctrine/phpcr-odm/issues/425





[PHPCR-91] getSIngleResult throws ambiguous Exception Created: 19/Feb/13  Updated: 22/Aug/13  Resolved: 22/Aug/13

Status: Resolved
Project: Doctrine PHPCR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: Daniel Leech Assignee: Lukas Kahwe
Resolution: Fixed Votes: 0
Labels: 1.0, query


 Description   

Query->getSingleResult correctly throws an Exception when there are no results (or more than one), but it is an Exception that could also be produced by other things, so not guaranteed to mean that (
(http://docs.doctrine-project.org/projects/doctrine-phpcr-odm/en/latest/reference/query.html#getsingleresult)



 Comments   
Comment by Lukas Kahwe [ 22/Aug/13 ]

https://github.com/doctrine/phpcr-odm/pull/320





[PHPCR-86] QueryBuilder QOMFactory access Created: 14/Jan/13  Updated: 06/Oct/13  Resolved: 06/Oct/13

Status: Resolved
Project: Doctrine PHPCR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Documentation Priority: Trivial
Reporter: Daniel Bojdo Assignee: Lukas Kahwe
Resolution: Fixed Votes: 0
Labels: builder,, qomfactory, query


 Description   

There is getQOMFactory method in PHPCR\Util\QOM\QueryBuilder (very useful) but it isn't in Doctrine\ODM\PHPCR\Query\QueryBuilder (it breaks bc).

Is it mistake or there is/will be another method to access QOMFactory instance?



 Comments   
Comment by Daniel Bojdo [ 15/Jan/13 ]

In fact it's not a bug, there is no docs about DocumentManager methods refactor.

Comment by Lukas Kahwe [ 06/Oct/13 ]

QB was refactored completely





[DDC-2643] Problem on updating an entity with multi-column-identifier with Nullable field Created: 30/Aug/13  Updated: 08/Sep/13  Resolved: 08/Sep/13

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

Type: Bug Priority: Major
Reporter: Dennis Jaschinski Assignee: Benjamin Eberlei
Resolution: Can't Fix Votes: 0
Labels: orm, query
Environment:

Symfony 2.1.x, Doctrine 2.3.x-dev and MySQL 5.5.16



 Description   

Updating an entity that has an multicolumn-key, where one or more columns can be null, would fail if one column is null. Following senario won't work:

CREATE TABLE `t1` (
`owner` int(11) NOT NULL,
`partner` int(11) NOT NULL,
`refNumber` int(11) DEFAULT NULL,
`text` varchar(255) NOT NULL,
UNIQUE KEY `refNumber` (`refNumber`),
UNIQUE KEY `identifier_key` (`owner`,`partner`,`refNumber`)
);

$em = $this->getDoctrine()->getEntityManager();

$entity = $em->getRepository('CoreBundle:T1') ->findOneBy(array('owner'=>1,'partner'=>2)); //

{ Entity has following values 'owner':1,'partner':2, 'refNumber':null, 'text': "simple text"}

$entity->setText('another simple text');
$em->flush();
// results in following query: UPDATE t1 SET text = ? WHERE owner = ? AND partner = ? AND refNumber = ?
// the query resolves but doesn't change any, because "refNumber = null" should be "refNumber is null" to work



 Comments   
Comment by Benjamin Eberlei [ 08/Sep/13 ]

We cannot fix this issue, Doctrine needs the primary key columns to be a value not equaling NULL.





[DDC-2469] SQLite handling for ENUM-Fields Created: 24/May/13  Updated: 24/May/13  Resolved: 24/May/13

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

Type: Bug Priority: Major
Reporter: Andy Rosslau Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: query, schematool, sqlite


 Description   

SQLite doesn't support ENUMS!

But when I try create the schema of the following Entity Doctrine generates this "CREATE TABLE" - Statement:

CREATE TABLE Entity ([...] NOT NULL, taxation ENUM('incl', 'excl'), maxNumbe[...]
class Entity {
...

    /**
     * @var string
     *
     * @ORM\Column(type="string", columnDefinition="ENUM('incl', 'excl')")
     */
    private $taxation = self::TAXATION_INCL;

...
}

Produces this error:

SQLSTATE[HY000]: General error: 1 near "'incl'": syntax error'



 Comments   
Comment by Marco Pivetta [ 24/May/13 ]

Usage of

columnDefinition

in annotations or generally metadata mappings is all about vendor specific syntax. `columnDefinition` is designed to allow overriding the default ORM column generated DDL to build vendor specific syntax/types, therefore the issue is invalid





[DDC-2394] QueryExpressionVisitor has no implementation of Comparison::CONTAINS Created: 08/Apr/13  Updated: 03/Jun/14  Resolved: 14/Apr/13

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

Type: Bug Priority: Major
Reporter: Boris Guéry Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: criteria, expression, orm, query
Environment:

n/a



 Description   
Use case
$criteria = Criteria::create();
$criteria
    ->andWhere(
        $criteria->expr()->contains('r.body', 'foo')
    )
;

$entities = $repo->createQueryBuilder()->addCriteria($criteria)->getQuery()->getResult();

Throws the following exception:

RuntimeException: Unknown comparison operator: CONTAINS

I except it to properly handle the CONTAINS comparison and result in a LIKE operator.

-------

I added a failing test case & a fix there: https://github.com/borisguery/doctrine2/tree/DDC-2394



 Comments   
Comment by Benjamin Eberlei [ 14/Apr/13 ]

This was added in 2.4, you are probably using Collections 1.1 with ORM 2.3, where this occurs.

Comment by Matthieu Napoli [ 16/Sep/13 ]

Apparently it wasn't, I'm on 2.4 and still get the exception.

I submitted a PR: https://github.com/doctrine/doctrine2/pull/791

Comment by Doctrine Bot [ 11/Oct/13 ]

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

Comment by Matthias Althaus [ 27/May/14 ]

As this issue confused me, I took a look into it and the reason seems to be that there's no current release of doctrine/orm including this bugfix. It's not part of the current v2.4.2 tag:

https://github.com/doctrine/doctrine2/blob/v2.4.2/lib/Doctrine/ORM/Query/QueryExpressionVisitor.php
https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Query/QueryExpressionVisitor.php

We'd be really happy to get a new bugfix release.

Running those lib versions:

doctrine/annotations v1.1.2 Docblock Annotations Parser
doctrine/cache v1.3.0 Caching library offering an object-oriented API for many cache b...
doctrine/collections v1.2 Collections Abstraction library
doctrine/common v2.4.2 Common Library for Doctrine projects
doctrine/data-fixtures v1.0.0 Data Fixtures for all Doctrine Object Managers
doctrine/dbal v2.4.2 Database Abstraction Layer
doctrine/doctrine-bundle v1.2.0 Symfony DoctrineBundle
doctrine/doctrine-fixtures-bundle v2.2.0 Symfony DoctrineFixturesBundle
doctrine/inflector v1.0 Common String Manipulations with regard to casing and singular/p...
doctrine/lexer v1.0 Base library for a lexer that can be used in Top-Down, Recursive...
doctrine/orm v2.4.2 Object-Relational-Mapper for PHP

Comment by Marco Pivetta [ 27/May/14 ]

Matthias Althaus this is a new feature, it won't be backported as bugfix.

Comment by Matthieu Napoli [ 27/May/14 ]

Marco Pivetta I would rather say it's a bug because the feature works with ArrayCollection. It was something missing in the implementation in the ORM. The feature is offered by the interface of the Criteria, so the ORM implementation should support it (else the Collection abstraction is useless).

Comment by Marco Pivetta [ 27/May/14 ]

Matthieu Napoli the criteria expressions support depends on the visitor implementation.
They are not interfaced, and custom expression types are also accepted.

Comment by Matthieu Napoli [ 27/May/14 ]

Beyond code interface, I rather mean "contract" between the library and the user.

The criteria's purpose is a query API that works both on persistent and non-persistent collections: it abstracts the persistence away. By having differences in implementation, the main purpose of the criteria is lost, which IMO is a bug.

Comment by Marco Pivetta [ 27/May/14 ]

Matthieu Napoli there are actually various implementations that just don't support many of the operations (wrote some cache-based adapters and some Zend\Db ones as well). It's just an unsupported case in this version, it is not a bug.

Comment by Matthias Althaus [ 03/Jun/14 ]

I can understand both sides, but it's a pity that the QueryExpressionVisitor has such issues with the Criteria API (which is basically quite nice). We've just build some complex filter management around the Criteria API and now it seems more and more like a bad decision.





[DDC-2352] [GH-615] Update SqlWalker.php Created: 15/Mar/13  Updated: 19/Oct/14  Resolved: 19/Oct/14

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

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: aliases, escaping, postgresql, query


 Description   

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

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

Message:

Always be sure that only a-z characters are used for table alias, otherwise use generic "t" for "table"



 Comments   
Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DBAL-999] Get a Sql Server error on Order By - Symfony2 Created: 08/Oct/14  Updated: 19/Oct/14

Status: Awaiting Feedback
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Maël SOURISSEAU Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: orderBy, query, sqlserver


 Description   

Using Symfony with Sql Server and from what I've read, it seems that the connection to the database is not stable.

As soon as I use the orderBy method I get an error :

Here's an example :

Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
  $qStores =
        $this->getManager()
             ->createQueryBuilder()
             ->select('rpdv')
             ->from('MainBundle:PointDeVenteReference', 'rpdv')
             ->andWhere( 'rpdv.partenaireClient = :id_partner ' )
                 ->setParameter( 'id_partner', $this->getUser()->getPartenaire()->getIdPartenaire() )
             ->orderBy( 'rpdv.idPointDeVenteReference' , 'DESC' )
             ->setFirstResult( 0 )
             ->setMaxResults( 30 );

And the error :

An exception has been thrown during the rendering of a template ("An exception occurred while executing
'SELECT DISTINCT TOP 30 id_point_de_vente_reference0
FROM ( SELECT p0_.id_point_de_vente_reference AS id_point_de_vente_reference0,
p0_.reference AS reference1,
p0_.date_derniere_modification AS date_derniere_modification2,
p0_.blocage AS blocage3
FROM point_de_vente_reference p0_
WHERE p0_.id_partenaire_client = ?
ORDER BY p0_.id_point_de_vente_reference DESC ) dctrn_result
ORDER BY id_point_de_vente_reference0 DESC'
with params [2829]:SQLSTATE[42000]:
[Microsoft][SQL Server Native Client 11.0][SQL Server]
The ORDER BY clause is invalid in views, inline functions, derived tables, subqueries, and common table expressions,
unless TOP, OFFSET or FOR XML is also specified.") in MainBundle:Default:store/list.html.twig at line 79.
I tried to change the class SQLServerPlatform with corrections found on the net, without success.

Do you have any idea?

Thx !



 Comments   
Comment by Steve Müller [ 08/Oct/14 ]

Which version of DBAL are you using? A lot of fixes have been applied to SQL Server's LIMIT/OFFSET query rewriting in DBAL during the last months.

Comment by Maël SOURISSEAU [ 08/Oct/14 ]

2.4 for DBAL.

Under my request, I have :

$stores = new Paginator( $qStores, TRUE );

In passing the second parameter to FALSE, I have no error.

Comment by Marco Pivetta [ 19/Oct/14 ]

I'd suggest checking ORM+DBAL latest to see if the issue still exists, as those component have suffered from radical changes in the last few months.





[DBAL-761] Driver\ResultStatement::fetchAll() returns empty array on a seemingly valid Driver\PDOStatement object Created: 03/Jan/14  Updated: 08/Jan/14

Status: Open
Project: Doctrine DBAL
Component/s: Drivers
Affects Version/s: 2.4
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Dennis Matveyev Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mysql, orm, query, schematool
Environment:

Windows 7 64 bit, Zend Server/Studio, PHP 5.4.16,
Server: Apache/2.2.22 (Win32) mod_ssl/2.2.22 OpenSSL/0.9.8x



 Description   

I came across a weird issue, where when running:

vendor/bin/doctrine-module orm:schema-tool:update

I would get:

[Doctrine\DBAL\Schema\SchemaException]
There is no column with name 'resource_id' on table 'role_resource'.

But I did have a column with the above name in the above table, so that was a weird message for me. So I traced it all the way to this line of code:

https://github.com/doctrine/dbal/blob/2.4/lib/Doctrine/DBAL/Connection.php#L630

If I remove "->fetchAll()" from that line, I get this object:

object(Doctrine\DBAL\Driver\PDOStatement)#531 (1)

{ ["queryString"]=> string(332) "SELECT COLUMN_NAME AS Field, COLUMN_TYPE AS Type, IS_NULLABLE AS `Null`, COLUMN_KEY AS `Key`, COLUMN_DEFAULT AS `Default`, EXTRA AS Extra, COLUMN_COMMENT AS Comment, CHARACTER_SET_NAME AS CharacterSet, COLLATION_NAME AS CollactionName FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = 'loginauth' AND TABLE_NAME = 'role_resource'" }

Which has a valid SQL query that runs fine and shows Field names on my local machine's MySQL prompt. But when I add ->fetchAll() back in that line of code, an empty array is returned, field names are not returned, and a SchemaException is generated. I found this odd and wanted to report it. Whether it is a bug or not, hopefully I can find the cause of this issue.

For loads more info, please see this: http://stackoverflow.com/questions/20907491/doctrine-2-there-is-no-column-with-name-columnname-on-table-table



 Comments   
Comment by Steve Müller [ 03/Jan/14 ]

Dennis Matveyev It seems you are using MySQL. Can you please tell which version you use?

Comment by Steve Müller [ 03/Jan/14 ]

Dennis Matveyev Please also provide whether you use mysqli or PDO_MYSQL.

Comment by Steve Müller [ 03/Jan/14 ]

Dennis Matveyev Sounds dumb, but also are you sure that the vendor/bin/doctrine-module orm:schema-tool:update uses the correct connection parameters and does not by error connect to another database server or something? Because otherwise everything looks good IMO.

Comment by Dennis Matveyev [ 07/Jan/14 ]

Yes, I am using:
Server version: 5.5.23-log MySQL Community Server (GPL)
mysql client Ver 14.14 Distrib 5.5.23, for Win32 (x86)

Doctrine connection string for 'driverClass' is 'Doctrine\DBAL\Driver\PDOMySql\Driver', so it is PDO_MYSQL.

I am connecting to the right database, but your last suggestion is what helped to uncover the issue. When connecting to the database with the very same user/pass, and running the command, here is what I saw:

mysql> select resource_id from role_resource;
ERROR 1142 (42000): SELECT command denied to user 'login'@'localhost' for table 'role_resource'

Running a GRANT command to allow SELECT for this user solved the problem.

To improve debugging of similar issues, I'd see if there is a way to propagate the error from MySQL server to ./doctrine-module,
or
improve the error message of SchemaException, to i.e. "There is no column with name 'action_id' on table 'role_action', or database permissions prevent table access."

Thanks!

Comment by Steve Müller [ 07/Jan/14 ]

Dennis Matveyev Thank you for reporting this and I'm glad I could help. I will mark this as improvement, though. You are right in that the root cause of the error should be propagated to the user instead.

Comment by Steve Müller [ 08/Jan/14 ]

Dennis Matveyev Okay I found the root cause of the problem. See what MySQL states about access to the information_schema table for retrieving metadata about a certain database:

Each MySQL user has the right to access these tables, but can see only the rows in the tables that correspond to objects for which the user has the proper access privileges. In some cases (for example, the ROUTINE_DEFINITION column in the INFORMATION_SCHEMA.ROUTINES table), users who have insufficient privileges will see NULL.

So it returns NULL instead of raising an error and this is why Doctrine is not able to propagate the proper exception in this case. I'm not sure if changing the exception message in the SchemaException class is the proper way of handling this. Also please note that this is not only about columns (where you got stuck at) but can occurr for almost every list*() action called in the SchemaManager I suppose. Furthermore this might be a MySQL specific issue, not sure about that.

The proper solution would be to throw an exception much earlier, to have a decent behaviour in such an edge case. I think we should throw an exception here: https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php#L267 because a table cannot live without columns and indicates an error somewhere. But I would like to hear the opinion of Benjamin Eberlei on that issue.

Comment by Steve Müller [ 08/Jan/14 ]

I checked the SQL Server documentation and it seems they behave exactly the same: http://technet.microsoft.com/en-us/library/ms187113.aspx

In SQL Server 2005 and later, the visibility of metadata is limited to securables that a user either owns or on which the user has been granted some permission. For example, the following query returns a row if the user has been granted a permission such as SELECT or INSERT on the table myTable.

However, if the user does not have any permission on myTable, the query returns an empty result set.





[DBAL-578] [GH-354] Added hour to DATE_ADD and DATE_SUB Created: 06/Aug/13  Updated: 08/Sep/13  Resolved: 07/Aug/13

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

Type: Improvement Priority: Major
Reporter: Alexey Makhov Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: dql, query


 Description   

Url: https://github.com/doctrine/dbal/pull/354



 Comments   
Comment by Doctrine Bot [ 06/Aug/13 ]

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

Comment by Marco Pivetta [ 07/Aug/13 ]

Merged: https://github.com/doctrine/dbal/commit/b4d80abd371a15fa24f06417973223569d971ef8





Generated at Mon Dec 22 01:26:53 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.