doctrine/archived-orm
1
0
Fork 0
mirror of https://github.com/doctrine/orm.git synced 2026-03-23 22:42:18 +01:00
Code Issues 5.3k Packages Projects Releases 100 Wiki Activity

Update (change id) OneToMany relation? #6160

New Issue
Closed
opened 2026-01-22 15:27:56 +01:00 by admin · 10 comments
admin commented 2026-01-22 15:27:56 +01:00
Owner
Copy Link

Originally created by @enima-web on GitHub (Jan 21, 2019).

Originally assigned to: @Ocramius on GitHub.

Actualite Entity :


<?php

namespace App\Entity;

use ApiPlatform\Core\Annotation\ApiResource;

/**
 * @ApiResource(
 *     normalizationContext={"groups"={"get"}, "enable_max_depth"=true},
 *     denormalizationContext={"groups"={"write"}}
 * )
 * @ORM\Entity(repositoryClass="App\Repository\ActualiteRepository")
 */
class Actualite
{
    /**
     * @ORM\Id()
     * @ORM\GeneratedValue()
     * @ORM\Column(type="integer")
     */
    private $id;

    /**
     * @var string titre actualite
     * @ORM\Column(type="string", length=255)
     * @Assert\NotBlank
     * @Groups({"get", "write"})
     */
    private $titre;

    /**
     * @var text contenu actualite
     * @ORM\Column(type="text")
     * @Assert\NotBlank
     * @Groups({"write", "get"})
     */
    private $contenu;

    /**
     * @ORM\OneToMany(targetEntity="App\Entity\Comment", mappedBy="actualite", cascade={"all"})
     * @Groups({"get"})
     */
    private $comments;


    public function __construct()
    {
        $this->comments = new ArrayCollection();
    }

    public function getId(): ?int
    {
        return $this->id;
    }


    public function getTitre(): ?string
    {
        return $this->titre;
    }

    public function setTitre(string $titre): self
    {
        $this->titre = $titre;

        return $this;
    }

    /**
     * @return Collection|Comment[]
     */
    public function getComments(): Collection
    {
        return $this->comments;
    }

    public function addComment(Comment $comment): self
    {
        if (!$this->comments->contains($comment)) {
            $this->comments[] = $comment;
            $comment->setActualite($this);
        }

        return $this;
    }

    public function removeComment(Comment $comment): self
    {
        if ($this->comments->contains($comment)) {
            $this->comments->removeElement($comment);
            // set the owning side to null (unless already changed)
            if ($comment->getActualite() === $this) {
                $comment->setActualite(null);
            }
        }

        return $this;
    }

    public function getContenu(): ?string
    {
        return $this->contenu;
    }

    public function setContenu(string $contenu): self
    {
        $this->contenu = $contenu;

        return $this;
    }


}

Comment Entity :


<?php

namespace App\Entity;

use ApiPlatform\Core\Annotation\ApiResource;

/**
 * @ApiResource(
 *     normalizationContext={"groups"={"get"}, "enable_max_depth"=true},
 * )
 * @ORM\Entity(repositoryClass="App\Repository\CommentRepository")
 */
class Comment
{
    /**
     * @ORM\Id()
     * @ORM\GeneratedValue()
     * @ORM\Column(type="integer")
     */
    private $id;

    /**
     * @ORM\ManyToOne(targetEntity="App\Entity\Actualite", inversedBy="comments")
     * @ORM\JoinColumn(name="actualite_id", referencedColumnName="id")
     * @Assert\NotBlank
     * @Groups({"get"})
     * @MaxDepth(1)
     */
    private $actualite;

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


    /**
     * @var text commentaire
     * @ORM\Column(type="text")
     * @Assert\NotBlank
     * @Groups({"get"})
     */
    private $message;


    public function __construct()
    {
        $this->ajouter = new \Datetime();
    }

    public function getId(): ?int
    {
        return $this->id;
    }

    public function getActualite(): ?Actualite
    {
        return $this->actualite;
    }

    public function setActualite(?Actualite $actualite): self
    {
        $this->actualite = $actualite;

        return $this;
    }

    public function getEmail(): ?string
    {
        return $this->email;
    }

    public function setEmail(string $email): self
    {
        $this->email = $email;

        return $this;
    }

    public function getMessage(): ?string
    {
        return $this->message;
    }

    public function setMessage(string $message): self
    {
        $this->message = $message;

        return $this;
    }
}

after i insert some data in tables all work perfect :

in table Actualite

+----+---------+---------+ 
| id | titre   | contenu |
+----+---------+---------+ 
| 1  | titre1  | lorem 1 |
| 2  | titre2  | lorem2  |
| 3  | titre3  | lorem3 |
+----+---------+---------+

in table Comment

+----+--------------+---------+-----------+
| id | actualite_id | email   | message   |
+----+--------------+---------+-----------+ 
| 1  |       1      | e@e.com | someText  |
| 2  |       2      | b@b.com | someText1 |
| 3  |       2      | a@a.com | text      |
| 4  |       3      | q@a.com | text2     |
+----+--------------+---------+-----------+

I want to change the ID of a iten (id=2) in the Actualite table, i must also change the actualite_id in the related table : like this ==>

in table Actualite

+----+---------+---------+ 
| id | titre   | contenu |
+----+---------+---------+ 
| 1  | titre1  | lorem 1 |
| 4  | titre2  | lorem2  |
| 3  | titre3  | lorem3  |
+----+---------+---------+

in table Comment

+----+--------------+---------+-----------+
| id | actualite_id | email   | message   |
+----+--------------+---------+-----------+ 
| 1  |       1      | e@e.com | someText  |
| 2  |       4      | b@b.com | someText1 |
| 3  |       4      | a@a.com | text      |
| 4  |       3      | q@a.com | text2     |
+----+--------------+---------+-----------+

I tried to do this operation with the Api-platform method PUT it doesn't work :

Json request : URL : http://127.0.0.1:8000/api/actualites/2

{
  "id": 4
}

nothing change !

Also i tried to craeact a costum controller to do this operation :

// scr/Controller/CustomController.php
<?php
namespace App\Controller;

use App\Entity\Actualite;
use App\Entity\Comment;

use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Annotation\Route;

class CustomController extends AbstractController
{
    /**
     *
     * @Route("/cid")
     */

    public function cidAction()
    {

        $em = $this->getDoctrine()->getManager();
        $actualite = $this->getDoctrine()
            ->getRepository(Actualite::class)
            ->cid('2', '4');
        return new Response('ok', Response::HTTP_CREATED);

    }
}

and

<?php
/// src/RepositoryActualiteRepository.php

namespace App\Repository;

use App\Entity\Actualite;
use Doctrine\Bundle\DoctrineBundle\Repository\ServiceEntityRepository;
use Symfony\Bridge\Doctrine\RegistryInterface;

/**
 * @method Actualite|null find($id, $lockMode = null, $lockVersion = null)
 * @method Actualite|null findOneBy(array $criteria, array $orderBy = null)
 * @method Actualite[]    findAll()
 * @method Actualite[]    findBy(array $criteria, array $orderBy = null, $limit = null, $offset = null)
 */
class ActualiteRepository extends ServiceEntityRepository
{
    public function __construct(RegistryInterface $registry)
    {
        parent::__construct($registry, Actualite::class);
    }
    /**
     * @return Actualite[] Returns an array of Actualite objects
     */
    public function cid($id, $value)
    {
      $qb = $this->createQueryBuilder('a')
        ->update()
        ->set('a.id', $value)
        ->where('a.id = :val')
        ->setParameter('val', $id); 

        return $qb->getQuery()->getResult();
    }
}

I get Error violation :

SQLSTATE[23000]: Integrity constraint violation: 1451 Cannot delete or update a parent row: a foreign key constraint fails (api.comment, CONSTRAINT FK_9474526CA2843073 FOREIGN KEY (actualite_id) REFERENCES actualite (id))
How can i change the ID of a item in Actualite entity , and change the actualite_id in the related entity?

How can I do this operation ?

Originally created by @enima-web on GitHub (Jan 21, 2019). Originally assigned to: @Ocramius on GitHub. Actualite Entity : ``` <?php namespace App\Entity; use ApiPlatform\Core\Annotation\ApiResource; /** * @ApiResource( * normalizationContext={"groups"={"get"}, "enable_max_depth"=true}, * denormalizationContext={"groups"={"write"}} * ) * @ORM\Entity(repositoryClass="App\Repository\ActualiteRepository") */ class Actualite { /** * @ORM\Id() * @ORM\GeneratedValue() * @ORM\Column(type="integer") */ private $id; /** * @var string titre actualite * @ORM\Column(type="string", length=255) * @Assert\NotBlank * @Groups({"get", "write"}) */ private $titre; /** * @var text contenu actualite * @ORM\Column(type="text") * @Assert\NotBlank * @Groups({"write", "get"}) */ private $contenu; /** * @ORM\OneToMany(targetEntity="App\Entity\Comment", mappedBy="actualite", cascade={"all"}) * @Groups({"get"}) */ private $comments; public function __construct() { $this->comments = new ArrayCollection(); } public function getId(): ?int { return $this->id; } public function getTitre(): ?string { return $this->titre; } public function setTitre(string $titre): self { $this->titre = $titre; return $this; } /** * @return Collection|Comment[] */ public function getComments(): Collection { return $this->comments; } public function addComment(Comment $comment): self { if (!$this->comments->contains($comment)) { $this->comments[] = $comment; $comment->setActualite($this); } return $this; } public function removeComment(Comment $comment): self { if ($this->comments->contains($comment)) { $this->comments->removeElement($comment); // set the owning side to null (unless already changed) if ($comment->getActualite() === $this) { $comment->setActualite(null); } } return $this; } public function getContenu(): ?string { return $this->contenu; } public function setContenu(string $contenu): self { $this->contenu = $contenu; return $this; } } ``` Comment Entity : ``` <?php namespace App\Entity; use ApiPlatform\Core\Annotation\ApiResource; /** * @ApiResource( * normalizationContext={"groups"={"get"}, "enable_max_depth"=true}, * ) * @ORM\Entity(repositoryClass="App\Repository\CommentRepository") */ class Comment { /** * @ORM\Id() * @ORM\GeneratedValue() * @ORM\Column(type="integer") */ private $id; /** * @ORM\ManyToOne(targetEntity="App\Entity\Actualite", inversedBy="comments") * @ORM\JoinColumn(name="actualite_id", referencedColumnName="id") * @Assert\NotBlank * @Groups({"get"}) * @MaxDepth(1) */ private $actualite; /** * @var string email * @ORM\Column(type="string", length=255) * @Assert\NotBlank */ private $email; /** * @var text commentaire * @ORM\Column(type="text") * @Assert\NotBlank * @Groups({"get"}) */ private $message; public function __construct() { $this->ajouter = new \Datetime(); } public function getId(): ?int { return $this->id; } public function getActualite(): ?Actualite { return $this->actualite; } public function setActualite(?Actualite $actualite): self { $this->actualite = $actualite; return $this; } public function getEmail(): ?string { return $this->email; } public function setEmail(string $email): self { $this->email = $email; return $this; } public function getMessage(): ?string { return $this->message; } public function setMessage(string $message): self { $this->message = $message; return $this; } } ``` after i insert some data in tables all work perfect : in table Actualite ``` +----+---------+---------+ | id | titre | contenu | +----+---------+---------+ | 1 | titre1 | lorem 1 | | 2 | titre2 | lorem2 | | 3 | titre3 | lorem3 | +----+---------+---------+ ``` in table Comment ``` +----+--------------+---------+-----------+ | id | actualite_id | email | message | +----+--------------+---------+-----------+ | 1 | 1 | e@e.com | someText | | 2 | 2 | b@b.com | someText1 | | 3 | 2 | a@a.com | text | | 4 | 3 | q@a.com | text2 | +----+--------------+---------+-----------+ ``` I want to change the ID of a iten (id=2) in the Actualite table, i must also change the actualite_id in the related table : like this ==> in table Actualite ``` +----+---------+---------+ | id | titre | contenu | +----+---------+---------+ | 1 | titre1 | lorem 1 | | 4 | titre2 | lorem2 | | 3 | titre3 | lorem3 | +----+---------+---------+ ``` in table Comment ``` +----+--------------+---------+-----------+ | id | actualite_id | email | message | +----+--------------+---------+-----------+ | 1 | 1 | e@e.com | someText | | 2 | 4 | b@b.com | someText1 | | 3 | 4 | a@a.com | text | | 4 | 3 | q@a.com | text2 | +----+--------------+---------+-----------+ ``` I tried to do this operation with the Api-platform method PUT it doesn't work : Json request : URL : http://127.0.0.1:8000/api/actualites/2 ``` { "id": 4 } ``` nothing change ! Also i tried to craeact a costum controller to do this operation : ``` // scr/Controller/CustomController.php <?php namespace App\Controller; use App\Entity\Actualite; use App\Entity\Comment; use Symfony\Bundle\FrameworkBundle\Controller\AbstractController; use Symfony\Component\HttpFoundation\Response; use Symfony\Component\Routing\Annotation\Route; class CustomController extends AbstractController { /** * * @Route("/cid") */ public function cidAction() { $em = $this->getDoctrine()->getManager(); $actualite = $this->getDoctrine() ->getRepository(Actualite::class) ->cid('2', '4'); return new Response('ok', Response::HTTP_CREATED); } } ``` and ``` <?php /// src/RepositoryActualiteRepository.php namespace App\Repository; use App\Entity\Actualite; use Doctrine\Bundle\DoctrineBundle\Repository\ServiceEntityRepository; use Symfony\Bridge\Doctrine\RegistryInterface; /** * @method Actualite|null find($id, $lockMode = null, $lockVersion = null) * @method Actualite|null findOneBy(array $criteria, array $orderBy = null) * @method Actualite[] findAll() * @method Actualite[] findBy(array $criteria, array $orderBy = null, $limit = null, $offset = null) */ class ActualiteRepository extends ServiceEntityRepository { public function __construct(RegistryInterface $registry) { parent::__construct($registry, Actualite::class); } /** * @return Actualite[] Returns an array of Actualite objects */ public function cid($id, $value) { $qb = $this->createQueryBuilder('a') ->update() ->set('a.id', $value) ->where('a.id = :val') ->setParameter('val', $id); return $qb->getQuery()->getResult(); } } ``` I get Error violation : `SQLSTATE[23000]: Integrity constraint violation: 1451 Cannot delete or update a parent row: a foreign key constraint fails (`api`.`comment`, CONSTRAINT `FK_9474526CA2843073` FOREIGN KEY (`actualite_id`) REFERENCES `actualite` (`id`))` How can i change the ID of a item in Actualite entity , and change the actualite_id in the related entity? How can I do this operation ?
admin added the Question label 2026-01-22 15:27:56 +01:00
admin closed this issue 2026-01-22 15:27:57 +01:00
admin commented 2026-01-22 15:27:58 +01:00
Author
Owner
Copy Link

@Ocramius commented on GitHub (Jan 23, 2019):

Changing identifiers (any identifiers) after an object has been persisted is generally not supported by the ORM, nor can be supported in future.

Identifiers are supposed to be stable.

@Ocramius commented on GitHub (Jan 23, 2019): Changing identifiers (any identifiers) after an object has been persisted is generally not supported by the ORM, nor can be supported in future. Identifiers are supposed to be stable.
admin commented 2026-01-22 15:27:58 +01:00
Author
Owner
Copy Link

@ancpru commented on GitHub (Apr 3, 2019):

I understand that it's not supported by ORM, but having some kind of "hint" in the relation declaration to generate cascade update/delete/set null in the foreign key would be really helpful.

@ancpru commented on GitHub (Apr 3, 2019): I understand that it's not supported by ORM, but having some kind of "hint" in the relation declaration to generate cascade update/delete/set null in the foreign key would be really helpful.
admin commented 2026-01-22 15:27:58 +01:00
Author
Owner
Copy Link

@Ocramius commented on GitHub (Apr 3, 2019):

having some kind of "hint" in the relation declaration to generate cascade update/delete/set null in the foreign key would be really helpful.

We had that, and we removed it explicitly, as a conscious project decision.

@Ocramius commented on GitHub (Apr 3, 2019): > having some kind of "hint" in the relation declaration to generate cascade update/delete/set null in the foreign key would be really helpful. We had that, and we removed it explicitly, as a conscious project decision.
admin commented 2026-01-22 15:27:58 +01:00
Author
Owner
Copy Link

@ancpru commented on GitHub (Apr 4, 2019):

having some kind of "hint" in the relation declaration to generate cascade update/delete/set null in the foreign key would be really helpful.

We had that, and we removed it explicitly, as a conscious project decision.

And I still do not get the reason for removing it ;)
Yes, it does not make much sense in the context of ORM, but it does make sense for having the whole database scheme description in one place and not having to mess around with custom migration scripts - esp. as the name of the constraints may be unknown because they are generated.
I think "Database Hints" could be separated in an own class and considered as "Scheme information which do not affect ORM and might not be respected by all platforms)

e.g.

@OneToMany(targetEntity="Foo",
mappedBy="bar",
dbHint={@RelationHint(constraintName="fk_xxx", onCascade="all", onUpdate="all")})

@ancpru commented on GitHub (Apr 4, 2019): > > having some kind of "hint" in the relation declaration to generate cascade update/delete/set null in the foreign key would be really helpful. > > We had that, and we removed it explicitly, as a conscious project decision. And I still do not get the reason for removing it ;) Yes, it does not make much sense in the context of ORM, but it does make sense for having the whole database scheme description in one place and not having to mess around with custom migration scripts - esp. as the name of the constraints may be unknown because they are generated. I think "Database Hints" could be separated in an own class and considered as "Scheme information which do not affect ORM and might not be respected by all platforms) e.g. @OneToMany(targetEntity="Foo", mappedBy="bar", dbHint={@RelationHint(constraintName="fk_xxx", onCascade="all", onUpdate="all")})
admin commented 2026-01-22 15:27:59 +01:00
Author
Owner
Copy Link

@Ocramius commented on GitHub (Apr 4, 2019):

And I still do not get the reason for removing it ;)

It is incompatible with the basic operative invariants of the ORM, and won't be re-introduced, as it would only encourage its usage.

As mentioned above, you are 100% free to manage the schema on your own, and you should have committed schema migrations regardless of whether you use the ORM or not anyway.

@Ocramius commented on GitHub (Apr 4, 2019): > And I still do not get the reason for removing it ;) It is incompatible with the basic operative invariants of the ORM, and won't be re-introduced, as it would only encourage its usage. As mentioned above, you are 100% free to manage the schema on your own, and you should have committed schema migrations regardless of whether you use the ORM or not anyway.
admin commented 2026-01-22 15:28:00 +01:00
Author
Owner
Copy Link

@Ocramius commented on GitHub (Apr 4, 2019):

To be more clear: schema management is secondary in the context of ORM: it is nice to have a managed DB, but every application will eventually outgrow the ORM DSL for schema management.

Use DDL, which is specifically designed for this, if you need to go the extra mile.

@Ocramius commented on GitHub (Apr 4, 2019): To be more clear: schema management is secondary in the context of ORM: it is nice to have a managed DB, but *every* application will eventually outgrow the ORM DSL for schema management. Use DDL, which is specifically designed for this, if you need to go the extra mile.
admin commented 2026-01-22 15:28:00 +01:00
Author
Owner
Copy Link

@ancpru commented on GitHub (Apr 4, 2019):

To be more clear: schema management is secondary in the context of ORM: it is nice to have a managed DB, but every application will eventually outgrow the ORM DSL for schema management.

Use DDL, which is specifically designed for this, if you need to go the extra mile.

Well, I probably have to accept this design decision, but I am not really happy with it as it makes things more complicated than necessary. I completely understand that it's not possible to cover 100 %, but I think it would be nice to cover may be 90 % which are often used - even if they are not important in context of ORM.
Most stuff as to be declared in context of ORM anyway, so a deliberately reduced functinality of ORM schema declaration leads to having to declare it with DDL and ORM. Duplicate work which could be avoided in many cases and could reduce errors.
And yes, I understand the problem of having things in the ORM which do not have an influence on the ORM or do not lead to the expected result. But that was the reason for my suggestion to explicitely name it as schema-hint: Is optional, does not have anything to do with ORM and platform might not be able to handle it.

@ancpru commented on GitHub (Apr 4, 2019): > To be more clear: schema management is secondary in the context of ORM: it is nice to have a managed DB, but _every_ application will eventually outgrow the ORM DSL for schema management. > > Use DDL, which is specifically designed for this, if you need to go the extra mile. Well, I probably have to accept this design decision, but I am not really happy with it as it makes things more complicated than necessary. I completely understand that it's not possible to cover 100 %, but I think it would be nice to cover may be 90 % which are often used - even if they are not important in context of ORM. Most stuff as to be declared in context of ORM anyway, so a *deliberately* reduced functinality of ORM schema declaration leads to having to declare it with DDL and ORM. Duplicate work which could be avoided in many cases and could reduce errors. And yes, I understand the problem of having things in the ORM which do not have an influence on the ORM or do not lead to the expected result. But that was the reason for my suggestion to explicitely name it as schema-hint: Is optional, does not have anything to do with ORM and platform might not be able to handle it.
admin commented 2026-01-22 15:28:00 +01:00
Author
Owner
Copy Link

@Ocramius commented on GitHub (Apr 4, 2019):

ORM is already covering well over the 80% of cases: stretching it further will just amplify edge cases.

If you need something custom, write the customisation explicitly yourself: this will also communicate to other developers whether there is impedance between ORM generated schema and actual schema.

In retrospect, I'd say that the ORM should support even less schema definition nuances than it currently does, because those non-ORM-specific nuances is where the majority of reported issues come from.

@Ocramius commented on GitHub (Apr 4, 2019): ORM is already covering well over the 80% of cases: stretching it further will just amplify edge cases. If you need something custom, write the customisation explicitly yourself: this will also communicate to other developers whether there is impedance between ORM generated schema and actual schema. In retrospect, I'd say that the ORM should support even less schema definition nuances than it currently does, because those non-ORM-specific nuances is where the majority of reported issues come from.
admin commented 2026-01-22 15:28:00 +01:00
Author
Owner
Copy Link

@ancpru commented on GitHub (Apr 4, 2019):

In retrospect, I'd say that the ORM should support even less schema definition nuances than it currently >does, because those non-ORM-specific nuances is where the majority of reported issues come from.

Well, In understand that issue: Features cause more possible errors and also cause more possibilities for using them the wrong way, having wrong expectations and thus creating errors on the user side. Bugs are annoying.
But I still think that a "missing feature" is often the biggest bug: No, it does not work wrong in this case. It does not work at all.

If you need something custom, write the customisation explicitly yourself: this will also communicate to ther developers whether there is impedance between ORM generated schema and actual schema.

What do you mean with with customisation and other developers here? A pure project related customisation or extending Doctrine with additional classes to support this?
My issue is that patching the generated scheme with cascades is something regulary do and would be happy if I could avoid it. IOW: No need to "patch" the scheme if it was generated "right" (in the sense of "how I want it") from the beginning. For me this is no unusual use-case because often things are not just done in an application but also by other people manually in simple SQL. Cascading makes many things much easier in this context.
But yes, things might become easier once the constraints can be named and writing DDL for the minor, but regular modification become easier to read and write.

@ancpru commented on GitHub (Apr 4, 2019): >In retrospect, I'd say that the ORM should support even less schema definition nuances than it currently >does, because those non-ORM-specific nuances is where the majority of reported issues come from. Well, In understand that issue: Features cause more possible errors and also cause more possibilities for using them the wrong way, having wrong expectations and thus creating errors on the user side. Bugs are annoying. But I still think that a "missing feature" is often the biggest bug: No, it does not work wrong in this case. It does not work at all. > If you need something custom, write the customisation explicitly yourself: this will also communicate to ther developers whether there is impedance between ORM generated schema and actual schema. What do you mean with with customisation and other developers here? A pure project related customisation or extending Doctrine with additional classes to support this? My issue is that patching the generated scheme with cascades is something regulary do and would be happy if I could avoid it. IOW: No need to "patch" the scheme if it was generated "right" (in the sense of "how I want it") from the beginning. For me this is no unusual use-case because often things are not just done in an application but also by other people manually in simple SQL. Cascading makes many things much easier in this context. But yes, things might become easier once the constraints can be named and writing DDL for the minor, but regular modification become easier to read and write.
admin commented 2026-01-22 15:28:00 +01:00
Author
Owner
Copy Link

@Ocramius commented on GitHub (Apr 4, 2019):

But I still think that a "missing feature" is often the biggest bug: No, it does not work wrong in this case. It does not work at all.

Sorry, but you have to look it at the maintenance side of this as well: time is not infinite, especially weekends.

What do you mean with with customisation and other developers here? A pure project related customisation or extending Doctrine with additional classes to support this?

Writing DDL by hand (in migrations)

My issue is that patching the generated scheme with cascades is something regulary do and would be happy if I could avoid it. IOW: No need to "patch" the scheme if it was generated "right" (in the sense of "how I want it") from the beginning. For me this is no unusual use-case because often things are not just done in an application but also by other people manually in simple SQL. Cascading makes many things much easier in this context.
But yes, things might become easier once the constraints can be named and writing DDL for the minor, but regular modification become easier to read and write.

My response from above (rephrased here) is specifically: "get used to it, because it is normal and also OK to do so".

@Ocramius commented on GitHub (Apr 4, 2019): > But I still think that a "missing feature" is often the biggest bug: No, it does not work wrong in this case. It does not work at all. Sorry, but you have to look it at the maintenance side of this as well: time is not infinite, especially weekends. > What do you mean with with customisation and other developers here? A pure project related customisation or extending Doctrine with additional classes to support this? Writing DDL by hand (in migrations) > My issue is that patching the generated scheme with cascades is something regulary do and would be happy if I could avoid it. IOW: No need to "patch" the scheme if it was generated "right" (in the sense of "how I want it") from the beginning. For me this is no unusual use-case because often things are not just done in an application but also by other people manually in simple SQL. Cascading makes many things much easier in this context. > But yes, things might become easier once the constraints can be named and writing DDL for the minor, but regular modification become easier to read and write. My response from above (rephrased here) is specifically: "get used to it, because it is normal and also OK to do so".
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
BC Break
Bug
Can't Fix
Deprecation
Documentation
DQL
Duplicate
Failing Test
Hacktoberfest
Improvement
Improvement
Incomplete
Invalid
Missing Tests
New Feature
PR Created
pull-request
Mirrored from GitHub Pull Request
 Question
Regression
Status: Waiting feedback
Waiting feedback
WIP
Won't Fix
No Label Question
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
admin
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#6160
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?