ноября 09 2015
0

Два сайта с общими таблицами пользователей

ieasyweb    9 ноября 2015, 15:16    в избранное в избранном    23 комментариев
Вопросы, проблемы и их решения   
Путём манипуляций с конфигами удалось частично решить вопрос по сабжу. Но толку от этого ноль, т.к. на double-сайте юзер не может создать блог или топик: ошибки, указывающие на FOREIGN KEY и ссылающиеся на различные мапперы не дают.
В соответствующих местах конфигов второго сайта добавил
$config['db']['table']['prefix_double'] = 'double_';, заменил пользовательскую на $config['db']['table']['user'] = '___db.table.prefix_double___user';,
а так же таблицы полей пользователей и сессий (чтоб не разлогинивались при переходе).
Что ещё нужно наколдовать, чтоб избежать полной зависимости от основной БД (контент основного сайта на дополнительном не нужен)?
Спасибо.
Теги:

Похожие статьи

  • MySQL replace serialized data (Замена сериализованных данных в MySQL)
    Когда-то мне понадобилось поковыряться в стерилизованных данных AltoCMS. В тот раз я набросал костыль в админку на php. Теперь, после перехода на https, опять столкнулся с проблемой URL'ов — в БД повсеместно URL ...
  • Что за предупреждения в журнале?
    Не первый раз обнаруживаю в журнале ошибок такие сообщения: E_WARNING [2] mysqli::real_connect(): (42000/1203): User xxxxxx already has more than 'max_user_connections' active connections (/xxxxxxxxx/sovunion....
  • Как очистить БД от ненужных таблиц?
    Вот где-где, но тут я точно полный ноль... Я даже правильный запрос в поисковик сделать не могу (ну не в теме я...). В общем, после переезда с LS на Alto (с помощью конвертации базы данных при установке) в БД...
  • Ошибка при импорте дампа базы
    Подскажите если не сложно. При импорте дампа базы Alto выдает такую ошибку: В работе SQL-парсера произошла ошибка. Убедитесь в корректности запроса, отсутствии в нем опечаток и незакрытых кавычек. Возможной причиной ...

23 комментария

0
Я не понимаю смысла в этих манипуляциях. Нужна авторизация с двух сайтов по одной базе пользователей?
В этом случае более уместным было бы использование единого LDAP каталога с обоих сайтов. Плагин такой ранее существовал, незнаю подойдет ли он к текущей версии cms.
0
LDAP не ушёл дальше недоработаной и предварительной версий, последние изменения 3 года назад…
кроме того, насколько я понял, он годится для сети поддоменов, а у меня второй сайт в подпапке + версии сайтов разные (в силу отсутствия обновлений нужных плагинов) + уже под пару сотен зарегистрированных пользователей…
но всё это не помешало бы мне попробовать LDAP, если с ним был внятный мануал для типичного пользователя плагинов, а не программиста
0
А можете поподробней обрисовать задачу. Возможно у меня похожая, но решать думаю ее по-другому.
0
одна БД на два сайта (с разными префиксами таблиц, за исключением юзеров и их настроек профиля)
иначе
два сайта с одной базой пользователей, но разным контентом
…
сейчас получилось только с пользователями, но, как видно, записать что-либо (создать блог или топик) юзер не может
0
А какая именно ошибка возникает например при создании топика? Если общие у них только таблицы пользователей и сессий.
0
например
SQL Error: Cannot add or update a child row: a foreign key constraint fails (`p325521_test`.`ter_topic_content`, CONSTRAINT `ter_topic_content_fk` FOREIGN KEY (`topic_id`) REFERENCES `ter_topic` (`topic_id`) ON DELETE CASCADE ON UPDATE CASCADE) at /...второй сайт/classes/modules/topic/mapper/Topic.mapper.class.php line 85

ter — это префикс таблиц второго сайта, а юзеры берутся из основного и их префик, разумеется, другой
эта ошибка, кстати, была при попытке прочесть уже созданный админом топик, т.е. получается, что юзер как бы и не юзер…
остальные ошибки при создании блога/топика такие же, только на соответствующие мапперы ссылаются…

при этом, в Новое светится +1, но при переходе — «сюда ещё никто не успел написать»
Отредактирован:
0
Мда чувствую с этой схемой придется повозиться.

1. Правильно я понимаю что вы создали такие же таблицы в той же схеме БД, но с другим префиксом?
2. Беглый поиск честно говоря заставляет сомневаться что вообще задание отдельных теблиц в конфиге будет работать. По крайней мере конструкцию Config::Get('db.table.user') я нашел только в плагине mailing.
3. Есть ощущение что придется руками менять эти внешние связи в таблицах второго сайта на таблицы первого.

Возможно чуть позже я поэкспериментирую.
Отредактирован:
0
1 — да.
2 — результат «клонирования» юзеров говорит об обратном))
3 — не совсем понял, что имеется в виду, но при изменении префиксов (в конфиге), например, у blog, на втором сайте появляется список блогов первого, что логично — это равносильно целиком общей БД для обоих сайтов
0
В общем у меня все заработало.

Нужно провести дебильную обезьянью работу и поменять старый FK на таблицы которые должны бы были дублироваться на таковые в исходных таблицах (которые собой их заменяют). Пройтись по всем таблицам второго сайта.

ALTER TABLE `pefix2_blog` DROP FOREIGN KEY `prefix2_blog_fk` ,
ADD FOREIGN KEY ( `user_owner_id` ) REFERENCES `alto`.`prefix1_user` (
`user_id`
) ON DELETE CASCADE ON UPDATE CASCADE ;


В PMA это делается через «структуру» и дальше «связи».
Отредактирован:
0
спасибо!
0
Там еще префикс для кэша надо другой задать.

Upd. Все-таки нашел в мапперах этот Get, так что возможно не все так плохо.
Отредактирован:
0
Проблема в FOREIGN KEYS — внешних ключах. Нужно либо их обновлять, чтобы задать связи для таблиц с разными префиксами, либо удалить совсем. Второй вариант проще, но не тестировался совсем, хотя скоро и планируется отказаться от внешних ключей.
0
отлично, спасибо, попробую как-раз потестить и этот вариант
0
скоро и планируется отказаться от внешних ключей.
турбо жесть -).
0
А логика очень простая, если задаться вопросом: для чего используются внешние ключи в движке? Вот не вообще зачем они нужны, а реально для чего используются в таких движках, как ЛС и Альто? Ответ: для каскадного удаления связанных записей в таблицах. А кто-нибудь встречал хоть один сторонний плагин, который создает новые таблицы, связанные логически с сущностями движка, и который бы создавал при этом свои внешние ключи? Я не видел ни одного.

Что получаем в итоге: при активном использовании сторонних плагинов целостность базы все равно часто нарушается, а гибкость кастомизации системы в целом ухудшается. Так какой смысл тянуть механизм внешних ключей? А организовать каскадное удаление сущностей не так уж и сложно. Нагрузка при удалении будет выше, но это не такая уж и частая операция.
0
для чего используются внешние ключи в движке?
внешние ключи, триггеры и процедуры используются не в движке, а в схеме данных, в БД. Для чего? Уфф. Для верного, правильного описания модели данных?

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

Так какой смысл тянуть механизм внешних ключей?
Звучит как: «вокруг нас всё больше и больше безграмотных. Так какой смысл выделяться, давайте опустимся до общего уровня и будет всем хорошо...»

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

Тот момент, что в основной массе рнр-продуктов СУБД используется только как хранилище данных, да и то, данные зачастую хранятся «как бык поссал» — это да, но ведь это не повод разучиться читать и писать?!

Отказ от моделирования данных и переход просто к хранению — это шаг в сторону неправильного понимания модели, фундамент конструкционных ошибок уже в коде, неэффективность хранения, избыточность, потери быстродействия, логично более дорогая цена за ошибку на более высоком уровне в приложении…
0
Это все абсолютно верно. Если рассуждать с позиции «от кутюр». Мы же имеем дело с «прет-а-порте». Хорошо ли, плохо ли, нравится или нет, но это факт.

К тому же надо понимать, что эффективно заниматься моделированием данных можно только тогда, когда у тебя есть абсолютно четкое представление обо всей структуре данных и обо всех методах манипулирования ими. А когда тут моделируется, а тут — нет, то все моделирование улетает в трубу.

Конечно, это было б здорово, если б никто не мусорил. Но т.к. на практике мы этого добиться не можем, то нужно реализовать качественную уборку.

А вообще, если говорить об интеграции, то в общем случае должна быть полная абстракция от механизмов хранения данных, и это на уровне API должно выполняться.
0
FK на таблицу comment не позволяет удалять комментарии. Причем ссылается она сама на себя — это вообще нормально? Если я правильно понимаю, то по идее комментарии должны были удалиться при удалении топика, но не смогли из-за этого FK. Новая фишка с удалением из админки тоже не срабатывает. как я тут описывал в конце.

Можно ли просто убрать этот FK из базы, могут ли быть какие-то негативные последствия?
0
Возможно, из-за каких-то манипуляций с БД (либо просто из-за сбоя) что-то сломалось во внешних ключах, потому эта проблема и возникла. И из админки, наверное, они не удаляются по той же причине.

Негативные последствия — это не будут удаляться комменты вместе топиками. Но эти последствия, как я понимаю, и так имеют место быть. Так что, я полагаю, ничего хуже этого уже не будет.
0
Смотрите, о чем я говорю. Таблица comment ссылается сама на себя
github.com/altocms/altocms/blob/master/install/db/sql.sql#L1158

ALTER TABLE `prefix_comment`
  ADD CONSTRAINT `prefix_topic_comment_fk` FOREIGN KEY (`comment_pid`) REFERENCES `prefix_comment` (`comment_id`) ON DELETE CASCADE ON UPDATE CASCADE,
  ADD CONSTRAINT `topic_comment_fk1` FOREIGN KEY (`user_id`) REFERENCES `prefix_user` (`user_id`) ON DELETE CASCADE ON UPDATE CASCADE;


FK только называется prefix_topic_comment_fk, а на самом деле связывается с самой собой с полем comment_pid.

Или вот как это выглядит в базе



Я не большой эксперт в базах данных но мне кажется что что-то здесь не то. Понятно что наверно стояла задача на дать удалить комментарий к которому подвязано дерево дискусии. Но в итоге получается что комментарии вообще нельзя удалить (без отключения проверки FK).
0
А, вон о чем речь. Я так понимаю, что этот ключ, по идее, должен предотвращать возникновение «подвисших» веток комментов, когда удаляется родительский комментарий. И получается, что при удалении комента из середины ветки, должны удалиться все комменты, для которых он является родителем.

Но, кстати, натолкнули на мысль: тут действительно могут быть проблемы при удалении топика с деревом комментариев — комментарии из дерева должны удаляться в определенном порядке. Надо будет перепроверить
0
Проще иметь для каждого сайта свою БД. Независимую, саомодостаточную, целостную. Как это и было изначально задумано разработчиками.
Если далее нужно иметь единую БД пользователей между двумя сайтами — то настроить соответствующую репликацию (в ту или иную или даже в обе стороны).
Если нужна авторизация сквозная, то реплицировать сессии. Если сайты в разных доменах, но использовать единую куку не получится и надо менять авторизационный механизм, обновляя куку исходя из реплицированных данных по сессиям.
Отредактирован:
0
да, в моём случае подойдёт только этот вариант, теперь уже ясно
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.