1. пгик

    16.01.2009

    0 ↑
    0 ↓
    Совсем новичок в Django и Python, но имею некоторый опыт работы с PostgreSQL и хочу использовать несколько фишек продвинутой СУБД, к которым успел привыкнуть. Посему несколько вопросов:

    1. Довольно часто использую колонки со свойствами NOT NULL DEFAULT custom_expression, причем custom_expression важно вычислять именно в базе. Создавая инстанс модели в Django, соответственно, эти поля я не хочу задавать, а джанга при m.save() насильно подставляет NULL-ы в незаполненные аттрибуты. Есть ли возможность создавать INSERT и UPDATE только на основании заполненных полей?

    2. Хочу использовать INSERT ... RETURNING вместо некорректного INSERT ...; SELECT currval() (достаточно подумать о менеджерах соединений, которые могут ротировать бакенды СУБД между запросами, и становится страшно от inconsistency, к которой эта ошибка может привести), нашел совсем свежий патч http://code.djangoproject.com/attachment/ticket/3460/insertwithreturning.patch и не знаю что с ним делать. То есть вопрос по сути в том, какова политика применения таких патчей (ну то есть я его себе сейчас применю, а в джанге его отрежектят, например, и буду я потом мучаться с обновлением джанги) и насколько можно использовать в production HEAD джанги, если такие патчи быстро попадают в репозиторий?

    3. Кто-нибудь делал модели с поддержкой наследования таблиц в PostgreSQL? У меня есть абстрактная таблица, от которой отнаследованы еще несколько таблиц, в джанге организовал наследование и все вроде хорошо, кроме полей типа ForeignKey из абстрактной таблицы на таблицы-инстансы. Есть ли у кого-нибудь примеры моделей в джанго с чем-нибудь подобным?

    4. Есть ли у кого-нибудь примеры написания custom field types для каких-нибудь хороших типов PostgreSQL? Видел здесь на форуме TsvectorField (но не до конца полноценный из-за отсутствия поддержки собственного lookup-а). Написал по аналогии HstoreField, но еще не проверил и опять понятно, что с lookup-ом придется извращаться... Может, кто-то работает с GiST/GIN-типами?

    5. Правильно я понимаю, что IntegerField корректно работает с 64-битными интами?

    Буду признателен за любые комментарии по использованию Django в приложениях на основе PostgreSQL.

  2. Иван Сагалаев

    16.01.2009

    0 ↑
    0 ↓

    Рискну сказать, что скорее всего Джанго — не ваш инструмент. Насколько я могу судить (то есть это мое наблюдение извне, а не позиция корных разработчиков), вынесение логики обеспечения целостности данных из базы на уровень приложения — сознательный выбор. База третируется как некое усредненное хранилище, и какие-то отдельные фичи отдельных бэкендов используются только если без этого было бы совсем плохо.

    Однако, в принципе ничто вам не мешает использовать Джанго как веб-фреймворк, не пользуясь его db api (которое все называют ORM). Вы, правда, не сможете пользоваться фичами, рассчитанными на него — админкой например. Но админка в Джанго, все же, не главное.

    И несколько конкретных ответов.

    Есть ли возможность создавать INSERT и UPDATE только на основании заполненных полей?

    Нет. Дефолты для полей в Джанге считаются в Питоне.

    нашел совсем свежий патч http://code.djangoproject.com/attachment/ticket/3460/insertwithreturning.patch и не знаю что с ним делать. То есть вопрос по сути в том, какова политика применения таких патчей

    У этого тикета проблема... Он пытается делать много глобальных вещей, и конкретно вот эта замена на insert .. returning там похоронена между кучи других патчей. Боюсь, ни один комиттер не приступит к этой штуке без глобального решения заняться проблемой. А это может быть долго.

    Вот отдельно неприменение insert .. returning — это просто баг, который надо исправить. Поэтому тут верная модель поведения — завести отдельный тикет конкретно про это, четко описать проблему и сделать патч с тестами (последнее обязательно). Потом еще можно вылезти в django-developers@ и рассказать, в каких случаях без этого патча все будет ломаться.

    Но это, конечно, не оперативное решение.

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

    Проблемы такого рода обычно решаются заведением у себя локальной копии Джанги под какой-нибудь распределенной системой контроля версий. Насколько я знаю, все три известных (git, mercurial, bazaar) в явном виде поддерживают такой usecase: поддержка локальных патчей к upstream'у.

    насколько можно использовать в production HEAD джанги, если такие патчи быстро попадают в репозиторий?

    HEAD использовать вполне можно, мы в Яндексе на транке живем. Конечно делать svn up прямо на рабочей директории не стоит во избежание... У нас очередной снапшот транка успевает где-то с пару-тройку недель вылежаться на разработческих машинах. А потом — ура в продакшн.

    Кто-нибудь делал модели с поддержкой наследования таблиц в PostgreSQL?

    Ни разу не слышал.

    Правильно я понимаю, что IntegerField корректно работает с 64-битными интами?

    Нет. Есть тикет: http://code.djangoproject.com/ticket/399. Но тут можно патча и не ждать, сделать свой вариант IntegerField'а с правильным типом колонки как раз очень просто.

  3. пгик

    19.01.2009

    0 ↑
    0 ↓
    Иван, спасибо за разъяснения и комментарии.

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

  4. Иван Сагалаев

    19.01.2009

    0 ↑
    0 ↓

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

    Ну я там дальше уточнил, что не вся Джанго, а только ORM — не ваш инструмент. Ну да и бес с ним :-)

  5. Grigory Fateyev

    19.01.2009

    0 ↑
    0 ↓
    ORM — не ваш инструмент. Ну да и бес с ним :-)
    А как же новые "вкусности", агрегация? Очень удобно...

  6. Иван Сагалаев

    19.01.2009

    0 ↑
    0 ↓

    Григорий, почитайте в первом посте, что требуется. Это просто не то направление, куда джанговский ORM идет.

  7. пгик

    19.01.2009

    0 ↑
    0 ↓
    Но вот как раз от ORM совсем отказываться не хочется. Админки всякие и готовые вещи для новичков мне совсем не нужны, но хочется уметь делать save(), update() и get(). Хочется сразу иметь маппинг каких-нибудь постгресовых массивов или хешей в соотв. питоновские структуры, хочется подгружать объекты по внешним ссылкам в базе и т.п. Все-таки немного не хватает гибкости джанге в этом отношении. Нет такой цели у фреймворка, я понимаю, но все же...

  8. redbaron

    19.01.2009

    0 ↑
    0 ↓
    Если не нужны админки и готовые вещи, то вкручивайте sqlalchemy руками и будет у вас вменяемый ORM ;)

  9. проходил тут..

    21.01.2009

    0 ↑
    0 ↓
    может лучше посмотреть в сторону например http://openobject.com/
    он боллее ориентирован на Постгрес, ну и одержите и WEB и GUI

Внимание! Это довольно старый топик, посты в него не попадут в новые, и их никто не увидит. Пишите пост, если хотите просто дополнить топик, а чтобы задать новый вопрос — начните новый.