[DDC-3945] call an undefined method named "__set_state" of class Table Created: 09/Oct/15  Updated: 09/Oct/15

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

Type: Bug Priority: Critical
Reporter: Sullivan SENECHAL Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm

PHP 5.6
Doctrine/ORM 2.5.1
Symfony 2.8-dev


If I upgrade to Symfony 2.8, I got this error on each page of my project:

UndefinedMethodException in [AppBundle-Entity-User-[Annot]][1].doctrinecache.php line 6:
Attempted to call an undefined method named "__set_state" of class "Doctrine\ORM\Mapping\Table".

[DDC-3942] Nested embeddables Created: 08/Oct/15  Updated: 08/Oct/15

Status: Open
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers, ORM
Affects Version/s: Git Master, 2.5
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Anders Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: mapping, orm

PHP 5.6, nginx


When you nest an @Embeddable inside another @Embeddable it fails with a ReflectionError

Property Ceremony::$person.hunger.id does not exist

[DDC-1628] onUpdate parameter on @JoinColumn not supported Created: 31/Jan/12  Updated: 07/Oct/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


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?

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:


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

CREATE TABLE `transaction` (
`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:
Then repeat the following for each constraint whose UPDATE_RULE is RESTRICT:
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");

Comment by Petr Černý [ 07/Oct/15 ]

Hi, we are using Doctrine Migrations as an extension in our Symfony project.
I guess everyone agrees that "on update cascade" is one of the essential parts of RDBMS. I agree that it is not essential part of ORM system. Except for the case when the ORM annotations are also used to generate Doctrine Migrations - without onUpdate keyword we are unable to automatically generate "on update cascade" constraints.
It this a sufficient use case?
With kind regards,

Generated at Fri Oct 09 11:58:14 EDT 2015 using JIRA 6.4.10#64025-sha1:5b8b74079161cd76a20ab66dda52747ee6701bd6.