[DDC-3706] DQL parsing fail when using COUNT with "Simple Derived Identity" primary key Created: 21/Apr/15  Updated: 21/Apr/15

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

Type: Bug Priority: Major
Reporter: Dmitry Korotovsky Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: bidirectional, count, onetoone, parser
Environment:

Mac osx Maverick
PHP 5.5.13
Nginx 1.6.0
Mysql 5.6.19


Attachments: File DDC3331Test.php    

 Description   

There is the regression https://github.com/doctrine/doctrine2/commit/097840dc935e1cfbc93fc673be077a8fe67e8e52

commit 097840dc935e1cfbc93fc673be077a8fe67e8e52
Author: Marco Pivetta <ocramius@gmail.com>
Date: Wed Aug 27 01:56:11 2014 +0200

Allowing expression in `COUNT()` DQL aggregation functions

:040000 040000 5d5f12583a38f54e5966b1cb65dfe487d932a728 982b2c8642e311730b48c6e5d6e6740c97e3bd5c M lib

On Doctrine 2.5.0 FOSElasticaBundle doesn't work completely

$ php app/console fos:elastica:populate --env=test
Resetting users
Refreshing users

[Doctrine\ORM\Query\QueryException]
[Semantical Error] line 0, col 13 near 'a) FROM F\Q\C\N\Entity\UserProfile': Error: Invalid PathExpression. Must be a StateFieldPathExpression.

[Doctrine\ORM\Query\QueryException]
SELECT COUNT(a) FROM F\Q\C\N\Entity\UserProfile a






[DDC-3705] Order by With Equals is not supported Created: 20/Apr/15  Updated: 20/Apr/15

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

Type: Bug Priority: Major
Reporter: Alexey Kosov Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: dql


 Description   

Related to this issue: http://www.doctrine-project.org/jira/browse/DDC-2204
Solution proposed by Benjamin Eberlei doesn't work so the issue it still unresolved.

SELECT
e.status = 1 AS HIDDEN orderField
FROM
Entity e
ORDER BY
orderField DESC

Doctrine\ORM\Query\QueryException
\vendor\doctrine\orm\lib\Doctrine\ORM\Query\QueryException.php:52
[Syntax Error] line 0, col 47: Error: Expected Doctrine\ORM\Query\Lexer::T_FROM, got '='






[DDC-3704] [GH-1390] Document the ChainCache class Created: 20/Apr/15  Updated: 20/Apr/15

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

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


 Description   

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

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

Message:

I was thisclose to writing a ChainCache class myself, and only avoided it by actually looking in the source. There's no mention of ChainCache on Google, probably because there's no docs for it. ChainCache is a bit different from other drivers in that it's something implementers will want to use in their own code in place of an ArrayCache or static array. However, I also added a link to the cache drivers given there's quite a few that aren't mentioned in the docs.






[DDC-3703] [GH-1389] Fix Lexer::match() so it does not accept T_WHERE when T_WITH is supposed to be matched Created: 19/Apr/15  Updated: 19/Apr/15

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

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


 Description   

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

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

Message:

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



 Comments   
Comment by Matthias Pigulla [ 19/Apr/15 ]

This is the PR for DDC-3701. Please close or mark as duplicate of DDC-3701, whatever your workflow is.





[DDC-3702] [GH-1388] Fix Lexer::match() so it does not accept T_WHERE when T_WITH is supposed to be matched Created: 19/Apr/15  Updated: 19/Apr/15

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

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


 Description   

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

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

Message:

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



 Comments   
Comment by Doctrine Bot [ 19/Apr/15 ]

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

Comment by Matthias Pigulla [ 19/Apr/15 ]

Please disregard / close.





[DDC-3701] Questions regarding Parser::match and "identifier" EBNF Created: 19/Apr/15  Updated: 19/Apr/15

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

Type: Bug Priority: Minor
Reporter: Matthias Pigulla Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I am currently investigating a problem where I am suspecting the DQL parser to wrongly transform a DQL statement to SQL. While I haven't yet found the exact reason (will open a new case for it), I have come across the following in the Parser::match() method:

   if ($lookaheadType !== $token && $token !== Lexer::T_IDENTIFIER && $lookaheadType <= Lexer::T_IDENTIFIER) {
      $this->syntaxError($this->lexer->getLiteral($token));
   }

The if-condition was changed a while ago in order to allow DQL terms like WHERE to appear as identifiers.

I think that the condition is wrong as it will only fail (create the syntax error) when the actual token does not match the expected type, we're not expecting an "identifier" and the next token is something special like punctuation that could not serve as an identifier.

So, for example when we're match()ing a T_WITH, a T_WHERE will be accepted as well. A correct check would probably not solve my actual problem, but it would probably have been spotted much earlier due to syntax errors issued.

IMO this should actually read

if ($lookaheadType !== $token && ($token !== Lexer::T_IDENTIFIER || $lookaheadType <= Lexer::T_IDENTIFIER)) { ... syntax error ... }

That is, fail if the token does not match the expectation; and when the expectation is T_IDENTIFIER, also accept every terminal string that can also be considered an "identifier".

With this change, the tests almost pass. The only problem is when a FROM clause expects an "identifier" and now a fully qualified class name starting with a backslash is no longer accepted.

Unfortunately, I also did not manage to find an exact definition of "identifier" somewhere in the EBNF. Lexer::getType() considers everything that starts with a character or underscore an identifier, but that does not match FQCNs.

As there seems to be no special token for backslashes, I tried allowing the backslash as a starting character for identifiers as well (in the Lexer), and it seems to work (all non-skipped tests pass).

What do you think about it? Is that something we should fix and does my change make sense?






[DDC-3700] orderBy stopped working after upgrading to 2.5v (Column not found error) Created: 19/Apr/15  Updated: 19/Apr/15

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

Type: Bug Priority: Major
Reporter: Khurshid Yalgashev Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orderBy
Environment:

ubuntu 14.04


Attachments: JPEG File sl_notification.jpg    

 Description   

Hi,
I have this very simple method in my repository class which fetches a list as query builder object:

public function fetchListAsQueryBuilder(User $user, $receiverType, $limit, $offset)
{
    $queryBuilder = $this->getEntityManager()->createQueryBuilder();
    $query = $queryBuilder
        ->select(['no'])
        ->from('SLCoreBundle:Notification', 'no')
        ->where('no.receiver = :user')
        ->andWhere('no.receiverType = :receiverType')
        ->orderBy('no.createdAt', 'DESC')
        ->setParameters([
            'user' => $user,
            'receiverType' => $receiverType,
        ])
        ->setMaxResults($limit)
        ->setFirstResult($offset)
    ;

    return $query;
}

After upgrading to v2.5 it stopped working and is giving this error:

An exception occurred while executing 'SELECT DISTINCT id_6 FROM (SELECT s0_.receiver_type AS receiver_type_0, s0_.importance AS importance_1, s0_.seen AS seen_2, s0_.deleted AS deleted_3, s0_.created_at AS created_at_4, s0_.updated_at AS updated_at_5, s0_.id AS id_6, s0_.reason AS reason_7 FROM sl_notification s0_ WHERE s0_.receiver_id = ? AND s0_.receiver_type = ?) dctrn_result ORDER BY s0_.created_at DESC LIMIT 25 OFFSET 0' with params [2, 1]:

SQLSTATE[42S22]: Column not found: 1054 Unknown column 's0_.created_at' in 'order clause'

My entity has been configured like this:

Mapped superclass AbstractMessage:

abstract class AbstractMessage
{
    use CreatedUpdatedAtTrait;

    // here go properties, setters and getter

Notification class:

class Notification extends AbstractMessage
{
    // here go properties, setters and getters

And CreateUpdatedAtTrait:

trait CreatedUpdatedAtTrait
{
    /**
     * @var \DateTime
     */
    private $createdAt;

    /**
     * @var \DateTime
     */
    private $updatedAt;

    // Here go setters and getters
}

Schema (AbstractMessage) :

<mapped-superclass name="SL\CoreBundle\Entity\AbstractMessage">

    ... 

    <field name="createdAt" column="created_at" type="datetime">
        <gedmo:timestampable on="create" />
    </field>

    <field name="updatedAt" column="updated_at" type="datetime">
        <gedmo:timestampable on="update" />
    </field>

</mapped-superclass>

I'dont understand what causes this error, my others entities work well with this trait, and also my other queries with orderBy method and mappedsuperclass classes work without any error. And also very interesting part is if I remove orderBy my method is working and I am able to get the createdAt value ($object->getCreatedAt()).

PS// Reference: http://stackoverflow.com/questions/29715104/error-with-orderby-column-not-found






[DDC-3699] [GH-1387] Fix skipping properties if they are listed after a not loaded relation. Created: 17/Apr/15  Updated: 18/Apr/15

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

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


 Description   

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

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

Message:

This issue fixes an issue that occurs when merging entites, when the entity that is being merged has some other properties after a association type field.

Fixes the following scenario :
Your entity extends a parent entity and when it is merged by the entity manager first its fields are computed, this is done correctly bby `ReflectionPropertiesGetter::getProperties()`, but in the `mergeEntityStateIntoManagedCopy` method the iteration is stopped when it gets to a field that is a relationship and it is Proxy and was not loaded yet.
The order in which the fields are computed is : current class properties and then the parent properties, so if the current class has a lazy loaded relationship then the properties of the parent are not merged.

So the fix doesn't stop the iteration it just skips the current property that is not loaded yet and goes to the next property.



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

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





[DDC-3698] [GH-1386] PersisterException: missing license added Created: 17/Apr/15  Updated: 18/Apr/15  Resolved: 18/Apr/15

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

Type: Documentation Priority: Trivial
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed 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/1386

Message:



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

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





[DDC-3697] WHERE conditions can get moved into JOIN conditions with JOINed Inheritance and non-association-JOINs Created: 17/Apr/15  Updated: 17/Apr/15

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

Type: Bug Priority: Major
Reporter: Malte Wunsch Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: dql, orm


 Description   

With the following entities:

/**
 * @ORM\Entity()
 * @ORM\InheritanceType("JOINED")
 * @ORM\DiscriminatorColumn(name="discriminaor", type="integer")
 * @ORM\DiscriminatorMap({"1" = "GeneralEntity", "2" = "SpecializedEntity"})
 */
class GeneralEntity {
    /**
     * @ORM\Id
     * @ORM\GeneratedValue
     * @ORM\Column(type="integer")
     */
    protected $id;
}

/**
 * @ORM\Entity()
 */
class SpecializedEntity extends GeneralEntity {
}

you can create a DQL query (note we're JOINing freely here without traversing a defined association) like

SELECT g1.id
FROM GeneralEntity g1
JOIN GeneralEntity g2
WHERE g2.id = 1

This gets converted to the following SQL:

SELECT g0_.id AS id0
FROM GeneralEntity g0_
LEFT JOIN SpecializedEntity s1_ ON g0_.id = s1_.id
INNER JOIN GeneralEntity g2_
LEFT JOIN SpecializedEntity s3_ ON g2_.id = s3_.id AND (g2_.id = 1)

As you can see, the condition in the WHERE part (g2.id = 1) is no longer in a WHERE clause by it's own, but got moved to the LEFT JOIN of the table inheritance. In this simple special case it probably makes no difference, but in general it does and leads to wrong results.






[DDC-3696] flushing traversable objects Created: 17/Apr/15  Updated: 18/Apr/15

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

Type: New Feature Priority: Major
Reporter: mw Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm, unitofwork


 Description   

Hi,

https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/UnitOfWork.php#L331

it would be easier if you could the method "flush" pass a traversable object. I've implement this behavior in my decorated entity manager. In my opinion this should be an official supported behavior.

The new code should be inside of Orm\UnitOfWork::commit($entity = null) and looks like the following code:

// Compute changes done since last commit.
if( $entity instanceof \Traversable ) {
	$entity = iterator_to_array( $entity );
}

By the way, the foreach part can be simplified to one line. This can be made possible by array_walk.
You can use:

} elseif (is_array($entity)) {
	array_walk($entity, array($this, 'computeSingleEntityChangeSet'));
}

Now, the new code in one piece:

// Compute changes done since last commit.
if( $entity instanceof \Traversable ) {
	$entity = iterator_to_array( $entity );
}

if ($entity === null) {
	$this->computeChangeSets();
} elseif (is_object($entity)) {
	$this->computeSingleEntityChangeSet($entity);
} elseif (is_array($entity)) {
	array_walk($entity, array($this, 'computeSingleEntityChangeSet'));
}

Thanks in advance.



 Comments   
Comment by Marco Pivetta [ 17/Apr/15 ]

Two things:

1) we are more inclined to remove the parameter from flush(), as it was exploited for purposes it wasn't designed for.
2) what happens if you persist an entity that is a traversable?

Comment by mw [ 17/Apr/15 ]

1.Is that really planned? I guess this is a helpful feature and makes not a difference if you flush a small collection of entities before you flush the remaining entities without the parameter.

2. The object will be treated as entity, because it's an object. This will throw an "Doctrine\ORM\Mapping\MappingException" exception with following message:

Class "SplObjectStorage" is not a valid entity or mapped super class.
Exception-Class: Doctrine\ORM\Mapping\MappingException 
Exception-Code: 0 
Exception-File: Composer/doctrine/orm/lib/Doctrine/ORM/Mapping/MappingException.php 
Exception-Line: 346

This simple senseless code shows you what you can do to test this behavior.

$em = Doctrine_Factory::getEntityManager();
$em->persist($entity);
$x = new SplObjectStorage();
$x->attach($entity);
$em->flush($x);
Comment by Marco Pivetta [ 17/Apr/15 ]

You can implement the Traversable interface (as iterator or iteratoraggregate) on any entity.

As for "planned", it obviously won't happen in 2.x.

We are mainly interested in finding better ways to speed up flush() operations rather than delegating transactional boundaries knowledge to the user.

Anyway, so far, flush($entities) has been more of a source of bugs rather than an actual useful API.

Comment by mw [ 18/Apr/15 ]

The Traversable interface serves to detect whether a class is traversable using foreach. The flush parameter surrenders this parameter one-to-one to $this->unitOfWork->commit($entity).
What I want to do is to hand over an traversable object to the method EntityManager::flush with a collection of entities instead of an single entity object. It's also possible to pass a collection of entities as array. But it's not possible to pass a collection of entities as an object, because when passing an object UnitOfWork::commit assumes that it's an entity. To implement the Traversable interface on any entity will not help and is not the same intention. Because an Traversable object it means, that is a collection of entities like an array.

In my opinion there are not objections that speak against it to support traversable object (SplObjectStorage, ArrayIterator, ArrayObject).

There are two ways to do that.

The first option would be:

// Compute changes done since last commit.
if( $entity instanceof \Traversable ) {
	$entity = iterator_to_array( $entity );
}

if ($entity === null) {
	$this->computeChangeSets();
} elseif (is_object($entity)) {
	$this->computeSingleEntityChangeSet($entity);
} elseif (is_array($entity)) {
	array_walk($entity, array($this, 'computeSingleEntityChangeSet'));
}

The second option would be:

// Compute changes done since last commit.
if ($entity === null) {
	$this->computeChangeSets();
} elseif (is_array($entity) || $entity instanceof \Traversable) {
	foreach ($entity as $object) {
		$this->computeSingleEntityChangeSet($object);
	}
} elseif (is_object($entity)) {
	$this->computeSingleEntityChangeSet($entity);
}

By the way: the SplObjectStorage object has the benefit that every entity is present only once.





[DDC-3695] [GH-1385] duplicated param in phpdoc Created: 17/Apr/15  Updated: 18/Apr/15  Resolved: 18/Apr/15

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

Type: Documentation Priority: Trivial
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed 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/1385

Message:



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

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





[DDC-3694] [GH-1384] cs Created: 17/Apr/15  Updated: 18/Apr/15  Resolved: 18/Apr/15

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

Type: Improvement Priority: Trivial
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: code-style, coding-standards, cs


 Description   

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

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

Message:



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

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





[DDC-3693] Notify change tracking policy breaks in the face of individual entity flushes Created: 15/Apr/15  Updated: 15/Apr/15

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

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


 Description   

The notify change tracking policy breaks, if other entities are individually flushed between change and flush on a given notify-based entity.

The culprit seems to be that UnitOfWork.commit() resets its scheduledForSynchronization and entityChangeSets arrays (name(s) has changed since 2.2.2) - even when the commit is for a single entity, and the arrays hold other scheduled entities/changes.

An example:

use \net\jay\test\A;

$em = \Doctrine2::getEntityManager();

# persist and flush two instances of A
$a1 = new A(1, 'x');
$a2 = new A(2, 'y');
$em->persist($a1);
$em->persist($a2);
$em->flush();

# change both, but flush $a2 first, then do a general flush
$a1->setName('xx');
$a2->setName('yy');
$em->flush($a2);
$em->flush();

# $a1 entity should be changed, but isn't
$em->clear();
$a1 = $em->getRepository('net\jay\test\A')->find(1);
echo $a1->getName(); # = 'x' (should be 'xx')
namespace net\jay\test;

/**
 * @Entity
 * @ChangeTrackingPolicy("NOTIFY")
 */
class A implements \Doctrine\Common\NotifyPropertyChanged
{
	/** @Id @Column(type="integer") */
	private $id;
	
	/** @Column(length=100) */
	private $name;
	
	private $_changeListeners;
	
	public function __construct($id, $name)
	{
		$this->id = $id;
		$this->name = $name;
	}
	
	public function addPropertyChangedListener(\Doctrine\Common\PropertyChangedListener $listener)
	{
		$this->_changeListeners[] = $listener;
	}
	
	private function _onPropertyChanged($propName, $oldValue, $newValue)
	{
		if ($this->_changeListeners)
		{
			foreach ($this->_changeListeners as $listener)
			{
				$listener->propertyChanged($this, $propName, $oldValue, $newValue);
			}
		}
	}
	
	public function getID()
	{
		return $this->id;
	}
	
	public function getName()
	{
		return $this->name;
	}
	
	public function setName($name)
	{
		$this->_onPropertyChanged('name', $this->name, $name);
		$this->name = $name;
	}
}





[DDC-3692] [GH-1383] DDC-3691 add test case Created: 14/Apr/15  Updated: 14/Apr/15

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

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


 Description   

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

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

Message:

Test case for DDC-3691






[DDC-3691] Filtering by 'date' column does not return enough values on SQLite Created: 14/Apr/15  Updated: 17/Apr/15

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

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

Windows 8.1 x64
PHP 5.6.2
date.timezone => Europe/Berlin


Attachments: Zip Archive sandbox.zip    

 Description   

When using a column of type 'date' in a where clause, filtering fails and does not return entries which clearly should match.

I have implemented a small proof of concept on the Doctrine sandbox. You can find it by checking out my branch at https://github.com/XitasoChris/doctrine2/tree/date_filter_bug and then run the tools/sandbox/index.php . Alternatively, I have zipped the sandbox folder and attached it to this bug report.

I don't know whether this affects other database systems as well. I only tested it on SQLite.



 Comments   
Comment by Marco Pivetta [ 14/Apr/15 ]

Linking the diff: https://github.com/doctrine/doctrine2/compare/master...XitasoChris:date_filter_bug

Should be a test case, XitasoChris - can you convert it?

Comment by XitasoChris [ 14/Apr/15 ]

@Marco: I will try, though I have never done that on the doctrine project before.

Comment by XitasoChris [ 14/Apr/15 ]

Test case created: https://github.com/doctrine/doctrine2/pull/1383

Comment by XitasoChris [ 17/Apr/15 ]

After some more debugging: The problem is that the type of the parameter is inferred as "datetime", leading Doctrine to format the value as "2015-03-01 00:00:00". However, SQLite needs the value formatted as "2015-03-01" to find a match.

A workaround is to tell Doctrine to format the parameter as a date [$queryBuilder->setParameter("date", $date, "date")] and then the test case works fine.

My question now is: is this behavior expected? If so, then the bug report is probably invalid.





Generated at Tue Apr 21 09:53:41 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.