Raw query must include the primary key

Как и любое достижение прогресса ORM-ы в каких-то кейсах хороши и удобны, а в некоторые моменты - раздражают. Например, когда речь о Django и случае, когда ты хочеш выполнить raw-запрос с группировкой ( чтобы не париться с нечевидными annotate и импортом нужных агрегатных функций ) . Пример:

r = CourseStudent.objects.raw("select course_id, count(*) as c from coursestudent group by course_id order by c")

В ответ мы видим:

Raw query must include the primary key

WTF? Как я вам воткну pk в запрос с группировкой по произвольному ключу ? К счастью, обойти просто - вот такой запрос спокойно отработает:

r = CourseStudent.objects.raw("select course_id as id, count(*) as c from coursestudent group by course_id order by c")

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

Migration is applied before its dependency on database

Разбираемся с ошибкой

Migration B is applied before its dependency A on database

Django version 1.11 Поселектив табличку %%django_migrations%% можно выяснить точную хронологию применения миграций и дальше выправить ее руками. Автоматически такое разрулить, по-видимому, не выйдет.

Еще раз про юникод в perl и злосчастный Wide character in subroutine entry

Многие perl скриптеры  порой впадают в ступор от Wide character in subroutine entry. Хорошо, если знают хотя бы примерно о том, что такое Wide character, хуже , если нет. Хорошо, если начинают копать матчасть и разбираются с в общем-то нехитрой работой с юникодом в perl, хуже, если начинают наобум тыкать в use utf8, encode/decode... На выходе порой может получиться забавная инструкция с кучей вызовов на всякий случай.. она может даже будет работать, но подобный модуль будет доставлять всем вокруг головную боль. Итак, все просто: 1. если имеешь дело с данными из внешнего источника - проверяй их перед употреблением на is_utf8 и дальше действуй по обстоятельствам: либо кодируй, либо декодируй - но осознанно. 2. если имеешь дело со строковыми константами , то достаточно сказать use utf8 , чтобы для интерпретатора все константы скрипта были помечены не как последовательность байт, а именно как юникод-строка. 3. чтобы перевести в последовательность байт из юникода - decode 4. чтобы перевести из последовательности байт в юникод - encode помните о том, кто будет вас дергать и описывайте свои входы и выходы а также свою политику относительно внутренней работы со строками ( работаете как с последовательностю байт или как со юникод-строками ) и все будет хорошо.

Классическая проблема верстки - выравнивание блоков

Часто встречается ситуация, когда некий контейнер "набивается" float-ом дочерними элементами . На макете все красиво и ровно. На практике, после того как начинается работа с реальным контентом (например содержимое категории товаров в магазине), то однотипные блоки получаются разными по высоте. Проблему можно решить принудительным транкейтом содержимого, подбором "максимальной" фиксированной высоты или javascript-ом. Пример кода, решающего подобную проблему (используется jQuery):

//делаем высоту всех .thumbnail одинаковой
   var  max_height = 0;
 $('.thumbnail').each(function(){
    h = $(this).height();
   if(h > max_height){
     max_height = h;
    };
   });
 $('.thumbnail').css('height',max_height);

Этот код хорошо отработает , например , в IE, а вот Chrome могут быть проблемы, если в .thumnail внутри есть изображение. На момент вычисления height оно еще может быть не загруженным и поэтому полученные величины height и width могут очень удивить верстальщика :) Поэтому код надо модифицировать , например, вот так:

$(document).ready(function(){
//делаем высоту всех .thumbnail одинаковой только после полной загрузки всей страницы
   var  max_height = 0;
 $('.thumbnail').each(function(){
    h = $(this).height();
   if(h > max_height){
     max_height = h;
    };
   });
 $('.thumbnail').css('height',max_height);
});

Unable to find vcvarsall.bat

Часто при установке некоторых python-библиотек (PIL, django-imagestore .. ) под windows возникает ошибка:

Unable to find vcvarsall.bat

Причина отсутствии или невозможности при установке найти нужный Сишный компилятор, который как правило есть  в поставке MS VS.

Для решения проблемы совсем необязательно ставить "студию". Можно обойтись компилятором mingw:

1. качаем отсюда и ставим
2. скачиваем нужную python - библиотеку и выполняем для ее setup.py :

setup.py install build --compiler=mingw32

Перед этим не забудьте прописать путь к mingw32.exe в PATH (например C:\mingw\bin)

django-rest-framework - некоторые особенности

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

Сразу отмечу, что авторы этого приложения большие молодцы - документация на фреймворк сделана в виде пошагового туториала - фактически онлайн учебника. На первых шагах все делается стандартными механизмами. И дальше, по мере продвижения, авторы упрощают код с помощью многочисленных "плюшек" , которые предоставляет их приложение. Советую для лучшего понимания и во избежание последующего недопонимания :) именно так и поступать, а не копипастить конечные синтаксические конструкции.
Хотя при этом могут и проблемы возникнуть . Например, на одном из шагов авторы предлагают реализовать rest-вьюхи  как обычные function-based django views, сопровождая их декоратором api_view. Этот шаг - исключение и его лучше пропустить, сразу перейдя к class based views , иначе возникнет ошибка:

Cannot apply DjangoModelPermissions on a view that does not have `.model` or `.queryset` property.

Но и после перехода в class-based views не забываем указывать model или queryset в полях вьюшного класса.

Unicode

Для того, чтобы в отдаваемом REST-ом контенте корректно отображался Unicode необходимо в settings явно прописать UnicodeJSONRenderer.

Например:

REST_FRAMEWORK = {
 
    'DEFAULT_RENDERER_CLASSES': (
        'rest_framework.renderers.UnicodeJSONRenderer',
    )
}

Выбор решения для организации API на django-сайте

Возникла задача в одном из моих django-проектов предоставить API для взаимодействия с некоей внешней системой.
Первоначальный выбор пал на django-piston. Реализовать операции read-доступа к объектам БД удалось довольно быстро, но вот с операцией создания объекта начались проблемы, частично решив которые и получив новые , решил выбрать другое решение.. Уж больно надоело патчить чужую библиотеку.
Другое решение - это Django Rest Framework. Знакомство с отзывами и документацией обещает менее нервную разработку. К непосредственной попытке использования приступлю на днях.
Постараюсь не забыть задокументировать здесь все особенности и подводные камни, если таковые найдутся :)

django: форма обратной связи с аттачами и проверкой на вирусы

Предыстория

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

В процессе обсуждений  выяснилось, что файлов надо аттачить "сколько хочешь".

А чтобы заказчик не "словил вирусняк" через эти самые аттачи , я решил реализовать сканирование.

Было 2 варианта:

• настроить на серваке (linux) какой-нибудь , желательно бесплатный , антивирусный демон 
• использовать API какого-нибудь авторитетного онлайн сервиса

Я остановился на втором варианте, тем более что был немного знаком с Virustotal. 

Бегло ознакомился с доками на его API . 

Проверил работоспособность его тестовых примеров  - все ок. 

И приступил к "допиливанию" имеющейся формы обратной связи.

Как только причешу код , чтобы было не стыдно опубликовать на bitbucket, то детально опишу реализацию.

Кому не терпится - пишите, торопИте :)

django-lfs: особенности работы со скидками

Текущая стабильная версия 0.7.7

В django-lfs есть два механизма работы со скидками:

1. назначать скидку каждому товару отдельно в карточке товара
2. создавать глобальные скидки, которые действуют в зависимости от критериев (например общая сумма покупки в корзине) - данные скидки применяются не к отдельным  товарам ,  а к всему содержимому корзины.

Особенность в том, что при наличии обоих скидок они суммируются.

При использовании данной и более младших версий django-lfs вместе с django >= 1.4 есть проблема с интерфейсом управления -  а именно бага при работе с критериями. Суть ошибки и как  ее решить  я уже описывал здесь.

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

Доработать не трудно. 

1. добавляем нужное поле в Discount 
2. добавляем колонку в таблицу discount_discount (если база уже существует) или пересоздаем базу (если старого контента не жалко :)
3. добавляем нужный html-шаблон для страницы со списком скидок
4. добавляем view, которая будет рендерить этот шаблон
5. добавляем url, по которому это view будет "дергаться"

кому нужен патч - пишите.

django-lfs: установка на Windows 7

Установка django-lfs  подробно описана здесь

Но у установки под windows есть несколько особенностей, которые не описаны на официальном сайте

Исходные данные:

• windows7 64 bin
• python 2.7 , установленный , например в c:\Python27

Требуется установить django-lfs (на текущий момент версия 0.7.7)

1. качаем инсталлятор http://pypi.python.org/pypi/django-lfs
2. распаковываем куда нам нужно
3. cd lfs-installer
4. качаем правильный bootstrap.py 
5. python bootstrap.py
6. качаем win-инсталлятор для библиотеки PIL (так как установщик ругнется на отсутствие батника vcvarsall.bat)
7. создаем ключ в реестре HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.7\InstallPath со значением, которое копируем из ключа  HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.7\InstallPath  - без этой манипуляции инсталлятор PIL "ругнется"  Python27 not found
8. удаляем Pillow из списка зависимостей djanfo-lfs (файл: lfs-installer\eggs\django_lfs-0.7.7-py2.7.egg\EGG-INFO\requires)
9. устанавливаем PIL
10. bin/buildout.exe -v
11. указываем параметры доступа к базе данных (предполагается, что она уже создана)  в settings to lfs_project/settings.py
12. $ bin/django syncdb
13. $ bin/django lfs_init
14. $ bin/django collectstatic
15. $ bin/django runserver
16. Открываем дефолтный магазин http://localhost:8000 и торгуем :)