KorcarВсем привет. Хочет пойти по накатанной дорожке. Делаю вывод данных из БД в jsp. Иногда в этих данных встречаются null. Кто как их проверяет с заменой на какой-то дефолт? Или может лучше подмену делать в СУБД, тогда в jsp никаких проверок делать не нужно, а то ифами и процентами как-то всё грустно и некрасиво получается


зы: Вадя и Петя могу проходить мимо этого топа) особенно Вадя ... и особенно Петя))

null - это отсутствие данных или данные не определены - тут замена может быть только исходя из бизнес логики.

KorcarВсем привет. Хочет пойти по накатанной дорожке. Делаю вывод данных из БД в jsp. Иногда в этих данных встречаются null. Кто как их проверяет с заменой на какой-то дефолт? Или может лучше подмену делать в СУБД, тогда в jsp никаких проверок делать не нужно, а то ифами и процентами как-то всё грустно и некрасиво получается


зы: Вадя и Петя могу проходить мимо этого топа) особенно Вадя ... и особенно Петя))

в общем случае костыль будет в jsp странице через какой-нить

KorcarОзверин, это спринг?

это jstl
Подключи его к своей странице и делай что хочешь.

вадяKorcarправильно! никакого, поэтому мне хочется заменить при отображении, поэтому и задаю сей вопросец)
дак это проще и бысрее будет в запросе

можно и в запросе, но тут 2 подводных костыля:

1. использование специфичных для бд конструкций
2. из коробки по моему быстрее настроить сущности и объявить репозиторий, чем запросами там что-то делать.

KorcarPetro123пропущено...
учить JSTL
Ради замены нулов? это ж верх нелогичности) сделаю в субдхе. Ваде респект. потрудился в этот раз)

если у вас 2 версии приложения - одна для тестирования, а другая - продакшн и в этих версиях разные бд используются - уже такое себе удовольствие использовать специфичные команды для каждой из БД. Писать отдельный запрос просто для того, чтобы конвертить некие значение в другие значения - тоже логичного мало подразумевает.

Я опишу сущность
создам интерфейс репозитория
и на этом закончу работу с запросами к бд на примитивном уровне. Дальше - я уже буду сущность маппить на view, как это делает программисты в ООП языках, не страдать функциональщиной, которая используется только там, где узко или где долго.

А как вы планируете получать данные запросом?

вадя_Getleman_Так можно огромное количество данных перебирать/формировать, если нет стандарта, как в БД хранится.стандарт создаётся при создании таблицы, всё что нужно получается запросом, запрос выбирает и формирует данные так как удобно и нужно, для этого и существуют запросы.
к примеру дата хранится всегда в секундах с 1970года, а вывести можно в любом виде, для этого и существуют команды форматирования дат в любой субд.

безотносительно взгляда на то, для чего существуют запросы, ты приводишь пример работы с данными, которые не меняют своей сути, а лишь имеют разный формат. Противопоставить изменение формата замене одного значения другим - ну то такое себе сравнение.

вадяОзверинпродакшн и в этих версиях разные бд используютсяза такое надо голову сворачивать

в моей реальности надо сто раз подумать, прежде чем использовать специфичные для бд конструкции. А почему в юнит тестировании я не могу себе позволить in memory db?

Т.е. ты своим одним типа простым запросом меняешь меняешь сразу подход к тестированию, кроме очевидных минусов, а голову отварачивать надо не тебе ?:)

вадяОзверинбезотносительно взгляда на то, для чего существуют запросы, ты приводишь пример работы с данными, которые не меняют своей сути, а лишь имеют разный формат. Противопоставить изменение формата замене одного значения другим - ну то такое себе сравнение.запросы и существуют чтоб выбрать данные в нужном формате.

замена null на 0 - это не изменение формата данных, это замена одних данных другими (с) кэп

А теперь про неочевидные минусы - поддержка.
Итак, что-то случилось, человек лезет разбираться(не тот, который писал сей код).

В первом случае он видит явный костыль во view - там конвертируется null -> 0.
Во втором случае к нему приходит уже 0.

В первом случае, достаточно этого костыля, чтобы понять примерную бизнес логику, во втором случае, надо полезть внутрь, чтобы понять, откуда этот 0 приходит, если в базе null, допустим.

Да, примеры выдуманы, совпадения - случайны, но в первом случае программист не будет тратить свое время на неочевидные вещи.

вадяОзверинВ первом случае он видит явный костыль во view - там конвертируется null -> 0.
Во втором случае к нему приходит уже 0.ещё раз - не надо путать данные хранимые и данные выбранные

Я не путаю, я привел реальный пример поддержки приложения. Я не говорю, что в запросах нельзя что-то там менять на что-то, я говорю, что сами запросы к бд следует делать в ситуациях, когда их нельзя не сделать, либо когда запрос реально быстрее отработает, либо ты быстрее напишешь запрос, чем сущность+репозиторий. Причем настолько быстрее, что сможешь оценить время на поддержку этого запроса с маппингом его как-нибудь и где-нибудь.

вадяОзверинА теперь про неочевидные минусы - поддержка.
Итак, что-то случилось, человек лезет разбираться(не тот, который писал сей код).не надо допускать дилетантов - не будет проблем
ОзверинВ первом случае он видит явный костыль во view - там конвертируется null -> 0.
Во втором случае к нему приходит уже 0.для дилетантов всё будет не понятно

то есть если ты увидишь, что у тебя во view 0, а в другом view это же значение будет пустым, ты полезешь в бд - там будет ваще null - то ты не полезешь искать, где происходит конвертация данных?:) Я ж не говорю, что ты не найдешь, я говорю, что ты сделаешь лишнее телодвижение - абсолютно бессмысленное.

вадявсё зависит от владения субд.

вопрос вообще не во владении субд. Внимательно перечитай то, о чем я тебе пишу.