[DDC-3413] Types are always ignored when performing a one to many statement Created: 26/Nov/14  Updated: 27/Nov/14

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

Type: Bug Priority: Major
Reporter: Edouard COLE Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: persister


 Description   

BasicEntityPersister#getOneToManyStatement() is building an array named $criteria. This array is built this way:

$criteria[$tableAlias . "." . $targetKeyColumn] = ...;

This means this array is indexed by keys looking like that:

t0.fieldName

But the function BasicEntityPersister#expandParameters() is used in this function, and this function is NOT able to handle SQL field name as keys, but PHP attributes, because it uses BasicEntityPersister#getType() which is doing this:

case (isset($this->class->fieldMappings[$field])):
case (isset($this->class->associationMappings[$field])):

I think the $criteria array should be used to call BasicEntityPersister#getSelectSQL(), but another array should be passed to expandParameters. Here is a potential fix:

$cleanCriteria[$owningAssoc['fieldName']] = $criteria[$tableAlias . "." . $targetKeyColumn] = ...;

And $cleanCriteria should be passed to expandParameters.



 Comments   
Comment by Marco Pivetta [ 27/Nov/14 ]

Edouard COLE I suggest you to open a pull request with a failing test case, otherwise this issue is hard to follow/understand.





[DDC-3387] [GH-1182] #1086 identifier type in proxies Created: 11/Nov/14  Updated: 17/Nov/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: hydration, jti, persister, sti

Issue Links:
Dependency
is required for DDC-3223 Failing test (get id return string type) Open
Reference
is referenced by DDC-3394 UOW CreateEntity failure with zerofil... Resolved

 Description   

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

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

Message:

See #1086. This fix simply ensures that the column type for identifiers of proxies of STI/JTI are kept consistent with the DBAL types they are mapped to.

May be related/colliding with #1178

Ping @jaspernbrouwer






[DDC-2965] Error after changing IdGenerator to AssignedGenerator when for this entity class insert has been already executed Created: 08/Feb/14  Updated: 09/Feb/14  Resolved: 09/Feb/14

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

Type: Bug Priority: Major
Reporter: Piotr Śliwa Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: mapping, persister

Issue Links:
Reference
is referenced by DDC-2966 [GH-942] DDC-2965 - Changing ID gener... Resolved

 Description   

When you persist and flush entity and then change id generator to AssignedGenerator (and id generator type to NONE) for this entity class and then you persist and flush new entity with assigned id, below error will occur:

Exception: [Doctrine\DBAL\Exception\DriverException] An exception occurred while executing 'INSERT INTO cms_emails (email) VALUES ' with params [13, "example@example.com"]:

SQLSTATE[HY000]: General error: 25 bind or column index out of range

There is test that reproduces this issue:

    public function testPersistEntityAndThenSwitchToAssignedIdGenerator()
    {
        $email = new \Doctrine\Tests\Models\CMS\CmsEmail();
        $email->email = 'example5@example.com';

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

        $this->assertNotNull($email->id);

        $classMetadata = $this->_em->getClassMetadata('Doctrine\Tests\Models\CMS\CmsEmail');
        $classMetadata->setIdGeneratorType(ClassMetadataInfo::GENERATOR_TYPE_NONE);
        $classMetadata->setIdGenerator(new \Doctrine\ORM\Id\AssignedGenerator());

        $id = 13;

        $newEmail = new \Doctrine\Tests\Models\CMS\CmsEmail();
        $newEmail->email = 'example@example.com';
        $newEmail->id = $id;

        $this->_em->persist($newEmail);
        $this->_em->flush();
        $this->_em->clear();

        $newEmail = $this->_em->find('Doctrine\Tests\Models\CMS\CmsEmail', $id);

        $this->assertNotNull($newEmail);
    }

The problem is in BasicEntityPersister because insertSql is cached and is not cleared after changing id generator. Binded parameters count doesn't match with insert query because there is new parameter: id.



 Comments   
Comment by Marco Pivetta [ 09/Feb/14 ]

Provided a possible fix at https://github.com/doctrine/doctrine2/pull/942

Comment by Doctrine Bot [ 09/Feb/14 ]

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

Comment by Benjamin Eberlei [ 09/Feb/14 ]

It is not a supported use case to change metadata after loading them.





[DDC-2579] BasicEntityPersister - delete bug Created: 29/Jul/13  Updated: 10/Aug/13  Resolved: 30/Jul/13

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

Type: Bug Priority: Major
Reporter: Jan Pecek Assignee: Fabio B. Silva
Resolution: Fixed Votes: 0
Labels: orm, persister
Environment:

PHP 5.4.4, PostgreSQL 9.2



 Description   

I think, in BasicEntityPersister is bug in detecting types:
https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php#L583

The $types array is not defined inside closure function. This makes problem with deleting entity with two and more primary keys which one of them references to another entity with reference too.
My relationship (example):
User(id,name)
Person(user_id,birthdate)
Email(user_id, email) but FK (and @manyToOne relation) on user_id field references to Person table/entity, not User. FK in Person entity references to User of course.
Trying delete the Email entity record throws exception based a few lines later.



 Comments   
Comment by Fabio B. Silva [ 30/Jul/13 ]

Fixed : https://github.com/doctrine/doctrine2/commit/7055ccbf9bc9bd72b184734bcbeb72e682bf642b

Comment by Jan Pecek [ 30/Jul/13 ]

I agree with fix. I've done the same at my local repo and it works well. Thanks for confirmation.





[DDC-2089] Modify OneToMany to allow unidirectional associations without the need of a JoinTable Created: 19/Oct/12  Updated: 13/Oct/14

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

Type: Improvement Priority: Major
Reporter: Enea Bette Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: onetomany, persister, unidirectional
Environment:

Debian Wheezy, Mysql 5.1, Apache2, PHP 5.4



 Description   

As I sayd in the title, it would be nice if the ORM layer could permit to map a 1:n association in the db as an unidirectional OneToMany in the classes, without using a JoinTable in the database.
This would permit us to get rid of the unnecessary database JoinTable, which creates disorder and decreases performance for no valuable reason.

Is it possible?



 Comments   
Comment by Enea Bette [ 16/Dec/12 ]

A little up... for inspiration from JPA

http://en.wikibooks.org/wiki/Java_Persistence/OneToMany#Undirectional_OneToMany.2C_No_Inverse_ManyToOne.2C_No_Join_Table_.28JPA_2.0_ONLY.29

Comment by Daniel Pitts [ 07/Oct/14 ]

This is also a big issue for Symfony2 forms. It's very difficult to make a form type for a collection of "things", where the "things" are fully owned by the parent object.





Generated at Thu Nov 27 14:24:41 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.