избавиться от кириллицы и пробелов в путях

Решил через импорт os и указания пути

В общем я раскопал, если интересно. Переименование моделек и перенос их из одной апки в другую привели к тому, что у меня образовалась каша с привилегиями и записями в таблицах django_content_type и auth_permission. Что в свою очередь привело к тому, что чисто номинально кастомных привилегий у меня было по прежнему то же кол-во, но некоторые из них уже ничего не означали, так как были мусором или вовсе назывались по старому, а привилегий с новым названием не было.

Например, была у меня моделька contacts для личных сообщений, но потом я ее переименовал в messages. Так вот в базе у меня по прежжнему были view_contacts, add_contacts и т.п.

Что больше всего сбило с толку так это то, что на проде и локально бардак был разный. Выполнение команды remove_stale_contenttypes частично исправило ситуацию, поудаляв старые записи, но переименовывать пришлось руками

Ребят, подскажите, пожалуйста по структуре как лучше сделать: есть таблица "Сделка", есть "Работник", который оформил эту сделку. Сохранение работника в сделке происходит автоматически. Теперь вопрос: есть вариант в бп, когда нужно добавить второго работника вручную, какой тип поля лучше выбрать? Я подумал, что можно два вк сделать, но потом понял, что бред, а manytomany не совсем правильно

через внешнюю таблицу

- сделки
- сделки_работники (id сделки + id работника)
- работники

Так это же и будет m2m?

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

А зачем так делать? Вроде же можно без вспомогательной таблицы обойтись

ага, можно вообще все в одну таблицу засунуть ))

Как раз сегодня просто смотрел Маркова он объяснял м2м и сделал всё без вспомогательной таблицы

а почему бред? может быть и 3й работник?

Два внешних ключа на одну таблицу не может быть.

ерунда

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

contenttypes создается при первой миграции - на момент 1й миграции на проде, задействованые apps могли и скорей всего сильно отличались от сегодняшних

кстати и django_auth тоже

У меня просто представление было такое, что если структура базы данных одна и та же, и проект в двух окружения зачекаутен на один и тот же коммит, то все дела с привилегиями должны быть одинаковыми. Ан нет )) Долго же провозился

Всем спасибо, особенно @lannoyy и @dantyan за помощь. Я тогда искал решение, как корректно поднять django на gunicorn+nginx. У меня получилось уже несколько дней сайт работает исправно!
Я делал сайт как раз для написания инструкций, в том числе и по django, теперь есть там пару статей, чтобы другие люди, как я не заходили в тупик.

Да, я мало того что модельки переименовывал несколько раз, так я их еще между апками менял местами

Посоветуйте пожалуйста сервисы типа dbdesigner.net , что бы наброски для бд делать