Этот туториал для самостоятельных людей, которые не ищут готовых решений, а хотят разобраться. Поэтому и не стал разжевывать вещи, которые не относятся к сути содержимого.
Если последовательно выполнить всё, что написано, то должно прийти понимание, если понимание не приходит, то можно задать конкретный вопрос в комментарии или разобраться самому.
Но спасибо за критику, она тоже полезна, как для авторов, так и для читателей.
Согласен, но в контексте данной статьи это не важно. Можно вынести путь в проперти, или прописать относительные пути, но это никак не меняет суть изложенного материала.
Соединение достаточно открывать одно, а не переоткрывать на каждой итерации.
Это дело вкуса, в моём случае, когда за одно соединение переносится таблица весом в 1 ГБ, не так уж важно, закрою я его перед переносом следующей таблицы, или нет.
Лишние фиксации, замедляют код, мешают атомарности и отсутствие транзакций
Не вижу отката транзакции при возникшем исключении.
Здесь явное противоречие, если я уже перенес 99% таблиц и на последней у меня возникло исключение, да еще и закрылась транзакция rollback, то выходит я зря сделал 99% работы. В oracle возникшее исключение автоматически откатывает транзакцию (так настроена БД, например, в PSQL есть понятие автокоммитов). Кроме того, не закрытая транзакция никакого вреда данным не наносит, если не лочит таблицы. В моем случае таблицы не лочатся.
Это было бы действительно хорошей идеей, если бы множество было упорядоченным.
Лучше добавлять объекты в конец списка, расширяя его, благо while терпим к такому.
Получилось бы так (см. листинг), но тогда теряется идея чек-листа:
etl_objects = [('MY_SCHEMA', 'MY_TABLE1'), ('MY_SCHEMA', 'MY_TABLE2'), ...]
i = 0
while i < len(etl_objects):
try:
with cx_Oracle.connect(user=user,
password=password,
tns=tns,
encoding='utf-8') as db_conn:
with db_conn.cursor() as cursor:
sql_text = (f"delete from {etl_objects[i][0]}.{etl_objects[i][1]} "
"where my_column = 'my_variable'")
cursor.execute(sql_text)
cursor.execute('commit')
sql_text = (f"insert into {etl_objects[i][0]}.{etl_objects[i][1]} "
"select * "
f"from {etl_objects[i][0]}.{etl_objects[i][1]}@src_dblink "
"where my_column = 'my_variable';")
cursor.execute(sql_text)
сursor.execute('commit')
except Exception as e:
print(f"Сработало исключение {str(e)}: объект загрузки отправлен в конец очереди")
etl_objects.append(etl_objects[i])
i += 1
Чет как будто не проще просто экспортировать бд файлом .sql, а затем просто воссоздать из файла бд?
Ну или там другой какой-нибудь формат
А зачем экспорт/импорт, если линки между БД настроены?
А что делать, если в цикле ты удаляешь данные из базы, а они не вставляются в новую, ты же теряешь данные насовсем, разве это безопасно?
При работе ETL всегда есть база-источник с исходными данными и база приемник. Данные на источнике в этом случае не теряются, так как из нее они только селектятся.
В проекте, который мне понадобилось ускорить, я много что перепробовал уже и не вспомню, но точно помню, что с хэндлерами игрался, правда не помню, почему отказался от этой идеи:) Спасибо за подсказку, возможно, так, как сделал я, делать действительно не нужно.
А он и сейчас популярен, много полезного для себя нахожу именно здесь (ну и на stackoverflow кончено)
Если Вы уже давно прочитали весь Хабр, то стоит сделать паузу и дать шанс новой полезной для Вас информации, накопиться.
;)
Этот туториал для самостоятельных людей, которые не ищут готовых решений, а хотят разобраться. Поэтому и не стал разжевывать вещи, которые не относятся к сути содержимого.
Если последовательно выполнить всё, что написано, то должно прийти понимание, если понимание не приходит, то можно задать конкретный вопрос в комментарии или разобраться самому.
Но спасибо за критику, она тоже полезна, как для авторов, так и для читателей.
Согласен с вами, учту на будущее. Мастерством нужно прирастать и в этом компоненте. Спасибо за замечания!
Согласен, но в контексте данной статьи это не важно. Можно вынести путь в проперти, или прописать относительные пути, но это никак не меняет суть изложенного материала.
Это дело вкуса, в моём случае, когда за одно соединение переносится таблица весом в 1 ГБ, не так уж важно, закрою я его перед переносом следующей таблицы, или нет.
Здесь явное противоречие, если я уже перенес 99% таблиц и на последней у меня возникло исключение, да еще и закрылась транзакция rollback, то выходит я зря сделал 99% работы. В oracle возникшее исключение автоматически откатывает транзакцию (так настроена БД, например, в PSQL есть понятие автокоммитов). Кроме того, не закрытая транзакция никакого вреда данным не наносит, если не лочит таблицы. В моем случае таблицы не лочатся.
Это было бы действительно хорошей идеей, если бы множество было упорядоченным.
Лучше добавлять объекты в конец списка, расширяя его, благо while терпим к такому.
Получилось бы так (см. листинг), но тогда теряется идея чек-листа:
А зачем экспорт/импорт, если линки между БД настроены?
При работе ETL всегда есть база-источник с исходными данными и база приемник. Данные на источнике в этом случае не теряются, так как из нее они только селектятся.
В проекте, который мне понадобилось ускорить, я много что перепробовал уже и не вспомню, но точно помню, что с хэндлерами игрался, правда не помню, почему отказался от этой идеи:) Спасибо за подсказку, возможно, так, как сделал я, делать действительно не нужно.
Спасибо за намек, покопаю в этом русле.