Псс чел, есть у меня для тебя порево! Решение "MySQL delete duplicate records but keep the latest" через один запрос без .extra() .group_by() и подзапросов но с созданием объектов Join(), WhereNode(), и ExtraWhere(), не обещаю полный разбор, но пофапать есть на что.
Кстати, .get() я уже расписывал, и что ошибка там была до Dj3.01
Спасибо @romblin, а что насчет builk_create и atomic transaction, разве это не аналогичный функционал в Джанго?
Соответственно если во втором примере - создание телефона для Don в Джанго - сделать через один запрос Phone.filter(user_Name=Don).create(**kwargs) - то в чем преимущество сессии?
Спрашиваю,т.к. смотрел на алхимию из Джанго-орм но больших преимуществ не нашел.
ну тогда так. Но шансов прервать процедуру принудительно не останется.
work=True
while work:
try:
log = self.queue.get(timeout=self.settings['time_quant'])
self.do_anything(log)
self.queue.task_done()
except Empty:
work = not self.stopped
except Exception as e:
self.queue.task_done()
Привет. Интересно было посмотреть, как работают новички с параллельным выполнением кода, спасибо.
Немного поправлю:
class ThreadPool:
def wait_empty_queue(self):
delay = self.settings['time_quant'] * self.settings['delay_on_exit_loop_iteration_in_quants']
while not self.queue.empty():
time.sleep(delay)
где Delay, вероятно, стоит вычислять отдельной функцией.
Кстати, большинство циклов в коде можно сделать генераторами.
ну и метод run явно может быть проще:
while not self.stopped:
try:
log = self.queue.get(timeout=self.settings['time_quant'])
self.do_anything(log)
self.queue.task_done()
except Empty:
pass
except Exception as e:
self.queue.task_done()
смотри. сам же пишешь сообщения об остановке выглядит как установка в значение True флага self.stopped.Так и проверяй его в первом цикле.
Отличие, в моем варианте в том, что если на сбое пришел стоп - мой вариант закончит раньше работу.
В твоем варианте будет считывать дальше из queue и делать do_anything пока не выпадет except Empty. Подумай, действительно ли ты уверен в двух циклах. Выглядит, неостанавливаемо, если self.stopped но не выпадает Empty
Привет, я прочел несколько книжек по Джанго, и поддерживаю предыдущего оратора. Дронова можно читать в случае если с английским беда. Иначе есть такие авторы:
Two scopes of Django. Много раз переизданная отвратная книжка по Джанго, где много примеров на python и мало на Джанго.
Django Project Blueprints - сухая книжка примеров без объяснений. Читать скучно, мне интересней было б полазать по репозиториям откуда взяты примеры.
Pro Django - хорошо было для изучения на 2009 год.
Мой фаворит это первая редакция Django Design Patterns and Best Practices. Автор хорошо передал идею как работать больше с Объектами Джанго и меньше с python-объектами. Вторая редакция тоже сойдёт, читается тяжелее.
Автор забыл cracing coding Interview. Этакая аптечка решений.
Я бы сказал еще, что зря пропущены Итан Маркот, Банда четырех, Дядюшка Боб.
Спасибо за статью, заглянул и в уроки, несколько посмотрел.
Подумал что нашел серебряную пулю... но увы. Для специфичных задач трясогузка не прокатит: мультитеннантность не доделали. Поскольку они используют Django.contrib.sites - то я знаю как допилить, даже статью писал об этом. Но так хотелось готового решения... :'(
Мультиязычность через modeltranlation если в проекте 32 языка замедлит каждое языковое дерево в Pages, так ещё и fallback всей страницы из дерева по умолчанию. Fallback только одного поля - ручками делать. Ну и с мультитеннантностью вообще не работает - одному сайт на хинди второму на немецком, а в модели, да и в админке и хинди и немецкий. Админку конечно можно допилить. Переводные Модели - нет.
Некоторые решения выглядят недоделанно. Pages это микс модели и администратора. Что ж они авторегистрацию полей для бэкэнда не сделали? Например по атрибуту поля модели. Модельные поля у них свои. Любой же атрибут могли добавить.
Бэк вагтайла выглядит благороднее винтажной админки чистого Джанго, но до Админ панели здоровой Python-cms (не существует в природе) ещё далеко.
Можно посмотреть меня на видео с PyCon второй день, первое выступление. Вроде видео уже есть. Или подождать когда я выложу статью. Увы в документации минимум.
недавно делал два доклада тут и тут, как раз про админку Django.
Стандартный select / raw_id_fields в принципе то да, для новой джанго завезли уже select2 из коробки. Работает отлично. Правда, ломает grapelli, если у кого стоял.
Фраза "выгружайте все необходимое одним запросом несовместима" с prefetch_related. Данные полей prefetch_related догружаются после отдельными запросами. Я бы в статье добавил активное использование "only", вот эта штука здорово заставляет подумать и получить только то, что надо.
Стоит убедится, что нигде не указываете ordering. Увы, даже если нигде ничего не указано, джанго приклеит .order_by(model._meta.pk.name)
SHOW TABLE STATUS LIKE table_name, не работает в случае предварительных фильтров. В случае мультитеннантности на разнобазовых запросах, придется переделывать запрос.
25 раз по мало < 1 раз много. Согласен, другой вопрос, если данные второй таблицы точно присутствуют, то можно переопределить тип джоина на INNER JOIN. для больших таблиц может быть быстрее.
перегрузить поиск. Прям да.В одном из моих проектов только этим и спасались. Только конечно все намного глобальнее. Сначала собирали ID по моделям из ModelAdmin.search_fields и потом filter(linked_model__id_in=id_set).
продумай заранее индексы. Спорно, поскольку заранее "соломку" не всегда успеешь подстелить.Про индексы в таблице с 62mln строк была Альбина Альмухаметова на pycon 2021 с докладом "Оптимизация i-запросов в Django+Postgres". От себя скажу, что один раз в моей жизни для убыстрения запросов индекс пришлось удалять.
сложные фильтры в админке. Бывает. Бизнесу не прикажешь работать проще. Но посмотреть на запросы стоит, иногда можно сформировать зпрос проще, чем это делает родной ORM
Работает только с недавнего момента. В ранних версиях Django возвращает EmptyQuerySet вместо type(super().get_queryset(request)). Если класс был переопределен, то все ломалось.
Не знаешь зачем тебе данные, не показывай. Понимаю что речь немного о другом, но сюда подходит текст про only. Этот метод точно заставить подумать "нужны ли мне все данные которые я получаю из базы".
Группируй модели в группы по смыслу.Вместо предложенной сомнительной батарейки можно использовать смысловое группирование по множественным SiteAdmins. Я в своих проектах использую именно эту возможность Django.
Мой вывод, что Django Contrib Admin + прямые руки помогут и графики показать и запросы сложные сделать и лишние батарейки деинсталлировать. Для красоты мне не хватает анимаций и переходов "из коробки", это пришлось допиливать другими средствами.
Спасибо @WarmongeR. Жаль я не прочел это в 2017. Пришлось разбираться самому.
Модель пользоваеля испортируем начиная с 2013 как:
from django.contrib.auth import get_user_model
UserModel = get_user_model()
Не придумываем в бизнес слое новые методы менеджера модели, поскольку хардкод, а используем методы менеджера.
Записью в файлы/потоки/память занимаются обьекты класса Storage из django.core.files.storage, у них даже метод по генерации уникального file_name есть (generate_filename).
Проблем с замкнутым импортом тех же моделей быть не должно при позднем связывании. Имеется в виду, что вызов сервиса с выдачей "имен" вообще не должен знать о моделях Django. Сервис знает, что должен использоватся публичный метод переданного в execute объекта или класса для выполнения своей работы. Пример из статьи: Бизнес задача выдавать csv/xls список имен обьектов. Передал User получил usernames, передал Store получил Storenames.
ну и напоследок - сам сервис у тебя никак не "low in coupling and high in cohesion", а именно для сервис слоя это особенно важно. В твоем примере - методы сервиса могут быть просто функциями модуля Service Layer.
@ChasingRainbows у меня есть четкое ощущение, что я уже читал нечто подобное на medum. Это перевод?
А теперь по делу. Историю развития hexagonal архитектуры Django проекта с выносом Service Layers хорошо подали Stéphane Angel и Joachim Jablon в статье Maintaning a Django project after 10.000 commits. Я писал об их суперполезном докладе на Django Conf 2019 (подраздел Редизайн вашего проекта Django). В видео есть упоминания статей и книг, развивающих эту идею. Спасибо тебе, что озвучиваешь эту тему еще раз, вдруг кому еще зайдет.
Привет, спасибо за примеры. Локализация циферок у нас была сделана за счёт сил базы, а теперь это можно апи-зировать, это хорошо. Но намного больше сил уходит на поддержание мультиязычности приложения. В статье в примерах есть статические тексты. Скажи, а чем у вас обрабатывают подобные тексты как вы с ними работаете?
Поправьте пожалуйста: Renault Zoe МОЖНО купить без аккумулятора и взять последний в аренду. В статье стоит "только". Я владелец Renault Zoe, купленного вместе с аккумулятором в официальном дилерском центре Renault.
Как же поразительно отличается опыт владения электромобилем у осознанных владельцев электромобиля от опыта тех, кому он достался потому что "выгодный лизинг план". Посмотрите комментарии к статье.
Я осознанный владелец неожиданно Renault Zoe. Мы в Австрии. Перед покупкой мы с супругой брали на день hyundai iconik, hindai kona, nissan leaf, tesla s, smart f4 Electro, Kia Niro и поехали покупать Kia Soul. А вернулись на Renault Zoe.
В отличие от дизельного Peugeot Partner который был запланирован, если идея с электромобилем не сработает, электромобиль сильно дороже. Почти в два раза - мы купили сразу с аккумулятором, хотя можно купить только машину а батарейку арендовать.
Нашей Zoe чуть больше года и мы довольны. Пробег 330-345км летом, 280-312 зимой. Зарядка из дома. На автобанах заправки-зарядки стоят как бензин. 43минуты на силовой зарядке оказалось мало - собаке пос-ать, кошке поменять насыпку, дочке помыть задницу мне и супруге кофе попить по очереди потому, как этот зоопарк без присмотра взорвется. И вуаля - 570 км спокойно до побережья Италии или до Вены или до Праги.
Я не заметил за год тех ограничений в мобильности, которые видятся или озвучены в статье. И да, электромобиль намного дороже машины с ДВС.
Псс чел, есть у меня для тебя порево! Решение "MySQL delete duplicate records but keep the latest" через один запрос без .extra() .group_by() и подзапросов но с созданием объектов Join(), WhereNode(), и ExtraWhere(), не обещаю полный разбор, но пофапать есть на что.
Кстати, .get() я уже расписывал, и что ошибка там была до Dj3.01
Спасибо за сочувствие. Согласен, что хороший дизайнер нам не помешает. Хорошо, что на знания фреймворка Django это не влияет.
не думаю, что этот комментарий относится к моей статье.
Да блин. Извини, Минус нажал хотя хотел по ссылке пройти. Вернул в карму.
Спасибо @romblin, а что насчет builk_create и atomic transaction, разве это не аналогичный функционал в Джанго?
Соответственно если во втором примере - создание телефона для Don в Джанго - сделать через один запрос Phone.filter(user_Name=Don).create(**kwargs) - то в чем преимущество сессии?
Спрашиваю,т.к. смотрел на алхимию из Джанго-орм но больших преимуществ не нашел.
ну тогда так. Но шансов прервать процедуру принудительно не останется.
это аналог твоего кода.
Привет. Интересно было посмотреть, как работают новички с параллельным выполнением кода, спасибо.
Немного поправлю:
где Delay, вероятно, стоит вычислять отдельной функцией.
Кстати, большинство циклов в коде можно сделать генераторами.
ну и метод run явно может быть проще:
смотри. сам же пишешь сообщения об остановке выглядит как установка в значение
Trueфлагаself.stopped.Так и проверяй его в первом цикле.Отличие, в моем варианте в том, что если на сбое пришел стоп - мой вариант закончит раньше работу.
В твоем варианте будет считывать дальше из queue и делать
do_anythingпока не выпадет except Empty. Подумай, действительно ли ты уверен в двух циклах. Выглядит, неостанавливаемо, если self.stopped но не выпадает Emptyпривет, есть видео моего доклада https://www.youtube.com/watch?v=8v2uaeV8MZo, первая половина про множественные SiteAdmins
Привет, я прочел несколько книжек по Джанго, и поддерживаю предыдущего оратора. Дронова можно читать в случае если с английским беда. Иначе есть такие авторы:
Two scopes of Django. Много раз переизданная отвратная книжка по Джанго, где много примеров на python и мало на Джанго.
Django Project Blueprints - сухая книжка примеров без объяснений. Читать скучно, мне интересней было б полазать по репозиториям откуда взяты примеры.
Pro Django - хорошо было для изучения на 2009 год.
Мой фаворит это первая редакция Django Design Patterns and Best Practices. Автор хорошо передал идею как работать больше с Объектами Джанго и меньше с python-объектами. Вторая редакция тоже сойдёт, читается тяжелее.
Автор забыл cracing coding Interview. Этакая аптечка решений.
Я бы сказал еще, что зря пропущены Итан Маркот, Банда четырех, Дядюшка Боб.
Это то что прям сейчас под рукой лежало.
Спасибо за статью, заглянул и в уроки, несколько посмотрел.
Подумал что нашел серебряную пулю... но увы. Для специфичных задач трясогузка не прокатит: мультитеннантность не доделали. Поскольку они используют Django.contrib.sites - то я знаю как допилить, даже статью писал об этом. Но так хотелось готового решения... :'(
Мультиязычность через modeltranlation если в проекте 32 языка замедлит каждое языковое дерево в Pages, так ещё и fallback всей страницы из дерева по умолчанию. Fallback только одного поля - ручками делать. Ну и с мультитеннантностью вообще не работает - одному сайт на хинди второму на немецком, а в модели, да и в админке и хинди и немецкий. Админку конечно можно допилить. Переводные Модели - нет.
Некоторые решения выглядят недоделанно. Pages это микс модели и администратора. Что ж они авторегистрацию полей для бэкэнда не сделали? Например по атрибуту поля модели. Модельные поля у них свои. Любой же атрибут могли добавить.
Бэк вагтайла выглядит благороднее винтажной админки чистого Джанго, но до Админ панели здоровой Python-cms (не существует в природе) ещё далеко.
Спасибо, в репозитории нет упоминаний djantic, нет заимствований, нет одних и тех же контрибьюторов. А идея да, одинаковая.
Обязательно попробую, благодарю за свежие новости.
Можно посмотреть меня на видео с PyCon второй день, первое выступление. Вроде видео уже есть. Или подождать когда я выложу статью. Увы в документации минимум.
django_admin_log индекс на какое-то из строковых obj_repr или message. При высокой частоте записи в лог.
Почему так, человечьим языком обьясняется тут
недавно делал два доклада тут и тут, как раз про админку Django.
Стандартный select / raw_id_fields в принципе то да, для новой джанго завезли уже select2 из коробки. Работает отлично. Правда, ломает grapelli, если у кого стоял.
Фраза "выгружайте все необходимое одним запросом несовместима" с prefetch_related. Данные полей prefetch_related догружаются после отдельными запросами. Я бы в статье добавил активное использование "only", вот эта штука здорово заставляет подумать и получить только то, что надо.
Стоит убедится, что нигде не указываете ordering. Увы, даже если нигде ничего не указано, джанго приклеит .order_by(model._meta.pk.name)
SHOW TABLE STATUS LIKE table_name, не работает в случае предварительных фильтров. В случае мультитеннантности на разнобазовых запросах, придется переделывать запрос.
25 раз по мало < 1 раз много. Согласен, другой вопрос, если данные второй таблицы точно присутствуют, то можно переопределить тип джоина на INNER JOIN. для больших таблиц может быть быстрее.
перегрузить поиск. Прям да. В одном из моих проектов только этим и спасались. Только конечно все намного глобальнее. Сначала собирали ID по моделям из ModelAdmin.search_fields и потом filter(linked_model__id_in=id_set).
продумай заранее индексы. Спорно, поскольку заранее "соломку" не всегда успеешь подстелить. Про индексы в таблице с 62mln строк была Альбина Альмухаметова на pycon 2021 с докладом "Оптимизация i-запросов в Django+Postgres". От себя скажу, что один раз в моей жизни для убыстрения запросов индекс пришлось удалять.
сложные фильтры в админке. Бывает. Бизнесу не прикажешь работать проще. Но посмотреть на запросы стоит, иногда можно сформировать зпрос проще, чем это делает родной ORM
Работает только с недавнего момента. В ранних версиях Django возвращает EmptyQuerySet вместо type(super().get_queryset(request)). Если класс был переопределен, то все ломалось.
Не знаешь зачем тебе данные, не показывай. Понимаю что речь немного о другом, но сюда подходит текст про only. Этот метод точно заставить подумать "нужны ли мне все данные которые я получаю из базы".
Группируй модели в группы по смыслу. Вместо предложенной сомнительной батарейки можно использовать смысловое группирование по множественным SiteAdmins. Я в своих проектах использую именно эту возможность Django.
Мой вывод, что Django Contrib Admin + прямые руки помогут и графики показать и запросы сложные сделать и лишние батарейки деинсталлировать. Для красоты мне не хватает анимаций и переходов "из коробки", это пришлось допиливать другими средствами.
Спасибо @WarmongeR. Жаль я не прочел это в 2017. Пришлось разбираться самому.
эээ ребят, ModelAdmin.show_full_result_countNew in Django 1.8 (April 1, 2015)Сначала немного ворчания:
Модель пользоваеля испортируем начиная с 2013 как:
Не придумываем в бизнес слое новые методы менеджера модели, поскольку хардкод, а используем методы менеджера.
Записью в файлы/потоки/память занимаются обьекты класса Storage из django.core.files.storage, у них даже метод по генерации уникального file_name есть (generate_filename).
Проблем с замкнутым импортом тех же моделей быть не должно при позднем связывании. Имеется в виду, что вызов сервиса с выдачей "имен" вообще не должен знать о моделях Django. Сервис знает, что должен использоватся публичный метод переданного в execute объекта или класса для выполнения своей работы. Пример из статьи: Бизнес задача выдавать csv/xls список имен обьектов. Передал User получил usernames, передал Store получил Storenames.
ну и напоследок - сам сервис у тебя никак не "low in coupling and high in cohesion", а именно для сервис слоя это особенно важно. В твоем примере - методы сервиса могут быть просто функциями модуля Service Layer.
@ChasingRainbows у меня есть четкое ощущение, что я уже читал нечто подобное на medum. Это перевод?
А теперь по делу. Историю развития hexagonal архитектуры Django проекта с выносом Service Layers хорошо подали Stéphane Angel и Joachim Jablon в статье Maintaning a Django project after 10.000 commits. Я писал об их суперполезном докладе на Django Conf 2019 (подраздел Редизайн вашего проекта Django). В видео есть упоминания статей и книг, развивающих эту идею. Спасибо тебе, что озвучиваешь эту тему еще раз, вдруг кому еще зайдет.
Привет, спасибо за примеры. Локализация циферок у нас была сделана за счёт сил базы, а теперь это можно апи-зировать, это хорошо. Но намного больше сил уходит на поддержание мультиязычности приложения. В статье в примерах есть статические тексты. Скажи, а чем у вас обрабатывают подобные тексты как вы с ними работаете?
Привет. Задание Можно доделать:
Консоль sqlite3 импортирует CSV.
Стоит не клеить CSV а по-файлово выгружать в базу и отслеживать вывод ошибок. Изучение отслеживания вывода предупреждений.
Можно сделать через Fabric - изучение модуля автоматизации процессов.
Ну и конечно же можно сделать через питоновские читалки xls/xlsx и научиться работать, например, с датафреймами пандас.
Норм пример для обучения, если у вас есть потом фидбек от ментора.
Поправьте пожалуйста: Renault Zoe МОЖНО купить без аккумулятора и взять последний в аренду. В статье стоит "только". Я владелец Renault Zoe, купленного вместе с аккумулятором в официальном дилерском центре Renault.
Как же поразительно отличается опыт владения электромобилем у осознанных владельцев электромобиля от опыта тех, кому он достался потому что "выгодный лизинг план". Посмотрите комментарии к статье.
Я осознанный владелец неожиданно Renault Zoe. Мы в Австрии. Перед покупкой мы с супругой брали на день hyundai iconik, hindai kona, nissan leaf, tesla s, smart f4 Electro, Kia Niro и поехали покупать Kia Soul. А вернулись на Renault Zoe.
В отличие от дизельного Peugeot Partner который был запланирован, если идея с электромобилем не сработает, электромобиль сильно дороже. Почти в два раза - мы купили сразу с аккумулятором, хотя можно купить только машину а батарейку арендовать.
Нашей Zoe чуть больше года и мы довольны. Пробег 330-345км летом, 280-312 зимой. Зарядка из дома. На автобанах заправки-зарядки стоят как бензин. 43минуты на силовой зарядке оказалось мало - собаке пос-ать, кошке поменять насыпку, дочке помыть задницу мне и супруге кофе попить по очереди потому, как этот зоопарк без присмотра взорвется. И вуаля - 570 км спокойно до побережья Италии или до Вены или до Праги.
Я не заметил за год тех ограничений в мобильности, которые видятся или озвучены в статье. И да, электромобиль намного дороже машины с ДВС.