Многократное распухание базы данных из-за UCM (Unified Content Model — версии контента в Joomla 3.x) - Joomla 3.x: Установка, обновление и настройка

Поискав по форуму, я с удивлением для себя обнаружил, что эта тема еще не обсуждалась.
А ведь серьезная тема — в Joomla (начиная с версии 3.2) появился функционал, позволяющий хранить историю изменения статей (как в wiki) и при желании откатываться на более ранние версии.

Потенциально возможность интересная, только вот на практике (во всяком случае для меня) она вылилась проблемой.
Узнал я об этой великой возможности после того, как на одном из сайтов база данных вдруг начала раздуваться до неимоверных размеров.
Почему?
Да потому, что:
Во-первых, по умолчанию сохраняются последние 10 версий статьи, что довольно-таки немало.
Во-вторых, сами статьи в БД хранятся как положено в кириллице, а вот сохраненные версии почему-то хранятся в кодах Unicode (типа «\u0440\u0435\u043c\u043e\u043d\u0442» вместо шестибуквенного слова). Итого база распухает еще в 6-7 раз.

Я не разбирался в механизме, но если все версии контента хранятся целиком, то получаем увеличение БД в 60-70 (!) раз. Даже если данные сохраняются не полностью, распухание все равно будет очень существенным. Например, в моем случае таблица _ucm_history занимает около 95% от общего объема БД, и это при том, что сайт новый и статьи после создания почти не редактировались.

На большинстве моих сайтов версионность в принципе не нужна, и думаю, что не один я такой.
Версионность контента легко можно отключить в настройках материалов на вкладке «Форма редактирования» (Сохранять историю -> Нет).
Но вот вопрос — как корректно поудалять уже существующую сохраненную историю изменения статей?
Странно, но в настройках возможности пакетной чистки не предусмотрено (или я плохо искал), а удалять вручную версии в каждой статье — слишком долго и напоминает мартышкин труд.
Можно ли просто удалить таблицы «_ucm_base», «_ucm_content», «_ucm_history»? Или есть более корректный способ очистки?

Насчет пакетной очистки не знаю, но вот удалять таблицы «_ucm_base», «_ucm_content», «_ucm_history» нельзя. А вот очистить данные из них по моему можно.

«По моему» — звучит как-то неуверенно
Пускай не удалять таблицы целиком, пускай почистить — могу ли я это сделать безболезненно, не опасаясь за стабильность работы сайта?

P.S.: Ручная очистка таблиц — странный способ обслуживания современной дружественной CMS. Также сомневаюсь, что меня одного смущает увеличение базы в 60-70 раз на пустом месте. Видимо, Joomla 3.2 пока еще слишком свежа и мало людей успели ей попользоваться или заметить эту чудесную особенность. Надеюсь, эти недостатки со временем будут устранены.

Конечно неуверенно, потому что я не пользуюсь версионностью... Попробуй задать фопрос на forum.joomla.org.

Хорошо, попробую.
А версионностью я тоже не пользуюсь. Только у меня об этом не спросили, в Joomla 3.2 она активирована по дефолту. Тоже странно кстати, могли бы по умолчанию оставить эту опцию неактивной.

Вот это уже хороший вопрос. Можно поднять бучу на том же org, чтобы по дефу была отключена, раз она так базу сжирает.

Все таки нашёл этот параметр. Компоненты-Метки-Настройки. Каким боком управление версиями попало в раздел Метки.
А нет, это относится к меткам, а материалы в Менеджере материалов - Настройки - Форма редактирования

Вот это уже хороший вопрос. Можно поднять бучу на том же org, чтобы по дефу была отключена, раз она так базу сжирает.

Не надо буч, хорошая фича именно для многих новичков.
Я еще в 2.5 через плагин юзал.

Очистить таблицы можно безболезненно, но только после отключения версионности, хотя они сами при этом очиститься должны.
Непонятно, чем именно полезна эта фишка именно новичкам.

И кстати, хорошую русскую доку по таблицам J где можно почитать?

И кстати, хорошую русскую доку по таблицам J где можно почитать?

Вот и мне интересно... Давно ищу.

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

Очистить таблицы можно безболезненно, но только после отключения версионности, хотя они сами при этом очиститься должны.

Подскажите почему после отключения, таблица _ucm_history так и не очистилась?
Если выполнить вручную очистку, то на сколько это безопасно?

Так вроде проще чем через php.

Очистить таблицы можно безболезненно, но только после отключения версионности, хотя они сами при этом очиститься должны.

Это проверенная информация (таблицы чистятся после отключения параметра) или все же руками нужно очищать таблицу?

Так вроде проще чем через php.

Во-первых, не php, а MySQL, а во-вторых:

Странно, но в настройках возможности пакетной чистки не предусмотрено (или я плохо искал), а удалять вручную версии в каждой статье — слишком долго и напоминает мартышкин труд.

Это проверенная информация (таблицы чистятся после отключения параметра) или все же руками нужно очищать таблицу?

Сами таблицы не чистятся. После отключения функции, очистил вручную. Пока проблем не наблюдаю.

А как отключить версионность?

А как отключить версионность?

В менеджере материалов - > Настройки - > вкладка Форма редактирование -> Сохранять историю -> Нет

Во-вторых, сами статьи в БД хранятся как положено в кириллице, а вот сохраненные версии почему-то хранятся в кодах Unicode (типа «\u0440\u0435\u043c\u043e\u043d\u0442» вместо шестибуквенного слова). Итого база распухает еще в 6-7 раз.

Фантастический тип хранения. Кроме того чищу таблицу assets: http://joomlaforum.ru/index.php/topic,330897.msg1669897.html#msg1669897
В которую пишутся права доступа к каждому материалу, даже если вы их не задаёте, они при сохранении материала пишутся туда и тормозят.
Таблицы - это оперативка.

Кроме того, сохраните любой материал и гляньте в таблицу content:
Столбец images, что там в каждой строке?

Аналогично столбец urls, что там:

Аналогично столбец attribs:

Аналогично в metadata:

На кой чёрт пустые названия настроек писать в каждый материал, если в материале нет прикреплённых картинок, нет прикреплённых url, они отключены в настройках, и так-же нет каких-то доп атрибутов? Кто придумал такой тип хранения? Столбцы уже отменили, дополнительные таблицы уже отменили? Почисти всё это и таблица content начинает весить до двух(!) раз меньше.

Очень надеюсь с кастомными полями в Joomla 3.7 не выдумают что-то в том-же духе.

Слава Богу, что заметил этот беспридел по 40 мб в базе на 8 сайтах.

Фантастический тип хранения

это точно. теоретически спасло бы использование JSON_UNESCAPED_UNICODE, но он появился только в php 5.4, а J3 требования 5.3.10 минимальная. хотя могли бы и проверку сделать...

А подскажите как автоматически, через MySQL запрос очистить _ucm_history, а то там столько информации, что вручную просто жесть удалять.

Вроде бы так: