Менедежеру проекта например сказал. Зваисит от структуры команды,

Менеджер сказалд дизайнеру, дизайнер нарисовал, отдал верстаку. Верстак сделал правку.\

Окей, но у вас в команде все в курсе чехарды с лишними запросами

Менеджер говорит кодеру - "посмотри, хотим вывести новые поля, подкрути бекенд, пока дизайнер их рисует"

Кодер крутит. Все, что надо, за один раз за итерацию

Не отвлекаясь на запросы верстальщика каждые пять минут

Ты можешь попытаться поченить это с помощью процесса, но это не ознапчает что нет проблемы. Я видел проекты на джанге где 800 sql запрпосов на страницу. Из-за таких элементарных вещей. Да и у самого посмототянно такие проблемы вознимают. Пишешь пишешь, смотрешь у тебя вдруг 300 запросов на странице. А потом оказалось, что гдето там добавили теги или еще что-то.

Так исключения-то зачем? Ставишь тулзу для дебага и следишь за числом запросов на странице

Эффект тот же

Верстальщик следить чтоли будет? Я эту страницу месяц назад сделал и большее ее не трогал.

А такие вещи тестированием могут покрываться?

В плане количества запросов относительно количества объектов, или что-то в этом роде.

Почему нет?

С такой панелшью даже ребенок разберется

Ну например debug тулбар не работает в jinja2. Во вторых он сильно тормозной. В третьих SQL запросы это не отвественность версиальщика.

Тестируйте время отклика?

Ну например debug тулбар не работает в jinja2. Во вторых он сильно тормозной. В третьих SQL запросы это не отвественность версиальщика.

Ну, согласитесь, что дёргать разработчика для фикса исключения тоже вариант не лучше, чем поставить "тормозную панель".

Это лучше, потому что проблема в любом случае должна быть пофиксена. И лучшее ее пофиксить сразу, чем потому мучаться искать, откуда взялся этот запрос.

В проекте были сломанные миграции. Хочу сделать новые. БД уже существует. 1) удалил все файлы миграций в проекте. 2) удалил все записи в таблице django_migration. 3) makemigrations. 4) migrate —fake-initial. Получил ошибку column "name" of relation "django_content_type" does not exist . Погуглил, говорят, там какие-то изменения в джанге были, т.е. я так понял, это не совсем мой косяк, а побочный эффект от изменений джанги. Кто-то может подробнее про это рассказать?

Перезапусти девсервер

причем тут это?

просто сделай

я миграции делаю с локального ПК, просто подключил БД нужную в настроках

не пойму, что перезапускать

Возможно, поменялся порядок создания таблиц в новой миграции, и у тебя где-то внешний ключ ссылается на несуществующую колонку или таблицу?

у меня модели полностью БД соответствуют

Ну джанго прилложение тогда перезапусти там где миграции деалал

Ну джанго прилложение тогда перезапусти там где миграции деалал

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

Мб код миграции куда-нибудь на пастбин закинешь?

Мб код миграции куда-нибудь на пастбин закинешь?

знать бы, что именно запостить. Миграциии, где есть упоминание "django_content_type"?

Ну там с контент тайпом какая-то магия, оно создается при запуске сервера, а не при миграциях.

сейчас апп запущу локально

ничего не поменялось

там есть такая запись, в одном из файлов dependencies = [ ('auth', '0007_alter_validators_add_error_messages'), ('contenttypes', '0002_remove_content_type_name'), ] . но в таблице django_content_type nameуже нет, т.к. моя БД существует УЖЕ

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

Хм. Тогда все, что могу предложить - руками добавить эту колонку или попробовать удалить эту зависимость, если это в своей миграции

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

ну это геморный вариант)

Я бы руками просто добавил эту колонку, все равно очевидно, что миграция из зависимости ее удалит, так что в базе потом она мешаться не будет

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

Судя по тому, что я нагуглил, это реально просто отличия в бд разных версий. Но я глубоко в это не вникал

accounts [ ] 0001_initial [ ] 0002_emailconfirmation_user admin [ ] 0001_initial [ ] 0002_logentry_remove_auto_add auth [ ] 0001_initial [ ] 0002_alter_permission_name_max_length [ ] 0003_alter_user_email_max_length [ ] 0004_alter_user_username_opts [ ] 0005_alter_user_last_login_null [ ] 0006_require_contenttypes_0002 [ ] 0007_alter_validators_add_error_messages competitions [ ] 0001_initial [ ] 0002_auto_20170403_1155 contenttypes [X] 0001_initial [ ] 0002_remove_content_type_name core [ ] 0001_initial [ ] 0002_auto_20170403_1155 fileimport (no migrations) guardian [ ] 0001_initial news [ ] 0001_initial roles [ ] 0001_initial [ ] 0002_auto_20170403_1155 sessions [ ] 0001_initial users [ ] 0001_initial

это showmigrations

По поводу select_related, я так понимаю, если его не делать, то в моем случае так же порождаются дополнительные запросы к базе? Листинг: http://vpaste.net/iSf0U

http://stackoverflow.com/questions/30545562/django-column-name-of-relation-django-content-type-does-not-exist

Django 1.8 changed its internal data base structures and the column name is no longer existing in the data base (see is taken from the verbose_name attribute of the model). To adress this, a migration contenttypes-0002_remove_content_type_name is automatically created. Usually, all your migrations should ahve been applied and this should be recorded in the table django_migrations and all should be fine. If you for example did a backup of your data base using dumpdata, cleared (flushed) all data base content, and loaded the dump with loaddata, your django_migrations table remains empty. Thus, migrate tries to apply all migrations again (even though your tables are existing), and it fails when it tries to remove the non-existing column name.

http://stackoverflow.com/questions/30545562/django-column-name-of-relation-django-content-type-does-not-exist

да я это нагуглил, спасибо)

По поводу select_related, я так понимаю, если его не делать, то в моем случае так же порождаются дополнительные запросы к базе? Листинг: http://vpaste.net/iSf0U

Достаточно во вьюхе заменить model = Post на def get_queryset(self): return Post.objects.all().select_related('author') ?

Это к вопросу, зачем Джанга эту колонку создает, потом удаляет

Перед тем как что то пилить, посетите djangopackages.com

я посещаю, но по статистике часто получается так, что проще напилить вот к примеру с hijack, у меня кастомный юзер, а hijack-admin хочет разрегистрировать модель... упс!

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

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

Подскажите что за панель, пожалуйста.

Нашел: https://github.com/jazzband/django-debug-toolbar

Ага, она самая

какого типа создать поле у модели, чтобы оно было похоже на choiceField, но в базе не хранились возможные значения?

в смысле не хранились ?

и зачем тогда создавать моле ?

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

какого типа создать поле у модели, чтобы оно было похоже на choiceField, но в базе не хранились возможные значения?

в базе и не хранятся возможные значения, они в коде хранятся в базе это обычный charfield или integerfield

если создам обычный charfield, то как в админке сделать чтобы нужно было выбрать из нескольких вариантов?

https://docs.djangoproject.com/en/1.10/ref/models/fields/#choices

choices=ТВОИ ЧОИСЫ

о, спасибо. Всем чойсов

Народ кто "щупал" django-channels? Стоит оно того или лучше на aiohttp переползать?

подскажите как лучше хранить конфиг сайта, вроде title сайта меню и тп. в базе

такая single object таблица в бд

django-solo

https://github.com/lazybird/django-solo

thx

https://github.com/lazybird/django-solo

О, крутая штука!

Народ Есть ли какая нить штука, чтоб вывела суммарные release notes с версии на версию? Ну то есть 1.7 -> 1.10 и посмотреть все деприкейтед, etc...

подскажите как лучше хранить конфиг сайта, вроде title сайта меню и тп. в базе

https://pypi.python.org/pypi/django-dynamic-preferences лучше

Народ Есть ли какая нить штука, чтоб вывела суммарные release notes с версии на версию? Ну то есть 1.7 -> 1.10 и посмотреть все деприкейтед, etc...

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

и переходить надо аккуратно в случае больших приложений, по одной версии за раз

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

Ну вот смотри, есть задача обнвить джангу скажем с 1.7 до 1.10 Я ж не знаю всех нотисов, но нужно как то оценить время... следовательно было бы удобнее наблюдать некую сводку, с чем придётся столкнуться

Ну вот смотри, есть задача обнвить джангу скажем с 1.7 до 1.10 Я ж не знаю всех нотисов, но нужно как то оценить время... следовательно было бы удобнее наблюдать некую сводку, с чем придётся столкнуться

релиз нотес от 1.8 размером 35 пейдждаунов. И что из этого лишнее - только ты знаешь Кому-то критично важно знать про django.utils.html.remove_tags() and removetags template filter, а кому-то - изменения в gis.

Я к тому, чтоб не пришлось переписывать одно и тоже по несколько раз. Допустим в 1.8 выпилили какой то метод, мол юзайте теперь метод2, однако этот метод2 выпиливатся в 1.10 и нужно юзать метод3... так вот удобнее было бы иметь инфу метод -> метод3, а не метод->метод2->метод3

Если нет такого, ну что ж... будем по старинке)))

народ подскажите у меня есть N записей у каждой записи есть tags нужно вытащить максимально похожие по тегам записи

https://www.postgresql.org/docs/9.1/static/fuzzystrmatch.html

народ подскажите у меня есть N записей у каждой записи есть tags нужно вытащить максимально похожие по тегам записи

А сколько уникальных тегов?

В 1.10 добавили поддержку postgresql триграмов

ну и если не лень- можно настроить django-haystack

А сколько уникальных тегов?

сложно сказать количество растет

У похожести должен быть какой-то критерий, "похожие" - понятие размытое. Обычно можно использовать склоения тезариуса и search в постгри.

наверно не совсем правильно объяснил

нужно вытащить записи отсортированные по максимальному количеству общих тегов

Тогда можно использовать функции включения из postgres.arrayfield

https://docs.djangoproject.com/en/1.10/ref/contrib/postgres/fields/#arrayfield

ну и надо сказать что теги хранятся в отдельной таблице и связыны many to many

как то тут ссылка на трекер на джанго пролетала, не могу найти, напомните плз

трекер для задач, сделано,не сделано и тд

taiga.io

taiga.io

спасибо. а такой чтобы себе на хостинг поставить?

Ну он на гитхабе в открытом доступе)