Сохранен 45
https://2ch.hk/b/res/192993460.html
Архивач перешёл на постоянный домен ARHIVACH.NG. Независимо от дальнейшего развития событий, сайт всегда доступен через Tor.
Ваши пожертвования помогают нам оплачивать хостинг и домены.

В тред призываются программисты на Java, конкретно

 Аноним 14/03/19 Чтв 21:38:11 #1 №192993460 
изображение.png
изображение.png
изображение.png
изображение.png
В тред призываются программисты на 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.

Быть может есть какие-то более выгодные и правильные пути реализации этих отношений?

Большая просьба, не кидаться в меня говном, я всего лишь учусь, и чего-то могу не понимать. Спасибо.

Абу благословил этот пост.
Аноним 14/03/19 Чтв 21:38:45 #2 №192993499 
>>192993460 (OP)
Даже сам Абу благословил этот пост
Аноним 14/03/19 Чтв 21:39:12 #3 №192993531 
>>192993499
О, а тут дабл выбил. Бамп
Аноним 14/03/19 Чтв 21:40:15 #4 №192993577 
Бамп
Аноним 14/03/19 Чтв 21:42:41 #5 №192993712 
.png
>>192993460 (OP)
Аноним 14/03/19 Чтв 21:42:50 #6 №192993719 
Бамп
Аноним 14/03/19 Чтв 21:44:19 #7 №192993793 
>>192993712
Читать умеешь?
>Большая просьба, не кидаться в меня говном

Так что кто тут еще примат. Пошутил? Молодец. Изволь покинуть тред, поищи может там фап-тред кто создал или танцульки
Аноним 14/03/19 Чтв 21:46:53 #8 №192993929 
Бамп
Аноним 14/03/19 Чтв 21:50:36 #9 №192994128 
>>192993793
Даже не читал твой пост, пиздуй в пр, там у вас отдельный загон есть.
Аноним 14/03/19 Чтв 21:53:09 #10 №192994255 
>>192994128
>так как /pr/ мертв.

Действительно не читал
Аноним 14/03/19 Чтв 21:56:11 #11 №192994404 
Пиздец эта енерпрайз жава,
какая же ебля в очко
Аноним 14/03/19 Чтв 21:56:22 #12 №192994417 
Бамп
Аноним 14/03/19 Чтв 21:57:39 #13 №192994475 
>>192994255
ПР живее всех живых, это только ты чатикохуесос, которому если не ответили за пол часа, значит никого нет.
Аноним 14/03/19 Чтв 21:58:47 #14 №192994538 
>>192994475
5 часов прошло. Пост в Java треде уже вверх улетел давно
Аноним 14/03/19 Чтв 22:02:51 #15 №192994763 
>>192993460 (OP)
Если твой userRepo наследуется от CrudRepository, то метод save вернет сохраненный объект, то бишь id в том числе, и не нужен будет доп запрос...
Аноним 14/03/19 Чтв 22:04:48 #16 №192994870 
>>192994763
Так в моем Entity User не описаны Entity Candidate и HeadHunter. Наоборот, в них описан User. Разве будет норм сохранятся из userRepo?
Аноним 14/03/19 Чтв 22:11:58 #17 №192995276 
>>192994870
Должно нормально, но я бы еще сделал так:
Классу User добавил аннотацию @MappedSuperclass, то бишь чтобы база данных не создавал под него таблиц, а классы(domain) работника и кандидата бы унаследовал от User
Аноним 14/03/19 Чтв 22:14:53 #18 №192995460 
>>192994870
И вообще, какого лешего, ты вручную, домейну(кандидат) ставишь id(метод setId), когда в аннотацию к этому полю ты явно написал @GeneratedValue
Аноним 14/03/19 Чтв 22:17:47 #19 №192995624 
Зачем из транзакшена редирект возвращать?
Аноним 14/03/19 Чтв 22:22:12 #20 №192995863 
Ну и имплиментить в сущностях это хуй знает, конечно. Показывай шо там у тебя в интерфейсе
Аноним 14/03/19 Чтв 22:23:29 #21 №192995918 
>>192995863
UserDetails это спринговый интерфейс, нужен для логина
Аноним 14/03/19 Чтв 22:25:58 #22 №192996040 
>>192995276
Хмм, а если я наследую domainы от User, то надо ли мне оставлять @OneToOne связь с полем private User user;?
Аноним 14/03/19 Чтв 22:28:48 #23 №192996180 
>>192995460
> И вообще, какого лешего, ты вручную, домейну(кандидат) ставишь id(метод setId), когда в аннотацию к этому полю ты явно написал @GeneratedValue
Проиграл кстати
Да, ломбок тащит
Аноним 14/03/19 Чтв 22:33:48 #24 №192996413 
twooo.png
three.png
>>192996040
1) "то надо ли мне оставлять @OneToOne связь с полем private User user;?"
-в твоей простой работе(исходя из описания) я бы выпилил подобные связи, нет смысла

2) "UserDetails это спринговый интерфейс, нужен для логина"
-на самом деле не нужен, можно заимплементить UserDetailsService, где перезаписать метод loadUserByUsername, который бы брал юзера из твоего репозитория, смотри пик

TokenUser наследуется от User из пакета org.springframework.security.core.userdetails

3) Как понимаю ты юзаешь Spring Security
Надеюсь логин и пасс ты передаешь не на стандартный контроллер, который ожидает лог и пасс прямо в заголовке запроса, а не в теле, что пиздец зашквар...
Аноним 14/03/19 Чтв 22:40:13 #25 №192996719 
>>192996413
>3
Бля а чо так делать не надо? Сильно надают по курсовой если сдавать буду
мимо
Аноним 14/03/19 Чтв 22:44:37 #26 №192996927 
>>192996719
Ну представим что ты делаешь продакшн решение, и твои сервис(ы) наверняка будут за каким нибудь nginx...

Дак вот, nginx-то логирует запросы на серваке, и если потом посмотреть лог, можно будет увидеть незахешированный пасс юзера и его логин соответственно, тут это нужно спрятать в тело запроса, чтобы не логировалось это дело...
Аноним 14/03/19 Чтв 22:45:52 #27 №192996983 
>>192996719
Сильно надают - врятли, но сможешь блеснуть знаниями, так сказатб
Аноним 14/03/19 Чтв 22:47:15 #28 №192997049 
Попытался добавить @MappedSuperclass к User, @MappedSuperclass и @Entity нельзя ставить вместе, в итоге из-за того что убрал @Entity UserRepository не создается...
Аноним 14/03/19 Чтв 22:48:17 #29 №192997095 
>>192997049
Так и должно быть, убираешь @Entity и UserRepository, создаешь два репозитория для кандидатов и работников
sage[mailto:sage] Аноним 14/03/19 Чтв 22:48:48 #30 №192997121 
>>192993460 (OP)
Пошел нахуй со своим говном отсюда. Твоя хуета никому не нужна, кроме таких же хуесосов как ты.
Аноним 14/03/19 Чтв 22:49:28 #31 №192997160 
>>192997049
А зачем тебе вообще сущности друг от друга наследовать? Просто замути их независимыми друг от друга, джойни таблицы если нужно.
Аноним 14/03/19 Чтв 22:51:47 #32 №192997268 
>>192997095
Тогда получается и сервиса два и в каждый имплементить UserDetailsService и переопределять loadUserByUsername?
Аноним 14/03/19 Чтв 22:54:49 #33 №192997404 
>>192996927
Бля, ору. Кстати, а зачем за нгыгниксом делать? Можно же просто так развернуть, не?
>>192996983
Ну найс, чо
Аноним 14/03/19 Чтв 22:56:11 #34 №192997460 
>>192993460 (OP)
Лучше скажите как подключиться к mysql на джаве. И чтоб в любой IDE работало.
Аноним 14/03/19 Чтв 22:57:01 #35 №192997502 
>>192997460
Юзай гибернейт
Аноним 14/03/19 Чтв 22:57:28 #36 №192997517 
>>192997460
Хз про любую IDE. Зачем тебе? Надо уж решить эклипс или идея
Аноним 14/03/19 Чтв 22:59:30 #37 №192997621 
>>192997404
Потому-что если микросервисная архитектура, то прокси - ОБЯЗАТЕЛЕН, или это будет зашквар...

конечно, можно использовать спринговые прокси, типа zull, spring-cloud, но они хуево работают например с wss(секъюрным веб сокетами) и там есть баги(точно помню), и как правило во внешку смотрит nginx, а какой-нибудь спринговый прокси уже внутри системы, например видоизменяет там запросы(добавляет header в запрос например, чекает доступы и тд...)
Аноним 14/03/19 Чтв 22:59:39 #38 №192997630 
>>192997517
Нетбинс.
Аноним 14/03/19 Чтв 23:00:21 #39 №192997677 
>>192997621
Бля, сложно. Где мануалы курить?
Аноним 14/03/19 Чтв 23:04:08 #40 №192997901 
>>192997677
юзай гугл
Аноним 14/03/19 Чтв 23:07:09 #41 №192998050 
>>192997901
Перефразирую вопрос - оно мене на курсовой надо?
Аноним 14/03/19 Чтв 23:14:08 #42 №192998394 
>>192998050
Ну смотри, у тебя есть авторизация(сервис авториазции) и бизнес логика(что-там с кондидатами)...
По хорошему нужно так:
1) отдельный сервис авторизации, который отвечает только за авторизацию
2) твой сервис бизнес логики, запросы на который требуют токена аутентификации, который проверяется в сервисе авторизации
3) прокси сервис, который бы разруливал запрос с фронта в сервис авторизации, и запрос на логику в бизнес сервис, тут более чем пойдет спринговый прокси
Аноним 14/03/19 Чтв 23:54:49 #43 №193000310 
>>192997095

Такс, ну, вроде бы все работает, но есть одно НО.
ID в таблице HeadHunter и Candidate повторяются, хоть оба domain-а и наследуются от User. Само поле ID, оставил только в User, из остальных выпилил.
Проблема возникает когда я хочу задать роль по ID.
Получается что у меня есть Candidate с ID = 1 и HeadHunter с ID = 1. И им обоим ставится какая-то роль.
Аноним 15/03/19 Птн 00:18:15 #44 №193001236 
Бамп
Аноним 15/03/19 Птн 00:23:39 #45 №193001445 
Бамп
comments powered by Disqus

Отзывы и предложения