[DDC-2285] Repeating the same query with different parameter value returns the same results Created: 08/Feb/13  Updated: 08/Feb/13  Resolved: 08/Feb/13

Status: Closed
Project: Doctrine 2 - ORM
Component/s: DQL, Mapping Drivers, ORM
Affects Version/s: 2.3.2
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Mehdi Bakhtiari Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None
Environment:

Ubuntu 12.10, Zend Server CE



 Description   
$activeAdsCustomers = \Ez\Registry::getDoctrineEntityManager()
    ->createQuery( "SELECT c, a FROM \Spot101\Model\Ad\Customer c JOIN c.ads a WHERE a.status = :status" )
    ->setParameter( "status", \Spot101\Model\Ad\Status::ACTIVE )
    ->getResult();

$inactiveAdsCustomers = \Ez\Registry::getDoctrineEntityManager()
    ->createQuery( "SELECT c, a FROM \Spot101\Model\Ad\Customer c JOIN c.ads a WHERE a.status = :status" )
    ->setParameter( "status", \Spot101\Model\Ad\Status::INACTIVE )
    ->getResult();

Having the code above I am getting the same results for $inactiveAdsCustomers as I get for $activeAdsCustomers. And when I try hydrating the results everything works so fine.

Both queries look the same except the value provided for the "status" parameter.



 Comments   
Comment by Marco Pivetta [ 08/Feb/13 ]

You are hydrating joined and filtered resultsets. You should never do this, as this will hydrate an invalid association into your objects.





[DDC-2036] indexBy breaks cascade remove Created: 20/Sep/12  Updated: 03/Oct/12  Resolved: 03/Oct/12

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

Type: Bug Priority: Critical
Reporter: James Bench Assignee: Fabio B. Silva
Resolution: Can't Fix Votes: 0
Labels: None
Environment:

Ubuntu 12.04, PHP 5.3, 64 Bit, Symfony 2


Attachments: File AbstractData.php     File DDC2036Test.php     File Location.php     File LocationData.php     Text File msql.log     Text File sql_flush.log    

 Description   

Adding the annotation indexBy causes the cascade annotation to be ignored:

/**
*

  • @var ArrayCollection
  • @ORM\OneToMany(targetEntity="LocationData", mappedBy="location", indexBy="name", cascade= {"persist", "remove"}

    )
    */
    protected $data;

Will cause an error when deleting the objects:

An exception occurred while executing 'DELETE FROM location WHERE id = ?' with params

{"1":19306}

:

SQLSTATE[23000]: Integrity constraint violation: 1451 Cannot delete or update a parent row: a foreign key constraint fails (`symfony`.`location_data`, CONSTRAINT `FK_2DF7462364D218E` FOREIGN KEY (`location_id`) REFERENCES `location` (`id`))

Removing indexBy fixes the issue.

My class structure is:

Location has many LocationData
LocationData extends AbstractData

The name field I am trying to index by comes from the AbstractData class.



 Comments   
Comment by Fabio B. Silva [ 23/Sep/12 ]

Hi James

Do you have a failing test case ?
Could you attach/paste your entity please ?

Thanks

Comment by James Bench [ 28/Sep/12 ]

Entity exhibiting the behavior.

Comment by Fabio B. Silva [ 29/Sep/12 ]

Hi James,
I can't reproduce,

Are you sure that you dont have more than one LocationData whith the same name ?

When working with indexBy the index columns must be unique into the collection.
I recommend that you add a unique constrain in the columns name.

If i'm wrong about it, please
Could you change the added test case and try to make it fails ?

Thanks

Comment by James Bench [ 02/Oct/12 ]

Hi Fabio,

The test case uses a SQLite DB without any foreign keys so the issue wouldn't be apparent.

How would I run the test against a MySQL db?

I've also attached the SQL log for the script I'm running, it looks the same as the output from the testcase.

Cheers,JB

Comment by James Bench [ 02/Oct/12 ]

SQL Log from script causing errors.

Comment by Fabio B. Silva [ 02/Oct/12 ]

Hi James,

You must copy phpunit.xml.dist to phpunit.xml and change the database configurations.

I have attached the mysql log, the test case works fine.

Comment by James Bench [ 02/Oct/12 ]

It appears that it only attempts to delete 68 LocationData rows but in the database there are 76.

Comment by James Bench [ 02/Oct/12 ]

Okay, I've found the reason for this; the name isn't unique, some are duplicated.
Once the duplicates are removed there are 68 rows.
I'll add a unique index to the name column and hopefully this problem will go away.

Not sure whether you would consider this a bug.

Thanks for your help.

Comment by Fabio B. Silva [ 02/Oct/12 ]

No problem, you are welcome

Actually isn't a bug, it is a documented behavior.

"Fields that are used for the index by feature HAVE to be unique in the database."

http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/tutorials/working-with-indexed-associations.html#working-with-indexed-assocations

Comment by Fabio B. Silva [ 03/Oct/12 ]

Fields that are used for the index by feature HAVE to be unique in the database.

http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/tutorials/working-with-indexed-associations.html#working-with-indexed-assocations





[DDC-2404] Filter using join tables Created: 19/Apr/13  Updated: 12/Sep/13  Resolved: 11/Sep/13

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

Type: New Feature Priority: Major
Reporter: Filip Procházka Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 1
Labels: filter, filters, join, joins


 Description   

Allow filters to add join tables to sql queries for filtering.

Let's have Brand entity, and BrandText entity. Text is localisation for each Brand. If there is no BrandText with bt.isPublic and bt.web_id = 123 I wanna filter it globally and not even allow to load Brand entity.

This cannot be solved by using DQL, because I need to affect lazily loaded associations, for example in templates

Accessing $product->brand-> in template should resolve to NULL, when there is no BrandText.isPublic = 1.

This could be solved by allowing filters to add joins to queries. Should I prepare a pull request?



 Comments   
Comment by Oleg Namaka [ 21/Apr/13 ]

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

Comment by Filip Procházka [ 21/Apr/13 ]

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

Comment by Filip Procházka [ 11/Sep/13 ]

Because the DDC-2220 is closed.

Comment by Benjamin Eberlei [ 11/Sep/13 ]

We won't add this feature.

Comment by Filip Procházka [ 11/Sep/13 ]

I don't understand it... Think about it once again, you've never used inner joins, or left joins with where is null for filtering results?

Comment by Filip Procházka [ 11/Sep/13 ]

And I don't what the ugly api that is mentioned in DDC-2220, I wanna addFilterJoin method here, next to addFilterConstraint https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Query/Filter/SQLFilter.php#L128

Ok then, you're not going to support this, let's assume you have good reasons for it. What are the alternatives? If you give me working filtering alternative based on WHERE statements what won't kill the server performance I'm going to give up on this issue.

Comment by Filip Procházka [ 11/Sep/13 ]

Have there at least been some discussion somewhere I can read it? So I can understand why you don't like this? The "We won't add this feature." isn't a reason.

// Btw, jira could really use some comment edits...

Comment by Benjamin Eberlei [ 12/Sep/13 ]

Filip Procházka You can use a subselect, but we cannot extend the filters to add joins for technical reasons. An implementation would raise the complexity for all the code, not just the one affected by filters.

You could try to return a JOIN from 'addFilterConstraint', but I am not sure if that works (and i would recommend it)





[DDC-2399] unserializing returns proxyclass name with slashes Created: 12/Apr/13  Updated: 12/Apr/13  Resolved: 12/Apr/13

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

Type: Bug Priority: Major
Reporter: Quintenvk Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None
Environment:

OSX, PHP 5.4.9



 Description   

I serialize a "user"-entity using the following code:

$user->getBusinessid()->getId(); //this is necessary to load the proxy
$em->detach($user);
$_SESSION['user'] = serialize($user);

When I unserialize said entity with this code:

$em = self::getEntityManager();
$user = unserialize($_SESSION['user']);
return $em->merge($user);

I get an error like this:
require(): Failed opening required './core/project/Proxy/_CG_/core/project/Entity/Businesses.php' .

The thing is that everything after _CG_ should not have any forward slashes. In that case the path would be completely correct.



 Comments   
Comment by Marco Pivetta [ 12/Apr/13 ]

There's an appositely coded autoloader in the ORM in 2.3 ( https://github.com/doctrine/doctrine2/blob/2.3.3/lib/Doctrine/ORM/Proxy/Autoloader.php ) and in common in 2.4-RC ( https://github.com/doctrine/common/blob/2.4.0-RC1/lib/Doctrine/Common/Proxy/Autoloader.php ). Proxies are not PSR-0 compliant

Comment by Quintenvk [ 12/Apr/13 ]

Ah, I hadn't found anything about that. Thank you!





[DDC-2378] Efficient count using Selectable Created: 28/Mar/13  Updated: 16/May/14  Resolved: 28/Mar/13

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

Type: Improvement Priority: Major
Reporter: Michaël Gallego Assignee: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: criteria, selectable


 Description   

Hi,

I'm currently using intensively the Criteria and Selectable interfaces to provide a generic REST library.

However, I've found a problem when I want to paginate data:

count
return count($this->selectable->matching(new Criteria()));

The problem is that EntityRepository returns an ArrayCollection and, hence, load the whole collection which is inefficient. It would be nice if it could return a PersistentCollection instead with lazy-load and perform an optimized count.

Thanks



 Comments   
Comment by Christophe Coevoet [ 28/Mar/13 ]

duplicate of DDC-2217

Comment by Doctrine Bot [ 16/May/14 ]

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





[DDC-2358] [GH-621] [doc] adding some more doc and examples for lifecycle event listeners and subscribers Created: 19/Mar/13  Updated: 14/Oct/14  Resolved: 06/Apr/13

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

Type: Documentation Priority: Major
Reporter: Benjamin Eberlei Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

as requested in https://github.com/symfony/symfony-docs/pull/2301



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

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





[DDC-2317] [UnitOfWork] Entity in identityMap but not present in entityIdentifiers Created: 24/Feb/13  Updated: 26/Feb/13  Resolved: 26/Feb/13

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

Type: Bug Priority: Major
Reporter: Rémi Piotaix Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: orm, unitofwork
Environment:

php 5.4.11, MySQL 5.5, ubuntu 12.10


Attachments: File Buff.php     File Competence.php     File CompetenceAction.php     File CompetenceActionBuff.php     File CompetenceActionBuffType.php    

 Description   

I'm using symfony 2.1.8 and sonata/admin-bundle
I have a quite complex entity mapping.

  • A Competence has many CompetenceAction (superclass)
  • CompetenceActionBuff is a subclass of CompetenceAction and has exactly one buff (selectable in the form by an 'entity' field).

When i want to edit a Competence, i have the following error message about the Buff entity linked to the CompetenceActionBuff:
"Entities passed to the choice field must be managed. [...]"
The exception is raised in Symfony/Bridge/Doctrine/Form/ChoiceList/EntityChoiceList.php at line 412

I've added some debug code in the EntityManager::contains() method and it shows that my entity is in the entityMap but his oid is not in the keys of entityIdentifiers making the call to UnitOfWork::isInIdentityMap() return false at line 1505.

When submitting the form, there is no problems. All the entities are correctly created in the database. The exception is thrown only when i want to edit the Competence object. Saying that the Buff object is not managed when it was first loaded from the database... strange, no?

Finally, i tried to comment the test

if (!$this->em->contains($entity)))

in EntityChoiceList::getIdentifierValues() and everything seemed to work properly.



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

Can you please reproduce this in an insulated environment (without symfony forms involved)?

Comment by Rémi Piotaix [ 24/Feb/13 ]

By doing this, all work properly, the exception is not thrown:

$competence = $this->getRepo(\Sistearth\JeuBundle\Entity\Competence\Competence::REPO)->find(1);
$buff = $competence->getActions()[0]->getBuff();
      
$em = $this->getDoctrine()->getEntityManager();
        
if(!$em->contains($buff))
    throw new \Exception("Not in EntityManager");

but if i add this after:

$form = $this->createForm(new \Sistearth\JeuBundle\Form\Competence\CompetenceType(), $competence);

then, the exception "Entities passed to the choice field must be managed. Maybe persist them in the entity manager?" is back.

I'll try to do some others tests...

Comment by Marco Pivetta [ 24/Feb/13 ]

Rémi Piotaix the problem is exactly the last bit Doctrine has no forms, so you will have to create a small script that reproduces the problem without symfony, starting from:

php composer.phar require doctrine/orm:dev-master@dev
Comment by Rémi Piotaix [ 24/Feb/13 ]

Bug found!

In the form type CompetenceActionBuffType, i marked the field buff with

array('by_reference"=>false)

. If by_reference is set to false, the modelData is cloned (here the Buff proxy) at line 349 in Form.php.
And, by cloning the object, the spl_object_hash of the clone is different from the original one's.

Is this a symfony Form component bug or a doctrine one?

Comment by Marco Pivetta [ 26/Feb/13 ]

Rémi Piotaix this is a problem of symfony forms, please report it on the symfony issue tracker (check if there's a similar open issue first) at https://github.com/symfony/symfony/issues/





[DDC-2244] One-To-Many Cascade saving not working properly Created: 15/Jan/13  Updated: 15/Jan/13  Resolved: 15/Jan/13

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

Type: Bug Priority: Major
Reporter: Paweł Łaskarzewski Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

I have the following code:

$new = new InterviewReview();

$question = new InterviewReviewQuestion();
$new->addQuestion($question);

$em->persist($new);
$em->flush();

When i execute this code i have the following error:

An exception occurred while executing 'INSERT INTO interview_review_question (question, tags, created_at, interview_review_id) VALUES (?, ?, ?, ?)' with params {"1":"asdfg","2":"asdfg","3":null,"4":null}:

Column 'interview_review_id' cannot be null

Here are my entities:

/**
 * InterviewReview
 *
 * @ORM\Table(name="interview_review")
 * @ORM\Entity
 */
class InterviewReview
{
    /**
     * @var integer
     *
     * @ORM\Column(name="id", type="integer")
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    private $id;

    /**
     * @var Doctrine\Common\Collections\ArrayCollection
     *
     * @ORM\OneToMany(targetEntity="Absolvent\AbsolventBundle\Entity\InterviewReviewQuestion", cascade={"persist", "remove"}, mappedBy="interview_review")
     * @ORM\JoinColumn(name="interview_review", referencedColumnName="id")
     */
    private $questions;

    /**
     * Add question
     *
     * @param \Absolvent\AbsolventBundle\Entity\InterviewReviewQuestion $question
     * @return InterviewReview
     */
    public function addQuestion(\Absolvent\AbsolventBundle\Entity\InterviewReviewQuestion $question)
    {
        $this->questions[] = $question;

        return $this;
    }

    /**
     * Remove question
     *
     * @param \Absolvent\AbsolventBundle\Entity\InterviewReviewQuestion $question
     */
    public function removeQuestion(\Absolvent\AbsolventBundle\Entity\InterviewReviewQuestion $question)
    {
        $this->questions->removeElement($question);
    }

    /**
     * Get questions
     *
     * @return \Doctrine\Common\Collections\Collection
     */
    public function getQuestions()
    {
        return $this->questions;
    }
}


/**
 * InterviewReviewQuestion
 *
 * @ORM\Table(name="interview_review_question")
 * @ORM\Entity
 */
class InterviewReviewQuestion
{
    /**
     * @var integer
     *
     * @ORM\Column(name="id", type="integer")
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    private $id;

    /**
     * @var Absolvent\AbsolventBundle\Entity\InterviewReview
     *
     * @ORM\ManyToOne(targetEntity="Absolvent\AbsolventBundle\Entity\InterviewReview", cascade={"persist", "remove"}, inversedBy="questions")
     * @ORM\JoinColumn(name="interview_review_id", referencedColumnName="id", nullable=false)
     */
    private $interview_review;

    /**
     * Get id
     *
     * @return integer
     */
    public function getId()
    {
        return $this->id;
    }

    /**
     * Set interview_review
     *
     * @param \Absolvent\AbsolventBundle\Entity\InterviewReview $interviewReview
     * @return InterviewReviewQuestion
     */
    public function setInterviewReview(\Absolvent\AbsolventBundle\Entity\InterviewReview $interviewReview = null)
    {
        $this->interview_review = $interviewReview;

        return $this;
    }

    /**
     * Get interview_review
     *
     * @return \Absolvent\AbsolventBundle\Entity\InterviewReview
     */
    public function getInterviewReview()
    {
        return $this->interview_review;
    }
}

This problem is causing because the is no $question->setInterviewReview() called anywhere.

I know that i can call it inside addQuestion function, but is should work out of the box - isn't it?



 Comments   
Comment by Marco Pivetta [ 15/Jan/13 ]

Fixing code highlighting

Comment by Paweł Łaskarzewski [ 15/Jan/13 ]

Fixed

Comment by Marco Pivetta [ 15/Jan/13 ]

Works here with your code. What's the exact ORM version you're using?

Comment by Marco Pivetta [ 15/Jan/13 ]

Calling

$question->setInterviewReview($this);

is up to you. Doctrine does not apply this kind of "magic".
You are responsible for keeping your object graph consistent.

Comment by Paweł Łaskarzewski [ 15/Jan/13 ]

In composer (using symofny) i have:

"doctrine/orm": ">=2.2,<2.4-dev"

and got the latest version.

Lanuched composer update 2 hours ago

Comment by Paweł Łaskarzewski [ 15/Jan/13 ]

Ok but both objects are new and connected (using add function). I thought that cascade=

{"persist"}

will do this magic

Comment by Marco Pivetta [ 15/Jan/13 ]

No, associating them is up to you. The ORM is only responsible for saving/loading data, not for manipulating your associations like that.

Comment by Paweł Łaskarzewski [ 15/Jan/13 ]

In the documentation there is some info about this:

http://docs.doctrine-project.org/projects/doctrine-orm/en/2.0.x/reference/working-with-associations.html#transitive-persistence-cascade-operations

Even if you persist a new User that contains our new Comment this code would fail if you removed the call to EntityManager#persist($myFirstComment). Doctrine 2 does not cascade the persist operation to all nested entities that are new as well.
[....]
To have Doctrine handle both cases automatically we can change the User#commentsAuthored property to cascade both the “persist” and the “remove” operation.

Comment by Marco Pivetta [ 15/Jan/13 ]

Paweł Łaskarzewski see DDC-2227

Comment by Paweł Łaskarzewski [ 15/Jan/13 ]

Ok thanks for your help





[DDC-2177] WHERE IN not working Created: 28/Nov/12  Updated: 29/Nov/12  Resolved: 28/Nov/12

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

Type: Bug Priority: Major
Reporter: Moritz Kraft Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None
Environment:

Linux, Symfony 2, PHP 5.3.10



 Description   

I'm going by the docs, trying to get a WHERE IN type of query working with the query builder.

I've got a flat array of IDs, e.g. something like this:

$IDs = array( 228052, 265635, 344498, 391761, 329203, 317911, 305961, 299939, 249429, 344706 );

I've tried the following ways to get this working:

  • using the Expr class:

$qb->add( 'where', $qb->expr()->in( 'c.id', ':IDs' ));
$qb->setParameter( 'IDs', $IDs );

  • alternatively:

$qb->add( 'where', $qb->expr()->in( 'c.id', $IDs ));

  • even direct DQL:

$qb->where( 'c.id IN (:IDs)' );
$qb->setParameter( 'IDs', $IDs );

The generated DQL looks fine:

SELECT c FROM MyEntity c WHERE c.id IN('228052', '265635', '344498', '391761', '329203', '317911', '305961', '299939', '249429', '344706')

But when I call execute() on that query, all these variations give me the following error:

Expected argument of type "Doctrine\ORM\QueryBuilder", "array" given



 Comments   
Comment by Moritz Kraft [ 28/Nov/12 ]

never mind.... it was something i was doing wrong. thank god...

Comment by Marco Pivetta [ 28/Nov/12 ]

Moritz Kraft what was it exactly?

Comment by Moritz Kraft [ 29/Nov/12 ]

The error was thrown by the Symfony Form Framework, not Doctrine. Sorry about that. :-/





[DDC-1628] onUpdate parameter on @JoinColumn not supported Created: 31/Jan/12  Updated: 30/Jul/15  Resolved: 21/Mar/13

Status: Closed
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers
Affects Version/s: 2.2
Fix Version/s: None

Type: Task Priority: Major
Reporter: Chris Richard Assignee: Marco Pivetta
Resolution: Invalid Votes: 3
Labels: None


 Description   

It looks like this is in the older documentation (2.0) but not mentioned in the latest.

I need to use ON UPDATE CASCADE in a few cases. Seems odd to support onDelete and not onUpdate. Am I missing something?



 Comments   
Comment by Benjamin Eberlei [ 31/Jan/12 ]

We removed onUpdate because we couldnt come up with a use-case. CAn you share yours?

Comment by Chris Richard [ 08/Mar/12 ]

I assume it's just the mysql driver but all the constraints get created such that you cannot change the primary keys (even if it's not an auto-gen PK). ON UPDATE CASCADE would probably be a better default.

Comment by Kaspars Sproģis [ 28/Aug/12 ]

I really hope onUpdate annotation attribute will be restored.
I used it in PostgreSQL very often. In some entities in some projects Primary Key ID can be very important its sequence, and if you want to change it, then "ON UPDATE CASCADE" changed it for all the references too. It was must have feature. Now few of my applications are broken with latest doctrine orm.
Please consider restoring it back.
Thank you

Comment by Václav Novotný [ 11/Oct/12 ]

+1 - onUpdate attribute is very useful for PostgreSQL databases, it controls operations with foreign keys.

Comment by Kenneth Kataiwa [ 10/Nov/12 ]

What do you mean, you couldn't come up with a use-case? If one is migrating data from one table to another and requires that all foreign key references be changed to map the ones in the new table created, before deleting the last table. And there are may more case. Maybe I am missing some thing here, if it's a use-case for the MySQL and PostgreSQL guys, why would you not support it.

Comment by Marco Pivetta [ 10/Nov/12 ]

Kenneth Kataiwa updating identifiers is something you don't do, and I sincerely also don't have a use case for this, not in the context of an ORM at least. Also, handling changes in your identifiers in the UnitOfWork is a real problem that adds a lot overhead.

Comment by Václav Novotný [ 12/Nov/12 ]

+1 - onUpdate attribute is very useful for PostgreSQL databases, it controls operations with foreign keys.

I'm taking my words back. It is not a good idea to define onUpdate on foreign keys. Yes, PostgreSQL supports it but it doesn't mean that we should use it in ORM.
Thanks for your time.

Comment by Marco Pivetta [ 21/Mar/13 ]

This issue is invalid, since data migration is not a task for the ORM anyway.

Comment by Gary Golden [ 01/May/13 ]

I have a third party table which holds users:

CREATE TABLE `user`
(
`user_id` INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
`email` VARCHAR(255) NOT NULL UNIQUE,
) ENGINE=InnoDB CHARSET="utf8";

In my table I want to use natural foreign key, so I reference `email`.

CREATE TABLE `transaction` (
`id` INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
`user_email` VARCHAR(255) NOT NULL,
FOREIGN KEY (`user_email`) REFERENCES `user`(`email`)
);

I would like to RDBMS handle email updates on the foreign records.

That is a real-life use case of the onDelete, which you decided to remove.
Please, get it back if possible.

Comment by I. S. [ 07/Jan/14 ]

I have a good use case and I am really missing the onUpdate cascade.
However it is working inside a many-to-one association but not in a one-to-one association.
The use case is a little complicated but I can send it to you if it could change something.

Comment by James Hudson [ 30/Jul/15 ]

Sorry to drag this up again, but…

I've also come across a use case as I'm migrating data in MySQL. I had to migrate data from a single table to MTI, which meant I had to investigate INFORMATION_SCHEMA, find the relevant constraints and change them in the migration script before I could migrate my data.

I appreciate that migrations and emails/usernames as PKs, are probably the only use cases, and that in general you wouldn't want the onUpdate to cascade... but is there some sort of extension that can update the constraints of all tables referencing the PK of a specified table to allow the onUpdate? If not, is that possible? Perhaps this should be raised against the doctrine migrations project... I'm not sure and would value some steer.

For anyone wondering, here's how I found the relevant constraints to batch update the onUpdate behaviour during migrations in mysql:
```sql
SELECT a.CONSTRAINT_SCHEMA, a.CONSTRAINT_NAME, a.TABLE_NAME, a.COLUMN_NAME, a.REFERENCED_TABLE_NAME, a.REFERENCED_COLUMN_NAME, c.UPDATE_RULE, c.DELETE_RULE FROM KEY_COLUMN_USAGE a LEFT JOIN REFERENTIAL_CONSTRAINTS c ON a.CONSTRAINT_NAME = c.CONSTRAINT_NAME AND a.CONSTRAINT_SCHEMA=c.CONSTRAINT_SCHEMA WHERE a.CONSTRAINT_SCHEMA = '<db-name>' AND a.REFERENCED_TABLE_NAME='<table-name>'
```
Then repeat the following for each constraint whose UPDATE_RULE is RESTRICT:
```sql
ALTER TABLE <table-name> DROP FOREIGN KEY `<constraint-name>`
ALTER TABLE <table-name> ADD CONSTRAINT `<constraint-name>` FOREIGN KEY (`<column-name>`) REFERENCES `<referenced-table-name>` (`<referenced-column-name>`) ON UPDATE CASCADE ON DELETE CASCADE");
```





[DDC-2398] Add a "use namespace" like feature to DQL to have short/reusable entity classname Created: 11/Apr/13  Updated: 11/Apr/13  Resolved: 11/Apr/13

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

Type: New Feature Priority: Minor
Reporter: David Berlioz Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: Namespace, portability


 Description   

I find not always portable-friendly the use of full class path in DQL.

$query = $em->createQuery('SELECT u FROM \MyProject\Model\User u WHERE u.age > 20');

could be :

$query = $em->createQuery('USE \MyProject\Model SELECT u FROM User u WHERE u.age > 20');

or :

$query = $em->use('\MyProject\Model')->createQuery('SELECT u FROM User u WHERE u.age > 20');

And with a default namespace attached to the entity manager :

$query = $em->use()->createQuery('SELECT u FROM User u WHERE u.age > 20');



 Comments   
Comment by Marco Pivetta [ 11/Apr/13 ]

In strings, you always use the fully qualified class name, or an entity alias

Comment by David Berlioz [ 11/Apr/13 ]

yes and so it's not symmetrical with PHP coding...
it's unesthetic and when you do code refactoring it's harder than just managing your use "namespace";
but i've put priority to minor ;p

Comment by Marco Pivetta [ 11/Apr/13 ]

David Berlioz I'm closing this. Strings are values passed around in your system, and having their meaning depend on context is absolutely a no-go





[DDC-1931] Cache $oid and $className through method calls in UoW internals Created: 17/Jul/12  Updated: 24/Jul/12  Resolved: 24/Jul/12

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

Type: Improvement Priority: Minor
Reporter: Marco Pivetta Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

As suggested by Johannes Schmitt, calls in UoW can re-use $oid and $className by passing them to the various methods of UoW internals



 Comments   
Comment by Marco Pivetta [ 18/Jul/12 ]

Performance gain is nearly 0... Not worth it as far as I've seen.





[DDC-1359] Deleting and inserting with unique index Created: 02/Sep/11  Updated: 09/Feb/13  Resolved: 09/Feb/13

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

Type: Bug Priority: Minor
Reporter: Rafal Radulski Assignee: Marco Pivetta
Resolution: Invalid Votes: 1
Labels: None
Environment:

MySQL



 Description   

I'm getting a database error when deleting and inserting records in a single unit of work. Consider this example:

I have a user and user_info tables. user_info stores additional data about a user as a list of key-values.
user: id, name, email, password
user_info: id, user_id, info_key, info_value

I created a unique index on user_info table: CREATE UNIQUE INDEX `user_info_key` ON `user_info` (`user_id` , `key` ) ;

Each table is represented as an Entity class.

Now, I run this code:
1. $user->removeAllInfo(); // remove old entries
2. $user->addInfo('first_name', 'John'); // add new entries
3. $this->em->flush(); // save

This causes MySQL error: "Integrity constraint violation: 1062 Duplicate entry". Doctrine ORM first persists new entities and then deletes old entities. I think the relevant code is at Doctrine/ORM/UnitOfWork :277-313. Everything works fine if I add flush() before line 2. Also, everything works fine if I change the index to non-unique.



 Comments   
Comment by Marco Pivetta [ 08/Jul/12 ]

I just got back to the UnitOfWork and (in latest master) it executes deletes as last operation (maybe to avoid cascades), and this is also documented.

In my opinion, you should do the operation of computing the changeset on your `info` collection manually...

Comment by Marco Pivetta [ 09/Feb/13 ]

Invalid usage of collection API/object graph





Generated at Sat Sep 05 04:06:17 EDT 2015 using JIRA 6.4.10#64025-sha1:5b8b74079161cd76a20ab66dda52747ee6701bd6.