LINUX.ORG.RU

Кастомное хранение полей модели в django

 ,


0

2

Всех с Новым Годом!

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

1) при ./manage.py migrate помимо всех остальных действий клонируется/пуллится репозиторий с гита. Креды репозитория указаны в class Meta модели.

2) при создании нового инстанса модели, создается запись в БД и в гитовом репозитории создается файл с нужным коммитом, и пушится в репозиторий. Все действия с данным полем будут проходить только через репозиторий.

3) Я готов пойти на определенные издержки (созданий и изменений инстансов будет мало, чтений много).

4) Для чего это нужно? Чтобы хранить статьи в гите в формате markdown, чтобы и править было просто, и историю изменений посмотреть было можно, и авторство установить. Также, чтобы при падении базы, можно было просто спуллить репозиторий и жить как ни в чем не бывало. Это гораздо проще, чем подымать кластер из постгри для обеспечения сохранности данных в джанге.

5) Всякие сложные ситуации вида «два человека вносят правки в один и тот же файл, и как быть в этом случае» опускаются. в крайнем случае можно показать сообщение из гита, что надо разрешить конфликт последнему человеку.

6) Больший приоритет у конечного репозитория. То есть, если локально на серваке одна версия репозитория, а удаленно - другая, то в любом случае надо пуллить удаленный репозиторий.

7) Поддержка веток не планируется. Статьи, сохраненные в гите отображаются только из мастера. Пока не было мерджа в мастер, джанга их не видит.

Может кто-то видел/делал нечто подобное?

★★

фикстуры - не вариант, так как может легко сломать структуру базы при добавлении новой статьи

aido ★★
() автор топика

Ну, а в чем собственно проблема? Сделай management комманду для первого пункта, пункт 2 по сигналу. С полем работай через property, чтобы оно читало из файла.

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

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

pawnhearts ★★★★★
()
Ответ на: комментарий от pawnhearts

С полем работай через property, чтобы оно читало из файла.

Это как? ни разу пока не видел.

в джанго есть готовые решения для хранения истории изменений и кто их делал

Но гит для этого лучше подходит, да и постабильнее/попроще будет. В одном случае тебе надо БД поднять, настроить ее (да пусть даже в докере), найти/сделать к БД вебку, которая позволяет показывать и писать в маркдауне, а в другом - просто pull/push в gitlab тот же, и там же можно править. И даже если gitlab упадет, поднять локальную репку куда проще и надежнее, чем развлекаться с кластером постгри.

Не совсем понятно когда ты будешь делать pull

Только при миграциях либо нажатиях кнопки «синхронизировать с репозиторием»

aido ★★
() автор топика
Ответ на: комментарий от aido

С полем работай через property, чтобы оно читало из файла.

Это как? ни разу пока не видел.

class Foo(models.Model):
    field1 = models.SomeField()
    field2 = models.SomeField()

    # тупо питоновая пропертя безо всяких джанг
    @property
    def markdown_text(self):
        return file.read()

    # тупо питоновый метод
    def get_markdown_text(self):
        return file.read()
anonymous
()
Ответ на: комментарий от aido

БД у тебя в любом случае будет, что такое вебка? Веб интерфейс? Ну джанговская админка у тебя уже есть, есть куча всего https://djangopackages.org/grids/g/markdown/

Это не миграция имхо, тебе нужна https://docs.djangoproject.com/en/2.1/howto/custom-management-commands/

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

Мне просто кажется, ты увидел молоток и видишь везде гвозди.

pawnhearts ★★★★★
()
Ответ на: комментарий от pawnhearts

Мне просто кажется, ты увидел молоток и видишь везде гвозди.

Я просто эту репку могу править хоть в виме, вообще хоть в чем, и где угодно. В случае постгри и джанги, мне придется париться о стабильности работы БД, которой на первых этапах быть не может. У меня, например, нужно согласование кликхауса и постгреса, и если я что-то сделал не так, то проще обе БД затереть и заново залить данные в нужном формате, чем делать это аккуратно с удалением и созданием таблиц. А если у меня в этих же базах будут храниться статьи с использованием матана из кликхауса, то совсем все плохо - придется каждый раз их пересоздавать.

aido ★★
() автор топика
Ответ на: комментарий от aido

Например, ситуация:

Я по ошибке неправильно в КХ создал TABLE или MATERIAL VIEW, в котором прописан id из постгреса для того, чтобы удобнее было делать по нему GROUP BY внутри КХ. Я обнаружил эту ошибку, понял, что таблицы в КХ мне надо пересоздать (ALTER и DELETE там работают не так, как везде, и они очень затратные), соответственно, мне пришлось бы дропать всю таблицу со всеми данными и ждать, пока КХ с постгрей синхронизируются снова, а потом продолжить загрузку данных в нужном формате. Это долго (пара часов или суток, в зависимости от количества данных). В этот момент проще дропнуть обе базы и сделать заливку всего сразу в верном формате.

Или какие еще БД очень хорошо поддерживают математику и нацелены на бигдата? Я пробовал те же алгоритмы написать для постгри, получается в разы больше кода и работает сильно медленнее. Были запросы вида: 4 вложенных селекта, с CROSS JOIN и условными операторами в одном из них (и это не предел, дальше будет больше).

aido ★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.