ТС это "топик стартер" = то есть тот с кого началось обсуждение в ветке. И от него была постановка что ошибка и на уровне валидатора и на уровне БД должны для клиента выглядить одинаково:
Ошибка конечно одна и та же.
Если на это требование забить, то тогда конвертировать ошибку ограничения уникальности со стороны БД уже будет не нужно и тогда да, нужен отдельный валидатор чтобы показывать клиенту внятное сообщение вместо не внятной ошибки БД. Но в рамках этой ветки обсуждается концепция того что и даже в случае ошибки уже на уровне БД, клиент бы всё равно увидел ответ такой же как если бы отработал просто валидатор.
Только они на эти саммиты специально собираются, а не просто приходят всей толпой в одно место чтобы заниматься чем-то отличным от "саммитов и переговоров", чтобы эти самые "саммиты и переговоры" выполнялись просто из-за того что они находятся в одном месте?
Хотите переговоров - не заглядывайте через плечо, а организуйте собрание на которое все придут подготовленными.
А мне от рабочего места в первую очередь требуется большой монитор и полноценная клава и мышь, а не ноутовые обрезки - куда это всё ставить в будку? Ну а ногу за ногу в телефончик я повтыкать могу и в будке, конечно.
Всё описанное будет в любом случае так как ошибка уникальности на стороне БД всё равно вероятна и её всё равно нужно конвертировать в сообщение идентичное сообщению от валидатора (это не моё желание - так описал задачу ТС).
А вот кода валидатора на уникальность - не будет. Как и тестов к нему.
И в итоге если убрать валидатор, то ничего не измениться с точки зрения клиента, только будет на один запрос к БД меньше и в принципе кода меньше. А в чём профит от того что валидатор на уникальный email есть?
Поддерживаю @breninsul - без проверки уникальности на стороне БД будет шляпа так как параллельные запросы на создание могут оба увидеть что такого значения ещё нет в БД и оба перейти к этапу записи - уникальность на уровне БД обеспечивается средствами БД.
Я вот переезжал недавно с Xiaomi Mi6 на OnePlus 9R 5G и процесс вышел совсем не таким уж и удобным как мне бы хотелось:
СМС: я смог забэкапить сторонней софтиной, но не смотря на её заверения об успешном их восстановлении, их не видно в стандартном приложении
Историю звонков перенес сторонней софтиной
Часть старых приложений просто отсутствует
Часть старых приложений сменили имя и владельца
Часть старых приложений есть только на альтернативных сторах
Часть старых приложений потеряли в функциональности: например ClockSync раньше мог сам время на телефоне подстраивать, а сейчас у него на это просто нет прав и с одной стороны как бы "и нечего кому попало разрешать менять системное время", а с другой стороны почему-бы не вынести это в отдельное право, которое я мог бы ему выдать?
Многие приложения просто не имеют своего облачного хранилища для настроек и не поддерживают Гугловое
Даже там где есть возможность "просто залогиниться" всё равно нужно доводить до привычных разные локальные настройки
Всякое кастомное всё равно не переехало, например записи звонков: лежали просто файлами - бери и сам их переноси, а ещё раньше можно было включить автоматическую запись всех звонков и без предупреждения, а сейчас только с предупреждением и только руками - а это, внезапно, отпугивает звонящих, даже если звонят действительно с компании и есть запись звонка с их стороны
Для меня переезд на новый телефон - это стресс. Сравнимый со сменой места проживания в пределах города - вроде всё знакомое, но всё равно другое и кучу всего нужно с собой везти, а что-то потеряется.
Пример по генерации Java кода странный - да, на выходе получился Java-код, но ведь он бесполезен чуть менее чем полностью - смысл конфигурации в том что её можно изменить, а приложение её прочитает и будет использовать измененные значения, а в сгенерированном коде просто набор констант.
Триггеров не видно, хотя хранимки есть. Про планы на JSONуже ответили, но судя по этому ответу XML даже не в планах. Про регулярки я в доке ничего не встрелил, как просто поиском, так и анализом доступных операторов сравнения.
Common Table Expressions (CTE) — это именованный временный результирующий набор, который существует в рамках одного оператора и на который можно ссылаться в последующих запросах в рамках этого оператора, возможно, несколько раз. Более подробное описание будет при ближайшем обновлении документа.
Рекурсивность упоминается рядом с CTE:
RECURSIVE WITH PUMP Получение очередной записи из результатов WITH в рамках исполнения WITH с рекурсией.
Про оконные функции там ничего нет - перечислены только скалярные и агрегатные. Термины XML и JSON так же не встречаются.
Лучшее что я нашёл в документации по этому поводу:
Целевой стандарт языка SQL: Система разработана с опорой на стандарт ANSI SQL:2016
Но такое описание не гарантирует собственно реализацию ANSI SQL:2016, так как реализована может быть только часть этого стандарта или вовсе что-то только отдалённо на него похожее.
Превращать "хочу сидеть в офисе" в "хочу программировать" это тоже не правильно. Да и даже если человек сказал "хочу", то это всё равно ничего не стоит до тех пор пока он не начнёт реализовывать это "хочу".
Мы же статью обсуждаем, да? Для начала тут автор статьи не приводил цитат про их намеренья, зато есть вот это:
Говорил, что его вдохновляет моя история, и он тоже хотел бы сидеть в офисе, а не горбатиться на бетонном заводе.
Где тут "пожалуйста, научи меня программировать"?
Начитался моих постов в соцсетях и решил, что хочет стать программистом.
Тут нет цитаты ученика, а только интепрететация его намерений со стороны автора.
Мама так красочно рассказывала про меня подруге, что та решила подсобить дочери за мой счёт. Понимая ситуацию, я не хотел браться, но мама настоятельно попросила. Мы списались с этой девушкой, она пребывала в диком восторге.
Про восторг написано, да, а вот про то что она реально планировала этим заниматься, а не действовала под давлением своей матери - нет.
ТС это "топик стартер" = то есть тот с кого началось обсуждение в ветке.
И от него была постановка что ошибка и на уровне валидатора и на уровне БД должны для клиента выглядить одинаково:
Если на это требование забить, то тогда конвертировать ошибку ограничения уникальности со стороны БД уже будет не нужно и тогда да, нужен отдельный валидатор чтобы показывать клиенту внятное сообщение вместо не внятной ошибки БД.
Но в рамках этой ветки обсуждается концепция того что и даже в случае ошибки уже на уровне БД, клиент бы всё равно увидел ответ такой же как если бы отработал просто валидатор.
Ну если обсуждаеть совершенно не то что изначально постулировалось ТС, то конечно можно получить другой вывод :)
Можно и так, то вот по рукам будут бить клиентов - пришёл создать пользователя, а получил невнятную ошибку от БД.
Только они на эти саммиты специально собираются, а не просто приходят всей толпой в одно место чтобы заниматься чем-то отличным от "саммитов и переговоров", чтобы эти самые "саммиты и переговоры" выполнялись просто из-за того что они находятся в одном месте?
Хотите переговоров - не заглядывайте через плечо, а организуйте собрание на которое все придут подготовленными.
А мне от рабочего места в первую очередь требуется большой монитор и полноценная клава и мышь, а не ноутовые обрезки - куда это всё ставить в будку?
Ну а ногу за ногу в телефончик я повтыкать могу и в будке, конечно.
Валидатор на уникальность - должен проверять только на уникальность.
Валидация формата - задача отдельного валидатора, который никак не связан с уникальностью.
Всё описанное будет в любом случае так как ошибка уникальности на стороне БД всё равно вероятна и её всё равно нужно конвертировать в сообщение идентичное сообщению от валидатора (это не моё желание - так описал задачу ТС).
А вот кода валидатора на уникальность - не будет.
Как и тестов к нему.
И в итоге если убрать валидатор, то ничего не измениться с точки зрения клиента, только будет на один запрос к БД меньше и в принципе кода меньше.
А в чём профит от того что валидатор на уникальный
emailесть?Поддерживаю @breninsul - без проверки уникальности на стороне БД будет шляпа так как параллельные запросы на создание могут оба увидеть что такого значения ещё нет в БД и оба перейти к этапу записи - уникальность на уровне БД обеспечивается средствами БД.
Я вот переезжал недавно с
Xiaomi Mi6наOnePlus 9R 5Gи процесс вышел совсем не таким уж и удобным как мне бы хотелось:СМС: я смог забэкапить сторонней софтиной, но не смотря на её заверения об успешном их восстановлении, их не видно в стандартном приложении
Историю звонков перенес сторонней софтиной
Часть старых приложений просто отсутствует
Часть старых приложений сменили имя и владельца
Часть старых приложений есть только на альтернативных сторах
Часть старых приложений потеряли в функциональности: например ClockSync раньше мог сам время на телефоне подстраивать, а сейчас у него на это просто нет прав и с одной стороны как бы "и нечего кому попало разрешать менять системное время", а с другой стороны почему-бы не вынести это в отдельное право, которое я мог бы ему выдать?
Многие приложения просто не имеют своего облачного хранилища для настроек и не поддерживают Гугловое
Даже там где есть возможность "просто залогиниться" всё равно нужно доводить до привычных разные локальные настройки
Всякое кастомное всё равно не переехало, например записи звонков: лежали просто файлами - бери и сам их переноси, а ещё раньше можно было включить автоматическую запись всех звонков и без предупреждения, а сейчас только с предупреждением и только руками - а это, внезапно, отпугивает звонящих, даже если звонят действительно с компании и есть запись звонка с их стороны
Для меня переезд на новый телефон - это стресс. Сравнимый со сменой места проживания в пределах города - вроде всё знакомое, но всё равно другое и кучу всего нужно с собой везти, а что-то потеряется.
Пример по генерации
Javaкода странный - да, на выходе получилсяJava-код, но ведь он бесполезен чуть менее чем полностью - смысл конфигурации в том что её можно изменить, а приложение её прочитает и будет использовать измененные значения, а в сгенерированном коде просто набор констант.Триггеров не видно, хотя хранимки есть.
Про планы на
JSONуже ответили, но судя по этому ответуXMLдаже не в планах.Про регулярки я в доке ничего не встрелил, как просто поиском, так и анализом доступных операторов сравнения.
Про
CTEв документации есть параграф:Рекурсивность упоминается рядом с
CTE:Про оконные функции там ничего нет - перечислены только скалярные и агрегатные.
Термины
XMLиJSONтак же не встречаются.А какая часть стандарта
SQL:99реализована?Ну или что не реализовано?
Лучшее что я нашёл в документации по этому поводу:
Но такое описание не гарантирует собственно реализацию
ANSI SQL:2016, так как реализована может быть только часть этого стандарта или вовсе что-то только отдалённо на него похожее.А есть планы на поддержку неблокирующей спецификации R2DBC?
Это из мира
Java, альтернатива блокирующемуJDBC.Из документации:
А есть планы на размещение
JDBC-драйверов в публичныхMaven-репозиториях?P.S.
Ну и у вас опечатка в документации - раздел про
JDBC-драйвер, а в тексте пишут проODBC-драйвер.А что с таймзонами?
Есть типы данных для их учёта? И как этот учёт реализован?
Превращать "хочу сидеть в офисе" в "хочу программировать" это тоже не правильно.
Да и даже если человек сказал "хочу", то это всё равно ничего не стоит до тех пор пока он не начнёт реализовывать это "хочу".
А вот этого не знал, спасибо за информацию.
Мы же статью обсуждаем, да?
Для начала тут автор статьи не приводил цитат про их намеренья, зато есть вот это:
Где тут "пожалуйста, научи меня программировать"?
Тут нет цитаты ученика, а только интепрететация его намерений со стороны автора.
Про восторг написано, да, а вот про то что она реально планировала этим заниматься, а не действовала под давлением своей матери - нет.