Не SQL'ем единым или как я попробовал buzhug

Недавно встала задача реализовать один сервис(аналог cron) на питоне. Для души так сказать. Одна из подзадачь: организация хранения данных. При первой итерации было решено использовать SQLite бэкэнд. Поскольку одним из требований к сервису был малый объем занимаемой памяти в процессе работы, т.к. ресурсы моего впс ограничены. Но после маленьких испытаний я понял, то SQLite не очень интересен для меня, как для вечно что-то новое пробующего разработчика, и не так уж и лайт, да и ничего нового. Подумал, а почему бы не использовать какой-нибудь из ORM движков. Стал пробовать и SQLAlchemy и SQLObject. Но эти варианты отпугнули своей тяжеловесность, хотя и интересны в плане изучения не джанговского ORM.

И вот однажды, на одном из регулярно читаемых мной форумов заприметил упоминание одной очень занятной библиотеки buzhug. Как обещают её авторы - мне не надо будет писать SQL запросы, а придется писать list comprehensions or generator expressions. Заманчиво и интересно.

Попробовал пример из туториала. Понравилось ещё больше. Всё просто и прозрачно. Решил остановить свой выбор на этой библиотеке и познакомиться с ней поближе.

Когда сервис был завершен в своей первой редакции, я осознал, что сделал правильный выбор. Код получился лаконичным и действительно без SQL запросов. Работать с данными удобно. Немного напрягло то, что база представляет собой директорию на диске и то, что имеет ограниченный набор поддерживаемых типов полей (по сути только строки, числа и даты). Хотелось бы ещё чтобы можно было сериализовать объекты, ну или на худой конец списки и словари, pure python как никак. Пока сделал через pickle конвертацию таких объектов в строку.

Одно меня пока огорчает, проверить все функции(особенно различные выборки данных) пока не получилось. Требования сервиса ограничились банальной CRUD'ом и какие-то мудреные селекты не понадобились. Но я сам себе придумал ещё одну задачу(менеджер очередей), в которой как мне кажется buzhug сможет раскрыть весь (ну или почти весь) свой потенциал.

О новых эмоциях обязательно напишу.

Комментарии 4

  1. d v s написал:

    Хотелось бы ещё чтобы можно было сериализовать объекты, ну или на худой конец списки и словари, pure python как никак. Пока сделал через pickle конвертацию таких объектов в строку.

    Durus/ZODB?

    Оставлен 08 Декабрь 2007 в 17:42
  2. Александр Кошелев написал:

    Durus/ZODB? Если честно то ни с одним, ни с другим не работал. Все впечатления у меня о этих технологиях исключительно сложились по описаниям и примерам кода, которые я видел. Так вот, Durus вполне мог бы мне и подойти(учитывая начальные условия, которые мне требовалось соблюсти), а вот ZODB наверно слишком тяжеловат. Хотя это всё эмоции со стороны. Надо бы попробовать лично. Спасибо за наводку.

    Оставлен 08 Декабрь 2007 в 20:35
  3. d v s написал:

    Хотелось бы ещё чтобы можно было сериализовать объекты, ну или на худой конец списки и словари, pure python как никак. Пока сделал через pickle конвертацию таких объектов в строку.

    Durus/ZODB?

    Оставлен 31 Декабрь 2007 в 02:22
  4. d v s написал:

    Хотелось бы ещё чтобы можно было сериализовать объекты, ну или на худой конец списки и словари, pure python как никак. Пока сделал через pickle конвертацию таких объектов в строку.

    Durus/ZODB?

    Оставлен 31 Декабрь 2007 в 05:22