Doctrine 2 - ORM
  1. Doctrine 2 - ORM
  2. DDC-1628

onUpdate parameter on @JoinColumn not supported

    Details

    • Type: Task Task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: 2.2
    • Fix Version/s: None
    • Component/s: Mapping Drivers
    • 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?

        Activity

        Chris Richard created issue -
        Hide
        Benjamin Eberlei added a comment -

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

        Show
        Benjamin Eberlei added a comment - We removed onUpdate because we couldnt come up with a use-case. CAn you share yours?
        Hide
        Chris Richard added a comment -

        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.

        Show
        Chris Richard added a comment - 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.
        Benjamin Eberlei made changes -
        Field Original Value New Value
        Workflow jira [ 13402 ] jira-feedback [ 14018 ]
        Benjamin Eberlei made changes -
        Workflow jira-feedback [ 14018 ] jira-feedback2 [ 15882 ]
        Benjamin Eberlei made changes -
        Workflow jira-feedback2 [ 15882 ] jira-feedback3 [ 18138 ]
        Hide
        Kaspars Sproģis added a comment - - edited

        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

        Show
        Kaspars Sproģis added a comment - - edited 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
        Kaspars Sproģis made changes -
        Priority Minor [ 4 ] Major [ 3 ]
        Hide
        Václav Novotný added a comment -

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

        Show
        Václav Novotný added a comment - +1 - onUpdate attribute is very useful for PostgreSQL databases, it controls operations with foreign keys.
        Hide
        Kenneth Kataiwa added a comment -

        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.

        Show
        Kenneth Kataiwa added a comment - 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.
        Kenneth Kataiwa made changes -
        Status Open [ 1 ] Awaiting Feedback [ 10000 ]
        Hide
        Marco Pivetta added a comment -

        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.

        Show
        Marco Pivetta added a comment - 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.
        Hide
        Václav Novotný added a comment -

        +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.

        Show
        Václav Novotný added a comment - +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.
        made changes -
        Status Awaiting Feedback [ 10000 ] In Progress [ 3 ]
        Hide
        Marco Pivetta added a comment -

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

        Show
        Marco Pivetta added a comment - This issue is invalid, since data migration is not a task for the ORM anyway.
        Marco Pivetta made changes -
        Status In Progress [ 3 ] Closed [ 6 ]
        Assignee Benjamin Eberlei [ beberlei ] Marco Pivetta [ ocramius ]
        Resolution Invalid [ 6 ]
        Hide
        Gary Golden added a comment -

        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.

        Show
        Gary Golden added a comment - 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.
        Hide
        I. S. added a comment -

        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.

        Show
        I. S. added a comment - 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.

        This list may be incomplete, as errors occurred whilst retrieving source from linked applications:

        • Request to http://www.doctrine-project.org/fisheye/ failed: Error in remote call to 'FishEye 0 (http://www.doctrine-project.org/fisheye/)' (http://www.doctrine-project.org/fisheye) [AbstractRestCommand{path='/rest-service-fe/search-v1/crossRepositoryQuery', params={query=DDC-1628, expand=changesets[0:20].revisions[0:29],reviews}, methodType=GET}] : Received status code 503 (Service Temporarily Unavailable)

          People

          • Assignee:
            Marco Pivetta
            Reporter:
            Chris Richard
          • Votes:
            3 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: