Oduvan's Web Blog

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 и холостого хода не происходит.

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

Об оговорках или “Мопед не мой, я просто разместил объяву…”

Oduvan — Mon, 27 Jun 2011 13:16:58 +0000

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

“Сразу скажу, что это мое личное мнение…”

“Я не профи, и могу что-то упустить…”

“Не бейте сильно, я недавно пишу…”

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

Первое, что мне непонятно – так это зачем это писать? Что за детская неуверенность и робость. Ну правда. Ну написал ты статью, ну к примеру, тюнинг конфига mysql. И в конце – “ну статья не может быть полной, и я не являюсь большим специалистом в MySQL поэтому не бейте меня сильно”. А я читаю это а в голове продолжение: ” … поэтому тупо хвалите меня и восхищайтесь мной”

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

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

А какая по Вашему идеальная концовка должна быть в постах?

Методология написания тестов в 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

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

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

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

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

Еще немного искусства

Oduvan — Fri, 03 Jun 2011 08:27:19 +0000

Обещаю, дальше будет по теме

Пользуйтесь сонцезащитными кремами

Oduvan — Sun, 08 May 2011 12:17:39 +0000

Фансы и шортсы. Такого программирования вы еще не видели :)

Oduvan — Sat, 07 May 2011 11:40:48 +0000

Вчера для CheckIO придумали вам новую развлекуху, друзья мои, на эти выходные

Идея развлекухи в том, что надо придумать максимально необычное решение для самой обычной задачи. Например, самое простое из раздела Funny, и проще уже не придумаешь - Funny addition. На вход – массив из 2х интов, а на выходе их сумма. Но функция sum(data) – это же не смешно. Смешнее что-то вроде max(data) + min(data).

Заходим, пишем свое аморальное решение, и рейтенгуем решения друзей.

По результатам выложу сюда топ аморальщины. Развлекайтесь и удачных вым выходных

ЗЫ: У нас есть еще прикольные шортсы, но о них уже в другой раз

ЧекЁ или почему я не сплю последние несколько месяцев

Oduvan — Sun, 24 Apr 2011 17:20:59 +0000

Я последние несколько месяцев любую свободную минутку посвящаю именно этому проекту www.checkio.org, т. к. чувствую, что делаю что-то полезное, что-то что может помогать молоды специалистам.

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

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

Так-же у нас на стадии тестирования терниры между программами. И первой задачей для турнира сейчас выбрана игра five in row. Надо написать программу, которая будет играть в эту игру, в простонародье – бота

После прохождения квалификации — вы сами, интерактивно, можете поиграть в нее. Можете поиграть с другими программами на арене. Турнир между программами у нас запланирован на конец мая. Хотелось бы увидеть по больше участников, должно быть интересно.

Еще хотелось бы услышать от вас отзыв. Как Вам проект?

Мы снова в сети

Oduvan — Fri, 18 Mar 2011 11:39:51 +0000

После нескольких месяцев скитаний моего блога, он снова ожил и обжился баджетами моего твитера, фейсбука и линкедина.

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

В блоге буду продолжать раскрывать тему питона и разработки в целом. А в твитере короткие идеи и анонсы на эту тему

Мы никуда не пропадали, мы просто болели, так что не переключайте.

UCSVLOG. Нужна точка.

Oduvan — Mon, 10 Jan 2011 23:39:31 +0000

Это продолжение моего общения с собой на тему логов.

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

Например у Вас такая часть лога

"date time,"log,"inc sum: 100

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

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

Так что теперь наша запись в логах меняется на следующую:
"date time,"log,"inc sum: 100,".

В принципе можно заморочиться на том, чтоб записи, в которых реально только одна точка – заменять на 2, а 2 – на 3. Ну т.е. при парсе надо понимать, что если в записи – одни точки, то нужно уменьшить их кол на одну. Но чем дольше я об этом думаю, тем больше понимаю, что это уже перебор. И такую погрешность можно взять в учет.

Откуда вообще у меня тараканы в голове на тему логов.

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

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

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