PostgreSQL: сообщения об ошибках

[Rikland]

Добрый день! 

Есть СУБД PostgreSQL и планируется приложение, суть которого - ведение БД: от простых справочников из 2-3 полей до сложных составных таблиц, на основании которых генерятся многостраничные отчеты. Сейчас как раз проектирую архитектуру, хочется сделать все красиво.
Необходимо правильно сообщать пользователю о возникших ошибках, каким образом это лучше всего организовать? Правильно - это понятным пользователю языком, а не:

Код

SQL
ERROR: NULL value IN COLUMN "column_name" violates not-NULL constraint

psql-драйвер, к сожалению, не возвращает коды ошибок. Я вижу два варианта.
1) Изменять данные в таблицах не напрямую (INSERT table ...), а с помощью хранимых процедур, в которых генерить исключение в случае ошибки с "красивым" текстом.
2) Парсить пришедший текст ошибки, на основании ключевых слов строить правильный текст, который и показывать пользователю.
В первом случае получается много-много функций в БД, второй - не очень надежен, т.к. текст может и измениться, со сменой версии СУБД, например.

Помогите определиться! Или, может, есть способы лучше? Как вы решаете такие задачи?

[Пантер]

Через хранимки достаточно удобно работать. У меня на текущей работе в проекте все делается через хранимки, а таблицы спрятаны в приватной схеме. Все красиво и удобно.

[torwig]

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

[GraninDm]

psql-драйвер, к сожалению, не возвращает коды ошибок.

Добрый день!
Вообще, вот тут про ошибки
http://www.prog.org.ru/index.php?topic=22903.msg162092#msg162092
Исправленный драйвер для 5.3 в архиве

[Rikland]

Через хранимки достаточно удобно работать. У меня на текущей работе в проекте все делается через хранимки, а таблицы спрятаны в приватной схеме. Все красиво и удобно.

Я правильно понимаю, что для каждой таблицы должно быть создано как минимум 3 хранимки - на добавление новой записи, на редактирование и на удаление? Не получается ли изобилие хранимок в таком случае?

[Rikland]

Первый вариант определенно лучше для внятных сообщений об ошибках. Тем более в этом случае все будет на сервере БД

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

[Rikland]

Исправленный драйвер для 5.3 в архиве

Вот править драйвер мне кажется не очень хорошим и "правильным" делом. Или я не прав?

[Пантер]

Через хранимки достаточно удобно работать. У меня на текущей работе в проекте все делается через хранимки, а таблицы спрятаны в приватной схеме. Все красиво и удобно.

Я правильно понимаю, что для каждой таблицы должно быть создано как минимум 3 хранимки - на добавление новой записи, на редактирование и на удаление? Не получается ли изобилие хранимок в таком случае?

У нас данные,в основном, добавляются сразу в несколько таблиц.

[Old]

Необходимо правильно сообщать пользователю о возникших ошибках, каким образом это лучше всего организовать?

Может лучше не допускать подобных ошибок.
На уровне UI контролировать заполнение обязательных полей и не давать завершать редактирование, пока пользователь их не введет.

[GraninDm]

Исправленный драйвер для 5.3 в архиве

Вот править драйвер мне кажется не очень хорошим и "правильным" делом. Или я не прав?

Можете посмотреть diff от оригинала. Ничего существенного там не добавлено.
Драйвер тоже люди писали. И там тоже могут быть ошибки и отсутствовать некий нужный функционал.
В багтрекер qt этот код просили добавить, но это там никому не нужно.
Я себе драйвер компилирую сам и им пользуюсь. Проблем нет.
А так... каждый для себя решает сам.

Вот код который я первоначально использовал.
http://www.dfndr.pp.ua/qt4-qpsql-%D0%B4%D1%80%D0%B0%D0%B9%D0%B2%D0%B5%D1%80-%D0%BA%D0%BE%D0%B4%D1%8B-%D0%BE%D1%88%D0%B8%D0%B1%D0%BE%D0%BA.html
Вот еще об этой же проблеме.
http://www.qtcentre.org/threads/17495-patch-QPSQL-set-an-error-code-so-QSqlError-number()-gives-a-useful-value

[Rikland]

Может лучше не допускать подобных ошибок.
На уровне UI контролировать заполнение обязательных полей и не давать завершать редактирование, пока пользователь их не введет.

Заполнение обязательных полей контролировать - это да. А вот что делать с попыткой удалить запись, на которую есть ссылки в других таблицах? Это уже не проконтролируешь, это только получать сообщение от БД, что нельзя удалять эту строку...

[Rikland]

Можете посмотреть diff от оригинала. Ничего существенного там не добавлено.

Спасибо за ссылки, изучу. Я все варианты рассматриваю

[Old]

Заполнение обязательных полей контролировать - это да. А вот что делать с попыткой удалить запись, на которую есть ссылки в других таблицах? Это уже не проконтролируешь, это только получать сообщение от БД, что нельзя удалять эту строку...

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

[Rikland]

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

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

И второй момент: если запись удалить хочется, а кнопка заблокирована - то как пользователю понять, почему именно она заблокирована? Мало ли, может, он таблицы чистит от устаревших данных, а тут удалять не дают и почему - не говорят...

[PimenS]

С другой стороны - вот пользователь только открыл справочник/таблицу "на посмотреть", он и не собирался ничего делать, а программа уже выполняет множество запросов-проверок "а можно ли удалить", "а можно ли изменить", "а что еще можно". В результате из-за проверок увеличивается время на загрузку данных и негодование пользователя.

И второй момент: если запись удалить хочется, а кнопка заблокирована - то как пользователю понять, почему именно она заблокирована? Мало ли, может, он таблицы чистит от устаревших данных, а тут удалять не дают и почему - не говорят...

Делай проверки не при открытии, а при выполнении пользователем определенных действий: попытке удаления, попытке изменения.