[DDC-3642] [GH-1351] Failing test cases regarding to #1325 #1337 Created: 27/Mar/15  Updated: 30/Mar/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 vaheshadunts:

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

Message:



 Comments   
Comment by Doctrine Bot [ 30/Mar/15 ]

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





[DDC-3298] Persisting one to one not nullable relational entity Created: 08/Sep/14  Updated: 30/Mar/15

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: Major
Reporter: Bil Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: onetoone, persist
Environment:

Use with Symfony 2.5



 Description   

When having a not nullable onetoone unidirectional relation and trying to persist the parent entityn sql throws this exception : SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'deliveryMode_id' cannot be null.

Scheme is Shop has a deliveryMode :

class Shop{

...

/**

  • @ORM\OneToOne(targetEntity="acme\Bundle\DeliveryBundle\Entity\DeliveryMode", cascade= {"all"}

    , orphanRemoval=true)

  • @ORM\JoinColumn(nullable=false)
  • @Assert\Valid
    */
    private $deliveryMode;
    ...
    }

When I do a :

$shop=new Shop();
$deliveryMode=new DeliveryMode();
$shop->setDeliveryMode($deliveryMode);
...
$entityManager->persist($shop);
$entityManager->flush();

Then, above exception is thrown

BUT: When I put in on a doctrine transaction, it works perfectly, and it also works when I remove the "not nullable" constraint, deliveryMode is perfectly persisted.

It seems to me there a bug with the order of executing the inserts, the deliveryMode should be inserted, then the shop, I think that is not the case



 Comments   
Comment by webDEVILopers [ 27/Mar/15 ]

Same problem here with the following annotations:

class Bundle
{
    /**
     * @ORM\OneToOne(targetEntity="ParttypeStateNokBlocked", mappedBy="bundle", cascade={"persist"})
     */
    public $parttypeStateNokBlocked;

    /**
     * @param field_type $parttypeStateNokBlocked
     */
    public function setParttypeStateNokBlocked($parttypeStateNokBlocked) {
        $this->parttypeStateNokBlocked = $parttypeStateNokBlocked;
    }
}

class ParttypeStateNokBlocked
{
    /**
     * @ORM\OneToOne(targetEntity="Bundle", inversedBy="parttypeStateNokBlocked")
     * @ORM\JoinColumn(name="bundle_id", referencedColumnName="id")
     */
    public $bundle;

    public function setBundle(\Plusquam\Bundle\ContractBundle\Entity\Bundle $bundle = null)
    {echo "setting bundle";exit;
        $this->bundle = $bundle;

        return $this;
    }
}

Error: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'bundle_id' cannot be null

The setBundle method is not called. I tested the SQL Query for inserting the bundle and it works fine.

Comment by Patrick Laxton [ 30/Mar/15 ]

I guess I'm stupid to ask, but isn't your foreign key not nullable, which you cannot set because you don't have any key right now?
Could you mysqldump your database structure? (Or pgdump, or whatever DBS you're using)

Comment by webDEVILopers [ 30/Mar/15 ]

Here is my setup causing the error in 2.4.7 and 2.5.0-DEV:
https://gist.github.com/webdevilopers/a8b39361d65b7d9d5ca4





[DDC-3639] [GH-1349] Fix #1347 Created: 26/Mar/15  Updated: 27/Mar/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 zeroedin-bill:

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

Message:

This PR fixes #1347.



 Comments   
Comment by Doctrine Bot [ 27/Mar/15 ]

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





[DDC-3645] [GH-1353] Paginator fixes take3 Created: 27/Mar/15  Updated: 27/Mar/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 zeroedin-bill:

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

Message:

This PR fixes issues reported in #1347 and #1351.

  • Ordering a query by a column from an association which uses SINGLE_TABLE inheritance no longer throws an error.
  • Limiting a query which is ordered by fields from a joined -To-Many association now works as expected.

This patch converts LimitSubqueryOutputWalker to use the ROW_NUMBER window function for queries on platforms that support it. Other platforms use a modified version of the previous method. The modification is to not select the ORDER BY columns in the wrapping query. The reason those columns were selected like that in the first place is that ORDER BY on columns not in the select list is unsupported on many platforms. MySQL and SQLite are fine with it, and don't support ROW_NUMBER.

The ROW_NUMBER solution is actually much simpler.

LimitSubqueryOutputWalker SQL generation tests for PG and Oracle have been changed.

*There are 2 failing expectedException tests right now.* The LimitSubqueryWalker needs to be modified to throw an exception when it detects a query that does the following things together:

  • Joins a -To-Many association
  • Orders by a column from the associated entity
  • Limits the result

As with the previous patch, this depends on changes to SQLServerPlatform2008 that have not yet been merged. SQLServerPlatform2008 in DBAL/master currently mangles the generated queries when trying to apply LIMIT/OFFSET.






[DDC-3644] One To Many Relationships do not properly support Orphan Removal Created: 27/Mar/15  Updated: 27/Mar/15

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

Type: New Feature Priority: Major
Reporter: Jarrett Croll Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

After speaking to @guilhermeblanco you assume the following method is unreachable when in fact it is not:

https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Persisters/Collection/OneToManyPersister.php#L39

If an entity currently has a persistent collection in a 1-m relationship and that persistent collection is replaced with a new collection the entities not contained in that new collection should be scheduled for deletion but they are not.






[DDC-3643] [GH-1352] fix EntityGenerator RegenerateEntityIfExists Created: 27/Mar/15  Updated: 27/Mar/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 Fedik:

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

Message:

Fix for Class generator,
when class already exists and `$generator->setRegenerateEntityIfExists(true);`






[DDC-3641] [GH-1350] Assigned default value to array Created: 26/Mar/15  Updated: 27/Mar/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 mmoreram:

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

Message:

  • For strict configurations of PHP, we were accessing to a non-array element


 Comments   
Comment by Doctrine Bot [ 27/Mar/15 ]

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





[DDC-3640] Force version increment via mapped property Created: 26/Mar/15  Updated: 27/Mar/15

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

Type: Improvement Priority: Minor
Reporter: Darien Hager Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mapping, orm

Issue Links:
Reference
relates to DDC-2864 New type of lock: OPTIMISTIC_FORCE_IN... Open
relates to DDC-1507 State change detection for version in... Open

 Description   

Existing feature:

It is currently possible to use optimist-locking against an entity through a version code or timestamp, which becomes incremented when the entity changes. Unfortunately, there is no way for an entity to signal that its version should be incremented when no (direct) changes have occurred.

Problem:

Sometimes you want to control or gate wide-spread or indirect changes via a particular entity, such as the root of a tree of other mutable entities. This is particularly common in Domain Driven Design.

Proposal:

Create a new configuration option for a PHP property that identifies it as a "version incrementor flag". It is only legal on entities that also have a version-field. This field will always be set to false when an entity is hydrated.

When entities are being checked for changes and flushed, this flag will (if it evaluates to true) force the version-field to update. Note that if the entity has "real changes", it will be saved and the version-field will update regardless. At the end of this process, the field is reset back to false.

This allows the user to write code such as:

Entity example

    /** @Version @Column(type="integer") */
    private $version;

    /** @VersionIncrementFlag */
    $changed = false;

    /** @OneToMany(targetEntity="Child", mappedBy="parent") */
    private $children;    

    public function zeroChildren(){
        foreach($this->children as $child){
            $child->setValue(0);
        }
        $this->changed = true; // Where $changed is the incrementor flag
    }    

Issues with other approaches:

The current workaround of a "junk column" is... suboptimal. It requires a junk data column in the database, and its presence does not easily capture the intent of the user. It also leads to extra database operations, since the junk data has to be saved no matter what.

Adding a specialized method to EntityManager, like with $em->touchVersion($entity); is also problematic, since it means you cannot conveniently trigger the new behavior when deep inside the object-graph.



 Comments   
Comment by Darien Hager [ 26/Mar/15 ]

I'm willing to try implementing this if folks feel it could get included.

Comment by Darien Hager [ 27/Mar/15 ]

I have a proof-of-concept working based off of 2.4.7, you can see a diff here:

https://github.com/doctrine/doctrine2/compare/2.4...DHager:force_version_increment

As of this writing, it can only be configured via XML. Here's a minimal example, for a table that has only two columns, an ID and a version.

<?xml version="1.0" encoding="utf-8"?>
<doctrine-mapping xmlns="http://doctrine-project.org/schemas/orm/doctrine-mapping" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://doctrine-project.org/schemas/orm/doctrine-mapping http://doctrine-project.org/schemas/orm/doctrine-mapping.xsd">
  <entity name="Example\Foo" table="example">

    <special-properties>
        <special-property name="vflag" type="versionIncFlag"/>
    </special-properties>

    <id name="id" type="integer" column="id"/>

    <field name="version" type="integer" column="version" version="true" nullable="false"/>

  </entity>
</doctrine-mapping>

The new <special-properties> section is intended to refer to PHP object-properties which are not mapped fields, but which still have significance to Doctrine. In PHP-land, it's as simple as:

        $targetId = 1;
        /** @var $em EntityManager */                
        /** @var $foo Foo */
        $foo = $em->find("Example\Foo",$targetId); // Hardcoded ID
        $foo->vflag = true; // TODO make private, use setter
        $em->persist($foo);
        $em->flush();

Afterwards, the "version" column in the DB for the row should be incremented, even though no "real" fields were changed:

UPDATE example SET version = version + 1 WHERE id = ? AND version = ?




[DDC-1507] State change detection for version incrementation (for optimistic locking) in combination with orphanRemoval Created: 23/Nov/11  Updated: 26/Mar/15

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

Type: Improvement Priority: Major
Reporter: Georg Wächter Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: unitofwork, versioned

Issue Links:
Reference
is referenced by DDC-2864 New type of lock: OPTIMISTIC_FORCE_IN... Open
is referenced by DDC-3640 Force version increment via mapped pr... Open

 Description   

As i understand the documentation correctly, orphanRemoval associations have the meaning of a "part of" relationship. In the example (http://www.doctrine-project.org/docs/orm/2.0/en/reference/working-with-associations.html#orphan-removal) the adresses are part of the contact.

In my opinion we should reason that the state of the adress consists of the states of all nested contacts. As a consequence we should flag the contact as "dirty" when the adresses change.

This is relevant for optimistic locking scenarios or event handlers. In my application i tried to use optimistic locking for "contacts", which does not work if i don't change anything in the contact but only in the nested addresses.



 Comments   
Comment by Benjamin Eberlei [ 27/Nov/11 ]

This is still only an approvement, you can workaround this and handle is in your domain code.

Comment by Georg Wächter [ 27/Nov/11 ]

Not in all cases. The first problem is that my domain code can't modify the version property, doctrine seems to block any manipulations to it. So i'm not able to increment the variable myself.

The only solution is to implement optimistic locking on my own or to add a dummy persistent boolean field that gets inversed by my domain code .. which would trigger the doctrine implementation for the optimistic locking.

I think it's clear that the second option shouldn't be a choice. If doctrine doesn't handle the overall case exactly it should allow me to increment the version number myself.

Comment by Darien Hager [ 26/Mar/15 ]

Bump: I'm having a similar issue. Essentially I want to force the entity's version to be updated, even if there aren't any other "real" changes to go with it.

One idea for a workaround: Since version fields can only be integers or timestamps, define a "clearly wrong" magic value like "FORCE_INCREMENT". This would allow objects to signal without needing a reference to the EntityManager.

Would folks be open to a pull-request over this?





[DDC-2864] New type of lock: OPTIMISTIC_FORCE_INCREMENT Created: 18/Dec/13  Updated: 26/Mar/15

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

Type: New Feature Priority: Minor
Reporter: Szurovecz János Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Reference
relates to DDC-1507 State change detection for version in... Open
is referenced by DDC-3640 Force version increment via mapped pr... Open

 Description   

When optimistick locking is being used, the version field is incremented after the update only if the entity itself has been modified. In Domain-Driven Design another kind of locking mechanism is essential: OPTIMISTIC_FORCE_INCREMENT. It means that the version field is always incremented after an update. The lack of this feaure can be realized when only the aggregate root has a version field and some other parts of the aggregate is being modified.

PESSIMISTIC_FORCE_INCREMENT is also an interesting lock type which might be useful as well.



 Comments   
Comment by Darien Hager [ 26/Mar/15 ]

I'm having this same issue, although I'm not certain a new locking-type is the answer.

Basically, I want to ensure that an entity gets updated with a new version integer/timestamp, whether or not anything "real" has been changed on it. It seems the only workaround is to designate a "junk" property and change that, which isn't particularly elegant.

The problem with a locking-type is that individual entities can't signal that they need incrementing without having a reference to the entity-manager so that they can $em->lock() .





[DDC-3625] [GH-1339] [DDC-2224] Honor convertToDatabaseValueSQL() in DQL query parameters Created: 18/Mar/15  Updated: 25/Mar/15  Resolved: 25/Mar/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: DQL
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: cache, dql, parameter

Issue Links:
Dependency
is required for DDC-2224 convertToDatabaseValueSQL() is not ho... Resolved

 Description   

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

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

Message:

This is a follow-up to the abandoned #574 by @mnapoli, that fixes DDC-2224(http://www.doctrine-project.org/jira/browse/DDC-2224).

At the time, @beberlei closed the PR for the following reason, deemed unfixable:

> Passing a type into the parameters is not recognized during caching, that means, using a DQL cache, the same DQL statement with (different parameter types) will lead to the same SQL being generated, depending on if the first or the second set parameter query is executed first.

This PR re-integrates the original fix, and offers a solution to the above issue: take the parameter types into account when checking the local `ParserResult` and the query cache.

In addition to the test for the DDC-2224 issue, I added a test to ensure that changing a parameter type invalidates the cache.



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

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

Comment by Doctrine Bot [ 25/Mar/15 ]

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

Comment by Doctrine Bot [ 25/Mar/15 ]

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





[DDC-2224] convertToDatabaseValueSQL() is not honored for DQL query parameters Created: 05/Jan/13  Updated: 25/Mar/15  Resolved: 04/Apr/13

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

Type: Bug Priority: Critical
Reporter: Benjamin Morel Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 1
Labels: None

Attachments: File DDC2224Test.php    
Issue Links:
Dependency
depends on DDC-3625 [GH-1339] [DDC-2224] Honor convertToD... Resolved
Duplicate
duplicates DDC-2240 Inconsistent querying for parameter t... Resolved

 Description   

Following discussion on Google Groups:
https://groups.google.com/d/msg/doctrine-dev/-/gG-VGiAGQiMJ

When using a mapping type which declares convertToDatabaseValueSQL(), this method is not invoked when passing a value as parameter to a DQL query.

For example, if I declare a mapping type MyType:

class MyType extends \Doctrine\DBAL\Types\Type
{
    public function canRequireSQLConversion()
    {
        return true;
    }

    public function convertToDatabaseValueSQL($sqlExpr, AbstractPlatform $platform)
    {
        return sprintf('FUNCTION(%s)', $sqlExpr);
    }

    // ...
}

And pass a parameter with this type to a DQL query:

$query = $em->createQuery('SELECT e FROM Entity e WHERE e.field = :field');
$query->setParameter('field', $value, 'MyType');

I would expect the following SQL to be generated:

SELECT ... WHERE ... = FUNCTION(?)

But the current SQL generated is the following:

SELECT ... WHERE ... = ?


 Comments   
Comment by Matthieu Napoli [ 08/Feb/13 ]

Fix proposal: https://github.com/doctrine/doctrine2/pull/574

Comment by Matthieu Napoli [ 08/Feb/13 ]

It turns out convertToDatabaseValue() is not called as well.

For example:

class MyType extends \Doctrine\DBAL\Types\Type
{
    public function convertToDatabaseValue($value, AbstractPlatform $platform)
    {
        return serialize($value);
    }

    // ...
}

The SQL generated should not change, but the parameter should go through "convertToDatabaseValue", which is not the case.

Comment by Benjamin Morel [ 08/Feb/13 ]

Have you passed the type as the third parameter to setParameter() ?
Because this works fine for me!

Comment by Matthieu Napoli [ 08/Feb/13 ]

You are right!

But shouldn't the Type mapping be taken into account anyway? I makes sense to me at least (a column has a type, when I specify a parameter for this column, it is for this type), but maybe that was just designed that way?

Comment by Benjamin Morel [ 08/Feb/13 ]

That would make sense, but I think that because of the flexibility of DQL, it's not always obvious what type you want to use.
Say you have some complex expression like:

WHERE entity.field = SomeDQLFunction(:value, entity.otherField)

Then we can't be sure what mapping type to use here (unless we can infer it from SomeDQLFunction, but this is yet another story).
Though I do agree that would be great to have the type inferred automatically when you do a simple:

WHERE entity.field = :value

Here, there's no ambiguity, and if entity.field has a custom mapping type, then I can't see a reason why it shouldn't be applied to the parameter by default.

Comment by Matthieu Napoli [ 08/Feb/13 ]

I made a failing test case, I'll see if I can work on that.

I will open a separate ticket for this.

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





[DDC-3621] Support embeddables in partial object query Created: 17/Mar/15  Updated: 25/Mar/15  Resolved: 23/Mar/15

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

Type: Improvement Priority: Minor
Reporter: Karl Rixon Assignee: Guilherme Blanco
Resolution: Duplicate Votes: 0
Labels: None

Issue Links:
Dependency
depends on DDC-3630 [GH-1343] Support embeddables in part... Resolved

 Description   

Hi,

Currently it's not possible to combine embeddables and partial objects - for example:

SELECT PARTIAL u.{id, name.first, name.last} FROM User

This results in an exception from the parser.

Is this just as simple as making the following change to Parser::PartialObjectExpression() line 1782?

// before
$partialFieldSet[] = $this->lexer->token['value'];

// after
$field = $this->lexer->token['value'];

while ($this->lexer->isNextToken(Lexer::T_DOT)) {
    $this->match(Lexer::T_DOT);
    $this->match(Lexer::T_IDENTIFIER);
    $field .= '.'.$this->lexer->token['value'];
}

$partialFieldSet[] = $field;


 Comments   
Comment by Karl Rixon [ 23/Mar/15 ]

doctrinebot automatically opened DDC-3621 when I issued a PR, so closing this issue as a duplicate.

Comment by Doctrine Bot [ 23/Mar/15 ]

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

Comment by Doctrine Bot [ 23/Mar/15 ]

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

Comment by Doctrine Bot [ 23/Mar/15 ]

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

Comment by Doctrine Bot [ 23/Mar/15 ]

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





[DDC-3630] [GH-1343] Support embeddables in partial object query expression [DDC-3621] Created: 20/Mar/15  Updated: 25/Mar/15  Resolved: 23/Mar/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: DQL
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: dql, embeddables, hydration, partial

Issue Links:
Dependency
is required for DDC-3621 Support embeddables in partial object... Resolved

 Description   

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

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

Message:

I don't see any existing tests covering this class, but all existing tests pass with this change.



 Comments   
Comment by Doctrine Bot [ 22/Mar/15 ]

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

Comment by Doctrine Bot [ 23/Mar/15 ]

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

Comment by Doctrine Bot [ 23/Mar/15 ]

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

Comment by Doctrine Bot [ 23/Mar/15 ]

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

Comment by Doctrine Bot [ 23/Mar/15 ]

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





[DDC-3062] [GH-997] [FIX] Allow to use ManyToMany with all operators Created: 31/Mar/14  Updated: 25/Mar/15  Resolved: 25/Mar/15

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

Type: Bug Priority: Critical
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Incomplete Votes: 0
Labels: collection, criteria, many-to-many, persister


 Description   

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

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

Message:

Hi,

ping @guillhermoblanco : I think this may be blocking for 2.5

I introduced not so long ago support for ManyToMany for Criteria. However, I realized my implementation was really incomplete, because I hard-coded the "=" operator (https://github.com/doctrine/doctrine2/pull/885/files#diff-982b7374bbe9d5f4b6b71f4869a446eaR575). This means that it fails in a lot of cases when you use something different than "eq" for Criteria.

This PR fixes that, however it's a bit hacky. The SqlExpressionVisitor was made by type hinting for a BasicEntityPersister, preventing us from using us for a collection persister. Therefore I added a new interface to keep BC.

There is also a lot of code duplication (the whole "getSelectConditionSQL" was copied from the BasicEntityPersister), but without trait or BC, I have no idea about how to solve it.

All tests pass, test were added for other operators.



 Comments   
Comment by Doctrine Bot [ 13/Jan/15 ]

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

Comment by Doctrine Bot [ 13/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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





[DDC-3184] Invalid hydration of entities using ManyToOne relation via queryBuilder Created: 23/Jun/14  Updated: 25/Mar/15

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4, 2.4.1, 2.4.2, 2.4.3
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Dmitry Korotovsky Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: None

Attachments: File DDC3184Test.php    

 Comments   
Comment by Dmitry Korotovsky [ 23/Jun/14 ]

In master branch all works perfect

Comment by Dmitry Korotovsky [ 23/Jun/14 ]

Marco Pivetta, fix in 2.5 branch will be ported to 2.4 stable version?

Comment by Marco Pivetta [ 23/Jun/14 ]

Dmitry Korotovsky first we'll need to check what commit fixed the issue. Could you git bisect with your test?

Comment by Dmitry Korotovsky [ 23/Jun/14 ]

Yes, i found it: https://github.com/doctrine/doctrine2/commit/38b683838648b549aad0e38ce88c70b6393755b3

Comment by Marco Pivetta [ 23/Jun/14 ]

Assigning to Guilherme Blanco, since he is the author of the fix.





[DDC-3515] [GH-1263] #1223 DDC-3453 - make `EntityManager` constructor `public` Created: 18/Jan/15  Updated: 25/Mar/15

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: constructor, entitymanager, setup

Issue Links:
Reference
is referenced by DDC-3453 [GH-1223] Refactored construction of ... Resolved

 Description   

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

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

Message:



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

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

Comment by Doctrine Bot [ 18/Jan/15 ]

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

Comment by Doctrine Bot [ 18/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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





[DDC-3534] [GH-1280] [DDC-3346] #1277 find one with eager loads is failing Created: 23/Jan/15  Updated: 25/Mar/15  Resolved: 25/Mar/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: collection, eager, fetch, hydrator, lazy-loading, many-to-many, onetomany, persister

Issue Links:
Dependency
is required for DDC-3346 findOneBy returns an object with part... Resolved
is required for DDC-3531 [GH-1277] [DDC-3346] Failing test for... Resolved

 Description   

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

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

Message:

Ping @scaytrase

Note that this is a first revision and needs refactoring, so please consider helping out with that if you can.

Ping @guilhermeblanco: please check the `CachedPersisterContext` stuff: it's dirty as heck, but that's because the persister internal generated SQL caching is inconsistent as heck too.

Resolution path for 2.4.x will be to throw an exception if there is an offset or a limit.



 Comments   
Comment by Doctrine Bot [ 23/Jan/15 ]

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

Comment by Doctrine Bot [ 23/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 25/Jan/15 ]

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





[DDC-1283] Possible issue with PersistentCollection#getDelete/InsertDiff() Created: 21/Jul/11  Updated: 25/Mar/15

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

Type: Improvement Priority: Minor
Reporter: Glen Ainscow Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Using the following code, when you go from (1, 2) to (1), (2) is deleted as expected. However, if you go from (1, 2) to (2), (1) and (2) are deleted and (2) is then inserted. Is this the desired behaviour? (i.e. 2 extra queries)

$bracket->getTournamentLocations()->takeSnapshot();

$col = $bracket->getTournamentLocations()->unwrap();

$col->clear();

foreach ($form->getValue('tournamentLocations') as $id) {
    $col->add($em->getReference('Tournaments_Model_TournamentLocation', $id));
}

$bracket->getTournamentLocations()->setDirty(true);


 Comments   
Comment by Benjamin Eberlei [ 26/Jul/11 ]

First, you are using internal API therefore you are on your own anyways.

This is marked as improvment now, the functionality works, it may just be inefficient.

Comment by Guilherme Blanco [ 09/Dec/11 ]

Hi,

I'm marking issue as invalid because you're conceptually wrong.
What you're trying to do is telling that a collection of new entities is holded by a collection of Persistent entities.
The reference internally of PersistentCollection to ArrayCollection means a lot here.

Correct code would be you to regenerate the collection (a new ArrayCollection) and just assign it to setTournamentLocations($newCollection);

Does this explanation is enough for you?

Cheers,

Comment by Glen Ainscow [ 23/Dec/11 ]

Hi Guilherme,

If I do this:

$locations = new ArrayCollection();

foreach ($form->getValue('tournamentLocations') as $id) {
    $locations->add($em->getReference('Tournaments_Model_TournamentLocation', $id));
}

$bracket->setTournamentLocations($locations);

... then all the records are deleted, before adding the new records. This is inefficient and causes extra, unnecessary write operations.

Can't Doctrine perform diffs when persisting the collection, so that only the necessary deletes and inserts are executed?

Comment by Guilherme Blanco [ 13/Jan/12 ]

We could add it, but I don't think it worth the effort.
Main problem with this one is that we use C-level binary comparison to get the diff. That's what you entities/hash pointers are different.
We would have to write our own diff-comparator for both collections, which would probably slowdown the entire Doctrine.

I'd rather consider that it's not possible to be done at the moment, but I need much more investigation for that. This will be something that I'll probably only do when I look at this issue again with a lot of time (which is really hard to happen).

If you have some spare time, feel free to make some attempts.
Just don't forget to enable performance tests in Doctrine Unit Test suite.





[DDC-3638] [GH-1348] Doctrine mapping:import command Created: 25/Mar/15  Updated: 25/Mar/15  Resolved: 25/Mar/15

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

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


 Description   

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

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

Message:

Why I cannot find this command:

`` php app/console doctrine:mapping:import --force AcmeBlogBundle xml ``
[here](http://doctrine-orm.readthedocs.org/en/latest/reference/tools.html?highlight=command) I mean mapping:import command.

I already replace this command:

`` php app/console doctrine:mapping:convert xml ./src/Acme/BlogBundle/Resources/config/doctrine/metadata/orm --from-database --force ``
with

`` sudo vendor/bin/doctrine orm:convert-mapping xml '/var/www/html/laravel/package' --from-database --force ``
and worked well.



 Comments   
Comment by Doctrine Bot [ 25/Mar/15 ]

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

Comment by Doctrine Bot [ 25/Mar/15 ]

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





[DDC-3637] [GH-1347] problem with LimitSubqueryOutputWalker when use InheritanceType Created: 25/Mar/15  Updated: 25/Mar/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 alexander-orabey:

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

Message:

When we use InheritanceType ("SINGLE_TABLE") catch exception that field in joined class does not exist in base class.



 Comments   
Comment by Doctrine Bot [ 25/Mar/15 ]

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





[DDC-3636] cannot extend ClassMetadataFactory Created: 25/Mar/15  Updated: 25/Mar/15  Resolved: 25/Mar/15

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

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


 Description   

We cannot extend the `ClassMetadataFactory` because most of the members are private.
Use case:
I have to overwrite only the `getShortName` and because most are private i need to copy/paste all the other private methods in my extended class just to make it work



 Comments   
Comment by Marco Pivetta [ 25/Mar/15 ]

The class metadata factory is not designed to be extensible, as it is an internal doctrine component.

Comment by Jurj Alin [ 25/Mar/15 ]

i understand that, however we are talking about custom discriminator value, nothing else, for example if i have the entity Application\Entity\User as the discriminator, it will be converted to `user`. Thats what i'm trying to do, just to allow different discriminator generation

Comment by Marco Pivetta [ 25/Mar/15 ]

Can't this simply be fixed via explicit mapping or via an event handler?





[DDC-3635] QueryBuilder - INSTANCE OF with parameter not working Created: 24/Mar/15  Updated: 25/Mar/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: Wouter Wiltenburg Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: binding, dql, parameter
Environment:

Zend Framework 2



 Description   

I use single table class inheritance.
When I write my INSTANCE OF clause in my QueryBuilder like this:

    $result = $this->createQueryBuilder('o')
        ->leftJoin('o.child', 'c')
        ->where('c INSTANCE OF :entity_class')
        ->setParameter('entity_class', 'My\Entity\Class')
        ->getQuery()
        ->getResult();

It does not work correctly. The problem seems to lie in the fact that the parameter is bound to the SQL query. So if I change the entity_class to the discriminator column name it works correctly.

So if the discriminator value for My\Entity\Class would be discriminator then this does work:

    $result = $this->createQueryBuilder('o')
        ->leftJoin('o.child', 'c')
        ->where('c INSTANCE OF :entity_class')
        ->setParameter('entity_class', 'discriminator')
        ->getQuery()
        ->getResult();

So the step for getting the discriminator column from the class name is missing and instead the class name is bound to the MySql query directly.






[DDC-2240] Inconsistent querying for parameter type (from ClassMetadata) between using Find/FindBy and DoctrineQL Created: 11/Jan/13  Updated: 25/Mar/15  Resolved: 13/Jan/13

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

Type: Bug Priority: Major
Reporter: Slavik Derevyanko Assignee: Benjamin Eberlei
Resolution: Duplicate Votes: 0
Labels: ClassMetadata, dql

Attachments: PNG File DoctrineQL methods trace.png     PNG File findBy methods trace.png     File UTCDateTimeType.php    
Issue Links:
Duplicate
is duplicated by DDC-2224 convertToDatabaseValueSQL() is not ho... Resolved

 Description   

Hi,

I have stumbled on a problem were querying the same data with different methods (findBy and DQL) retrieves different results.

I have extended the Doctrine\DBAL\Types\DateTimeType with my own type
BVD\PetroleumBundle\DoctrineExtensions\DBAL\Types\UTCDateTimeType,

which I attach.
I expect, that whenever we deal with an entity that has a property of this type, both convertToDatabaseValue() (whenever we access the DB, conversion from DateTime to a string) and convertToPHPValue() (whenever the result from DB query is returned back, conversion from string to DateTime) have to be executed.

It is important, as the single purpose of convertToDatabaseValue() is to perform conversion of the incoming DateTime to the UTC timezone prior to conversion to string,
and then whenever we convert the DB value to DateTime to set it's timezone not to default value (server local timezone), but to UTC (as the values are stored in UTC).

Example:
Query:
$entity = $em->getRepository('BVDPetroleumBundle:FuelCardTransaction')->findOneBy(array('id' => $id, 'processed_datetime' => new \DateTime('2011-03-10 23:58:37')));

as you see, DateTime object is created without DateTimeZone set, which makes it employ the server's default timezone (say EST).

Entity has this property registered as:
/**

  • @ORM\Column(type="utcdatetime")
    */
    public $processed_datetime;

And this datatype is registered with Doctrine through Symfony2 configuration:
doctrine:
dbal:
types:
utcdatetime: BVD\PetroleumBundle\DoctrineExtensions\DBAL\Types\UTCDateTimeType

Whenever I query the DB, prior to SQL generation, DateTime is getting converted to UTC by UTCDateTimeType#convertToDatabaseValue(), and becomes:
'2011-03-10 23:58:37' (EST) -> '2011-03-11 04:58:37' (UTC).
Then, whenever the object is retrieved back, I expect that UTCDateTimeType#convertToPHPValue() is used to set the correct timezone information
on the created DateTime object: '2011-03-11 04:58:37' (UTC).
This is the correct behaviour that is expected, and is correctly achieved by using findBy methods to retrieve data:

$entity = $em->getRepository('BVDPetroleumBundle:FuelCardTransaction')->findOneBy(array('id' => $id, 'processed_datetime' => new \DateTime('2011-03-10 23:58:37')));

But, when the DQL is used to issue the same query:

$queryBuilder = $em->createQueryBuilder()>select('a')>from('BVDPetroleumBundle:FuelCardTransaction','a')
->where('a.id = :transaction_id')
->andWhere("a.processed_datetime = :datetime")
->setParameter('transaction_id', $id)
->setParameter("datetime", new \DateTime('2011-03-10 23:58:37'));
$entity = $queryBuilder->getQuery()->getOneOrNullResult();

Doctrine\DBAL\Types\DateTimeType#convertToDatabaseValue() is getting executed for 'processed_datetime', instead of
BVD\PetroleumBundle\DoctrineExtensions\DBAL\Types\UTCDateTimeType,

and the conversion doesn't happen, so the query doesn't return the result, that really exists in DB.

I attach two methods traces, so it's easier to identify the problem: whenever the findBy is used, and whenever the DQL is used.
I have managed to trace it to the way how both methods retrieve their $types arrays.

The reason it succeeds when used with findBy methods:
Doctrine\ORM\Persisters\BasicEntityPersister#load() is used to retrieve the data.
The $types property that holds the type information ('utcdatetime') is formed by calling
BasicEntityPersister#expandParameters($criteria), and in the process of analyzing incoming parameters it queries the entity metadata (@ORM\Column(type="utcdatetime")),
stored in BasicEntityPersister#$_class property. (method BasicEntityPersister#getType())
Then it's able to match type 'utcdatetime' to class BVD\PetroleumBundle\DoctrineExtensions\DBAL\Types\UTCDateTimeType

The reason it fails with DQL:
It seems that with DQL, it doesn't query the entity metadata (@ORM\Column(type="utcdatetime")) to derive property type. This mechanism leads the type to be recognized as simply 'datetime', and the standard handler Doctrine\DBAL\Types\DateTimeType is used instead:

The $types (which has 'datetime' instead of 'utcdatetime') array is getting formed in
Doctrine\ORM\Query#_doExecute():
list($sqlParams, $types) = $this->processParameterMappings($paramMappings);

in Doctrine\ORM\Query#processParameterMappings($paramMappings)
Doctrine\ORM\Query#processParameterValue($parameter->getValue()) is called to convert parameter from Object to string.

in Doctrine\ORM\AbstractQuery#processParameterValue($value) for object of class DateTime I would expect this to be executed:
case is_object($value) && $this->_em->getMetadataFactory()->hasMetadataFor(ClassUtils::getClass($value)):
return $this->convertObjectParameterToScalarValue($value);

but it's not, and the DateTime is returned out of it, and in Doctrine\ORM\Query\processParameterMappings $type is getting set to $parameter->getType() ('datetime')

Please confirm/contradict the issue. Right now for workaround, whenever I use DQL, have to explicitly set the timezone of DateTime prior to issuing a query.

From Russia with love,
Slavik



 Comments   
Comment by Slavik Derevyanko [ 11/Jan/13 ]

I realized, that with DQL,
the default type 'datetime' of Doctrine\ORM\Query\Parameter for DateTime objects
is getting set
by Doctrine\ORM\Query\ParameterTypeInferer#inferType(),

and that it's possible to set the type as a third parameter:

$queryBuilder = $em->createQueryBuilder()
->select('a')
->from('BVDPetroleumBundle:FuelCardTransaction','a')
->where('a.id = :transaction_id')
->andWhere("a.processed_datetime = :datetime")
->setParameter('transaction_id', $id)
->setParameter("datetime", new \DateTime('2011-03-10 23:58:37'), 'utcdatetime');

It seems, this is worth noting in the documentation.

Comment by Benjamin Eberlei [ 12/Jan/13 ]

Verified, but I don't know how to fix it without breaking BC.

As a workaround you can convert the value yourself in your code, not the nicest solution, but when wrapped in a function call of your own, it shouldn't be to invasive.

Guilherme Blanco any idea what to do?

Comment by Guilherme Blanco [ 12/Jan/13 ]

There's a way currently to fix this issue.
Of course that we lack of some direct support, but you can take advantage of a second method to fix your problem.

Currently, setParameter only accepts key, value, type as arguments, creating its own Query\Parameter.
But if you look at setParameters receiving an ArrayCollection, it doesn't create the Parameter. This is where you can take advantage.

Ideally, any Type could convert back and forth from DB to PHP value. During a query, the algorithm should apply also. But if we do this change, we will introduce a BC break. To solve the issue, you'll have to create your own Parameter.

From the Doctrine perspective, we only need to support $key to be a class too. If it's a class, replace the value in the collection of parameters. This is the required change in our codebase.
But until this gets done, setParameters is already compatible with the solution.

All you have to do is create a class that extends Query\Parameter, then apply your required changes when doing getValue or during object construction. Then use the method I mentioned to inject an ArrayCollection of Parameters and everything will work. =)

Comment by Benjamin Eberlei [ 13/Jan/13 ]

Same as DDC-2224

Comment by Benjamin Eberlei [ 08/Feb/13 ]

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

Comment by Slavik Derevyanko [ 08/Feb/13 ]

Great, thanks!

Comment by Doctrine Bot [ 23/Mar/15 ]

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

Comment by Doctrine Bot [ 25/Mar/15 ]

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

Comment by Doctrine Bot [ 25/Mar/15 ]

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





[DDC-2290] Infer custom Types from the field for query parameters Created: 08/Feb/13  Updated: 25/Mar/15

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

Type: Improvement Priority: Major
Reporter: Matthieu Napoli Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 3
Labels: None


 Description   

When using a mapping Type that declares convertToDatabaseValue, the method is not always called in queries.

Example:

SELECT ... WHERE entity.field = ?1

(with entity.field being of custom type 'the_mapping_type')

Type::convertToDatabaseValue() is correctly called when using:

$query->setParameter('1', 'foo', 'the_mapping_type');

But it is not called when using:

$query->setParameter('1', 'foo');

which gives a query that returns invalid results.

Like other mapping types in this situation, there is no reason the type is not inferred automatically from the field.

I have written a failing test case in Doctrine\Tests\ORM\Functional\TypeValueSqlTest:

    public function testQueryParameterWithoutType()
    {
        $entity = new CustomTypeUpperCase();
        $entity->lowerCaseString = 'foo';

        $this->_em->persist($entity);
        $this->_em->flush();

        $id = $entity->id;

        $this->_em->clear();

        $query = $this->_em->createQuery('SELECT c.id from Doctrine\Tests\Models\CustomType\CustomTypeUpperCase c where c.lowerCaseString = ?1');
        $query->setParameter('1', 'foo');

        $result = $query->getResult();

        $this->assertCount(1, $result);
        $this->assertEquals($id, $result[0]['id']);
    }


 Comments   
Comment by Matthieu Napoli [ 08/Feb/13 ]

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

Comment by Matthieu Napoli [ 08/Feb/13 ]

The test is in this branch: https://github.com/myc-sense/doctrine2/tree/DDC-2290

Comment by Matthieu Napoli [ 29/Oct/13 ]

The organization name has changed so the previous URL is a 404.

Here is the branch containing the failing testcase: https://github.com/myclabs/doctrine2/tree/DDC-2290

Comment by Benjamin Morel [ 28/Jan/14 ]

Any news on this one? Also, I just noticed that it does not cover the original problem I've reported in DDC-2224: I was specifically talking about convertToDatabaseValueSQL() and not convertToDatabaseValue().
My problem is that even when passing the third parameter $type, it does not use the conversion function from convertToDatabaseValueSQL().

Should we reopen DDC-2224?

Comment by Doctrine Bot [ 23/Mar/15 ]

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

Comment by Doctrine Bot [ 25/Mar/15 ]

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

Comment by Doctrine Bot [ 25/Mar/15 ]

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





[DDC-1825] generate entities with traits Created: 18/May/12  Updated: 24/Mar/15

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.2.2
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Matthias Breddin Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 6
Labels: None
Environment:

php 5.4.3, symfony2.1-dev
php 5.5.12, symfony 2.5



 Description   

When a trait with included setters and getters is used and generate entities is called, doctrine add another set of getters and setters to the "main" entity where the trait is used.



 Comments   
Comment by Martin Aarhof [ 01/May/14 ]
/**
 * @ORM\Entity
 */
class Product {
    use Traits\Created;

    /**
     * @var integer
     *
     * @ORM\Column(name="id", type="integer")
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    private $id;

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

    /**
     * Set name
     *
     * @param string $name
     * @return Attribute
     */
    public function setName($name)
    {
        $this->name = $name;

        return $this;
    }

    /**
     * Get name
     *
     * @return string 
     */
    public function getName()
    {
        return $this->name;
    }

}
Trait Created {
    /**
     * @var \DateTime $created
     *
     * @Gedmo\Timestampable(on="create")
     * @ORM\Column(type="datetime")
     */
    private $created;

    /**
     * @return \DateTime
     */
    public function getCreated()
    {
        return $this->created;
    }
}

Now when I run php app/console doctrine:generate:entities it copies everything from the trait and into the entity, so the entity now looks like

/**
 * @ORM\Entity
 */
class Product {
    use Traits\Created;

    /**
     * @var integer
     *
     * @ORM\Column(name="id", type="integer")
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    private $id;

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

    /**
     * Set name
     *
     * @param string $name
     * @return Attribute
     */
    public function setName($name)
    {
        $this->name = $name;

        return $this;
    }

    /**
     * Get name
     *
     * @return string 
     */
    public function getName()
    {
        return $this->name;
    }

    /**
     * @var \DateTime $created
     *
     * @Gedmo\Timestampable(on="create")
     * @ORM\Column(type="datetime")
     */
    private $created;

    /**
     * @return \DateTime
     */
    public function getCreated()
    {
        return $this->created;
    }

}

And ofcourse invalidates the entity because it now has two methods of the getCreated and two of private $created

Comment by Wilgert Velinga [ 01/Dec/14 ]

Unfortunately I am also suffering from this bug. Is there anything I can do to help resolve it?

Comment by Ludwig Ruderstaller [ 24/Mar/15 ]

Same here - i think an easy fix would be to introduce an additional parameter, which if set, ignores all traits.





[DDC-3623] [GH-1337] Paginator OrderBy fix take 2 Created: 17/Mar/15  Updated: 24/Mar/15  Resolved: 24/Mar/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Tools
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: distinct, mssql, oracle, orderBy, paginator, postgresql

Issue Links:
Dependency
is required for DDC-3606 [GH-1325] fixed PostgreSQL and Oracle... Resolved
is required for DDC-3629 [GH-1342] Paginator functional tests Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of zeroedin-bill:

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

Message:

This PR fixes issues created in #1220, reported in #1267. The original PR was reverted in #1283.

The issue was that in queries ordered by joined association columns, the joined column aliases did not exist in the outer query created in LimitSubqueryOutputWalker.

This PR adds functionality to LimitSubqueryOutputWalker which finds any such columns referenced in the OrderBy clause, and adds them to the SelectStatement prior to SQL generation.



 Comments   
Comment by Doctrine Bot [ 17/Mar/15 ]

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

Comment by Doctrine Bot [ 17/Mar/15 ]

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

Comment by Doctrine Bot [ 24/Mar/15 ]

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





[DDC-3629] [GH-1342] Paginator functional tests Created: 19/Mar/15  Updated: 24/Mar/15  Resolved: 24/Mar/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Tools
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: distinct, mssql, oracle, orderBy, orderby, paginator, postgresql

Issue Links:
Dependency
depends on DDC-3623 [GH-1337] Paginator OrderBy fix take 2 Resolved
is required for DDC-3606 [GH-1325] fixed PostgreSQL and Oracle... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of zeroedin-bill:

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

Message:

PaginationTest has been expanded and now covers ordering and limiting rather thoroughly.

4 tests fail on PostgreSQL and MySQL, 14 tests fail on SQL Server, and I didn't try any other DBMS.



 Comments   
Comment by Doctrine Bot [ 22/Mar/15 ]

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





[DDC-3606] [GH-1325] fixed PostgreSQL and Oracle pagination issues Created: 09/Mar/15  Updated: 24/Mar/15  Resolved: 24/Mar/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Tools
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: 1
Labels: distinct, mssql, orderBy, paginator, postgresql

Issue Links:
Dependency
depends on DDC-3623 [GH-1337] Paginator OrderBy fix take 2 Resolved
depends on DDC-3629 [GH-1342] Paginator functional tests Resolved

 Description   

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

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

Message:

Pagination with ordering on 1:m and m:m relations, was not working
properly because of selecting the ordered fields in main select
statement with distinction (e.g. SELECT DISTINCT e0_.id, p1_.name from
... ) in this case we've received less rows than we've required in
query. So I've modified the subquery generation part.
In case of PostgreSQL and Oracle added the row_number in the subquery
over order by statement, then the main select is grouped by id and
selected min of row number, also ordering by rownumber asc, because they
are on right order already (e.g. select e0_.id, min(rownum) as rownum
from ..... order by rownum).
In case of MySQL, the subselect result with ids are in right order so
there is no need to select that fields(this fixes the same issue too)
In other cases I haven't tested because of that leaved the same.



 Comments   
Comment by Vahe Shadunts [ 09/Mar/15 ]

Hi Benjamin Eberlei, please let me know if I need to change something, I've used regular expression to change the doctrine's generated select statement, if there is a better way please let me know.

The code I've modified
https://github.com/vaheshadunts/doctrine2/blob/DDC-1958/lib/Doctrine/ORM/Tools/Pagination/LimitSubqueryOutputWalker.php#L221

Comment by Vahe Shadunts [ 09/Mar/15 ]

Also please let me know should I have to modify the test assertions of the queries which are have changed by my modifications? Or I have to skip the continuous integration ?

Comment by Doctrine Bot [ 16/Mar/15 ]

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

Comment by Doctrine Bot [ 16/Mar/15 ]

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

Comment by Doctrine Bot [ 24/Mar/15 ]

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

Comment by Doctrine Bot [ 24/Mar/15 ]

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





[DDC-3626] [GH-1340] Add inversed by annotations on auto generate entities Created: 18/Mar/15  Updated: 23/Mar/15  Resolved: 23/Mar/15

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

Type: New Feature Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: bidirectional, entityGenerator


 Description   

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

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

Message:

Add inversed by annotations on auto generate entities.

Source:
http://w3facility.org/question/symfony2-doctrine2-generate-one-to-many-annotation-from-existing-database-by-doctrinemappingimport/#answer-17881139



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

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





[DDC-3634] [GH-1346] Fix: generated IDs are converted to integer Created: 23/Mar/15  Updated: 23/Mar/15  Resolved: 23/Mar/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 1
Labels: autogeneration, autoincrement, big-integer, identifier


 Description   

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

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

Message:

When I try to use type `bigint` and `@GeneratedValue` together, generated value is converted to integer.

See PHP documentation http://php.net/manual/en/language.types.array.php

> Strings containing valid integers will be cast to the integer type. E.g. the key "8" will actually be stored under 8. On the other hand "08" will not be cast, as it isn't a valid decimal integer.



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

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

Comment by Doctrine Bot [ 23/Mar/15 ]

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

Comment by Doctrine Bot [ 23/Mar/15 ]

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





[DDC-3632] [GH-1345] Fix crashes in ConvertMappingCommand and GenerateEntitiesCommand... Created: 20/Mar/15  Updated: 23/Mar/15  Resolved: 23/Mar/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers
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: discriminator-map, inheritance, metadata, reflection


 Description   

This issue is created automatically through a Github pull request on behalf of zeroedin-bill:

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

Message:

... when using entities with joined table inheritance

ConvertMappingCommand and GenerateEntitiesCommand both use the DisconnectedClassMetadataFactory, which allows metadata manipulation without loading the associated classes. Commit a36bea broke these two commands by adding a bailout condition in ClassMetadataFactory::populateDiscriminatorValue which checks $metadata->reflClass->isAbstract(). If the DisconnectedClassMetadataFactory is being used, $metadata->reflClass will always be null, causing a fatal error, "Fatal error: Call to a member function isAbstract() on null".

This commit adds a check to see if $metadata->reflClass is set before checking isAbstract.



 Comments   
Comment by Doctrine Bot [ 22/Mar/15 ]

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

Comment by Doctrine Bot [ 22/Mar/15 ]

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

Comment by Doctrine Bot [ 22/Mar/15 ]

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

Comment by Doctrine Bot [ 23/Mar/15 ]

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





Generated at Mon Mar 30 14:12:18 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.