да)
nested_admin справляется с этой задачей, но выглядит нехорошо, не совсем удобно

ну ты же видишь что групируется по двум значениям

TabularInline надо заюзать, но все равно отстой какой-то) если будет три букета с цветами по 5 штук

надо чтобы только по одному

всем привет. я могу продолжить тот вопрос про проектирование? использовать вас в качестве утёнка?

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

пишется новый проект с нуля

был такой опыт?

сделал бы prefetch_related(), подменял шаблон и в шаблоне вывел. Это если контент статичен.

У меня была задача внедрить в форму несколько кусков форм от связанных объектов (в глубину): Order -> Many Steps -> Many Jobs (with many2may and one2many) + many2many
И все с манипуляциями в DOM (show / hide)

я добавил read-only поле в форму и в ней все через Vue, на компонентах, делал

Это было сложно)

Можно построить сложный джанго-формсет с вложениями (формы и формсеты). Так тоже делал для сохранения и валидации того что описал выше.

И подменить форму класса админки

*изменил

https://gist.github.com/lookonkz/975c27d555d2d83cafdf569b23057d86
всеравно

Спасибо большое!

ну правильно ты запрос не поменял

у тебя группировка по двум полям

У меня есть приложение "транспорт", в нем раньше была модель Data, в бд создавалась таблица transport_data(panel_data, surface_data.. итп) , собственно описывающая транспорт. Теперь приходят и говорят, хотим хранить дерижабли. Я вижу решения в нескольких вариантах
а) Мне при описании моделей стоит вводить уточняющую инфу (trabsport_data_kareta, transport_data_derijable, panel_data_kareta итп), сохранив названия приложений
б) вынести свойства, оставив общие таблицы для индексации и каких то общих параметров, типа названия. dirijable_properties, kareta_properties, panel_der_properties итп (transport_data, panel_data остаются, где возможно или где нужны)
хотя общие таблицы для сущностей обоих типов кажется мне неправильным, т.к. оператор работает только со своим типом, общих "кросс"-операций над всеми данными обоих типов не предвидится
в) завести новые приложения, попутно переименовав старые(самый трудозатратный и вырвиглазный вариант) transport_katafalk_data, transport_der_data ...

а если hour то у меня ошибка

Тебе нужно типы транспорта завести, и таблицу связей, для какого транспорта какая дата относится (если я верно понял суть вопроса)

вариант б) всё верно.

dirijable_properties, kareta_properties, panel_der_properties - это тоже через связи