Pull to refresh

Comments 36

Интересный способ. А не проще ли после пересоздания процедуры заново выдать гранты? Тут надо только позаботиться чтобы никто не был забыт.
Проще, конечно, но тут два момента:

1. Есть ли гарантии, что мы не забудем раздать всем сестрам по серьгам всем нужным юзерам?
2. Критично ли, что какое-то время данная процедура будет недоступна части посетителей сайта?
Список грантов можно вытащить из тех же таблиц MySQL. А насчёт критичности — решать вам.
Список грантов вытащить можно.
Но только, если уже был сделан DROP процедуры, в этом списке этой процедуры не будет.
забрал список
переделал порцедуру
вернул список
Вы открываете мне глаза на программирование.
Забей, очень тяжелый день проведенный в борьбе с жопорезом.
На самом деле, просто год назад пользоволся самопальным утил-скриптом, который так и работал.
Кстати, не желаете перенести статьяю в блог mysql?
В постгресе тоже не всё хорошо.
Особенно, в части работы с перлом.
Поработайте с ораклом из перла :)
UFO landed and left these words here
А что, в Оракле всё еще хуже? :)
А что не так с DBD::Oracle?
Мало приятный интерфейс.

p.s. имхо
Приятнее, чем интерфейсы для мускула и постгреса.
Нормальная работа с курсорами, анонимными блоками и так далее.
может, у вас другие задачи и другие данные, но мне с постгресом намного удобнее работать, чем с mysql хотя бы даже из perl.

чтобы не быть голословным — простите, но что мешало разработчикам mysql написать нормальный парсер sql, который бы не требовал чудовищных

delimiter $$$

без которых очень сложно представить себе триггеры и хранимые процедуры.

или, допустим кодировку клиента. почему–то нельзя было сделать это менее мудацким образом, чем set names или DBI:mysql:database=db;mysql_read_default_group=perl;mysql_read_default_file={$root}/etc/my.cnf

а давайте еще посмотрим на то, что происходит с dbh после возникновения ошибки в mysql…

не буду холиварить, но как–то немного необъективно
К разработчикам Мускула у меня много вопросов.
Сравнивая одни и те же вещи в разных СУБД, очень заметно как сильно уступает Мускул Постгресу и Ораклу.
Почти для каждой задачи можно использовать любую СУБД, некоторые задачи решаются проще и быстрее в одной, а в другой нет, но возможность использовать СУБД все равно остается.
А что вам не нравится в perl+pgsql?
Уебищная работа с курсорами, например.
Нужно радоваться, что они вообще реализованы :)
Ну если брать для сравнения мускул, то да, нужно радоваться успехам постгреса.
Хотя фраза «Although PostgreSQL supports cursors, they have not been used in the current implementation» не обещает легкой жизни.
UFO landed and left these words here
я стараюсь не использовать хранимые процедуры вабще. Возможно просто я не сталкивался с проблемой, где они бы стали решением.
А что используете, если не секрет? Параметризованные запросы?
Не хочу холивара, но все же, почему не попробовать перейти на PGSQL? Меня долго заставляли, но после переезда, я теперь проекты на MySQL больше не пишу. Я понимаю, конечно, если проект существует несколько лет и сложно перевести его на другую СУБД, но ведь «Все в трауре, миллионные потери, разработчики проекта уволены, занавес.» — не пара ли?
CREATE OR REPLACE… вам в помощь.
Хотя есть свои нюансы, конечно.
Для грамотных — пардон, «пара» — ошибка, «но после переезда, я теперь» — здесь запятая не нужна. Нетрезв, дико извиняюсь.
Не переживайте за нас, никого не уволили.
Эти подробности исключительно художественный вымысел ;)
А базы самые разные, как и задачи.
Плюсы и минусы есть в каждой СУБД, какую не выбери.

Странные люди. Топик про то, как в MySQL сделать то-то и то-то. Набегает толпа народа с воплями «А Postgres лучше!», «А IBM DB/2 наше всё!». Кого ебёт ваше всё? Имеем топик про MySQL — спасибо, интересно, прочла. Мнение тех, кто пишет на Paradox как-то не в кассу, собственно.
Ну, лирические отступления тоже не помешают ) Мне лично интересно, в какой СУБД удобнее использовать такие вещи, например, как хранимки. Хотя, холиварные крики — «А Postgres лучше!» — бессмысленны, тут я согласен.
Если вкратце, то в Оракле.
Подробнее может напишу позже. Как раз недавно сравнивал Мускул, Постгресс и Оракл.
Резюме: два хака для поддержки тривиальной функциональности. Знаете, что и в каких выражениях скажет о Вас человек, который будет поддерживать всё это через пол года? :)

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

Я не работал со stored procedures и не особо заморачивался правами юзеров, так что могу сильно промахнуться, но вот несколько вариантов навскидку:
  • — вместо выставления прав доступа к процедурам выставить их на таблицы/колонки в базе (ведь на самом деле именно данные а не код требуется защищать)
  • — подумать, может вообще не стоит разделять права пользователей A и B, а вместо этого ввести некую роль (аккаунт R), которым будут пользоваться оба пользователя
  • — если уж использовать эти хаки, то хотя бы автоматизировать их применение — повесить какой-нить триггер который при создании юзером A процедуры X' будет автоматически копировать её код поверх кода процедуры X (вызываемую юзером B) в таблице proc и делать ALTER
  • — сделать две процедуры — X и X', при этом процедура X' будет реальным кодом, а X обёрткой вокруг неё (если stored procedures умеют вызывать друг друга :)); тогда юзер A будет менять (через DROP/CREATE) процедуру X', а юзер B запускать не меняющуюсь процедуру X

В общем, подробности реализации могут быть самые разные, это уж Вам виднее, как лучше это сделать. Но любой другой вариант будет лучше этих хаков, IMHO.
Знаете, что и в каких выражениях скажет о Вас человек, который будет поддерживать всё это через пол года?

А знаете, что скажет ему менеджер, когда программист потеряет гранты на какие-то процедуры, используемые в 24x7 проекте?

Может стоит поискать другие подходы к решению этой проблемы?

Буду только рад, если кто-то мне подскажет эти подходы. Серьёзно.
К сожалению, изучение документации особо не помогло.

А ещё лучше — что-то изменить в рабочем процессе, чтобы эта проблема даже не возникала.
Если требование рабочего процесса — использование хранимых процедур, как прикажете его изменить?

Я не работал со stored procedures и не особо заморачивался правами юзеров

Пастернака не читал, но осуждаю. ©
Дальше могли бы не продолжать в таком случае.

вместо выставления прав доступа к процедурам выставить их на таблицы/колонки

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

подумать, может вообще не стоит разделять права пользователей A и B, а вместо этого ввести некую роль (аккаунт R), которым будут пользоваться оба пользователя

Какая разница? Имеем то же самое.

если уж использовать эти хаки, то хотя бы автоматизировать их применение

А кто сказал, что автоматизация не используется?
Автоматизация описанного не относилась к теме данной статьи.

сделать две процедуры

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

В общем, как я писал выше — могли бы не продолжать, если не занимались предметной областью.

подробности реализации могут быть самые разные

Пока я не услышал ни одного конструктивного предложения, кроме банального — автоматизации описанного мной процесса.

Но любой другой вариант будет лучше этих хаков

К сожалению, пока я не знаю ни одного нормального варианта в рамках MySQL, который бы помогал избежать хака. Был бы — я бы только радовался, поскольку не пришлось бы изобретать эти хаки.
Описанный хак — он от бессилия перед немощью Мускула.
Only those users with full accounts are able to leave comments. Log in, please.