1. Всем доброго дня.

    Есть некий коллективный блог, записи и комментарии к ним. Примерно так:

    class Post(models.Model):
       user = models.ForeignKey(User)
       content = models.TextField()
    
    class Comment(models.Model):
       post = models.ForeignKey(Post)
       author = models.ForeignKey(User)
    

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

    Причем проект в начальной стадии разработки и хотелось бы решить эту проблему прозрачно для остального кода.

    Наш первый вариант — отдельные таблицы и кастомные менеджеры там где нужно. Сейчас это решается подменой классов моделей в middleware, как-то так:

    models.Post = models.DemoPost
    

    Но он уже оброс такими костылями, что страшно, и не понятно, удастся ли довести его до конца.

    Посоветуйте, пожалуйста, как быть. Заранее огромное спасибо.

  2. А чего просто не добавить поле is_demo?
    Или я не понял задачу...
  3. Можно, но тогда нужно модифицировать существующий и новый код.

    При запросах добавляя .filter(is__demo=True), а при изменениях устанавливая is_demo в правильное значение.

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

  4. Dyadya Zed

    09.06.2009

    0 ↑
    0 ↓
    Вариант с новым полем мне видится достаточно простым.

    Можно просто написать менеджер, которым подменить objects у комментариев. По умолчанию будет отдаваться objects как .filter(is_demo=False).

    Для песочницы отдаем другой менеджер с .filter(is_demo=True)

    Если подменить objects код будет работать без изменений. Ну разве что save() придется подкорректировать.
  5. astur.net.ru

    09.06.2009

    0 ↑
    0 ↓

    Если отказаться от is_demo, то всё равно придётся хоть как-то модифицировать код. Как минимум, в самой песочнице отбирать по filter(user=request.user.username) и filter(author=request.user.username) для записей и комментов соответственно. Впрочем, это можно сделать только в коде песочницы, а остальной код не трогать.

  6. Потрясающе... после этого

    Но он уже оброс такими костылями, что страшно, и не понятно, удастся ли довести его до конца.

    человек пишет

    Можно, но тогда нужно модифицировать существующий и новый код.

    Вам на костылях легче идется?:-)

    Невозможно сделать какую-то систему при этом не сделав её.

  7. ziro

    09.06.2009

    0 ↑
    0 ↓
    Кстати, мне представляется, что модели можно вообще не изменять, а использовать User.is_staff, поскольку песочница должна быть доступна только для разработчиков.
    В плюсы - можно использовать стандартный декоратор staff_required на вьюшки песочницы.
    Ну и как Дядя Зед советовал менеджеры правильные прописать.
  8. Всем спасибо.

    Сделали так, middleware подменяет в нужных моделях _meta.db_table и менеджеров при необходимости.

  9. Alexander Artemenko

    09.06.2009

    0 ↑
    0 ↓
    Ммм, а это threadsafe? :-)
  10. По-моему, вы только что изобрели некий велосипед вместо использования proxy-моделей. http://docs.djangoproject.com/en/dev/topics/db/models/#proxy-models
  11. Dyadya Zed

    10.06.2009

    0 ↑
    0 ↓
    У меня сложилось впечатление, что собирали самокат, и тут срочно понадобилось приделать педали. Иногда проще забыть самокат и сделать велосипед.
    Но, видимо, вам виднее.

Внимание! Это довольно старый топик, посты в него не попадут в новые, и их никто не увидит. Пишите пост, если хотите просто дополнить топик, а чтобы задать новый вопрос — начните новый.