Symfony Encje Opcje

[Malinaa]

Witam, mam kłopot przy tworzeniu encji w Symfony,

Tworzę encje np.

[PHP] pobierz, plaintext 
class User implements UserInterface
{
    /**
     * @ORM\Id
     * @ORM\GeneratedValue
     * @ORM\Column(type="integer")
     */
    private $id;
 
  public function getId(): ?int
    {
        return $this->id;
    }
}
[PHP] pobierz, plaintext 

a chcę, aby było tak:

1. tabela z prefixem = ok / zrobione
2. klucz - id_user / standardowo generuje id i nie mogę zmienić na id_user bo się wysypuje

[PHP] pobierz, plaintext 
class DbmUsers implements UserInterface
{
    /**
     * @ORM\Id
     * @ORM\GeneratedValue
     * @ORM\Column(type="integer")
     */
    private $id_user;
 
  public function getIdUser(): ?int
    {
        return $this->id_user;
    }
}
[PHP] pobierz, plaintext 

Wykonuje migracje: php bin/console make:migration
i wyskakuje błąd: Column name `id` referenced for relation from App\Entity\DbmUsers towards App\Entity\DbmUsersProfile does not exist.

Jak zmienić automatycznie wygenerowane id na id_user?

Ten post edytował Malinaa 3.02.2021, 23:03:56

[nospor]

1) To jest bardziej Docrtine a nie Symfony wiec w docrtine dokumentacji szukaj pomocy
Dodaje NAME przy ORM\Column

2) A po grzyba w ogole chcesz to zmieniac? nie ma sensu dodawac do id nazwy tabeli. Nazwe tabeli masz w tabeli. Juz nasi pra pradziadkowie stosowali ID jako nazwe kolumny dla klucza glownego i nie ma wiekszego sensu tego zmieniac

[LowiczakPL]

Mam wrażenie że zależy Ci na tym id_user bo tak masz w jakiejś gotowej bazie, i potrzebujesz integracji, wystarczy dodać name.

[PHP] pobierz, plaintext 
    /**
     * @ORM\Id
     * @ORM\GeneratedValue
     * @ORM\Column(type="integer", name="id_user")
     */
    private $id;
[PHP] pobierz, plaintext 

Jeśli jednak nie to pomiń to id, niech sobie będzie, i dodaj swoje pole id_user

Ten post edytował LowiczakPL 4.02.2021, 09:53:32

[Malinaa]

A po grzyba w ogole chcesz to zmieniac?

Dzięki za informacje, bo zastanawiałem się, czy z tą zmianą id na name="id_user" to dobry pomysł,
ale jeśli już nasi pra pradziadkowie stosowali ID to zostawię id.

Mam wrażenie że zależy Ci na tym id_user

Chciałem id_user, bo uważam, że tak byłoby mi wygodniej przerobić pod Symfony 10 letnią bazę danych,
w której to muszę zmienić wszystko nazwy tabel, kolumn ich kolejność etc. i nie przestawić żadnego rekordu,
aby odpowiadał rekordom z kolejnych (edytowanych) tabel.

Kiedy mam "ręcznie" wykonać taką operacje wolałbym mieć id_user ponieważ jest unikalną nazwą,
natomiast samo id może wystąpić wszędzie również w rekordzie w słowie np. identyfikator, width, widok...
i przy tysiącach rekordów nie zrobić błędu -> wszystko jest możliwe (IMG:style_emoticons/default/wink.gif) Coś wymyślę (IMG:style_emoticons/default/smile.gif)

Chyba, że macie pomysł jak dokonać integracji takiej bazy, gdzie nic nie pasuje do Symfony,
gdzie struktura tabeli, nazwy kolumn będą nowe, ale rekordy muszą pozostać "nie ruszone",
[rekord] id tabeli użytkownicy musi odpowiadać [rekordom] artykułów, zdjęć, komentarzy itd.
id kategorii artykułów, galerii i innych modułów musi odpowiadać id artykułów, galerii...
id to id and id i jest ku*wa kosmos, do przerobienia na encje jedyne kilkadziesiąt tabel z ID
i wstrzyknięcie rekordów, które muszą się ze sobą zgadzać.

Ten post edytował Malinaa 4.02.2021, 17:03:00

[nospor]

Kiedy mam "ręcznie" wykonać taką operacje wolałbym mieć id_user ponieważ jest unikalną nazwą,
natomiast samo id może wystąpić wszędzie również w rekordzie w słowie

Dobrze, ale jesli przerabiasz to na symfony/doctrine, to ID nie bedzie sobie ot tak lezalo obok innego ID. Kazde ID bedzie powiazane z konkretnym obiektem i naprawde trzeba sie mocno starrac byc tam cos wtedy pomylic

[Malinaa]

Na początku chciałem przerobić te tabele w Notepad, ale zrobił się z tego kosmos,
Zajrzałem do phpMyAdmina i widzę, że tu można to zrobić możliwie sprawnie,
dane nie będą leżały na "jednej kartce papieru" i wówczas będzie tak jak piszesz
i dane będą widoczne w obiektach.

Patrząc na bazę w phpMyAdmin (na serwerze) widzę, że każde id ma atrybut unsigned, w Symfony domyślnie nie ma atrybutu.
Czy nie przeszkadza kiedy id będzie bez atrybutu?

[PHP] pobierz, plaintext 
/**
     * @ORM\ManyToOne(targetEntity=PreArticlesCategory::class, inversedBy="preArticles")
     * @ORM\JoinColumn(nullable=false)
     */
    private $category;
[PHP] pobierz, plaintext 

Próbowałem dodać tak
@ORM\JoinColumn(nullable=false, options={"unsigned":true})
ale przy $category(id) nie działa

[nospor]

Czemu ustawiasz to przy jakims JOINCOLUMN?

https://stackoverflow.com/questions/7692686...-unsigned-value

[LowiczakPL]

Jeśli masz starą bazę to nie kombinuj z zakładaniem Encji ręcznie bo się zamęczysz, ja pracuję na legacy z setkami tabel i robiłem to z automatu, nastepnie delikatnie zmodyfikowałem.
Są do tego automaty poczytaj to https://symfony.com/doc/current/doctrine/re...ngineering.html

[Malinaa]

Czemu ustawiasz to przy jakims JOINCOLUMN?

Encje utworzyłem w terminalu i Symfony automatycznie daje tu JoinColumn i byłoby dobrze, ale brakuje unsigned
Kiedy zamienię JoinColumn na Column pole traci swoje parametry, gubi klucz, nazwa zamiast category_id = category itd.

Dałem tak:
@ORM\Column(type="integer", name="cotegory_id", options={"unsigned":true}) pole jest unsigned,
ale zgubiło klucz i relacje, długość z integer(11) = integer(10) (length=11 nie pomogło)

Dobrze funkcjonuje w wygenerowanym JoinColum brakuje tu jednak unsigned,
więc pytanie czy nie przeszkadza kiedy id będzie bez atrybutu?

Chyba, że przy:
@ORM\Column(type="integer", name="cotegory_id", options={"unsigned":true})
można sprawić, aby był klucz i relacja w tabelą Category?

Z JoinColum jest super (bez kombinacji) tylko jak tu dodać unsigned?

Jeśli masz starą bazę to nie kombinuj z zakładaniem Encji ręcznie bo się zamęczysz

Mam starą bazę, w której nic nie pasuje do nowej, a rekordy muszą się zgadzać i tworzyć relacje.
Obawiam się, że przy tej bazie wymienione narzędzie nie sprawi cudu i będę musiał się zmęczyć...
przerobiłem 3 tabele (phpMyAdmin i ręczna robótka), dało się i można już na nich działać w PHP, więc jest dobrze.