Как устранить ошибку «relation does not exist» в Django?

Question

[gh0sty]

Я переношу django-проект на сервер.
Так получилось что у меня очень много моделей. И чтобы обойти ограничение 1600 columns от PostgreSQL, разбил свои модели на 3 приложения/файла модели. Т.е. у меня есть приложения main, translations и translations2. В каждом из них работает библиотека django-modeltranslation. Я создал 3 базы db, db_translations и db_translations2.
Внес их в settings:

INSTALLED_APPS = [
...
    'main',
    'translations',
    'translations2',
...
]

и

DATABASES = {
    'default': {
        ...
        'NAME': 'db',
	..
    },
    'trans': {
	...
        'NAME': 'db_translations',
        ...
    },
    'trans2': {
        ...
        'NAME': 'db_translations2',
        ...
    }
}

Провел миграции как:

python3 manage.py makemigrations main
python3 manage.py migrate main
python3 manage.py makemigrations translations
python3 manage.py migrate translations --database=trans
python3 manage.py makemigrations translations2
python3 manage.py migrate translations2 --database=trans2

Выполняю команды update_translation_fields или sync_translation_fields из приложения modeltranslations. По сути одна из команд должна добавлять поля перевода для моих языков, формата field, field_ru, field_en, field_fr.
Но выдается ошибка:

django.db.utils.ProgrammingError: relation "translations_translations" does not exist
LINE 1: UPDATE "translations_translations" SET "open_ad_ru" = "trans...

Пока не нашел решения данной проблемы. При вызове runserver, выдает, что действительно не проведены миграции translations, translations2. (хотя я их явно записал в базы иначе была бы вызвана ошибка ограничения)

Подскажите пожалуйста, может что в settings дописать? Уже устал тестировать команды с форумов)))

Comments

[gh0sty]

Dr. Bacon, это называется очень много работы/ полей в модельках)))

[gh0sty]

Dr. Bacon, нееет... а блин, через часа 2 попробую. Я думал достаточно закинуть в DATABASES

[gh0sty]

Dr. Bacon, Ну смотри, если я вручную вбиваю --database= при миграциях, мне все же нужен роутинг? Jsonb не пойдет, мне нужны явно поля для админки.

[gh0sty]

Dr. Bacon, Да все ок. Но щас новая проблема. При создании экземпляра выдает:

IntegrityError at /admin/translations/translations/add/
null value in column "balance_add" violates not-null constraint

Хотя в этой модельки нету поля balance_add. Тысячу раз пробовал всякое.

Ниже:

DETAIL: Failing row contains ( id-шник, мои заполненные поля..., null, null, null..., t)

(в поля входят переводы, если они включены)

Крч каким-то образом создаются поля, которые создаваться не должны. И через shell objects.create() и через админку - по нулям. Делал дроп базы, отключал modeltranslation - все то же. И фишка в том, что я это вернул на локалку (в одну базу) - все работает.
Пока продолжаю перебором дропать и пробовать.

Answer 1

[gh0sty]

Окей я разобрался.
Краткий гайд по менеджменту большого количества полей, на примере библиотеки Django modeltranslation. Все происходит на сервере и на PostgreSQL. Причина: "tables can have at most 1600 columns" и "row is too big: size ..., maximum size 8160"

1. Для начала создаем все наши поля на перевод у меня их около 400.
   
2. Считаем количество нужных языков + 1, у меня это 6. Почему? Modeltranslation оставляет оригинальное поле, чтоб быстро к нему обращаться на уже смененном языке. Т.е. динамическая удобная фича)
   
3. 400 * 6 = 2400 полей по итогу.
   
4. Эти 2400 делим примерно на 600-800 (если charfield max_length=200). На моем примере - хватило 5.
   
5. Разбиваем наш models и translation на 5 (вычислено выше) приложений. Это по 600 переводных строк, у меня, т.е. 100 обычных строк (+- 10).
   
6. Создаем базы под эти приложения (ну это не нуждается в пояснении, create + grant).
   
7. Создаем в settings ручные роуты, я их так называю. Пример:
   
   

   DATABASES = {
       'default': {  # Сюда будут записываться другие приложения, оставить "default"!!!
               'ENGINE': 'django.db.backends.postgresql_psycopg2',
               'NAME': 'db',
               'USER': 'username',
               'PASSWORD': 'pass',
               'HOST': 'localhost',
               'PORT': '',
       },
       't': {
               'ENGINE': 'django.db.backends.postgresql_psycopg2',
               'NAME': 'db_t',
               'USER': 'username',
               'PASSWORD': 'pass',
               'HOST': 'localhost',
               'PORT': '',
       },
       't2': {
               'ENGINE': 'django.db.backends.postgresql_psycopg2',
               'NAME': 'db_t2',
               'USER': 'username',
               'PASSWORD': 'pass',
               'HOST': 'localhost',
               'PORT': '',
       },
       't3': {
               'ENGINE': 'django.db.backends.postgresql_psycopg2',
               'NAME': 'db_t3',
               'USER': 'username',
               'PASSWORD': 'pass',
               'HOST': 'localhost',
               'PORT': '',
       },
       't4': {
               'ENGINE': 'django.db.backends.postgresql_psycopg2',
               'NAME': 'db_t4',
               'USER': 'username',
               'PASSWORD': 'pass',
               'HOST': 'localhost',
               'PORT': '',
       },
       't5': {
               'ENGINE': 'django.db.backends.postgresql_psycopg2',
               'NAME': 'db_t5',
               'USER': 'username',
               'PASSWORD': 'pass',
               'HOST': 'localhost',
               'PORT': '',
       }
   }

   
   
   
8. Записываем их все в приложения. НО!!! закомментируем.
   
9. В папках migrations в каждом приложении перевода удаляем все, кроме кеша и _init_.
   
10. Проводим на всяк случай makemigrations и migrations без параметров для остальных приложений, чтобы удостовериться что все будет записано правильно.
    
11. Далее раскомментируем в settings самое первое приложение. И применяем:
    
    

    manage.py makemigrations <название приложения перевода>
    manage.py migratе <название приложения перевода> --database=t<номер базы>
    manage.py migratе
    manage.py runserver <параметры>
    *Создаем тестовый экземпляр*
    manage.py update_translation_fields

    
    И проводим этот набор операций один за одним для каждого приложения.
    
    

Это делается, чтобы не было бредовых ошибок. Уж поверьте их может быть море. Если что-то не получается пересоздаем базы данных (желательно с новым именем), чистим migrations и начинаем сначала. Если что-то явно не получается - гуглим ошибку. Тут основная часть всей дичи, которая может вам встретиться.