Самое интересное что даже не могу проследить от чего так, то есть не было нечего вообще, просто оп и миграция не срабатывает

я про вот этот месседж

:D
Естественно я понимаю, где админка, а где on_delete находятся
Тот ответ с админкой - было предположение, как можно решить эту проблему (полезно это закинуть, чтобы убедиться, что люди здесь не подскажут решения лучше этого)

блин, ну оно же вообще между собой никак не связано, on delete и админка
какую проблему?

я наверное подустал и стал нетерпим, сорри

ты изначально пришел с вопросом - как удалять пользовательские данные каскадом
вот админка здесь вообще непричем

Дак и я и говорю, что это было предложение одного из решений:
1. Что-то мудрить в БД
2. Писать отдельную вьюху со списком пользователей и возможности их удалить
3. Реализовать это через админку
Видимо мы на разных уровнях находимся... не в мою пользу. И то, что вопросы вызывает у меня (три пункта выше, хоть тут выбор и очевиден, но бывают задачи, где он не очень очевиден для меня), у вас решаются уже рефлексорно автоматически

Поэтому и недопонимание

я не думаю что у нас там как-то глобально отличаются уровни :))

короче, если надо удалять "мусор" после пользователя и эта логика удаления "мусора" приемлема по умолчанию, то ничего лучше on_delete=models.Cascade наверное и не придумаешь
в противном случае, хоть через админку, хоть через вьюху прийдется выгребать все в "ручном режиме"

еще раз извиняюсь, если был груб (я был)

К такому же выводу пришёл
Хотя мои текущие проблемы в тестировании спокойно решили бы тесты... до которых руки так и не дойдут
Да и есть опасение, что сами тесты по объему раза в два больше основного кода будут. Это нормальная практика, интересно?

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

у меня у одного сердечко отсылается, когда я закрываю джангу на убунту? лол

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

функционал приходится допиливать по ходу дела, так как клиенты запрашивают обычно по чуть-чуть
и глобально уже все было когда я пришел
я скорее отдельные какие-то плюшки или модули допиливаю

я сильно не уверен, что могу тут рассказать хоть что-то интересное

Значит вполне нормально делать по чутьчуть по мере хотелок (даже своих)
Хотя в идеале бы было неплохо делать по принципу "реализуешь одно приложение полностью (с заглушками на будущие приложение) и только потом переходишь к другому"
Сейчас получается так, что там что-то сделал, потом переключился на другое место... потому что там что-то сделать проще и быстрее и можешь сделать раза в два-три больше, чем если бы остановился на сложной задаче и думал как её решить

Вот кстати такой крохотный вопрос: есть два метода в модели

get_avatar_buy  # возвращает список купленных аватаров
get_avatar_nonbuy  # возвращает список не купленных аватаров

Понятно, что под капотом методы будут на 99% идентичны и отличаться будет только дополнительная фильтровка по полю buy

Так вот, что это, вынужденное нарушение DRY?
Гораздо лучше, когда у тебя один метод с понятным названием возвращает тебе единственный результат?
Или метод, который принимает два аргумента, вроде get_avatar_buy(u_id, True)? но при этом избавляет тебя от дублирования кода? Это прям абсурдная проблема, вытянутая из пальца.

Ещё пример.

cost = 1000
if percent > 10:
    cost = 1100
# или
if percent > 10:
    cost = 1100
else:
   cost = 1000

Какой из этих вариантов наиболее удачный? Функционал у них один и тот же, только вот первый вариант имеет три строчки и читается (на мой взгляд) проще.
Тоже проблема вытянутая из пальца, но такие мелочи меня прям очень беспокоят.

get_avatar_buy  # возвращает список купленных аватаров
get_avatar_nonbuy  # возвращает список не купленных аватаров

cost = 1000
if percent > 10:
    cost = 1100
# или
if percent > 10:
    cost = 1100
else:
   cost = 1000

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

Или может нормальная практика прямо во вьюхе делать фильтрацию без дополнительной прослойки в виде методов? (именно простую фильтрацию без сложной логики, где ещё дополнительно данные нужно обработать)