Size: a a a

Django [ru] #STAY HOME

2020 June 12

НК

Никита Кадацкий... in Django [ru] #STAY HOME
Самое интересное что даже не могу проследить от чего так, то есть не было нечего вообще, просто оп и миграция не срабатывает
источник

AD

Alex Dem in Django [ru] #STAY HOME
Aquinary
Ну в крайнем случае проще в админке запилить крестик на удаление пользователя... тогда и не в рамках отладки можно будет использовать
я про вот этот месседж
источник

A

Aquinary in Django [ru] #STAY HOME
Alex Dem
где админка, и где on_delete?
:D
Естественно я понимаю, где админка, а где on_delete находятся
Тот ответ с админкой - было предположение, как можно решить эту проблему (полезно это закинуть, чтобы убедиться, что люди здесь не подскажут решения лучше этого)
источник

AD

Alex Dem in Django [ru] #STAY HOME
Aquinary
:D
Естественно я понимаю, где админка, а где on_delete находятся
Тот ответ с админкой - было предположение, как можно решить эту проблему (полезно это закинуть, чтобы убедиться, что люди здесь не подскажут решения лучше этого)
блин, ну оно же вообще между собой никак не связано, on delete и админка
какую проблему?
источник

AD

Alex Dem in Django [ru] #STAY HOME
источник

AD

Alex Dem in Django [ru] #STAY HOME
я наверное подустал и стал нетерпим, сорри
источник

AD

Alex Dem in Django [ru] #STAY HOME
Aquinary
:D
Естественно я понимаю, где админка, а где on_delete находятся
Тот ответ с админкой - было предположение, как можно решить эту проблему (полезно это закинуть, чтобы убедиться, что люди здесь не подскажут решения лучше этого)
ты изначально пришел с вопросом - как удалять пользовательские данные каскадом
вот админка здесь вообще непричем
источник

A

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

A

Aquinary in Django [ru] #STAY HOME
Поэтому и недопонимание
источник

AD

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

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

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

A

Aquinary in Django [ru] #STAY HOME
Alex Dem
я не думаю что у нас там как-то глобально отличаются уровни :))

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

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

AD

Alex Dem in Django [ru] #STAY HOME
Aquinary
К такому же выводу пришёл
Хотя мои текущие проблемы в тестировании спокойно решили бы тесты... до которых руки так и не дойдут
Да и есть опасение, что сами тесты по объему раза в два больше основного кода будут. Это нормальная практика, интересно?
не рискну утверждать в абсолюте, но у меня на работе часто так получается
зато живется потом спокойно, можно не уповать на работу QA
источник

НХ

Никита Хмель... in Django [ru] #STAY HOME
у меня у одного сердечко отсылается, когда я закрываю джангу на убунту? лол
источник

A

Aquinary in Django [ru] #STAY HOME
Alex Dem
не рискну утверждать в абсолюте, но у меня на работе часто так получается
зато живется потом спокойно, можно не уповать на работу QA
А как функционал реализуете, сразу весь или от приложения к приложению?
То есть если нужно написать приложение профиля, вы сразу пишите весь функционал к этому приложению или по мере возникающих связей?
Например, логин и пароль можно менять в профиле и это можно реализовать сразу
А вот просмотр отправленных сообщений на форум можно реализовать только после того, как будет написано приложение форума
(Я переживаю, что снова что-то не очень понятное скажу)
источник

AD

Alex Dem in Django [ru] #STAY HOME
Aquinary
А как функционал реализуете, сразу весь или от приложения к приложению?
То есть если нужно написать приложение профиля, вы сразу пишите весь функционал к этому приложению или по мере возникающих связей?
Например, логин и пароль можно менять в профиле и это можно реализовать сразу
А вот просмотр отправленных сообщений на форум можно реализовать только после того, как будет написано приложение форума
(Я переживаю, что снова что-то не очень понятное скажу)
функционал приходится допиливать по ходу дела, так как клиенты запрашивают обычно по чуть-чуть
и глобально уже все было когда я пришел
я скорее отдельные какие-то плюшки или модули допиливаю

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

A

Aquinary in Django [ru] #STAY HOME
Alex Dem
функционал приходится допиливать по ходу дела, так как клиенты запрашивают обычно по чуть-чуть
и глобально уже все было когда я пришел
я скорее отдельные какие-то плюшки или модули допиливаю

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

A

Aquinary in Django [ru] #STAY HOME
Вот кстати такой крохотный вопрос: есть два метода в модели
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

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

A

Aquinary in Django [ru] #STAY HOME
Aquinary
Вот кстати такой крохотный вопрос: есть два метода в модели
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

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

A

Aquinary in Django [ru] #STAY HOME
Aquinary
Вот кстати такой крохотный вопрос: есть два метода в модели
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

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

A

Aquinary in Django [ru] #STAY HOME
Или может нормальная практика прямо во вьюхе делать фильтрацию без дополнительной прослойки в виде методов? (именно простую фильтрацию без сложной логики, где ещё дополнительно данные нужно обработать)
источник