Проверки на основе данных сеанса, обмен данными между поддоменами - PullRequest
0 голосов
/ 20 января 2012

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

В основном, есть две проблемы:

1) многие проверки основаны на текущей ролиПользователь имеет.Так как это зависит от current_account (который является данными сеанса), я не могу делать такие виды проверок в модели.Это приводит меня к некоторому уродливому коду контроллера (уродливому в том смысле, что он действительно чувствует себя неуместным).Я думал о сохранении current_account после в переменной класса модели, но я читал, что это не потокобезопасно.Любые рекомендации?

2) почти каждая запись в базе данных относится к текущей учетной записи;Таким образом, почти каждая таблица должна иметь столбец account_id, а модель должна иметь связь с принадлежащим счетом.Я хочу избежать этого.Первая (очевидная) вещь - это иметь отдельную базу данных для каждой учетной записи, но

a) существуют общие таблицы

b) начальник говорит, что это решение неприемлемо (будет много учетных записей, с относительно небольшим количеством пользователей).Есть ли третий путь?

1 Ответ

0 голосов
/ 16 августа 2012

Если кто-то сталкивается с подобной проблемой: описанная проблема называется multitenancy ;понимание default_scope должно помочь.Кроме того, есть мультитенантный драгоценный камень , который мне очень понравился.

...