RS
И "founded" исправьте, глаз режет)
Size: a a a
2020 May 11
OD
Ruslan Stelmachenko
И "founded" исправьте, глаз режет)
+
AE
Подсветка атас, столько красного, как будто пол кода в ошибках
OD
Первый период объяви как
Второй так же, в качестве возвращаемого типа
public <T extends ....> ...(JpaRepository<T> ....
Второй так же, в качестве возвращаемого типа
TСпасибо, попробую
RK
Eugene Jesovile
При всем уважении к вашему опыту, сейчас другое время. И от того, что вы (как и я в свое время) хапнули много одной субстанции, не следует, что все остальные должны идти по этому же пути. Иначе смысл чатов действительно обнуляется. Спору нет, что угодно можно изучить самому. Есть доки, есть спеки, есть много километров написанного тестового кода. Только в чем тогда смысл всей коммуникации программистов?
Опять же математику тоже можно самому изучить. Есть учебники. Но мы все-таки почему-то приходим за этим в университет и зачем-то спрашиваем об этом преподавателей. Если бы мне так же отвечали мои преподаватели, я бы их, мягко говоря, не понял.
Опять же математику тоже можно самому изучить. Есть учебники. Но мы все-таки почему-то приходим за этим в университет и зачем-то спрашиваем об этом преподавателей. Если бы мне так же отвечали мои преподаватели, я бы их, мягко говоря, не понял.
Смысл коммуникации программистов - обмениваться набитыми шишками, а не пересказывать ленивым неофитам куски официальной документации
EJ
Смысл коммуникации программистов - обмениваться набитыми шишками, а не пересказывать ленивым неофитам куски официальной документации
А я-то, глупый, думал, что времена RTFM прошли. Ан нет. Токсик тот же самый. Времена идут, люди не меняются
RK
Eugene Jesovile
А я-то, глупый, думал, что времена RTFM прошли. Ан нет. Токсик тот же самый. Времена идут, люди не меняются
Времена rtfm никогда не пройдут, потому что fm даст знания намного более полные и последовательные, чем в сотый раз написанный на отъебись ответ
AE
Времена rtfm никогда не пройдут, потому что fm даст знания намного более полные и последовательные, чем в сотый раз написанный на отъебись ответ
ща будет "а ты не пиши на отъебись"
EJ
ща будет "а ты не пиши на отъебись"
А смысл? Я не пропагандист. Просто вот уже 5 лет в индустрии работаю, и суть та же самая. В мануалах и спеках все написано. И я либо задаю вопрос, на который никто не знает и не может знать ответа (потому что "Зависит от твоего окружения\кода\e.t.c") , либо мне опять же прилетает rtfm. Смысл тогда спрашивать вообще что-то? Чтобы какой-то там крутой-мега-сеньор оценил мой вопрос и решил, стоит ли на него отвечать или нет? Каждый раз вижу это и каждый раз понимаю, что если хочешь что-то узнать, проще действительно закинуться спеками и мануалами.
AE
Eugene Jesovile
А смысл? Я не пропагандист. Просто вот уже 5 лет в индустрии работаю, и суть та же самая. В мануалах и спеках все написано. И я либо задаю вопрос, на который никто не знает и не может знать ответа (потому что "Зависит от твоего окружения\кода\e.t.c") , либо мне опять же прилетает rtfm. Смысл тогда спрашивать вообще что-то? Чтобы какой-то там крутой-мега-сеньор оценил мой вопрос и решил, стоит ли на него отвечать или нет? Каждый раз вижу это и каждый раз понимаю, что если хочешь что-то узнать, проще действительно закинуться спеками и мануалами.
если ответа на вопрос реально нет, задача сложная, новые технологии, тогда да, можно спросить совета
Ar
если ответа на вопрос реально нет, задача сложная, новые технологии, тогда да, можно спросить совета
а может проще и вообще не отвечать на кажущийся глупым вопрос, нежели скатываться в стаковерфлоу?
возможна проблема флуда этим вопросом, но это так же можно решить через РО/баны за флуд
таким образом и время будет сэкономлено, и никто жаловаться не будет на RTFM
возможна проблема флуда этим вопросом, но это так же можно решить через РО/баны за флуд
таким образом и время будет сэкономлено, и никто жаловаться не будет на RTFM
EJ
Как вариант. Сэкономлю время админам
AE
а может проще и вообще не отвечать на кажущийся глупым вопрос, нежели скатываться в стаковерфлоу?
возможна проблема флуда этим вопросом, но это так же можно решить через РО/баны за флуд
таким образом и время будет сэкономлено, и никто жаловаться не будет на RTFM
возможна проблема флуда этим вопросом, но это так же можно решить через РО/баны за флуд
таким образом и время будет сэкономлено, и никто жаловаться не будет на RTFM
так я на банальщину и не отвечал, изначально не было понятно что у ТС проблема не конфигурцией, а с чтением мануалов
OD
У меня есть двусторонняя связь ManyToMany. При попытке получить любой из типов вхожу в рекурсию. Как можно сделать @JsonIgnore для поля только когда запрос не из конкретного контроллера? Или на уровне сервиса вырезать часть со списком если нужно?
РН
для этого используют дто
Д
У меня есть двусторонняя связь ManyToMany. При попытке получить любой из типов вхожу в рекурсию. Как можно сделать @JsonIgnore для поля только когда запрос не из конкретного контроллера? Или на уровне сервиса вырезать часть со списком если нужно?
я как только увидел имя класса хотел спросить, не путаетесь ли вы в коде, об этом последующий коммент. В чём смысл, есть модель бизнес логики - ей вы оперируете на уровне сервисов, есть физическая модель - то что хранится в БД, то что вы сохраняете/поулчаете из Repository/Dao/итд, есть модель представления - то что вы возвращаете на UI. Вот то что ыв получили из БД это физ модель, её надо смапить в бизнесовую, потом смапить в ответ для UI (можно пернебречь если это маппинг 1 к 1, но потом придёт кто-то и начнет туда добавлять поля тк они нужны на UI, а в бизнес сущности они этой не нужны, вообщем сами смотрите. Я бы вам рекоммендовал добавялть сущностям хранящиеся в БД префикс/суффикс чтобы в коде было яснее. Часто делают SomethingEntity например.
OD
Дмитрий
я как только увидел имя класса хотел спросить, не путаетесь ли вы в коде, об этом последующий коммент. В чём смысл, есть модель бизнес логики - ей вы оперируете на уровне сервисов, есть физическая модель - то что хранится в БД, то что вы сохраняете/поулчаете из Repository/Dao/итд, есть модель представления - то что вы возвращаете на UI. Вот то что ыв получили из БД это физ модель, её надо смапить в бизнесовую, потом смапить в ответ для UI (можно пернебречь если это маппинг 1 к 1, но потом придёт кто-то и начнет туда добавлять поля тк они нужны на UI, а в бизнес сущности они этой не нужны, вообщем сами смотрите. Я бы вам рекоммендовал добавялть сущностям хранящиеся в БД префикс/суффикс чтобы в коде было яснее. Часто делают SomethingEntity например.
Спасибо за информацию. Слышал и делал только DTO раньше, но "SomethingEntity" не видел.
Так как "проект" это лабораторка на сдать и забыть до послезавтра, то пока можно пренебречь. Но в будущем возможно действительно начну делать UI сущности для удобности подтягивания не через длинные цепочки.
Так как "проект" это лабораторка на сдать и забыть до послезавтра, то пока можно пренебречь. Но в будущем возможно действительно начну делать UI сущности для удобности подтягивания не через длинные цепочки.
Д
Спасибо за информацию. Слышал и делал только DTO раньше, но "SomethingEntity" не видел.
Так как "проект" это лабораторка на сдать и забыть до послезавтра, то пока можно пренебречь. Но в будущем возможно действительно начну делать UI сущности для удобности подтягивания не через длинные цепочки.
Так как "проект" это лабораторка на сдать и забыть до послезавтра, то пока можно пренебречь. Но в будущем возможно действительно начну делать UI сущности для удобности подтягивания не через длинные цепочки.
ну сейчас у вас будет проблема циклических зависимостей, пока маппинг не сделаете, есть либа mapstruct, маппинг 1 к 1 делается там элементарно
OD
