IG
Если это чисто readonly -> куда лучше иметь ОДНУ таблицу с полиморфным JSON.
Size: a a a
2020 September 17
D
согласен
D
а еще если ему не нравится паттерн выше, то лучше юзать entity manager
D
очевидно, репозитории определенным образом тебя ограничивают
D
хоть и дают готовый код
Д
почему возникла вообще задача на 50 таблиц внезапно делать? Раньше через jdbc?
Без разницы, что использовать, jdbc, jpa, data jpa. Задачу вот такое вот поставили
L
документация в сваггере
А можно пояснить? сваггер/json это ведь все уровнем выше, чем репы/сущности
D
А можно пояснить? сваггер/json это ведь все уровнем выше, чем репы/сущности
так ему потом это протащить наверх надо будет
D
и если он соблюдает иерархию наследования и имеет 1 точку входа - то очевидно возникает дискриминатор по которому надо определять что есть что)
L
так ему потом это протащить наверх надо будет
Задача не создавать руками 50 репозиториев. Про 50 контроллеров вроде речи не было (условно)
D
Задача не создавать руками 50 репозиториев. Про 50 контроллеров вроде речи не было (условно)
не юзай спринг дату
D
у тебя есть jdbcTemplate, entityManager
Д
Задача не создавать руками 50 репозиториев. Про 50 контроллеров вроде речи не было (условно)
Нет, будет один контроллер
IG
Map<String, String> findRowsByType(SomeType, Id)
D
я же говорил
IG
Давид
Нет, будет один контроллер
JDBC -> select * from <TABLE> where id = SOME_ID -> read ResultSet -> fill Map
IG
Ну а вообще — это всё глупости, так как если ты по одному endpoint будешь отдавать АБСОЛЮТНО РАЗНЫЕ объекты — это плохо кончиться. Нужен хоть ОБЩИЙ предок.
Д
Ну а вообще — это всё глупости, так как если ты по одному endpoint будешь отдавать АБСОЛЮТНО РАЗНЫЕ объекты — это плохо кончиться. Нужен хоть ОБЩИЙ предок.
Ок, сделаю
Д
Спасибо большое за помощь
D
Давид
Спасибо большое за помощь
у тебя старшие есть?