Laravel по-русски

e_shl

Сообщений: 3

php artisan make:auth без id

Версия Laravel 5.8.9
Операционная система Windows 10 x64

Как можно убрать столбец id из таблицы users, точнее как использовать login вместо идентификатора/первичного ключа в стандартной авторизации laravel(php artisan make:auth )?

Изменено e_shl (24.05.2019 15:13:37)

e_shl

Сообщений: 3

Re: php artisan make:auth без id

Сам нашёл ответ на свой вопрос,
добавил в модель user:

protected $primaryKey ='login';
    public $incrementing = false;

Если нужно что то ещё отпишитесь.

Теперь другой вопрос, через Auth::id() к новому  '$primaryKey' как нибудь можно обратиться или только через Auth::user()->login

Изменено e_shl (24.05.2019 16:32:35)

artoodetoo +160

Писарь

Сообщений: 674

Статей: 1

Re: php artisan make:auth без id

Мне кажется неоправданно много усилий понадобится. Зачем вообще отказываться от автоинкрементного id? Если цель гарантировать уникальность логина, надо в миграции объявить уникальный ключ по полю login. И, конечно, проверку на уникальность в валидаторе, чтобы контролировать процесс. А id пусть будет как есть, кушать не просит.

Изменено artoodetoo (24.05.2019 17:10:54)

---

There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.

e_shl

Сообщений: 3

Re: php artisan make:auth без id

проверку на уникальность в валидаторе

Это сделано, поэтому:

А id пусть будет как есть, кушать не просит.

я тоже так считал. Но делаю диплом и в комиссии сказали если у тебя логины уникальные то пусть он используеца как идентификатор.

Изменено e_shl (25.05.2019 06:41:05)

artoodetoo +160

Писарь

Сообщений: 674

Статей: 1

Re: php artisan make:auth без id

проверку на уникальность в валидаторе

Это сделано

это же только половина. надо использовать уникальный ключ И проверку в валидаторе.

Теперь другой вопрос, через Auth::id() к новому  '$primaryKey' как нибудь можно обратиться...

Берём в руки отладчик и смотрим:
Auth::id() через цепочку методов читает поле модели, которое указано как primaryKey. То есть, если ты объявишь login как PK, то его и будет возвращать.

То есть тут всё просто. Засады могут случиться там, где есть связи с user. Во всех типовых примерах и готовых пакетах подразумевается что внешние ключи целочисленные и ссылаются на user.id. А его не будет.

Внешние ключи никак не завязаны на Auth::id(), они обращаются к конкретному полю таблицы по имени.

$table->foreign('user_id')->references('id')->on('users');

Изменено artoodetoo (25.05.2019 12:27:13)

---

There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.

artoodetoo +160

Писарь

Сообщений: 674

Статей: 1

Re: php artisan make:auth без id

> в комиссии сказали если у тебя логины уникальные то пусть он используеца как идентификатор.

Ох уж этот академический подход! Типа "нормальная форма подразумевает что запись уникально определяется ключём и только им. А если не только им, то надо проводить декомпозицию". Другими словами, профессора считают, что ключи должны быть натуральными, а не суррогатными. На практике же 99.999% таблиц используют автоинкрементный ключ и соответственно целочисленные внешние ключи.

Ты можешь аргументировать свой выбор тем, что ты используешь фреймворк, а значит оперируешь шаблонными решениями. Велосипедостроительство слишком дорого обходится. Именно поэтому появились фреймворки и шаблоны проектирования.

---

There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.

Proger_XP +345

Топ 30%

Мастер

Сообщений: 1,312

Статей: 33

Re: php artisan make:auth без id

Но делаю диплом и в комиссии сказали если у тебя логины уникальные то пусть он используеца как идентификатор.

Не троллинга ради, но если у нас готовят ИТ вот с таким подходом - это просто тушите свет... Надо понимать, что члены комиссии никогда не участвовали в реальной разработке. У меня даже нет слов это прокомментировать, одни эмоции.

С формальной точки зрения делать логин первичным ключом верно, но это настолько против всех устоявшихся практик, что действительно, разве что в дипломе такой подход и увидишь. Причем причин-то менять практики нет - мало ли, логин будет перемещен в другую таблицу, да и вообще, с числовым ключом работать намного проще и быстрее (часто строка требует преобразования в число для использования в индексе). А если логин будет изменен (некоторые форумы, к примеру, это позволяют) - это повлечет за собой изменение его во всех связанных таблицах. И это только то что сразу приходит на ум.

Делать ПК на "обычных" данных хорошо разве что в pivot-таблицах, где поле с автоинкрементом совершенно излишне.