[DDC-3097] [GH-1015] Add ExpressionBuilder::contains() to docs Created: 23/Apr/14  Updated: 23/Apr/14  Resolved: 23/Apr/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


 Description   

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

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

Message:



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

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

Comment by Marco Pivetta [ 23/Apr/14 ]

Merged: https://github.com/doctrine/doctrine2/commit/9ec54b8fedc9d1b926b33af066ac9f263cadccc2





EntityManager::clear($entity) support (DDC-1278)

[DDC-2850] Allow cascaded clearing of Entities associated to the indicated Entity Created: 11/Dec/13  Updated: 21/Apr/14  Resolved: 21/Apr/14

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

Type: Sub-task Priority: Minor
Reporter: Menno Holtkamp Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

As described here, it would be nice to have associated Entities be cleared in case required and configured in such way. It seems the functionality is available already, but always disabled (noCascade => TRUE).
A secondary optional boolean parameter to the function would do:

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

 
public function clean($entityName = null, $noCascade = true)

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

$this->doDetach($entity, $visited, $noCascade);


 Comments   
Comment by Menno Holtkamp [ 30/Mar/14 ]

PR: https://github.com/doctrine/doctrine2/pull/995
Auto-created issue: http://www.doctrine-project.org/jira/browse/DDC-3060

Comment by Doctrine Bot [ 16/Apr/14 ]

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

Comment by Guilherme Blanco [ 21/Apr/14 ]

As of https://github.com/doctrine/doctrine2/commit/1cd0b26a40dc22b0d11b1860eb058ab9cdc29f36 this issue is now fixed.





[DDC-2946] [GH-926] Feature/console em helper interface Created: 01/Feb/14  Updated: 21/Apr/14  Resolved: 21/Apr/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: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 01/Feb/14 ]

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

Comment by Guilherme Blanco [ 21/Apr/14 ]

This was merged some time ago.

Reference commit: https://github.com/doctrine/doctrine2/commit/105d9e998baffb44cb44cf08d1c31c448ef6302a





[DDC-3058] [GH-993] Update JoinColumn.php Created: 28/Mar/14  Updated: 21/Apr/14  Resolved: 21/Apr/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: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

If $referencedColumnName = 'id' by default, it doesn't make sense to make checks like:
```php
if (empty($joinColumn['referencedColumnName'])) {
```
(ClassMetaDataInfo file)


Considering you map your column
```
@ORM\JoinColumn(onDelete="CASCADE")
```
You'll get JoinColumn with 'id' value, which doesn't let doctrine use naming strategies for referenced column names



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

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

Comment by Guilherme Blanco [ 21/Apr/14 ]

Unfortunately, while this is true for Annotations (it can never be empty), it is not for XML, YAML and PHP itself.
When using Annotations, we keep convention over configuration as the standard, providing the default id, while we require further configuration on other drivers.

Closing as invalid.





[DDC-3085] NULL comparison are not supported for result variables in the HAVING clause Created: 15/Apr/14  Updated: 21/Apr/14  Resolved: 21/Apr/14

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

Type: Bug Priority: Major
Reporter: Christophe Coevoet Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

the following DQL query fails saying that score does not point to a class:

SELECT u AS user, SUM(r.value) AS score
FROM User u
LEFT JOIN ResultEntry r WITH r.user = u
GROUP BY u
HAVING score IS NOT NULL AND score >= 5

When removing the condition score IS NOT NULL, the query is working fine. The score result variable can be used in other comparisons:

SELECT u AS user, SUM(r.value) AS score
FROM User u
LEFT JOIN ResultEntry r WITH r.user = u
GROUP BY u
HAVING score >= 5


 Comments   
Comment by Guilherme Blanco [ 21/Apr/14 ]

Added coverage for this issue on master as of https://github.com/doctrine/doctrine2/commit/63d21ca4b28cb0e9192dadf6ff9d9dd17f0c2e4c
I'm unable to "fix" this because it's an enhancement to DQL (support ResultVariable in NullComparisonExpression) that cannot be done in 2.4 series. Please use 2.5 (currently dev-master) instead.





[DDC-3095] [GH-1014] Update second level cache doc Created: 20/Apr/14  Updated: 21/Apr/14  Resolved: 21/Apr/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: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

Hi,

While testing the second level cache (side note: this is truly awesome and flexible, I love the fact it works with Criteria too), I realized that if you add the "Cache" annotation to an association, it won't put in cache the associated entities, until you also mark the target entity as cacheable. This is not obvious from reading the doc (and I don't know if that's expected behavior neither).



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

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

Comment by Guilherme Blanco [ 21/Apr/14 ]

This issue got merged into master.





[DDC-3065] Generated 'IN' clause doesn't handle 'null' values (needs to add 'IS NULL' check) Created: 03/Apr/14  Updated: 21/Apr/14  Resolved: 21/Apr/14

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

Type: Bug Priority: Critical
Reporter: Sam Adams Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: IN, null, orm

Issue Links:
Dependency
depends on DDC-3067 [GH-999] DDC-3065 null value in in cr... Resolved
Reference
is referenced by DDC-3066 [GH-998] DDC-3065 null value in in cr... Resolved

 Description   

BasicEntityPersister::getSelectSQL($criteria) first argument can take an array.
However, if that array contains an 'or' structure like so:

array(
  'mycol'=>array(
    'couldbethis','orthis',null
  )
);

it is converted into:

mycol IN (?)

With the final query looking like:

WHERE mycol IN ('couldbethis','orthis',null)

The problem is, mysql will never be able to match the null.

Possible change to getSelectConditionStatementSQL method:

        if (is_array($value)) {
            $in = sprintf('%s IN (%s)' , $condition, $placeholder);
            $nullKey = array_search(null, $value, true);

            if ($nullKey) {
                return sprintf('(%s OR %s IS NULL)' , $in, $condition);
            } else {
                return $in;
            }
        }

resulting in a final query like:

WHERE (mycol IN ('couldbethis','orthis',null) OR mycol IS NULL)


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

Please see https://github.com/doctrine/doctrine2/pull/998 - I applied your suggested fix and tested it carefully

Comment by Doctrine Bot [ 03/Apr/14 ]

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

Comment by Guilherme Blanco [ 21/Apr/14 ]

As of https://github.com/doctrine/doctrine2/commit/4185a9ce4b205e683097842916c8a8929659c6d1 this issue is fixed.





[DDC-3067] [GH-999] DDC-3065 null value in in criteria support Created: 03/Apr/14  Updated: 21/Apr/14  Resolved: 17/Apr/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

Issue Links:
Dependency
is required for DDC-3065 Generated 'IN' clause doesn't handle ... Resolved

 Description   

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

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

Message:

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

This MAY be a breakage, since the following API now works as expected:

```php
$repository->findBy(['fieldName' => [null]]);
$repository->findBy(['fieldName' => [123, null]]);
```

Where before, `null` was just ignored



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

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

Comment by Fabio B. Silva [ 17/Apr/14 ]

Closed, see : https://github.com/doctrine/doctrine2/pull/998

Comment by Doctrine Bot [ 21/Apr/14 ]

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





[DDC-3075] [GH-1005] Added support of the subselect expressions into NEW expressions Created: 08/Apr/14  Updated: 20/Apr/14  Resolved: 20/Apr/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: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

Added support for the subselects into the ���NEW��� Operator Syntax



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

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

Comment by Guilherme Blanco [ 20/Apr/14 ]

As of https://github.com/doctrine/doctrine2/commit/a3f95d919bfa52550b271486cd6e256e6c91d356 this issue is closed





[DDC-3094] dbal and orm versions not compatible Created: 20/Apr/14  Updated: 20/Apr/14  Resolved: 20/Apr/14

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

Type: Bug Priority: Blocker
Reporter: Luis Cordova Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: dbal, orm


 Description   

( ! ) Fatal error: Call to undefined method Doctrine\ORM\Event\LifecycleEventArgs::format() in /Users/cordoval/Sites/x/vendor/doctrine/dbal/lib/Doctrine/DBAL/Types/DateTimeType.php on line 53

This is happening on sf2.4 default project

"require":

{ "php": ">=5.3.3", "symfony/symfony": "~2.4", "doctrine/orm": "~2.2,>=2.2.3", "doctrine/doctrine-bundle": "~1.2", "twig/extensions": "~1.0", "symfony/assetic-bundle": "~2.3", "symfony/swiftmailer-bundle": "~2.3", "symfony/monolog-bundle": "~2.4", "sensio/distribution-bundle": "~2.3", "sensio/framework-extra-bundle": "~3.0", "incenteev/composer-parameter-handler": "~2.0", "jms/security-extra-bundle": "1.5.*", "jms/di-extra-bundle": "1.4.*", "friendsofsymfony/user-bundle": "dev-master@dev", "doctrine/doctrine-migrations-bundle": "dev-master@dev", "doctrine/migrations": "dev-master@dev", "doctrine/doctrine-fixtures-bundle": "dev-master@dev", "doctrine/data-fixtures": "dev-master@dev", "symfony/icu": "~1.1", "colourstream/cron-bundle": "dev-update23@dev", "nelmio/alice": "dev-master@dev", "raulfraile/ladybug-bundle": "0.7", "guzzle/guzzle": "~3.7", "jms/serializer-bundle": "0.12.0", "beberlei/DoctrineExtensions": "dev-master@dev" }

,
"require-dev":

{ "behat/behat": "~3.0@dev", "phpspec/phpspec": "dev-master@dev", "phpspec/symfony2-extension": "dev-master@dev", "behat/mink-bundle": "~1.4", "phpunit/phpunit": "~3.7", "behat/mink-selenium2-driver": "~1.1" }

,



 Comments   
Comment by Luis Cordova [ 20/Apr/14 ]

closing but you guys broke backward compatibility here, i had to figure it out thanks though

Comment by Luis Cordova [ 20/Apr/14 ]





[DDC-2575] Hydration bug Created: 27/Jul/13  Updated: 18/Apr/14  Resolved: 18/Apr/14

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

Type: Bug Priority: Major
Reporter: Nicolas Bottarini Assignee: Guilherme Blanco
Resolution: Fixed Votes: 1
Labels: dql, orm


 Description   

I have the following class mappings:

class A
{
    /**
     * @Id
     * @Column(type="integer")
     * @GeneratedValue(strategy="AUTO")
     */
    protected $id;
    
    /**
     * @Column(type="string", length=100, nullable=FALSE)
     */    
    protected $sampleField;
    
    /**
     * @OneToOne(targetEntity="B", mappedBy="aRelation")
     **/     
    protected $bRelation;
}
class B
{
    /**
     * @Id
     * @OneToOne(targetEntity="A", inversedBy="bRelation")
     * @JoinColumn(name="a_id", referencedColumnName="id", nullable=FALSE, onDelete="CASCADE")
     */
    protected $aRelation;

    /**
     * @ManyToOne(targetEntity="C")
     * @JoinColumn(name="c_id", referencedColumnName="id", nullable=FALSE, onDelete="CASCADE")
     */
    protected $cRelation;

}
class C
{
    /**
     * @Id
     * @Column(type="integer")
     * @GeneratedValue(strategy="AUTO")
     */
    protected $id;
    
    /**
     * @Column(type="string", length=100, nullable=FALSE)
     */    
    protected $sampleField;
}

Then I make the following query:

$qb = $em->createQueryBuilder();
$qb = $qb->select('a, b, c')
      ->from('A','a')
      ->leftJoin('a.bRelation', 'b')
      ->leftJoin('b.cRelation', 'c');
      
$result = $qb->getQuery()->getResult();

The result contains a collection of instances of class A with the a.bRelation field populated and the a.bRelation.cRelation field populated in all rows except the last one.

The problem is an hydration problem. The Parser constructs the select statement with the fields of class A, then the fields of class C and last the fields of class B. The hydrator don't work correctly because when it's hydrating class C it doesn't find the class B (because it appears last in the select statement).
I think the problem is because class B only contains associations. If i put an extra field (an string for example) in class B it works as expected.



 Comments   
Comment by Popy [ 28/Oct/13 ]

I have the same kind of bug : i have a OneToMany relations which stays to null if I request both entities in one query, and miss an entity if I preload the related entities in a second query. It seems to occur on the last entity of the list.

If I remember well the hydrator code, there's (in the hydratation loop) something like "If we find a new root entity (or maybe on each row, i'm not sure), link the entities we didn't link". Maybe this thing is not done AFTER the loop for remaining entities.

I'll try to dig again into the hydrator code tomorrow to check this hypothesis.

Comment by Popy [ 29/Oct/13 ]

This bug seems more severe :

I made a test on a query with 3 entities (root, root->a, root->b, a and b relations are OneToMany, so no connections on this side), and there's the process I witness :

  • First result row
  • The hydrator finds the linked entities before the root... and just does nothing (line 359)
  • The hydrator finds the root entity, and hydrate it
  • Other result rows
  • The hydrator finds the linked entities before the root... and associate them with the previously found root entity, which is the root entity fetched on the first row
  • The hydrator finds the root entity, so trash the previous, and hydrate (without related entities, as they were linked to previous root entity)

To finish, the last row has no related entities, as its related entities were given to the previous row.

Comment by Popy [ 29/Oct/13 ]

Bug confirmed in a small Symfony app and Doctrine 2.3. I managed to reproduce the bug with 3 entities :

  • A (id autoincrement)
  • B (id autoincrement)
  • Root (composite id a,b which are ManyToOne relations to A and B entities)

Can provide the app to ease things.

Comment by Popy [ 29/Oct/13 ]

Possible workaround : declaring integer fields as ID (with the same field name as relation fields) makes the thing working again (at the price of thoose two useless properties and a prePersist method to fill them with related entity ids)

Comment by Benjamin Eberlei [ 14/Dec/13 ]

First step here: Try to reproduce this issue with the given entities above in a Testcase

Comment by Karol Horowski [ 14/Dec/13 ]

I created test for this issue, but I can't reproduce id. My pull request is here https://github.com/doctrine/doctrine2/pull/878

Comment by Popy [ 15/Dec/13 ]

You should maybe call $this->_em->clear() at the end of your setUp method.

I still have a Symfony Bundle reproducing the bug, how can i hand it to you ?

Comment by Benjamin Eberlei [ 15/Dec/13 ]

Popy you can create a branch of that symfony standard edition, and push it to a fork of symfony-standard on your Github account. Then you can comment a link to your branch on Github.

Comment by Karol Horowski [ 17/Dec/13 ]

After Popy's suggestion I added $this->_em->clear() and now I have failing test. My fault with this quick "everything is ok".

I tried to search what's happening in ObjectHydrator but something strange is going on in hydrateRowData method.

Comment by Popy [ 17/Dec/13 ]

Be carefull, headache come fast while reading this method

As far as I know, the problem could be solved if the hydrator started by hydrating the root entity first. Maybe.

Comment by Karol Horowski [ 19/Dec/13 ]

In select statement fields are in this order Root, B, A. Relations in my test are Root 1:1 A *:1 B.
Hydrator first gets Root data and next B. But here (line 407 in ObjectHydrator) it doesn't find A parent in resultPointers.

For now I don't have any idea how to add new logic for this.

Comment by Doctrine Bot [ 18/Apr/14 ]

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

Comment by Guilherme Blanco [ 18/Apr/14 ]

As of https://github.com/doctrine/doctrine2/commit/38b683838648b549aad0e38ce88c70b6393755b3 this issue is now fixed.





[DDC-3093] [GH-1013] Remove SimpleXmlElement hack Created: 18/Apr/14  Updated: 18/Apr/14  Resolved: 18/Apr/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 FabioBatSilva:

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

Message:

The functionality it self its already tested by : https://github.com/doctrine/doctrine2/blob/master/tests/Doctrine/Tests/ORM/Tools/Export/AbstractClassMetadataExporterTest.php#L155



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

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

Comment by Guilherme Blanco [ 18/Apr/14 ]

Fixed already.





[DDC-3069] [GH-1000] [DDC-3068] EntityManager::find accept array of object as id Created: 04/Apr/14  Updated: 18/Apr/14  Resolved: 18/Apr/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 giosh94mhz:

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

Message:

Pull Request for ticket http://www.doctrine-project.org/jira/browse/DDC-3068
Here follow the ticket description for you convenience.

According to the documentation, ``EntityManager::find`` should return one entity given it's primary key. When a primary key of an entity is composed of multiple associations, one (me ) would expect that the following works, but it doesn't:
```php
$entity = $_em->find('My\EntityClass', array(
'assoc1' => $instance1,
'assoc2' => $instance2
));
PHP Fatal error: Object of class My\EntityClass could not be converted to string
```
The only working way I've found is the following:
```php
$entity = $_em->find('My\EntityClass', array(
'assoc1' => $instance1->getId(),
'assoc2' => $instance2->getId()
));
```
I think that this second scenario is not correct, since expose implementation details.



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

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

Comment by Guilherme Blanco [ 18/Apr/14 ]

As of https://github.com/doctrine/doctrine2/commit/10a0daf6203b6d2ea0c92e30edb07ca7e83058b3 this issue was fixed.





[DDC-3068] EntityManager::find does not accept an array of object as a primary key Created: 03/Apr/14  Updated: 18/Apr/14  Resolved: 18/Apr/14

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

Type: Improvement Priority: Minor
Reporter: Giorgio Premi Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

According to the documentation, EntityManager::find should return one entity given it's primary key. When a primary key of an entity is composed of multiple associations, one (me ) would expect that the following works, but it doesn't:

$entity = $_em->find('My\EntityClass', array(
    'assoc1' => $instance1,
    'assoc2' => $instance2
));
PHP Fatal error:  Object of class My\EntityClass could not be converted to string

The only working way I've found is the following:

$entity = $_em->find('My\EntityClass', array(
    'assoc1' => $instance1->getId(),
    'assoc2' => $instance2->getId()
));

I think that this second scenario is not correct, since expose implementation details.

I've created a patch on my github fork, I'll create a pull request ASAP.



 Comments   
Comment by Guilherme Blanco [ 18/Apr/14 ]

As of https://github.com/doctrine/doctrine2/commit/10a0daf6203b6d2ea0c92e30edb07ca7e83058b3 issue was fixed.





[DDC-823] Errors in 2.0 Cookbook Documentation Created: 01/Oct/10  Updated: 18/Apr/14  Resolved: 18/Apr/14

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

Type: Task Priority: Trivial
Reporter: Ralfas Jegorovas Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

http://www.doctrine-project.org/projects/orm/2.0/docs/cookbook/getting-started-xml-edition/en#getting-started-xml-edition

Paragraph 1:
The benefit of Doctrine for the programmer is the possibility can to focus soley solely on the business and worry about persistence only as a secondary task. This doesn't mean persistence is not important to Doctrine 2, however it is our belief that there are considerable benefits for object-oriented programming, if persistence and entities are kept perfectly seperated separated.

Paragraph 2:
Entities are leightweight lightweight PHP Objects that don't need to extend any abstract base class or interface. An entity class must not be final or contain final methods. Additionally it must not implement __clone nor __wakeup or it should do so safely.

What would be the best way to note other errors?



 Comments   
Comment by Benjamin Eberlei [ 04/Oct/10 ]

The best way for us would be if you fork the docs on github, change the stuff and commit it. Then issue a pull request. It sounds complicated, but should be minimal overhead of ~5 minutesn on your end, but then we can merge it with a mouse-click, so we dont need to duplicate the whole correction effort on our end.

Comment by Joel Clermont [ 27/Jan/11 ]

I have fixed the typos from this ticket that were still present in the docs and issued a pull request on Github.

Comment by Michael Ridgway [ 11/Jul/11 ]

This issue should be closed: https://github.com/doctrine/orm-documentation/pull/17

Comment by Guilherme Blanco [ 18/Apr/14 ]

Issue got fixed somehow in the past





[DDC-3021] [GH-976] Add cache invalidation strategy to AbstractQuery Created: 11/Mar/14  Updated: 17/Apr/14  Resolved: 17/Apr/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: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

By adding the cached timestamps of the involved entity tables to the query hash, we will invalidate the cache when any of those tables have changed.



 Comments   
Comment by Doctrine Bot [ 23/Mar/14 ]

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

Comment by Fabio B. Silva [ 17/Apr/14 ]

Closed, see : https://github.com/doctrine/doctrine2/pull/976





[DDC-3074] [GH-1004] Removed all useless occurrence of require_once TestInit.php Created: 07/Apr/14  Updated: 17/Apr/14  Resolved: 17/Apr/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: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

As @Ocramius pointed out when discussing about PR #1000, the statement ``require_once [...]TestInit.php`` is no longer useful.

I've removed all occurrence from the test cases.



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

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

Comment by Fabio B. Silva [ 17/Apr/14 ]

Fixed by : https://github.com/doctrine/doctrine2/commit/73e5bbecbef311194085e30d8b7fd6516bc50425





[DDC-2975] [GH-951] More informational entity not found exception Created: 11/Feb/14  Updated: 17/Apr/14  Resolved: 17/Apr/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: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:



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

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

Comment by Fabio B. Silva [ 17/Apr/14 ]

Fixed by : https://github.com/doctrine/doctrine2/commit/6e9b15a48fa9db4db6ba3cbb8c4fa5d40306a07c





[DDC-3081] [GH-1009] HHVM compatibility Created: 10/Apr/14  Updated: 17/Apr/14  Resolved: 17/Apr/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: Benjamin Eberlei
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/1009

Message:

With this PR (based on DDC-3078, see #1008) we finally get 100% compatibility with HHVM as we described on http://www.doctrine-project.org/2013/12/23/our-hhvm-roadmap.html

This PR needs to be rebased on master once #1008 is merged.



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

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

Comment by Doctrine Bot [ 17/Apr/14 ]

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

Comment by Fabio B. Silva [ 17/Apr/14 ]

Fixed by : https://github.com/doctrine/doctrine2/commit/54d9f05e39bc6c0943a48dfb523675c931a1435b





[DDC-3080] [GH-1008] DDC-3078 SLC Cache interface ctor removal Created: 10/Apr/14  Updated: 17/Apr/14  Resolved: 17/Apr/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

Issue Links:
Dependency
is required for DDC-3078 Doctrine\ORM\Cache::__construct is in... Resolved

 Description   

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

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

Message:

See DDC-3078 ( http://www.doctrine-project.org/jira/browse/DDC-3078 ) - the cache interface should NOT cover a constructor.



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

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

Comment by Doctrine Bot [ 17/Apr/14 ]

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

Comment by Fabio B. Silva [ 17/Apr/14 ]

Fixed by https://github.com/doctrine/doctrine2/commit/6af3236ba6f285fe14763866b20ddc1085e6ea39





[DDC-3078] Doctrine\ORM\Cache::__construct is in an interface Created: 10/Apr/14  Updated: 17/Apr/14  Resolved: 17/Apr/14

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

Type: Bug Priority: Blocker
Reporter: Marco Pivetta Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: cache, config, second-level-cache

Issue Links:
Dependency
depends on DDC-3080 [GH-1008] DDC-3078 SLC Cache interfac... Resolved

 Description   

CTOR in the interface is a huge problem. This absolutely needs to be fixed before 2.5 is released, or we will have trouble in future.

I'm writing a PoC patch right now.



 Comments   
Comment by Fabio B. Silva [ 17/Apr/14 ]

Fixed by https://github.com/doctrine/doctrine2/commit/6af3236ba6f285fe14763866b20ddc1085e6ea39





[DDC-3092] [GH-1012] Ddc 3078 slc cache interface ctor removal Created: 17/Apr/14  Updated: 17/Apr/14  Resolved: 17/Apr/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 FabioBatSilva:

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

Message:



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

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

Comment by Guilherme Blanco [ 17/Apr/14 ]

Issue now merged! \o/





[DDC-2890] Paginator generates invalid sql for some dql with setUseOutputWalkers(false) and $fetchJoinCollection = true Created: 07/Jan/14  Updated: 17/Apr/14  Resolved: 17/Apr/14

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

Type: Bug Priority: Major
Reporter: Jiri Kavalik Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: paginator
Environment:

ubuntu 12.04, ZF2 2.2.5, mysql 5.5.34



 Description   

We use doctrine paginator in zf2 for list pagination.

We tried to disable UseOutputWalkers because of performance gain - for some entities expected table size is in millions and we are paginating simple lists with some inner joins - but with UseOutputWalkers(false) and fetchJoinCollection=true (default) we get exception for queries ordering by referenced entity id.

Examples:

  • OK - DQL:
    SELECT Transaction FROM Transaction\Entity\Transaction Transaction ORDER BY Transaction.balance asc
    

    SQL:

    SELECT t0_.id AS id0, t0_.value AS value1, t0_.balance AS balance2, t0_.created_on AS created_on3, t0_.type_id AS type_id4, t0_.canceled_id AS canceled_id5, t0_.canceling_id AS canceling_id6, t0_.wallet_id AS wallet_id7 FROM transaction t0_ ORDER BY t0_.balance ASC
    

    Paginator SQL:

    SELECT count(DISTINCT t0_.id) AS sclr0 FROM transaction t0_
    SELECT DISTINCT t0_.id AS id0, t0_.balance AS balance1 FROM transaction t0_ ORDER BY t0_.balance ASC LIMIT 10 OFFSET 0
    SELECT t0_.id AS id0, t0_.value AS value1, t0_.balance AS balance2, t0_.created_on AS created_on3, t0_.type_id AS type_id4, t0_.canceled_id AS canceled_id5, t0_.canceling_id AS canceling_id6, t0_.wallet_id AS wallet_id7 FROM transaction t0_ WHERE t0_.id IN (?) ORDER BY t0_.balance ASC
    
  • Exception - Error producing an iterator - DQL:
    SELECT Transaction FROM Transaction\Entity\Transaction Transaction ORDER BY Transaction.type asc
    

    SQL:

    SELECT t0_.id AS id0, t0_.value AS value1, t0_.balance AS balance2, t0_.created_on AS created_on3, t0_.type_id AS type_id4, t0_.canceled_id AS canceled_id5, t0_.canceling_id AS canceling_id6, t0_.wallet_id AS wallet_id7 FROM transaction t0_ ORDER BY t0_.type_id ASC
    

    Paginator SQL with error:

    SELECT count(DISTINCT t0_.id) AS sclr0 FROM transaction t0_
    SELECT DISTINCT t0_.id AS id0, t0_. AS _1 FROM transaction t0_ ORDER BY t0_.type_id ASC LIMIT 10 OFFSET 0
    SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'AS _1 FROM transaction t0_ ORDER BY t0_.type_id ASC LIMIT 10 OFFSET 0' at line 1
    

    Same query with $fetchJoinCollection = false - OK - paginator SQL:

    SELECT count(DISTINCT t0_.id) AS sclr0 FROM transaction t0_
    SELECT t0_.id AS id0, t0_.value AS value1, t0_.balance AS balance2, t0_.created_on AS created_on3, t0_.type_id AS type_id4, t0_.canceled_id AS canceled_id5, t0_.canceling_id AS canceling_id6, t0_.wallet_id AS wallet_id7 FROM transaction t0_ ORDER BY t0_.type_id ASC LIMIT 10 OFFSET 0
    
  • using setUseOutputWalkers(true) generates most robust queries but count is really slow for 200k+ tables


 Comments   
Comment by Guilherme Blanco [ 17/Apr/14 ]

As of https://github.com/doctrine/doctrine2/commit/be1cc14a9c8641774d614f788103cef4a5373bb1 issue is now fixed.





[DDC-2935] [GH-919] tests for DDC-2890 Created: 24/Jan/14  Updated: 17/Apr/14  Resolved: 17/Apr/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 jkavalik:

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

Message:

First error is notice level so I added second test with notices ignored to show actual malformed SQL which will be executed on server ignoring notices.



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

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

Comment by Guilherme Blanco [ 17/Apr/14 ]

As of https://github.com/doctrine/doctrine2/commit/be1cc14a9c8641774d614f788103cef4a5373bb1 this issue is fixed.





[DDC-3090] Cannot use single table inheritance in entities deriving from classes using class table inheritance Created: 17/Apr/14  Updated: 17/Apr/14  Resolved: 17/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: Duplicate Votes: 0
Labels: None


 Description   

I have the following classes:

/**
 * @ORM\Table(name="diet_entries")
 * @ORM\Entity
 * @ORM\InheritanceType("JOINED")
 * @ORM\DiscriminatorColumn(name="discriminator", type="string")
 * @ORM\DiscriminatorMap({"recipe" = "Recipe", "ingredient" = "Ingredient" })
 */
abstract class DietEntry {}
/**
 * @ORM\Table(name="recipes")
 */
class Recipe extends DietEntry {}
/**
 * @ORM\Table(name="ingredients")
 * @ORM\InheritanceType("SINGLE_TABLE")
 * @ORM\DiscriminatorColumn(name="discriminator", type="string")
 * @ORM\DiscriminatorMap({ "ingredient" = "Ingredient", "supplement" = "Supplement" })
 */
class Ingredient extends DietEntry {}
/**
 * @ORM\Entity
 */
class Supplement extends Ingredient {}

and these tables: diet_entries, recipes, ingredients.

The idea was not to create the table for supplements since a supplement needs no extra attributes other then those derived from an ingredient, otherwise I would have added Supplement to discriminator map of DietEntry and provided a table for it which is mandatory in JOINED inheritance.
But the problem now is that when a query is build it looks like this:

An exception occurred while executing

SELECT i0_.id AS id0, i0_.name AS name1, i0_.energy AS energy2, d1_.name AS name3, d2_.name AS name4 FROM ingredients i0_ INNER JOIN diet_databases d1_ ON d3_.database_id = d1_.id LEFT JOIN dictionary d2_ ON i0_.group_id = d2_.id WHERE i0_.discriminator IN ('ingredient', 'supplement')

SQLSTATE[42S22]: Column not found: 1054 Unknown column 'i0_.name' in 'field list

The query for Ingredient is missing a join with the diet_entries table from which the ingredient derives. ORM only sees entities/tables down the inheritance path from the Ingredient class but not up from Ingredient to DietEntry



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

Duplicate of DDC-138





[DDC-3089] Doctrine1 to Doctrine2 Oracle type float Created: 17/Apr/14  Updated: 17/Apr/14  Resolved: 17/Apr/14

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

Type: Bug Priority: Major
Reporter: Antoine Dr Assignee: Steve Müller
Resolution: Invalid Votes: 0
Labels: None
Environment:

Linux - Oracle 10g



 Description   

I have a big problem migrating an application from Doctrine1 to Doctrine2.

The variable ROUNDNUMBER was set with Doctrine1 in the Oracle 10G database with the following schema :
ApprenticeYeartype:
columns:
id:

{type: integer, notnull: true, primary: true, autoincrement: true}

name:

{type: string(255), notnull: true}

roundNumber:

{type: float, notnull: true}

The values stored in this variable are: 0.1 or 0.5 or 1.0

In Oracle, the data type was set as "NUMBER" with no precision or scale set. I found this "If
a precision is not specified, the column stores values as given. If no scale is
specified, the scale is zero. ".
So there should be no scale which is weird because it worked with the values 0.1, 0.5...
It worked nicely on Symfony1 and Doctrine1, but for the migration to Symfony2 and Doctrine2, I used the command to import the schema from the database "php app/console doctrine:mapping:convert"

The created schema's ROUNDNUMBER variable was set with the Doctrine2 type "Integer". So now I get the variable as an int and not float and so I can't use it.

I tried changing the type to decimal, float etc...
/**

  • @var integer
    *
  • @ORM\Column(name="ROUNDNUMBER", type="integer", nullable=false)
    */
    private $roundnumber;

But I keep getting this error :
[Doctrine\DBAL\DBALException]
An exception occurred while executing 'ALTER TABLE APPRENTICE_YEARTYPE MODI
FY (ROUNDNUMBER DOUBLE PRECISION DEFAULT NULL)':

ORA-01440: column to be modified must be empty to decrease precision or sca
le

If anyone know a solution, please help me !



 Comments   
Comment by Steve Müller [ 17/Apr/14 ]

Looks like you create the column ROUNDNUMBER with an integer type mapping. Use "float" or "decimal" instead. When updating the schema please ensure that your ROUNDNUMBER column contains no data or at least all values in the column have to be NULL. See http://www.techonthenet.com/oracle/errors/ora01440.php
Please note that Doctrine's "float" maps to "DOUBLE PRECISION" and "decimal" to "NUMERIC(p,s)" on Oracle. See the DBAL types documentation for further information: http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/types.html#mapping-matrix

If you need further help, just drop me a line.

Comment by Steve Müller [ 17/Apr/14 ]

Not a Doctrine bug.





[DDC-2827] [GH-864] Updated parser to support aggegrate functions in null comparisons Created: 29/Nov/13  Updated: 17/Apr/14  Resolved: 17/Apr/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 curry684:

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

Message:

Parser didn't support syntax like "SELECT i FROM entity i JOIN i.second s GROUP BY i HAVING max(s.something) IS NULL" which should be perfectly valid. Changed isAggregateFunction to support parameterless call which makes it consistent with isFunction.



 Comments   
Comment by Guilherme Blanco [ 17/Apr/14 ]

As of https://github.com/doctrine/doctrine2/commit/841bdd5ca52d2849b8091c56f99e201d169e1639 this issue is fixed

Comment by Doctrine Bot [ 17/Apr/14 ]

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





[DDC-3009] [GH-968] Test: Add failing test Created: 04/Mar/14  Updated: 17/Apr/14  Resolved: 17/Apr/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: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

It says in http://www.doctrine-project.org/jira/browse/DBAL-446 that this issue has been fixed, but apparently, it hasn't.



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

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

Comment by Guilherme Blanco [ 17/Apr/14 ]

This issue is DBAL related, not ORM.





[DDC-2934] [GH-918] Fix use of function in OrderBy Created: 24/Jan/14  Updated: 17/Apr/14  Resolved: 17/Apr/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 iamluc:

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

Message:

This commit adds support for functions (like CONCAT()) in OrderBy.



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

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

Comment by Guilherme Blanco [ 17/Apr/14 ]

As of https://github.com/doctrine/doctrine2/commit/ceada41b83c9b71d4831d9e50d4c43a75b1ee531 this issue is fixed





[DDC-2249] Default value sequence Created: 19/Jan/13  Updated: 16/Apr/14  Resolved: 16/Apr/14

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

Type: Task Priority: Major
Reporter: Maria Assignee: Guilherme Blanco
Resolution: Can't Fix Votes: 1
Labels: None
Environment:

Symfony 2, linux



 Description   

I want to have a column on a table that by default it takes the value from a sequence.

I've tried to do something like this:
/**

  • @ORM\Column(type="integer", unique="true")
  • @ORM\GeneratedValue(strategy="SEQUENCE")
  • @ORM\SequenceGenerator(sequenceName="seq_categorias", initialValue=1, allocationSize=100)
    */
    protected $id_categoria;

But this doesn't work, it creates de sequence but not the link between the table column and the sequence. Is there any possibility to do something like this? Or any autoincrement default value instead?

Thanks!



 Comments   
Comment by Guilherme Blanco [ 16/Apr/14 ]

We cannot fix this as sequences only work internally in Doctrine for ID fields.





Generated at Wed Apr 23 16:45:27 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.