Własna definicja kolumn w tabeli

Odpowiedz Nowy wątek
2017-03-23 10:31
Wesoły Rycerz
0

Jeśli utworzę manualnie własną tabelę Users - nie za pomocą migracji laravel - i dodam np. kolumny jak u_key, u_username, u_psswd to poczas logowania np do systemu sprawia to problemy, bo widzę. że laravel w plikach katalogu /laravel ma na sztywno wpisane pole, jak np. password zaś u mnie to u_psswd.

To znaczy, że nie mogę tworzyć własnej definicji kolumn ? Co z tym można zrobić ? Czyżby laravel wymuszał jakich pól mam używać ...

Pozostało 580 znaków

2017-03-23 10:32
1

RTFM.

By default, Laravel uses the email field for authentication. If you would like to customize this, you may define a username method on your LoginController:

public function username()
{
    return 'custom_wtf_username_column';
}

The getAuthPassword should return the user's hashed password

public function getAuthPassword() {
    return $this->custom_wtf_password_column;
}
edytowany 1x, ostatnio: Desu, 2017-03-23 10:40

Pozostało 580 znaków

2017-03-23 11:01
Wesoły Rycerz
0

W pliku auth.php ustawiłem provider z bazy:

    'providers' => [
//         'users' => [
//             'driver' => 'eloquent',
//             'model' => App\User::class,
//         ],

        'users' => [
            'driver' => 'database',
            'table' => 'myTab',
        ],
    ],

zaś w kontrolerze klasy User, nadałem pola:

protected $table = 'myTab';
protected $primaryKey = 'u_id';

wynik jest już inny, ale z błędem jeszcze:

QueryException in Connection.php line 647:
SQLSTATE[42S22]: Column not found: 1054 Unknown column 'id' in 'where clause' (SQL: select * from myTab where id = 1 limit 1)

Wycofując zmiany z auth.php i ustawiając na 'driver' => 'eloquent', pola z klasy User działają, ale zaś problem z hasłem 'password', j.w.

Pozostało 580 znaków

2017-03-23 11:35
0

Nic nie musisz ruszac w Auth.php... Zmień protected $primaryKey = 'u_id'; i dodaj do modelu User metodę getAuthPassword. I pogoogluj troche bo informacji na ten temat jest full.

Swoją drogą strasznie dupne te twoje nazwy kolumn. Osobiście nie lubie prefiksować nazw kolumn, ale takie coś u_psswd to juz moim zdaniem przegięcie. Napisz po ludzku password. Później powstają takie kwiatki:

CREATE TABLE surv_event_answer (
  sea_id INTEGER PRIMARY KEY NOT NULL DEFAULT nextval('surv_event_answer_sea_id_seq'::regclass),
  sea_sq_id INTEGER,
  sea_sa_id INTEGER,
  sea_se_id INTEGER
);

Mam w systemie taką tabelę, która jest częścią modułu odpowiedzialnego za ankiety i za cholere nie idzie sie połapać o co chodzi z takimi kolumnami. Oczywiście też ktoś sobie wymyślił prefixy i aliasowanie kolumn zamiast normalnych nazw, żeby było krócej, ale jak czytam zapytanie no nie mam pojęcia o co tam chodzi.

edytowany 5x, ostatnio: Desu, 2017-03-23 11:41

Pozostało 580 znaków

2017-03-23 11:58
Wesoły Rycerz
0

OK, ale co do nazw kolumn nie masz racji, po są prefixy aby był porządek, szczególnie przy złączeniach i dużej ilości tabel, gdy nazwy kolumn z reguły się powtarzają w różnych tabelach, wtedy jest dopiero burdel i nie można się połapać, od lat stosuje prefixy i nie widzę nic strasznego w ich stosowaniu.

Pozostało 580 znaków

2017-03-23 12:36
0

Ja lubie używać prefiksów, ale tylko przy kluczu głównym, wtedy fajnie się to komponuje z FK. Co do prefiksowania każdej kolumny, to owszem wystepują kolizje, ale to dobrze. Wtedy nie przyjdzie Ci jakiś junior developer i nie zrobi SELECT a.*, b.*, c.*, d.*. Taka przynajmniej moja opinia.

Co by nie było, to nadrzędną zasadą jest spójność przede wszystkim.

edytowany 1x, ostatnio: Desu, 2017-03-23 12:37

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0