Компания Oracle сформировала новую ветку СУБД MySQL 9.1.0. Сборки MySQL Community Server 9.1.0 подготовлены для всех основных дистрибутивов Linux, FreeBSD, macOS и Windows. В рамках внедрённой в прошлом году новой модели формирования релизов, MySQL 9.1 отнесён к веткам "Innovation", к которым также будет отнесён следующий значительный релиз MySQL 9.2. Innovation-ветки рекомендованы для тех, кто хочет раньше получать доступ к новой функциональности, публикуются каждые 3 месяца и поддерживаются только до публикации следующего значительного релиза (например, после появления ветки 9.1 прекращена поддержка ветки 9.0). Летом следующего года планируют сформировать LTS-релиз, рекомендованный для внедрений, которым необходима предсказуемость и длительное сохранение неизменного поведения. Следом за LTS-веткой будет сформирована новая Innovation-ветка - MySQL 10.0...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62067
OpenID это очень интересно, а что там с LDAP в Community Server?
а ну да, OpenID тоже для версии за бабло.
>В написанных на JavaScript хранимых процедураха вирус для этой бд можно написать на яваскрипт?
манйнера какого нибудь.
> а вирус для этой бд можно написать на яваскрипт?Можете попробовать и первым рассказать.
да кому оно надо этот SSO в СУБД, много пользователей сидит в БД напрямую а не в фронте?как по мне самый бесполезный чендж в релизе
Ну не через phpmyadmin же.
Да дохрена: аналитики, тестировщики, разработчики. И всех нужно отдельным логином.
У нас помню даже поддержке давали доступ на чтение.
Если БД не дата-помойка тестовая, а бэк прода, то давать прямой доступ к базе вместо доступа к приложению - это идиотизм.Даже если надо получить что-то из базы за пределами бизнес логики, то за такую работу с данными отвечать должны несколько человек максимум (для среднего проекта), которые точно знают что делают, а не пускать туда бестолковых клерков.
А если это тестовая помойка, так и локально можно развернуть каждому кому надо, избежав side-effects от соседа при том же тестировании.
Чел, окей.
Где взять этих трех мартышек, что будут выкачивать селекты из какой-нибудь одной-двух табличек для целого отдела аналитики из 6-7 человек?
Или предлагаешь dba-шников на это подписывать? Так они сразу пошлют все это - и будут правы.
Мало того - эти три мартышки у тебя точно дамп всех данных не сохранят где-то у себя в корыстных целях?
Проще и надежнее загрантить селект по определенной табличке, с аудитом подобных запросов "на случай чего".
> Чел, окей.
> Где взять этих трех мартышек, что будут выкачивать селекты из какой-нибудь одной-двух
> табличек для целого отдела аналитики из 6-7 человек?
> Или предлагаешь dba-шников на это подписывать? Так они сразу пошлют все это
> - и будут правы.
> Мало того - эти три мартышки у тебя точно дамп всех данных
> не сохранят где-то у себя в корыстных целях?
> Проще и надежнее загрантить селект по определенной табличке, с аудитом подобных запросов
> "на случай чего".сделать морду и добавить логику работы с этими "одной-двух" табличками
ну и я не про мартышек писал, мартышкам как раз доступ в базу категорически запрещен, если ты прочитал внимательно мой пост
если нет бюджета на свои информационную систему, то точно есть на готовую с кастомизациями, а иначе это уже не бизнес, а банкрот, и уж точно не на таких рассчитывают в оракле
Т.е. вместо того чтобы использовать средства RBAC от СУБД мы сделаем свою IDEшку? Это нахрена, а главное зачем?
> Т.е. вместо того чтобы использовать средства RBAC от СУБД мы сделаем свою
> IDEшку? Это нахрена, а главное зачем?где ты там IDE увидел?
иногда полезно читать, а не сразу гундеть:
ведь написано было
> Если БД не дата-помойка тестовая, а бэк прода...
то да, хоть обмажься ролями или еще чем - это не является допустимым интерфейсом для взаимодействия неквалифицированного персонала
и ваши наколенники не могут быть весомым аргументом по определению
> много пользователей сидит в БД напрямую а не в фронте?Не поверите, но достаточно, чтобы заморочиться.
Причём доступы надо как давать, так и забирать.
Держу нашу БД на MySQL 5.7 и не вижу никакого смысла обновляться. Работает и не трожь, как говорится.
Там дыра.
Ни одной хранимой процедуры?
А много где они используются?
Там где их нельзя использовать почти не используются ;)
ну мы готовы и за бабло тоже, главное, что бы работало!
кстати, 1с с этим уже нативно работает?
если не работает, то такое гамно и за бесплатно не нужно.
Что значит "нативно" ? Она ж с ней, через клиента работает, так что ей пофик какая там версия самой БД.
Или ты про хранение самой конфигурации ? Тогда нет - не работает.
> Уязвимость может быть эксплуатирована удалённо
> без прохождения аутентификации.Зашибись!
> Проблема вызвана чтением данных из области вне выделенного буфера
Ha-ha. Classic.
> приводит к аварийному завершению
Ну подумаешь, база упала. Ничего страшного, дело то житейское (с)
Пнем админа, он подымет.> или утечке содержимого памяти в ответе
Даже лучше.
Всё как обычно
Дык в OpenSSL ашипка. (кстати был анонс её на опеннете)
Кто-то еще пользуется или все перешли на MariaDB ?
У MariaDB крайне нелепый логотип в виде мерзкого тюленя. Как-то всё естество инженера протестует, чтобы не то что ставить, а даже просто рассматривать данный продукт серьёзно.
Оценивать по логотипу — техническая безграмотность.
Ну, если даже нарисовать нормальный логотип в проекте не осилили... То это уже как бы намекает на качество проекта
Намекает что деньги потрачены на разработчика, а не дизайнера логотипов.
Мария сдулась, хотя очень форсили очередные фанатики. Прод (продолжающий развитие) у Оракла и в форк только криво копируют бездари, результат всего этого закономерен.
>Мария сдуласьМожно подробнее, а не свое имхо? Пруфца бы. Судя по поддержке и развитию, все там нормально. Не?
Сырое и глючное, в чём там поддержка и развитие? Разваливается постоянно у всех.
Кроме OpenID, остальное не выглядит как что-то, ради чего стоило бы создавать отдельную ветку. Обычное исправление багов и доработка функций.
Ну не скажи. Отключение триггеров на SELECT должно дать сильный прирост производительности. Почти как в старой MySQL где не было этих глупостей.
Есть проект работал на 5.6 с хранимками, триггерами и вьюшками. Хорошо так там логика домена утекла на базу, но всё для хорошей статистики. Так вот уже тогда на 5.7 не стали переходить из-за дороговизны процесса.
Стоит ли переходить с MyISAM на InnoDB?
Они про разное.
стоит, как минимум из-за того что появится row level lock, вместо table lock, при обновлении записи. ну и ничего вам не мешает запустить "ALTER TABLE table1 ENGINE = InnoDB;"
В этом весь удел Мю -- ей пользуются те, кто ни черта в ней не понимает. И это, как ни странно, нормально.
Одни неофиты повторяют бред других неофитов и так по кругу до полного выкристаллизовывания из этой массы новые евангелистов. И польётся новый золотой дождик всяких там микросервисов, солидов, саров и прочих чистых кодов.
"В написанных на JavaScript хранимых процедурах"
Вот он - дивный новый мир.
Хотя я уже вижу пару применений этому чуду чудному.
> Хотя я уже вижу пару применений этому чуду чудному.Так вперед, чего же вы упускаете такую возможность. Я бы с такой фантазией уже миллионером был и жил в Европе, но почему-то продолжаю клепать формочки за свои скромные 150к в Сибири.
Рублёвый миллионер - ну, есть такое, но это сейчас легко.
Жить в Европе - всерьёз в процессе, надоело, собираюсь отваливать. На этот раз всерьёз.
Формочки за 150 давно уже не клепаю, европейцы платят больше.
ещё open telemetry добавили