Стек оверфлоу не пашет 🙂
Ну, я такое видел в коде. Наверное, от задачи зависит.
А в чем проблема возвращать boolean для условного existsBy...?
Ну не знаю. Я не работал с jpa. Но как по мне лучше с базы взять количество и в сервисе уже делать проверки. Потом это количество может пригодится для чего нибудь другого
А может и не пригодится….
Есть такое. Но что то меня передергивает когда вижу всякие условия в репозитории, а не сервисе. Какая то интуиция что ли ) Не могу это объяснить
Добро пожаловать во взрослый мир
До тех пор, пока это не требуется, я бы предпочел читать код, который более явно выражает желание разработчика - проверить, что что-то существует. И в коде читаю то же самое - if (userRepo.existsByUsername(...)). Мне требуется меньше времени, чтобы понять смысл этой проверки, нежели if (userRepo.countByUsername(...) > 0) При этом если действительно такая проверка в одном месте, а во всех остальных требуется количество - возможно, имеет смысл сделать единообразно на основании количества (но, пожалуй, в любом случае я бы так сделал только если запрос действительно нетривиальный)
Надо заводить мета-таблицу с названием _boolean с двумя значениями: (id=1,value=true) и (id=2,value=true). В existsBy надо писать джоин на эту таблицу и возвращать BooleanEntity
Я, может, что-то забыл, но мне казалось, что и без такой наркомании работать будет
какие проверки в репозитории? можно показать? если ты про existsBy и прочие булевы, то почему тебя они смущают, если они уже вшиты в хибернет?
Да я уже вроде все расписал. И я не работал с hibernate
Да я прикалываюсь просто) тип, раз boolean якобы нельзя возвращать, то надо BooleanEntity тогда
Пригодится - делай, не пригодится - оставь буль
Это как бы нормально, база условие посчитает быстрее на данные, чем их вытащит, передаст тебе, ты из примешь, распарсишь, обработаешь, посчитаешь...
Обсуждают сегодня