Посты с тэгом db


Python: Работа с базой данных, часть 1/2: Используем DB-API

Python DB-API – это не конкретная библиотека, а набор правил, которым подчиняются отдельные модули, реализующие работу с конкретными базами данных. Отдельные нюансы реализации для разных баз могут отличаться, но общие принципы позволяют использовать один и тот же подход при работе с разными базами данных.

В статье рассмотрены основные методы DB-API, позволяющие полноценно работать с базой данных. Полный список можете найти по ссылкам в конец статьи.

Требуемый уровень подготовки: базовое понимание синтаксиса SQL и Python.
Читать дальше →


Генерация фиктивных данных с Elizabeth: Часть II


Ранее я уже публиковал статью о том, как генерировать фиктивные данные, при помощи Elizabeth — библиотеки для языка программирования Python. Статья, которую вы читаете является продолжением предыдущей, потому я не буду приводить основ работы с библиотекой. Если вы пропустили статью, поленились прочитать или просто не захотели, то, вероятно, захотите сейчас, ибо эта статья подразумевает, что читатель уже знаком с основами библиотеки. В этой части статьи, я буду говорить о том, каким образом организовывать генерацию фиктивных данных в собственных приложениях, расскажу о нескольких, на мой взгляд, полезных особенностях библиотеки. Примеров кода будет не много, но по сути.

Читать дальше →


Django DB Mailer — простая и удобная батарейка, для отправки почтовых сообщений в вашем проекте


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

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

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

Для подобных решений существует простая батарейка, призванная решить большинство подобных проблем


[Из песочницы] Связка ExtJS+Django+Apache+SVN deploy (и простой CRUD контроллер на Django)

Предисловие

Сразу хочу попросить прощения за столь перегруженную статью, но для меня сейчас всё это актуально и связано. Думаю что некоторым это может пригодиться для будущей разработки. Хочу обратить внимание, что в этой статье я не стану рассказывать вам как устанавливать те или иные тривиальные вещи, установка которых, к тому же, зависит от той или иной платформы. Также в статье я не описываю телодвижения по настройке прав доступа к файлам сервера, опять же, это зависит от реализации. В статье описан процесс настройки на PDC сервер с именем tci.lan, все имена сохранены, в вашем случае их следует заменить на соответствующие вам. Данная статья содержит код, для улучшения читаемости он спрятан в спойлерах. Читать дальше →


SQLAlchemy: как втянуться

SQLAlchemy сейчас - очевидный лидер ORM в питоне, но у неë есть один довольно неприятный недостаток: чтобы начать пользоваться, приходится прочитать немало документации. Поэтому я решил написать (очень) короткий пост-введение в алхимию.

Уровень 1: SQL руками

Первым делом нам нужно соединение к базе, с которым можно что-то делать:

>>> from sqlalchemy import create_engine
>>> e = create_engine('mysql://user:pass@host/db')
>>> for r in e.execute('select * from table where id < %s', 2):
...     print dict(r)


SQLAlchemy: как втянуться

SQLAlchemy сейчас – очевидный лидер ORM в питоне, но у неë есть один довольно неприятный недостаток: чтобы начать пользоваться, приходится прочитать немало документации. Поэтому я решил написать (очень) короткий пост-введение в алхимию.

Уровень 1: SQL руками

Первым делом нам нужно соединение к базе, с которым можно что-то делать:

Если хочется именованных параметров, можно использовать text():

Из объектов, которые получаются итерацией результата – RowProxy - данные можно вытаскивать и индексом, и ключом, и атрибутом:

Нужна транзакция?

Это уже что-то и так можно жить, тем более что оно экранирует параметры автоматически.

Уровень 2: SQL-выражения в питоне

Можно получить объект таблицы из базы (с автоопределением колонок) и работать с ним, если так будет удобнее:

Т.е. абсолютно идентичный запрос, но уже в питоне.

Уровень 3: ORM

Ну и если приятнее с объектами работать,



Сохранение времени в базе данных

Очень часто бывает, что практически все знают, как надо делать правильно, но при этом всё равно постоянно делают неправильно. Один из таких случаев — сохрание времени в базе данных. Понятно, что на персональном блоге вполне можно обойтись наивных подходом, не учитывающим перевод времени. Но для круглосуточно работающих приложений строгой системы отчётности вроде биллинга это неприемлемо.
Я не буду здесь рассматривать все возможные варианты корректной работы со временем. Покажу лишь насколько просто можно реализовать самый распространённый вариант — хранение в базе в UTC — на примере SQLAlchemy. Для этого достаточно определить новый тип колонки:
from sqlalchemy import types
from dateutil.tz import tzutc
from datetime import datetime

class UTCDateTime(types.TypeDecorator):

    impl = types.DateTime

    def process_bind_param(self, value, engine):
        if value is not None:
            return value.astimezone(tzutc())

    def process_res


Логгинг в базу или борьба с рекурсией

Как-то понадобилось мне сделать логгинг в базу для модуля logging. Сразу видна очевидная проблема: внутри такого обработчика идёт сохранения в базу некоторыми принятыми в проекте средствами, которые сами используют logging. В результате обработчик рекусивно будет вызывать себя и зацикливаться. Понятно, что можно отбросить привычные средства и сделать либо логгинг своими средствами без использования стандартного пакета logging, либо в базу писать низкоуровневым кодом, который logging не использует. Но это всё не интересно и ведёт за собой неудобства в использовании.
Первая мысль была выставлять флаг в обработчике перед записью в базу и снимать его после. Но это без ухищрений не будет работать в многопоточном приложении, а ведь есть ещё и обработчики сигналов. А нельзя ли определить, что обработчик был вызван из самого себя? Оказывается, можно — с помощью средств работы со стеком интерпретатора в модуле i