LINUX.ORG.RU

Работа с несколькими схемами в PostgreSQL из Django

 , ,


0

4

Есть база данных на PostgreSQL с очень большим количеством схем. Нужно научиться работать с ней из Django, а для этого нужно указывать моделям не только имя таблицы, но и имя схемы, в которой они хранятся. Умеет ли Django такое? Интернет заполнен утверждениями для разных версий, что не умеет, но вдруг это уже не так? Я использую Django 1.9. Вообще в Django я новичок, мог пропустить что-то очень большое и заметное, извините.

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

Вариант «Использовать search path», вы будете смеяться, тоже никак не подходит, потому что во многих схемах то и дело попадаются повторяющиеся имена таблиц, т.е. без указания схем будут конфликты имён.

Такая вот ситуёвина. На ЛОР вся надежда. Иначе мне, новичку в Django, придётся идти и патчить Django, а никому лучше от этого явно не станет. =)



Последнее исправление: greatperson (всего исправлений: 4)
Ответ на: комментарий от pawnhearts

Увы, он пока лишь убирает необходимость юзать стрёмное экранирование кавычек внутри имён таблиц (интернеты говорят, что так сейчас принято делать, чтобы «проинъектить» нужную конструкцию в джанговский запрос). А миграции всё ещё WIP. На данный момент в них что без этого патча, что с ним генерятся невалидные имена в CREATE INDEX и подобном. Так что смысла юзать прямо сейчас сало, увы.

greatperson
() автор топика
Последнее исправление: greatperson (всего исправлений: 1)
Ответ на: комментарий от pawnhearts

Да, уже сам присматриваюсь к Flask вместо Django. Flask как раз включает SQLAlchemy. Ещё понравилось, что SQLAlchemy (как я понял) умеет в many-to-many таблицы без лишних айдишников, а Django как будто не умеет.

Я правильно думаю, что, отказываясь от джанговских моделей, уже не имеет особого смысла использовать остальной Django? Ну разве что потом узнаю о какой-то киллер-фиче в его шаблонизаторе и пожалею о переходе. А кроме моделей да шаблонов – что от него остаётся-то?

greatperson
() автор топика
Последнее исправление: greatperson (всего исправлений: 1)
Ответ на: комментарий от Goury

А что, например?

Валидация форм (которые придётся вручную создавать по не-джанговским моделям)?

Миграции (которые я буду писать вручную, если использовать джанговские миграции с не-джанговскими моделями)?

Сессии и безопасность какие-то сверхкрутые?

Я правда не в курсе, ради чего ещё выбирают джанго. От чего не стоит отказываться! По сравнению с «микрофреймворком» Flask или ещё с чем-то.

greatperson
() автор топика
Ответ на: комментарий от greatperson

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

Deleted
()
Ответ на: комментарий от FIL

Вообще да, говорят, сегодня и релизнулся. А я начал приобщаться несколько дней назад и сразу на него сел, он был RC.

greatperson
() автор топика
Ответ на: комментарий от greatperson

Никто не мешает тебе прикрутить sqlalchemy сбоку джанги. Есть всякие решения для этого есть, можешь погуглить.

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

Алхимия гораздо мощнее конечно, если у тебя что-то сильно за рамками возможностей django orm лучше её взять. Иначе намучаешься.

pawnhearts ★★★★★
()
Ответ на: комментарий от vurdalak

Он имеет в виду суррогатные ключи, наверное. Не знаю, создаются ли они для автогенерируемых m2m-таблиц.

Deleted
()
Ответ на: комментарий от vurdalak

Это когда таблица articles_to_tags состоит из article_id и tag_id (составляющих вместе уникальный ключ, его же достаточно). А не из id, article_id и tag_id.

greatperson
() автор топика
Ответ на: комментарий от vurdalak

В джанге нельзя создать композитный ключ, т.к. архитектурно было решено все сделать через поле «id». Поэтому его не надо указывать в моделях (оно по умолчанию), поэтому к нему можно обращаться через магический атрибут pk. Проблема известна 10 лет (https://code.djangoproject.com/ticket/373) и как мне известно её решение потребует перепиливания ОРМ и админки как минимум. В админке тоже все завязано на «id», я так понял что изначально такое решение было принято под нее.

uralbash
()
Ответ на: комментарий от uralbash

Не обязательно id, это может быть любое поле, для которого указано primary_key=True. Но композитных ключей нет, да.

В джанго orm вообще дофига такого. Сейчас стало получше, потому что запилили Aggregation, Func, Conditional Expressions и т.п. Почти не приходиться писать sql руками хотя бы в элементраных случаях.

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

pawnhearts ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.