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


Работаем с оракловыми курсорами в Python с помощью библиотеки cx_Oracle

Курсорная переменная может возвращаться в качестве результата хранимой процедуры, написанной на PL/SQL. Например, вот такой:


create or replace procedure test_cur(
    a number,
    b number,
    p_ret out sys_refcursor)
is
begin
  open
p_ret for select a + level-1 v from dual
          connect by level <= b;
end;

Для работы с СУБД Oracle из Python есть весьма хорошая библиотека cx_Oracle . С курсорами работа построена там очень просто - они объявляются как обычные типизированные переменные библиотеки, в данном случае с типом курсора. Всё очень просто, смотрим на примере:




# -*- coding: utf-8 -*-


DJANGO и ORACLE VIEWS

Я использую связку DJANGO + ORACLE. Как известно, эта связка из стандартных бэкендов наименее проработана. Например, проблема с TRUNC DATE - адепты PostgreSQL передают туда 'hour', а для Oracle нужно 'HH24'. И таких мелких проблем очень много. К счастью, все эти проблемы решаемы, иногда даже без хаков db backenda django.
Итак, ситуация. Пишу B2B приложение, две базы Oracle связаны по dblinkу, одна корпоративная, где ведется учет и вторая специально под сайт. Чтобы не заниматься репликацией между базами было решено сделать несколько представлений на стороне web-базы. Для удобства я решил подложить под них модели, но столкнулся с проблемой syncdb - Oracle вполне ожидаемо не смог создать таблицы (которые по сути были не нужны), потому как имена были уже заняты соответствующими представлениями. Вопрос - как заставить django при синхронизации просматривать не только список таблиц, но также и список представлений?
Первое решение в лоб - как известно, django при проверке таблиц под



Заметка на полях - custom sql в Django.

Задача - при развертывании схемы Django на базу создавать триггер на таблицу. Пошел по стандартному пути - создал в директории приложения папку sql, положил туда файл имя_модели.sql Выполняю manage.py syncdb - ошибка ORA-0900, ругается на неправильный код. При выполнении того же кода в sqlplus - никаких ошибок. Посмотрел через sqlcustom - код вменяемый. Напрягло только наличие пустых строк в коде, а этого тот же sqlplus не переносит. Убрал все переводы строк - текст триггера стал выглядеть отвратно, но теперь он выполняется. Бинго!
Вывод - при создании хранимых процедур, функций и пакетов проверяйте скрипты через sqlcustom - вывод не должен содержать пустых строк.

Нашел также еще один баг - в скрипте создания триггера джанго вырезал последний символ

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