Как оформить запрос в БД при помощи Django ORM?

Bobsans, ну, как скажешь...

Как добавить пользователя в дочернюю модель, если он есть в родительской?

Сергей Протасов, ну wagtail так wagtail
разницы никакой.

Как добавить пользователя в дочернюю модель, если он есть в родительской?

Сергей Протасов, то, что ты делаешь (одно поле - одна запись в БД) похоже на EAV (entity-attribute-value). Попробуй, конечно. Оверхед это сильный и усложнеие. Особенно в привязке к такой модели, как User (я пробовал в своё время - замаялся).

Ты неверно понимаешь стандартный подход к профайлам, про который я писал:
1) Создаёшь User и выборки всегда по User
2) Драйвер - связанная таблица с доп.полями
3) В админке основная таблица - юзер, водителя инлайнишь к нему, а не наоборот
4) Админка - это твой инструмент, а не юзера или гражданского админа. Напиши им свои средства управления. Потому что админка - это (почти) прямой доступ к записям в БД - не надо им этого.

Но - это твё дело.

Вот EAV , попробуй. Среди форков точно есть и адаптации под третий питон.

Там и с менеджерами игрались и в админку расширяемой модели поля можно вставить и многое друоге.

Но лучше - как я посоветовал :-)

Как добавить пользователя в дочернюю модель, если он есть в родительской?

Сергей Протасов, модель Driver - не прокси. Не надо. Просто модель. В ней есть поле user и оно OneToOne к модели юзер. Вот и всё. Остальное решается сигналами, расширением метода save и добавлением в админку Inline
Просто выбираешь потом пользователей, у которых driver не null и получаешь всех водителей. Так же можно добавить модели Dispatcher, Buhgalter и RaznoRabochyi :-)

Как организовать учет в django?

Yermek, каждая запись реестра - один документ. Это как лог. Бухгалтерия так и работает.
Если надо как-то группировать - добавь в реестр "номер документа" - какое-то формальное текстовое поле... Но, мне кажется, ты пытаешься смешивать сущности

Как организовать учет в django?

Yermek, 1-й - это странно. Зачем там M2M? По сути ведь один документ - одна операция (пусть и в документе несколько товаров), значит M2M не нужно. Только усложняет всё.

Вариант 2 - не понял вообще. Т.е. это продолжение м2м варианта. А уж фоновое удаление всего - это вообще опасная штука. Ну и ты ж не гигабайтные блобы хранишь в этой таблице - зачем удалять?

Пусть будет документ, реестр, справочник типов операций.
Для тебя проще заносить в реестр записи как я и писал (с учётом типа):
- тип операции (приход, расход, кореектировка) - FK на справочник типов
- документ (FK на документ)
- откуда (FK на сток)
- куда (FK на сток)
- когда
- кто (FK на юзера)

теперь любые изменения в документе так же оражаются в реестре. Документ хранит последнюю актуальную версию.
Можно, конечно, хранить ещё и историю изменений самого документа - это уж из задач вытекает.

Теперь на любой чих просто создаётся новая запись в реестре. Ничего сложного городить с save() не придётся.

Как организовать учет в django?

Ну пусть в реестре будет не товар, а документ. Тогда добавится еще один тип операции (кроме перемещения товара) - корректировка.
Просто посмотри, как устроено документарное сопровождение товарооборота в известных складских программах.
Главное - это не "хотеть странного", а реализовать отработанный алгоритм. В 90-е, в эпоху дикой бухгалтерии каждый придумывал своё и это породило кучу велосипедов разной степени нерабочести

Как правильно реализовать возможность работы с несколькими наборами данных?

Ну, вроде б норм. Только можно сделать отдельную модель импортов и связать с жильцами по FK. Тут тебе и автонумерация импортов (потому что каждый - это запись в БД и возможность выбирать связанных жильцов...

Как правильно реализовать возможность работы с несколькими наборами данных?

Очень размытое описание. У тебя в голове, скорее всего, всё норм, но вот тут ничего не понятно. Опиши на каком-то примере. Или напиши прямо про свои "независимые наборы данных".
- Независимые от кого? От чего?
- Что за наборы данных?
- Какая работа? Получение? Отдача? Какая-то обработка?

Здесь слова REST и mysql лишние от слова "вообще". А "наборы данных" скорее всего имеют отношение к структуре данных и тому, как их лучше отразить в джанго-моделях.

Так что давай какую-то конкретику.

Какой gui для Python удобней?

ui файлы можно ж просто как ресурсы грузить без конвертации...

Как автоматически создать модель в Django?

leo9797, если мебель - это мебель (понятно, почему фурнитура :-) ), то три шкафа в квартире - это три разных записи в БД. Каждый шкаф может одновременно находится в одной комнате. Значит у мебели должен быть признак нахождения в комнате. Всё как и написал Astrohas В этом поле будет храниться ссылка на запись той комнаты, где стоит мебель. Выводить список мебели - просто. Это описано в документации.

Как автоматически создать модель в Django?

leo9797, таки путаешь понятия.
Модель - описание структуры таблицы в БД
Запись - собственно запись в таблице БД в соответствии со структурой.
От записи к записи структура не меняется.

У тебя есть комнаты.
У тебя есть фурнитуры (что вообще ты подразумеваешь под этим???)

Вот у меня есть комнаты: гостиная, спальня, детская.
Вот у меня есть фурнитуры (чтобы это ни было). Пусть это будет вид (а не конкретный экземпляр) мебели. Шкаф, диван, кровать, стол.
Тогда я могу установит отношения (реляции) и связать Гостиную с Диваном и Шкафом. А Спальню - с Шкафом и Кроватью.

Записи Гостиная, Шкаф и Детская имеют одинаковую структуру (состав полей). И записи фурнитуры - одинаковую структуру. Состав полей не меняется от записи к записи. Новые поля не добавляются.

Если у тебя добавлены поля, подразумевающие отношения записей (реляции), то их содержимое меняется, отражая эти отношения. Как я и писал в своём ответе.

Поля не появляются. Устанавливаются связи.

Тебе есть смысл разобраться с реляционными БД. Не знаю, куда и направить тебя... Может тут

И начни с простых примеров на Джанге. С документацией разберись... Если с английским туго - есть перевод. Там есть обучаловка. Тема реляций там затрагивается.

А то, похоже, у тебя в голове картинка сложилась, но к реальному миру ПО она пока имеет слабое отношение. Надо подучиться....

Ошибка при заходе в админпанель Django?

6379 это порт редиса. Я помню, потому что использую. Ошибка при входе в админку - значит не селери или что-то сложное, а простое, базовое. А редис в этом плане используют как кэш. 10061 - ошибка подключения. Значит или редис не стоит или не запущен..

Как-то так

Как в django python с помощью промежуточного слоя middleware изменить содержимое страницы до ёё вывода render'ом во view?

Клиент -> Сервер -> приняли запрос, получили данные из заголовка и тела запроса (request), на основании данных и запроса и переменных/условий/БД сформировали контекст, на основании контекста отрендерели шаблон и вернули обратно клиенту в браузер.
Нет тут, в насквозь синхронной джанге никаких "событий". Которые могли бы прилететь в промежуток между получением запроса и рендером шаблона. Есть полученные и имеющиеся данные. На основании этого всё и происходит.
Подумай, какие данные у тебя есть и как они должны повлиять на результат.

Ну или расскажи, какие "события", могущие повлиять на результат ты ожидаешь. А то просто не слишком-то из упрощённого примера понятно.

Как в django python с помощью промежуточного слоя middleware изменить содержимое страницы до ёё вывода render'ом во view?

Модель — Вью — Контроллер.
render - это часть внутренней реализации view (можно и не рендерить вообще — возвращать статику или нешаблонные данные).
Так что не render, а View. В документации всё написано.

нужно изменить до генерации

- до или внутри view.
Изначальный пример подразумевал попытку изменения именно после view (метод process_template_response), а это неверно.

Пока что решил обходным путём:

выглядит как верное направление, а не обходное :-)

Ну и

не пытайтесь понять "зачем?", лучше попытайтесь решить "как?".

Лучше разобраться в "зачем" и, тогда, возможно, не придётся думать, как нам перестать хотеть странного в "как" :-)

Но ровно с тем же успехом можно вставить

request.test_context += ' - 4. process_template_response'

прямо в test_context

либо запустить перегенерацию до вывода html

ну да, это возвращает нас к стадии рендера view. И зачем так мучиться?

не пытайтесь понять "зачем?", лучше попытайтесь решить "как?".

Иногда лучше ещё раз переосмыслить "зачем". Это вполне может избавить от желания "странного" в "как". :-)

Как в django python с помощью промежуточного слоя middleware изменить содержимое страницы до ёё вывода render'ом во view?

Необходимо, наоборот, ещё до генерации html изменить входные данные.

Ну, ок. Просто генерация происходит во view, поэтому менять request после генерации - бессмысленно. Видимо ты просто неверно понимаешь течение процесса.

request - до view, response - после.
Твой "обходной" путь - как раз и есть реализация view, т.е. работа с request до и в процессе рендера.

Ещё раз: после view менять request для изменения результата - бессмысленно. Результат уже есть.

Python: как передать параметр с пробелом?

process = Popen(['python3.5', BASE_DIR + '/script.py', field_id, username, password, agent])

как-то так

Python: как передать параметр с пробелом?

Rais, точно! Вообще из головы вылетело! Делал же это и сам пробежался по граблям, но быстро нашёл.
regerald, поправь параметры на список.

Как решить проблему с csrf_token?

1) не делай логин и восстановление на одной странице - лучше разнести на разные. Безопаснее и проще
2) закрывай форму отправки ссылки на почту сразу после отправки (редирект на страницу с надписью "всё ок, проверь почту") Тогда и проблемы не будет.
или
2) перехватывай 403 с ошибкой csrf и предпринимай действия со своей стороны

Это задача на юзабилити - перестань биться о csrf лбом. Обойди проблему. В любом случае обирай сам отработавшую форму - не надо оставлять её висеть.

Python: как передать параметр с пробелом?

regerald, ну, тогда логичный вопрос - какой путь проходит agent от параметра комстроки до параметра ф-ции main?
как ты получаешь, обрабатываешь параметры чтобы передать их в main?