VL
Я тут нашёл ишью на гитхабе, в общем сказали что выпилили эту поддержку и что нужно запускать untrusted код в отдельных процессах, ограничивая права на уровне OS
Size: a a a
2020 May 02
A
компанию вынеси в отдельную таблицу
A
не понял вопроса
OD
Я б сделал многие ко многим между ролями и юзерами, потому что вдруг потом захочешь несколько ролей прикручивать к юзеру
И вынес все что после isActive в отдельную таблицу типа UserInformation которая будет 1 к 1 с User
И вынес все что после isActive в отдельную таблицу типа UserInformation которая будет 1 к 1 с User
A
ну так для других ролей будет занулять данные
A
в чем проблема то
A
какие роли
A
чем отличаются
A
авторизация для всех одна, разный только доступ
A
1. нужно найти общие для всех полей
A
вынести в таблицу юзера
A
че за N?
OD
Ну инфу про компанию лучше точно в отдельную табличку, а потом с юзера FK туда
А то если два юзера с одной компании то повторять данные не оч ок
А то если два юзера с одной компании то повторять данные не оч ок
A
я бы еще препода и студента вынес
A
а вместо юзера identity прикрутил
OD
Что тебе самому больше нравится)
Я привык к Id<entity> и на моей галере так пишем
Up to you
Я привык к Id<entity> и на моей галере так пишем
Up to you
OD
Разве у каждого в голове/компании
A
все просто, если сущность юзер то id, если где то в другом месте то UserId
A
в этом есть смысл когда в девелопе фичи участвуют больше одного человека а потом фиксит это 3-й
A
как показала практика, по нейменгу и вообще по работе компонентов, лучше всего детальный планинг