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

Groups > comp.lang.php > #17937 > unrolled thread

Symfony 4 - problem z wykorzystaniem Doctrine

Back to article view | Back to comp.lang.php

Contents

  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

#17937 — Symfony 4 - problem z wykorzystaniem Doctrine

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

[toc] | [next] | [standalone]

#17949

Marek S:

> 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:

Sorry, this newsgroup is English speaking. If you want to get any help,
please write in English - thank you.



-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#17951

W dniu 2019-06-09 o 14:33, Arno Welzel pisze:
> Sorry, this newsgroup is English speaking. If you want to get any help,
> please write in English - thank you.
> 

Sorry, my mistake. Wrong subsriprion.


-- 
Pozdrawiam,
Marek

[toc] | [prev] | [next] | [standalone]

#17953

Marek S wrote:

> W dniu 2019-06-09 o 14:33, Arno Welzel pisze:
>> Sorry, this newsgroup is English speaking.

Utter nonsense.  This is the *international* PHP newsgroup.  *All* natural 
languages are welcome here.

>> If you want to get any help, please write in English - thank you.

That is a *recommendation* (since English has become the /lingua franca/ of 
information technology, the English-speaking audience here is 
*statistically* the largest), but NOT a requirement.  It never has been in 
the Big 8.


The main reason *for me* not to respond to the posting was that it read as 
if written by a *luser*: A code wall plus statements like «Zabieram się do 
mojego pierwszego projektu w Symfony 4.»  “I'm taking on my first project in 
Symfony 4” *and* then stating «Ok, zatem pozostaje używać durnego narzędzia 
do kreowania tabel» “Ok, so it is still necessary to use a stupid tool to 
create tables” and «graniczy z szaleństwem» “borders on madness” aso.); not 
because it was written in the Polish language (if language skills should 
fail, there is always machine translation such as Google Translate to help 
out; some general language skills provided, one can make sense even of that 
which is often googledygook[tm]).

<http://rtfm.killfile.pl/>

Also, it is inappropriate to falsify address header fields.  The “From” (and 
“Reply-To”) header fields MUST contain a *working* e-mail *address*.  Not 
being able to handle potential spam is not an excuse for being anti-social 
towards other netizens.  This “address munging” is also expressly forbidden 
by many Usenet service providers.  (It is also why you have to read this 
here and not in private.  Think about it.)

<http://www.interhack.net/pubs/munging-harmful/>

Finally, one ought to post using one‘s real name, “Marek S” no. 4711.
That is a matter of courtesy, too.

-- 
PointedEars
Zend Certified PHP Engineer <http://www.zend.com/en/yellow-pages/ZEND024953>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#17954

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
<cut>
> Also, it is inappropriate to falsify address header fields.  The “From” (and 
> “Reply-To”) header fields MUST contain a *working* e-mail *address*.

Your use of MUST (in capitals) makes it seem you have the force of net
standards behind you on this, whereas relevant RFC in fact says:

  ... a poster who does not, for whatever reason, wish to use his own
  mailbox MAY use any mailbox ending in the top-level domain ".invalid"
  
This is not how the OP "munged" the mailbox, but you appeared to be
making a general point about what MUST be done, rather than pointing out
what is usually considered to be the best thing, or simply the polite
thing to do.

<cut>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#17955

W dniu 2019-06-09 o 22:40, Ben Bacarisse pisze:

>    ... a poster who does not, for whatever reason, wish to use his own
>    mailbox MAY use any mailbox ending in the top-level domain ".invalid"

Ok, thanks. I didn't know about that.

-- 
Pozdrawiam,
Marek

[toc] | [prev] | [next] | [standalone]

#17965

Ben Bacarisse wrote:

> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
> <cut>
>> Also, it is inappropriate to falsify address header fields.  The “From”
>> (and “Reply-To”) header fields MUST contain a *working* e-mail *address*.
> 
> Your use of MUST (in capitals) makes it seem you have the force of net
> standards behind you on this, whereas relevant RFC in fact says:

You should have *cited* it, too.

RFC 5536 is not an Internet standard yet (then it would have a “STD” number, 
like <https://tools.ietf.org/html/std1>), but a Proposed Standard on the 
IETF Standards Track.  For practical purposes, it should be called a “quasi-
standard”:

,-<https://tools.ietf.org/html/rfc5536>
| 
|                                                        PROPOSED STANDARD
|                                                             Errata Exist
| Network Working Group                                  K. Murchison, Ed.
| Request for Comments: 5536                    Carnegie Mellon University
| Obsoletes: 1036                                               C. Lindsey
| Category: Standards Track                       University of Manchester
|                                                                  D. Kohn
|                                                       Healing Thresholds
|                                                            November 2009
| […]

>   ... a poster who does not, for whatever reason, wish to use his own
>   mailbox MAY use any mailbox ending in the top-level domain ".invalid"

The rules have changed a little in the meantime, indeed.  With that said, 
using the “invalid” TlD for anything but testing purposes is anti-social, 
too.  As a result, it is a killfile rule not only in my configuration.

Note that “MAY” is NOT a recommendation either:

,-<https://tools.ietf.org/html/rfc2119>
| 
| […]
| 5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
|    truly optional.  One vendor may choose to include the item because a
|    particular marketplace requires it or because the vendor feels that
|    it enhances the product while another vendor may omit the same item.
|    An implementation which does not include a particular option MUST be
|    prepared to interoperate with another implementation which does
|    include the option, though perhaps with reduced functionality. In the
|    same vein an implementation which does include a particular option
|    MUST be prepared to interoperate with another implementation which
|    does not include the option (except, of course, for the feature the
|    option provides.)

That is, *using* “.invalid” is “truly optional”.  A newsreader or mailreader 
*need NOT* recognize it as invalid (the RFC that defines it is NOT on the 
Standards Track).  E-mails can be written to it, and the inevitable bounces 
are allowed to happen.  That is not something that a poster should want to 
happen to people who could help them with their problem or want to engage 
with them in friendly private contact (for giving off-topic advice, or 
discuss common interests).
   
> This is not how the OP "munged" the mailbox, but you appeared to be
> making a general point about what MUST be done, rather than pointing out
> what is usually considered to be the best thing, or simply the polite
> thing to do.

Because I did not remember it.  Also (this was not my intention here), it is 
often a good idea to be more strict in describing things to beginners so 
that they do not get the wrong idea that it would be OK to play loose with 
the (unwritten) rules.

-- 
PointedEars
Zend Certified PHP Engineer <http://www.zend.com/en/yellow-pages/ZEND024953>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#17968

Thomas 'PointedEars' Lahn:

> Ben Bacarisse wrote:
> 
>> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>> <cut>
>>> Also, it is inappropriate to falsify address header fields.  The “From”
>>> (and “Reply-To”) header fields MUST contain a *working* e-mail *address*.
>>
>> Your use of MUST (in capitals) makes it seem you have the force of net
>> standards behind you on this, whereas relevant RFC in fact says:
> 
> You should have *cited* it, too.
> 
> RFC 5536 is not an Internet standard yet (then it would have a “STD” number, 
> like <https://tools.ietf.org/html/std1>), but a Proposed Standard on the 
> IETF Standards Track.  For practical purposes, it should be called a “quasi-
> standard”:
[...]
> The rules have changed a little in the meantime, indeed.  With that said, 
> using the “invalid” TlD for anything but testing purposes is anti-social, 
> too.  As a result, it is a killfile rule not only in my configuration.
Is it really needed to be available via e-mail if you want to
participate a public discussion?

In the past - which means at least 20 years ago - it was seen as polite
to answer postings with specific questions by sending an e-mail to the
poster, so he or she could then post a summary based on all answers he
or she got via e-mail later.

However nowadays this is completely unusual - posts are answered by
posts and sending an e-mail is a rare exception. I have a valid sender
address and the number of e-mails I got to that addess in the past 5
years is less than 1 e-mail per year.

That's the reason for RFC 5536 and a similar rules indivual.net to
adjust the rules to the reality many years ago.

See <http://individual.net/faq.php#5.3>, cite:

5.3
May I mangle my "From:" header address so that I do not get spam?

We recommend creating a special e-mail address for use with Usenet
articles only and protecting it with suitable filtering rules. This way
your regular mailbox will stay untroubled, but you can still receive
e-mail responses to your Usenet articles.

Another option is using the Top Level Domain ".invalid" (see RFC 2606).
The Top Level Domain ".invalid" is intended for construction of
obviously invalid addresses like "invalid@invalid.invalid". Such
addresses do not disturb and pollute regular name space and can easily
be identified as invalid by both humans and machines.



-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#17956

Thomas 'PointedEars' Lahn:

> Marek S wrote:
> 
>> W dniu 2019-06-09 o 14:33, Arno Welzel pisze:
>>> Sorry, this newsgroup is English speaking.
> 
> Utter nonsense.  This is the *international* PHP newsgroup.  *All* natural 
> languages are welcome here.

Anyway - since most people reading here usually speak English but not
neccessary French, Italian, German, Polish, Russian etc. it is makes no
sense to ask questions in languages other than English.

>>> If you want to get any help, please write in English - thank you.
> 
> That is a *recommendation* (since English has become the /lingua franca/ of 
> information technology, the English-speaking audience here is 
> *statistically* the largest), but NOT a requirement.  It never has been in 
> the Big 8.

Where did I say that it is a *requirement*?

-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.php

csiph-web