Этого треда уже нет.
Это копия, сохраненная 14 марта 2019 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 14 марта 2019 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
В тред призываются программисты на Java, конкретно Spring Boot.
Нужна ваша помощь так как /pr/ мертв.
Аноны, столкнулся с проблемой, делаю курсовую на Спринге
Хочу сделать сервис, в котором Пользователи (Candidat-ы) смогут регистрироваться и создавать заявки, а Работники (HeadHunter-ы) смогут обрабатывать эти заявки и выносить вердикт. Работники заранее прописаны в БД и на клиенте нет возможности зарегистрироваться как Работник, только как Пользователь.
Столкнулся с проблемой в Spring Security. Я хотел бы чтобы вход на сервис был из одной таблицы (User), а в добавок к ней была еще пара таблиц (Candidate, HeadHunter) с дополнительной информацией для каждого из типов аккаунта описанных выше, ведь у пользователя (как и у работника) есть поля, которые не добавить в общую таблицу, например опыт работы в этой организации может быть только у сущности Работника.
Разумеется при таком подходе связь должна быть односторонней, так как я не могу добавить в User описание и Candidate и HeadHunter, User всегда должен быть кем то одним.
На пике №1 мой класс User.
На пике №2 мой класс UserInfo.
На пике №3 мой класс WorkerInfo.
Правильно ли я делаю? Эта реализация - первое что пришло мне в голову, так что я не уверен, может быть есть варианты лучше.
Этот подход вызывает большие проблемы и вообще путает меня самого, чтобы зарегистрировать нового пользователя мне приходится лишний раз идти в БД, искать там пользователя, брать его ID и вручную подставлять его в Candidate (в боле user_id). Это показано в пост маппинге на пике №4.
Быть может есть какие-то более выгодные и правильные пути реализации этих отношений?
Большая просьба, не кидаться в меня говном, я всего лишь учусь, и чего-то могу не понимать. Спасибо.
Абу благословил этот пост.
Нужна ваша помощь так как /pr/ мертв.
Аноны, столкнулся с проблемой, делаю курсовую на Спринге
Хочу сделать сервис, в котором Пользователи (Candidat-ы) смогут регистрироваться и создавать заявки, а Работники (HeadHunter-ы) смогут обрабатывать эти заявки и выносить вердикт. Работники заранее прописаны в БД и на клиенте нет возможности зарегистрироваться как Работник, только как Пользователь.
Столкнулся с проблемой в Spring Security. Я хотел бы чтобы вход на сервис был из одной таблицы (User), а в добавок к ней была еще пара таблиц (Candidate, HeadHunter) с дополнительной информацией для каждого из типов аккаунта описанных выше, ведь у пользователя (как и у работника) есть поля, которые не добавить в общую таблицу, например опыт работы в этой организации может быть только у сущности Работника.
Разумеется при таком подходе связь должна быть односторонней, так как я не могу добавить в User описание и Candidate и HeadHunter, User всегда должен быть кем то одним.
На пике №1 мой класс User.
На пике №2 мой класс UserInfo.
На пике №3 мой класс WorkerInfo.
Правильно ли я делаю? Эта реализация - первое что пришло мне в голову, так что я не уверен, может быть есть варианты лучше.
Этот подход вызывает большие проблемы и вообще путает меня самого, чтобы зарегистрировать нового пользователя мне приходится лишний раз идти в БД, искать там пользователя, брать его ID и вручную подставлять его в Candidate (в боле user_id). Это показано в пост маппинге на пике №4.
Быть может есть какие-то более выгодные и правильные пути реализации этих отношений?
Большая просьба, не кидаться в меня говном, я всего лишь учусь, и чего-то могу не понимать. Спасибо.
Абу благословил этот пост.
>>3460 (OP)
Даже сам Абу благословил этот пост
Даже сам Абу благословил этот пост
>>3499
О, а тут дабл выбил. Бамп
О, а тут дабл выбил. Бамп
Бамп
Бамп
>>3712
Читать умеешь?
Так что кто тут еще примат. Пошутил? Молодец. Изволь покинуть тред, поищи может там фап-тред кто создал или танцульки
Читать умеешь?
>Большая просьба, не кидаться в меня говном
Так что кто тут еще примат. Пошутил? Молодец. Изволь покинуть тред, поищи может там фап-тред кто создал или танцульки
Бамп
Пиздец эта енерпрайз жава,
какая же ебля в очко
какая же ебля в очко
Бамп
>>4255
ПР живее всех живых, это только ты чатикохуесос, которому если не ответили за пол часа, значит никого нет.
ПР живее всех живых, это только ты чатикохуесос, которому если не ответили за пол часа, значит никого нет.
>>4475
5 часов прошло. Пост в Java треде уже вверх улетел давно
5 часов прошло. Пост в Java треде уже вверх улетел давно
>>3460 (OP)
Если твой userRepo наследуется от CrudRepository, то метод save вернет сохраненный объект, то бишь id в том числе, и не нужен будет доп запрос...
Если твой userRepo наследуется от CrudRepository, то метод save вернет сохраненный объект, то бишь id в том числе, и не нужен будет доп запрос...
>>4763
Так в моем Entity User не описаны Entity Candidate и HeadHunter. Наоборот, в них описан User. Разве будет норм сохранятся из userRepo?
Так в моем Entity User не описаны Entity Candidate и HeadHunter. Наоборот, в них описан User. Разве будет норм сохранятся из userRepo?
>>4870
Должно нормально, но я бы еще сделал так:
Классу User добавил аннотацию @MappedSuperclass, то бишь чтобы база данных не создавал под него таблиц, а классы(domain) работника и кандидата бы унаследовал от User
Должно нормально, но я бы еще сделал так:
Классу User добавил аннотацию @MappedSuperclass, то бишь чтобы база данных не создавал под него таблиц, а классы(domain) работника и кандидата бы унаследовал от User
>>4870
И вообще, какого лешего, ты вручную, домейну(кандидат) ставишь id(метод setId), когда в аннотацию к этому полю ты явно написал @GeneratedValue
И вообще, какого лешего, ты вручную, домейну(кандидат) ставишь id(метод setId), когда в аннотацию к этому полю ты явно написал @GeneratedValue
Зачем из транзакшена редирект возвращать?
Ну и имплиментить в сущностях это хуй знает, конечно. Показывай шо там у тебя в интерфейсе
>>5863
UserDetails это спринговый интерфейс, нужен для логина
UserDetails это спринговый интерфейс, нужен для логина
>>5276
Хмм, а если я наследую domainы от User, то надо ли мне оставлять @OneToOne связь с полем private User user;?
Хмм, а если я наследую domainы от User, то надо ли мне оставлять @OneToOne связь с полем private User user;?
>>5460
Проиграл кстати
Да, ломбок тащит
> И вообще, какого лешего, ты вручную, домейну(кандидат) ставишь id(метод setId), когда в аннотацию к этому полю ты явно написал @GeneratedValue
Проиграл кстати
Да, ломбок тащит
>>6040
1) "то надо ли мне оставлять @OneToOne связь с полем private User user;?"
-в твоей простой работе(исходя из описания) я бы выпилил подобные связи, нет смысла
2) "UserDetails это спринговый интерфейс, нужен для логина"
-на самом деле не нужен, можно заимплементить UserDetailsService, где перезаписать метод loadUserByUsername, который бы брал юзера из твоего репозитория, смотри пик
TokenUser наследуется от User из пакета org.springframework.security.core.userdetails
3) Как понимаю ты юзаешь Spring Security
Надеюсь логин и пасс ты передаешь не на стандартный контроллер, который ожидает лог и пасс прямо в заголовке запроса, а не в теле, что пиздец зашквар...
1) "то надо ли мне оставлять @OneToOne связь с полем private User user;?"
-в твоей простой работе(исходя из описания) я бы выпилил подобные связи, нет смысла
2) "UserDetails это спринговый интерфейс, нужен для логина"
-на самом деле не нужен, можно заимплементить UserDetailsService, где перезаписать метод loadUserByUsername, который бы брал юзера из твоего репозитория, смотри пик
TokenUser наследуется от User из пакета org.springframework.security.core.userdetails
3) Как понимаю ты юзаешь Spring Security
Надеюсь логин и пасс ты передаешь не на стандартный контроллер, который ожидает лог и пасс прямо в заголовке запроса, а не в теле, что пиздец зашквар...
>>6719
Ну представим что ты делаешь продакшн решение, и твои сервис(ы) наверняка будут за каким нибудь nginx...
Дак вот, nginx-то логирует запросы на серваке, и если потом посмотреть лог, можно будет увидеть незахешированный пасс юзера и его логин соответственно, тут это нужно спрятать в тело запроса, чтобы не логировалось это дело...
Ну представим что ты делаешь продакшн решение, и твои сервис(ы) наверняка будут за каким нибудь nginx...
Дак вот, nginx-то логирует запросы на серваке, и если потом посмотреть лог, можно будет увидеть незахешированный пасс юзера и его логин соответственно, тут это нужно спрятать в тело запроса, чтобы не логировалось это дело...
Попытался добавить @MappedSuperclass к User, @MappedSuperclass и @Entity нельзя ставить вместе, в итоге из-за того что убрал @Entity UserRepository не создается...
>>7049
Так и должно быть, убираешь @Entity и UserRepository, создаешь два репозитория для кандидатов и работников
Так и должно быть, убираешь @Entity и UserRepository, создаешь два репозитория для кандидатов и работников
>>3460 (OP)
Пошел нахуй со своим говном отсюда. Твоя хуета никому не нужна, кроме таких же хуесосов как ты.
Пошел нахуй со своим говном отсюда. Твоя хуета никому не нужна, кроме таких же хуесосов как ты.
>>7049
А зачем тебе вообще сущности друг от друга наследовать? Просто замути их независимыми друг от друга, джойни таблицы если нужно.
А зачем тебе вообще сущности друг от друга наследовать? Просто замути их независимыми друг от друга, джойни таблицы если нужно.
>>7095
Тогда получается и сервиса два и в каждый имплементить UserDetailsService и переопределять loadUserByUsername?
Тогда получается и сервиса два и в каждый имплементить UserDetailsService и переопределять loadUserByUsername?
>>3460 (OP)
Лучше скажите как подключиться к mysql на джаве. И чтоб в любой IDE работало.
Лучше скажите как подключиться к mysql на джаве. И чтоб в любой IDE работало.
>>7460
Юзай гибернейт
Юзай гибернейт
>>7404
Потому-что если микросервисная архитектура, то прокси - ОБЯЗАТЕЛЕН, или это будет зашквар...
конечно, можно использовать спринговые прокси, типа zull, spring-cloud, но они хуево работают например с wss(секъюрным веб сокетами) и там есть баги(точно помню), и как правило во внешку смотрит nginx, а какой-нибудь спринговый прокси уже внутри системы, например видоизменяет там запросы(добавляет header в запрос например, чекает доступы и тд...)
Потому-что если микросервисная архитектура, то прокси - ОБЯЗАТЕЛЕН, или это будет зашквар...
конечно, можно использовать спринговые прокси, типа zull, spring-cloud, но они хуево работают например с wss(секъюрным веб сокетами) и там есть баги(точно помню), и как правило во внешку смотрит nginx, а какой-нибудь спринговый прокси уже внутри системы, например видоизменяет там запросы(добавляет header в запрос например, чекает доступы и тд...)
>>7517
Нетбинс.
Нетбинс.
>>8050
Ну смотри, у тебя есть авторизация(сервис авториазции) и бизнес логика(что-там с кондидатами)...
По хорошему нужно так:
1) отдельный сервис авторизации, который отвечает только за авторизацию
2) твой сервис бизнес логики, запросы на который требуют токена аутентификации, который проверяется в сервисе авторизации
3) прокси сервис, который бы разруливал запрос с фронта в сервис авторизации, и запрос на логику в бизнес сервис, тут более чем пойдет спринговый прокси
Ну смотри, у тебя есть авторизация(сервис авториазции) и бизнес логика(что-там с кондидатами)...
По хорошему нужно так:
1) отдельный сервис авторизации, который отвечает только за авторизацию
2) твой сервис бизнес логики, запросы на который требуют токена аутентификации, который проверяется в сервисе авторизации
3) прокси сервис, который бы разруливал запрос с фронта в сервис авторизации, и запрос на логику в бизнес сервис, тут более чем пойдет спринговый прокси
Тред утонул или удален.
Это копия, сохраненная 14 марта 2019 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 14 марта 2019 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.