Oduvan's Web Blog » Python

Python. Json. Как не сериализировать уже сериализированое

Oduvan — Thu, 13 Oct 2011 13:00:32 +0000

Бомбезное название придумал!

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

Решение в лоп – загрузится с этих полей данные и использовать их в формировании жсона. Но получается дурная работа

return json.dumps({
'user_id':request.user.id
'user_data':request.user.data(),
'info_1':json.loads(model_obj.info1),
'info_2':json.loads(model_obj.info2)
})

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

import json
loads = json.loads
class JSONotEncode(object):
def __init__(self,data):
self.str = data
def simple(data):
return JSONotEncode(data)
class JSONEncoderSimple(json.JSONEncoder):
def _iterencode(self,obj,*args,**kwargs):
if isinstance(obj, JSONotEncode):
return obj.str
return json.JSONEncoder._iterencode(self,obj,*args,**kwargs)
def dumps(data):
return json.dumps(data,cls=JSONEncoderSimple)
def loads(data):
return json.loads(data)
if __name__ == '__main__':
print dumps({'a':1,'b':'sdr','c':simple('{"v":1}')})

Как видите, теперь данные, которые и так JSON просто оборачиваем в функцию simple и холостого хода не происходит.

Share and Enjoy:

Django. Быстрый способ сохранить копию объекта

Oduvan — Tue, 12 Jul 2011 00:36:28 +0000

from money.models import Trans
cur_model = Trans.objects.all()[0]
// and make a copy
cur_model.pk = None
cur_model.save() //ha ha

Share and Enjoy:

Методология написания тестов в Django с использованием fixtures

Oduvan — Fri, 10 Jun 2011 19:37:14 +0000

В Django есть такая удобная вещь для написания тестов — это fixtures. Удобство состоит в том, что ваши тесты могут входить в уже заполненный данными проект. Например тестируем работу админчасти статистики, надо иметь готовый массив данных, с которым оперируем и проверяем результаты. Неудобство состоит в том, что эти фикстуры надо где взять, надо поддерживать актуальными, такими-же актуальными как и тесты. Вот как раз и про неудобную часть, а также паре подводных камней я бы и хотел вам рассказать.

Получаем фикстуру

python manage.py dumpdata > all_data.json

Рассказывать, что это означает я не буду, но то есть хорошая документация по фикстурам у самой Django .

Я «обплетал» тесты уже готового написанного проекта. В нагрузку с проектом идет дамп базы, которая, как это не удивительно, может быть не целостная. Самый часты бок — это когда записи по форенключу нет. Например у Вас есть профиль, но нет юзера или есть транзакция между не существующими счетами.

Самое обидное, что Джанго Вам не поможет решить эту проблему. И получите что-то типа
Error: Unable to serialize database:

Нагугил тикет в Django Code:
https://code.djangoproject.com/ticket/6773

К которому прилагается команда, которая показывает Вам «разбитые модели», т. е. модели не полные с неверными данными в ForeignKey .
Я ее немного приукрасил возможностью удалять их автоматом https://gist.github.com/1018947. Для реальных данных удаление автоматом — это не очень обдуманный шаг, но мне сейчас надо получить хоть какую-то фикстуру.

Подержание актуальности фикстуры

Для поддержки актуальности базы между всеми разработчиками используется django-south, мне кажется это уже давно стало стандартом Django разработки. Тот же механизм можно использовать для поддержки актуальности с фикстурами, поэтому я одну фикстуру полностью перегоняю в sqlite3 базу, которую как и фикстуру держу в репозитарии проекта и для доступа к которой использую отдельный сетингс.

Сеттингс файл для этого состоит из 3х строчек (settings_lights.py):

from settings import *
DATABASES['default']['ENGINE'] ='django.db.backends.sqlite3'
DATABASES['default']['NAME'] = 'lights.db'

Как известно, в любую команду можно передать не стандартное имя сетингс модуля.

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

python manage.py runserver 0:8001 –settings=settings_lights
python manage.py dumpdata –setting=settings_lights > all_data.json

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

python manage.py migrate –settings=settings_lights
python manage.py dumpdata –setting=settings_lights > all_data.json

Тестирование

Для тестирования я использую тот-же settings_lights.py для того, чтобы использовать sqlite3 в тестах, при этом для тестов вся база будет держаться в памяти, что существенно ускорит процесс написания тестов и тестирования их.

python manage.py test –settings=settings_lights

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

python manage.py test

А собственно сам текст тестов может выглядить так:

from django.test import TestCase
from django.test.client import Client
from django.contrib.auth.models import User
class SimpleTest(TestCase):
fixtures = ['all_data.json']
def setUp(self):
self.client = Client()
def test_details(self):
print User.objects.all()

Этот пример ничего не тестирует, а просто показывает Вам, что данные на момент запуска тестов в базе уже есть. Фикстуры можно хранить как в папке fixtures любой апы, не только тестируемой. А еще в сетингсах можно прописать:

FIXTURE_DIRS = (
'/path/to/myapp/fixtures/',
)

Проблема с сигналами

Про сигналы в Django вы можете почитать в документции.

Фикстура — это по сути сериализация ОРМ объектов, т. е. объект будет сохранен как json, как просто текст. А значит загрузка из фикстуры — это поочередное добавление всех объектов, а добавление объектов связано с вызовом сигналов, которые в свою очередь могу сами создавать объекты моделей или изменять существующие.

Например. У Вас есть 2 модели счета и транзакции. При добавлении транзакции — дергается сигнал, по которому изменяются балансы счетов участников этой транзакции. При подготовке фикстуры вы создали одну транзакцию между двумя счетами на сумму 100 рублей, т. е. после ее проведения на одном счету прибавится 100 рублей, а на другой вычтится. Вы сохраните полученные данные в файл фикстуры, в которой будут готовые записи со счетами и транзакциями. Во время тестирования этот файл будет загружаться и вначале загрузятся модели счетов – на одном 100, на другом -100. После загрузятся транзакции и дернут сигнал, который еще раз изменит балансы на счетах и мы во время тестирования увидим состояния на счетах 200 и -200.

Решение у джанги есть , но почему-то не документированное, и как по мне — очень не удачное.

В обработчик сигнала передается параметр raw который True во время загрузки фиксутры.

Так что, если вы не хотите, чтоб обработчик сигнала работал в момент загрузки фикстуры, то первые 3 строчки вашего обработчика могут выглядит так:

def trans_save(sender, instance, raw, **kwargs):
if raw:
return

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

У меня все. Я описал то, как с фикстурами работаю я, и очевидно, что они могут сэкономить очень много времени Вам при разработке тестов, а также могут помогать Вам делать более качественные и реальные тесты.

Хотелось бы в комментариях увидеть критику такого подхода, дополнения, подводные камни, с которым вы сталкиваетесь. Буду дополнять статью Вашими цитатами и идеями.

Спасибо, и удачных Вам выходных.

Share and Enjoy:

UCSVLOG

Oduvan — Mon, 03 Jan 2011 00:48:04 +0000

Я уже когда-то писал и думал о системе логирования на основе csv формата. С начало идею, а потом первую версию для джанги.

Но в процессе пользования этой системы вылезло несколько недостатков.

1. В таком формате легко потерять целостность логов. Например скрипт ведения логов упал в момент из записи. Срока разорвалась в момент записи одно из полей и все. Вся БД логов потеряна
2. Надо заранее знать количество полей в логе

Поэтому я разработал другой формат – UCSV. И модуль для ведения логов на его основе python-ucsvlog.

В этом формате нет конца ни у записи ни у ячейки, есть только начало записи и начало ячейки. В этом случае конец ячейки — это просто начало следующей или начало следующей строки.

Начало записи — это перевод строки
а начало ячейки — это просто ”
ну и из csv формата — кавычка в данных ячейки заменяеться двумя

В этом случае нам не надо волноваться за целостность всех логов. В случае падения мы потеряем только одну строку

Вместе с логером я написал потоковый парсер. Ему не надо знать, какого размера у тебя файл, он читает файл порционно и порционно импортирует данные в БД. Все это происходит довольно просто и без регекспов.

Класс импорта в SQLite — ReaderSqlite. Правда во время импорта данных у которых в записи неограниченное число ячеек столбцы добавляются по ходу.

Из csv логов я забрал идею древовидности логов. Когда у каждой записи есть ключ, привязанный ко времени создания и ключ парент записи. За это отвечают 2 первые ячейки в записи. А также авторендеринг — имя файла логов можно задавать в виде шаблона. Например ‘/logs/%(syear)s-%(month)s-%(day)s.ucsv’

Для джанги я создал отдельный пакет django-ucsvlog. Те кто пользовался django-csvlog смогут легко перескочить. Поддержку последнего я осуществлять более не буду.

По мере пользования этой системы логирования я буду собирать еще один компонент django-ucsvlog-analytics. В нем будут собраны скрипты для анализа логов. Например профилирование, оно очевидно из-за привязки ко времени логов. Можно сводить статистику — самые тяжелые страницы + самые часто запрашиваемые и получать то, что надо оптимизировать в первую очередь. Или например анализ юзабилити. Можно вычислять точки не возврата, страницы, которые пользователь посещал в последний раз, или на какую страницу переходят после указанной ( иногда только такая сухая статика может убедить клиента в неюзабельность предложенного им варианта ). Можно делать каунтеры посещений определенных страниц, сколько уникальных просмотров было на этом альбоме. Можно увидеть путь по сайту определенного пользователя.

Такие логи дают много возможностей, и список «можно» – можно продолжать бесконечно. Пробуйте.
python-ucsvlog, django-ucsvlog, django-ucsvlog-analytics

Share and Enjoy:

Можно быстрее и красивее?

Oduvan — Sat, 03 Jul 2010 13:22:57 +0000

Как поменять местами ключи и значения в дикте?

d = {1:2,3:4,5:6}
dict(zip(d.values(),d.keys()))

Share and Enjoy:

Допоплнительные точки расширения Вашего апа

Oduvan — Thu, 01 Jul 2010 16:40:19 +0000

при создании нового джанго проекта я всегда выделяю две папки apps – для моих апов и compat – для сторонних апов, к разработки которых я не имею никакого отношения. Идея в том, что эти апы всегда остаются неприкосновенными для меня, и единственной точкой расширения остаются сеттингсы и возможно доп параметры, при инклюде урлов.

А представьте, что вы создаете апу с именем catalog, ее вы потом хотите выложить в общее пользования, и необходимо для нее сделать больше точек расширения. Структура такого апа может быть

catalog

urls.py
views.py
models.py
settings.py
tests.py

для 4 первых файлов можно просто вконце файла добавить строку, которая станет универсальной точкой расширения. Например для views.py

try:
from ex_catalog.views import *
except ImportError:
pass

таким образом, если кто-то будет использовать Вашу апу — точкой расширения будет дополнительная апа ex_catalog, в котором вы можете переопределить некоторый функции из view.py, и при этом ex_catalog не надо добавлять в список апов в настройках.

А теперь главный вопрос этого поста. Почему так не делают?

Share and Enjoy:

Fabric – деплойтинг должен быть легким и быстрым

Oduvan — Tue, 22 Jun 2010 21:22:18 +0000

Чем меньше рутины мы привносим в свою работу, тем больше она может приносить удовольствия.

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

Я Вам расскажу про Fabric(На момент написания статьи 0.9.1 — бала последняя стабильная версия), наиболее подходящий для этого инструмент, который делает все описанное и даже больше через ssh.

Про установку рассказывать особо нечего, pip отлично справляется с этим.

В корень своего проекта я кладу fabfile.py, в этом файле и будут храниться все процедуры для работы с Fabric. Ниже приведу небольшой пример скрипта, который будет архивировать наш проект, заливать его на сервер и там разархивировать.

from fabric.api import *
env.hosts = ['oduvan@lyabah.com']
def deploy():
local('tar czf /tmp/my_project.tgz .')
put('/tmp/my_project.tgz', '/tmp/')
with cd('/home/oduvan/www/test_fab/'):
run('tar xzf /tmp/my_project.tgz')

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

$ fab deploy
[localhost] run: tar czf /tmp/my_project.tgz .
Password for oduvan@lyabah.com:
[oduvan@lyabah.com] put: /tmp/my_project.tgz -> /tmp/my_project.tgz
[oduvan@lyabah.com] run: tar xzf /tmp/my_project.tgz
[oduvan@lyabah.com] err: tar: ./fabfile.pyc: time stamp 2010-06-21 10:03:41 is 4.461083597 s in the future
[oduvan@lyabah.com] err: tar: .: time stamp 2010-06-21 10:03:41 is 4.460804762 s in the future
Done.
Disconnecting from lyabah.com… done.

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

Кому лень вводить пароли могу добавить после второй сроки
env.password = ‘oh_its_my_real_password’

либо сгенерить себе файл с ссш ключом и путь к нему положить в
env.key_filename — в отличие и пароля тут может быть передан массив ключей

Но и этот код можно сократить. У Fabric есть contrib libs, одна из них project. Тут подробно каждую я описывать не буду, просто покажу пример с одной из них, дабы просто показать, что они есть

from fabric.api import *
from fabric.contrib.project import rsync_project
env.hosts = ['oduvan@lyabah.com']
def deploy():
local('python manage.py test', capture=False)
rsync_project('/home/oduvan/www/test_fab/','.')

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

Вот основные команды, которые Вам необходимо знать, чтоб свободно пользоваться Fabric

put — копировать файл с локальной машины на удаленную. Доп параметр mode — устанавливает права на файл, см chmod
get — копировать файл с удаленной на локальную
local — выполнить команду на локальной машине. Доп параметр capture — скрывать выходные данные, по умолчанию False
run — выполнить команду на удаленной машине
sudo — выполнить команду на удаленной машине через судо. Доп параметр user — указываем имя пользователя, под которым необходимо запустить команду

Обратите внимание, что у нас есть команда sudo, а значит при необходимости, мы можем и сервак зарелоадить и вообще сделать любые админ вещи, главное, чтоб пользователь был в судоерсах.

Для деплойтинга на несколько серверов, причем различной конфигурации, и роли – у Fabric тоже кое-что припасено.

from fabric.api import *
from fabric.contrib.project import rsync_project
env.roledefs = {'web':['oduvan@lyabah.com','oduvan@dev.lyabah.com'],
'db':['oduvan@db1.lyabah.com','oduvan@db2.lyabah.com'],
'media':['oduvan@media@lyabah.com'],
}
@roles('web')
def deploy():
rsync_project('/home/oduvan/www/test_fab/','.')

в этом примере заливка файлов будет идти сразу на 2 вебовых сервака. Как видите вы можете запланировать у себя роли отдельных серверов под БД, под медиа файл и т.д.

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

$ fab deploy -R web

Иногда в момент или во время запуска необходимо передать данные скрипту.

В момент запуска это делается через аргументы самой функции

к примеру если у вас

def deploy(arg1,arg2):
pass

то эти 2 аргумента можно передать как

$fab deploy:'HI','HO'
$ fab deploy:'HI',arg2='HO'
$ fab deploy:arg1='HI',arg2='HO'

Либо спросить что-то во время работы функции у пользователя функцией
prompt(text, key=None, default=”, validate=None)

Задает вопрос пользователю с текстом text, если пользователь не вводит данные, то возвращает значение из default, предварительно отчищая его функцией validate, и возвращает как результат этой функции, если не передан key, иначе кладет значение в env[key]

А теперь примеры функций деплойтинга из реальной жизни, которые вы можете написать и у себя в проекте:

bounce_wsgi_procs — зарелоадить wsgi через touch в него
deploy_media — загружаем только медиа файлы
migrate — запускаем скрипт миграции через South
update_repositories – обновляем репозитарии
update_dependencies — устанавливаем зависимости
reload_nginx — перегружаем nginx
deploy — полная установка, последовательный запуск всех этих функций.

Подводя итоги могу сказать, что Fabric должна стать musthave tool в разработке.

Share and Enjoy:

Django. URLUp – играться с урлами стало легче

Oduvan — Fri, 04 Jun 2010 11:37:16 +0000

Сложные выборки. Например, какая-то страница результатов. Там где много-много фильтров, + еще какие-то сортировки появились + все это надо прогнать через пейджирование. Выглядит страшно, но тем не менее задача банальная. Меня в этой задаче больше всего расстраивает шаманство с урлами. Ведь по факту Вам все эти параметры выборки надо уместить в урл, и каждой функции, например, смены страницы или смены направления сортировки — надо переформировать ссылку.

Через несколько минут у меня появился тег, который как всегда выношу на Ваш суд. Перед просмотром исходников, покажу, как он работает:

{% load djoutils_tags_url %}
Ordering:
Name UP
Name Down
Last Name UP
Lase Name Down

Paging:

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

Исходники чуда тега можно увидеть тут.

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

Share and Enjoy:

DevConf::Python

Oduvan — Sun, 09 May 2010 07:19:15 +0000

Думаю съездить на DevConf, который пройдет в Москве 17ого числа.

Программа, как мне кажется, будет интересная. Не обойдут стороной нашу любимую Джангу. Да и дополнятся она еще будет. Не может не радовать обилие кофебрейков и перерывов, это на всех питонячих конфах такое?

Интервью Ивана Салагаева о конфе о питоне и не только.

А вы что думаете? Стоит слетать в Россию?

Share and Enjoy:

Vim as IDE for Python

Oduvan — Wed, 05 May 2010 20:27:07 +0000

Мда. Экономней надо кодить. Мой эклипс с pydev и аптаной на борту не кисло оперотивочки съедает, а это, с появлением в моей семье нового нетбучного малыша – стало большой проблемой. И начал я посматривать в сторону VIMа. Не очень хочется прощаться с приятными IDE-шными фичами.

Вот то, что у меня получилось, после того, как я досмерти замучал глупыми вопросами весь pythonua@conference.jabber.ru

Тут у нас слева по F5 мы видим все функции и классы открытого файла, а по F6 файловый менеджер.

Вот архив с моими настройками и плагиными vim.zip. Тем, у кого вим вообще никак не настроен – можно просто взять и распоказать это в свой хоум.

Так что начинаю потихоньку прывыкать к виму. Думаю по мере развития этого моего нового пристрастия – буду вам писать.

Ну и на последок несколько ссылок в тему.

Статья на тему интеграции питона и вима. Хоть и старая но еще вполне актуальна. Да и вообще этот блог про вим очень хорош. На нем же наткнулся на подборочку команд для работы с вимом. Ну а кому показалось, что это банальная и маленькая подборочка – вот эта вам разорвет мозг.

Спасибо deepwalker за помощь и пояснения и за львиную часть его конфига вима

PS: А еще есть GVIM тоже, только в окошке и с менюшками.

Share and Enjoy: