Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.php > #17937

Symfony 4 - problem z wykorzystaniem Doctrine

From Marek S <precz@spamowi.com>
Newsgroups comp.lang.php
Subject Symfony 4 - problem z wykorzystaniem Doctrine
Date 2019-06-07 01:39 +0200
Organization ATMAN - ATM S.A.
Message-ID <qdc87m$qmb$1@node1.news.atman.pl> (permalink)

Show all headers | View raw


Witam,

Zabieram się do mojego pierwszego projektu w Symfony 4. Chcę zmienić 
swój sposób myślenia i zacząć korzystać z ORM -  w tym przypadku 
Doctrine. Póki co jestem na etapie postrzegania Doctrine jako rzucanie 
kłód pod nogi. To co było banalne w SQL, tu wymaga gimnastyki, a i tak 
kwiatki wychodzą. Zapewne czegoś nie wiem. Oto moje problemy:

Założenia.

Jest baza PostgreSQL. Dla testów tworzymy banalną tabelę, którą w SQL 
opisałbym jako:

CREATE TABLE public.task
(
     task_id BIGSERIAL,
     title varchar(255) NOT NULL,
     status boolean NOT NULL
)

W bazie istnieje inna tabela o nazwie "test", której Symfony nie będzie 
obsługiwać. Celem jest wyłącznie utworzenie w/w tabeli.

Czynności

1. Próbowałem podejścia Database First aby nie marnować czasu na 
zmaganie się z ORMem. Niestety wszędzie piszą (czasem nie wprost), że 
Doctrine przestaje to wspierać:
https://symfony.com/doc/4.0/doctrine/reverse_engineering.html
https://github.com/symfony/symfony-docs/issues/9172

"Symfony is a different project than Doctrine and we don't have any 
control over those decisions."

2. Ok, zatem pozostaje używać durnego narzędzia do kreowania tabel w 
postaci console make:entity. Wprowadzenie w ten sposób np. 100 pól 
bezbłędnie, graniczy z szaleństwem. A i tak narzędzie nie uwzględnia np. 
wartości domyślnych, nazwy klucza głównego itd więc ręcznie trzeba 
modyfikować klasę.

Jak sobie radzicie z tworzeniem tabel w bazie, aby było to przynajmniej 
tak proste, jak SQL i współgrało z Doctrine?

3. Na początek zbudowałem tabelkę jak w przykładzie powyżej, wpisując 
pole po polu w powyższym narzędziu. Oczywiście były potrzebne zmiany w 
klasie Task, bo kreator potrafi tylko zarys tabeli zbudować. Encja 
wygląda tak:


/**
  * @ORM\Entity(repositoryClass="App\Repository\TaskRepository")
  */
class Task {
     /**
      * @ORM\Id()
      * @ORM\GeneratedValue(strategy="IDENTITY")
      * @ORM\Column(type="bigint", name="task_id")
      */
     private $id;

     /**
      * @ORM\Column(type="string", length=255)
      */
     private $title;

     /**
      * @ORM\Column(type="boolean", options={"default": false})
      */
     private $status=false;


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


     public function getTitle(): ?string {
         return $this->title;
     }


     public function setTitle(string $title): self {
         $this->title = $title;

         return $this;
     }


     public function getStatus(): ?bool {
         return $this->status;
     }


     public function setStatus(?bool $status): self {
         $this->status = $status;

         return $this;
     }
}

Ręcznie musiałem zmienić:
      * @ORM\GeneratedValue(strategy="IDENTITY")
      * @ORM\Column(type="bigint", name="task_id")

i dopisać wartości domyślne pól poprzez zainicjowanie zmiennych 
prywatnych oraz uczynić to powtórnie zaklęciem 
@ORM\Column(type="boolean", options={"default": false})

Niesłychanie łatwo o błędy. Np. zmienię domyślną wartość w klasie, ale 
nie powtórzę tego w opcjach "default". Modyfikacji jest mnóstwo przy 
realnej wielkości tabeli.

Czy jest jakiś sposób usprawnienia kreowania tabeli?



3. Podczas rozmów tutaj, dowiedziałem się, że ORM zapewnia mi 
przenaszalność między bazami danych. Patrzę zatem w migrację i widzę:

 
$this->abortIf($this->connection->getDatabasePlatform()->getName() !== 
'postgresql', 'Migration can only be executed safely on \'postgresql\'.');

         $this->addSql('CREATE TABLE task (task_id BIGSERIAL NOT NULL, 
title VARCHAR(255) NOT NULL, status BOOLEAN DEFAULT \'false\' NOT NULL, 
PRIMARY KEY(task_id))');

Mimo iż nie używam żadnych specjalnych typów pól, to powyższy kod nie 
wykona się dla baz innych niż PostgreSQL. Zatem jak jest z ORMami? Są 
przenaszalne, czy nie?

4. Po wygenerowaniu pierwszej migracji, znalazłem w niej Drop'a 
wszystkich istniejących struktur w bazie. Co dopiszę ręcznie do bazy, to 
po wygenerowaniu kolejnej migracji, następuję dropowanie. Jak zmusić 
generator migracji by nie dropował niczego?



-- 
Pozdrawiam,
Marek

Back to comp.lang.php | Previous | NextNext in thread | Find similar | Unroll thread


Thread

Symfony 4 - problem z wykorzystaniem Doctrine Marek S <precz@spamowi.com> - 2019-06-07 01:39 +0200
  Re: Symfony 4 - problem z wykorzystaniem Doctrine Arno Welzel <usenet@arnowelzel.de> - 2019-06-09 14:33 +0200
    Re: Symfony 4 - problem z wykorzystaniem Doctrine Marek S <precz@spamowi.com> - 2019-06-09 16:12 +0200
      Re: Symfony 4 - problem z wykorzystaniem Doctrine Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-06-09 19:22 +0200
        Re: Symfony 4 - problem z wykorzystaniem Doctrine Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-06-09 21:40 +0100
          Re: Symfony 4 - problem z wykorzystaniem Doctrine Marek S <precz@spamowi.com> - 2019-06-09 23:46 +0200
          Re: Symfony 4 - problem z wykorzystaniem Doctrine Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-06-10 20:55 +0200
            Re: Symfony 4 - problem z wykorzystaniem Doctrine Arno Welzel <usenet@arnowelzel.de> - 2019-06-11 09:54 +0200
        Re: Symfony 4 - problem z wykorzystaniem Doctrine Arno Welzel <usenet@arnowelzel.de> - 2019-06-10 01:57 +0200

csiph-web