История изменений
Исправление ei-grad, (текущая версия) :
Просто с большой вероятностью твое dbdata это MetaData.tables, можно не плодить сущности, все нужные методы у тебя уже есть. Если ты не собираешься использовать ORM да ещё с разными реализациями - то дополнительная прослойка не нужна.
общий метод инициализации для всех скриптов, который бы устанавливал то, как скрипт должен работать с БД
Суть в том, чтобы явно перенести логику подготовки БД в отдельный кусок кода, например, класс типа такого:
class CommandManager:
def __init__(self):
self.tables = set()
self.scripts = []
def register_script(self, tables_for_script, script):
self.scripts.append(script)
self.tables.add(tables_for_script)
def run(self):
for table in self.tables:
self.load_metadata(table)
for script in self.scripts:
self.run_script(script)
В методе run_script - реализовать запуск скриптов с передачей им необходимых параметров.
Метод register_script вызывать, и создавать сам CommandManager, можно по-разному. Например сделать синглтон (просто глобальную переменную в модуле, модули в Python - сами по себе синглтоны) и обернуть все скрипты декораторами с указанием списков таблиц. Или в какой-нибудь функции main явно вызвать register_script по определенному там же списку скриптов.
Но, повторюсь, это может быть оверкилл, и всё что тебе не хватало, вероятно, это:
from . import db
if 'table1' not in db.metadata.tables:
db.load_table('table1')
С оглядкой на многопоточность можно обернуть load_table блокировками по ключу. И if тоже можно перенести внутрь load_table.
Исправление ei-grad, :
Просто с большой вероятностью твое dbdata это MetaData.tables, можно не плодить сущности, все нужные методы у тебя уже есть. Если ты не собираешься использовать ORM да ещё с разными реализациями - то дополнительная прослойка не нужна.
общий метод инициализации для всех скриптов, который бы устанавливал то, как скрипт должен работать с БД
Суть в том, чтобы явно перенести логику подготовки БД в отдельный кусок кода, например, класс типа такого:
class CommandManager:
def __init__(self):
self.tables = set()
self.scripts = []
def register_script(self, tables_for_script, script):
self.scripts.append(script)
self.tables.add(tables_for_script)
def run(self):
for table in self.tables:
self.load_metadata(table)
for script in self.scripts:
self.run_script(script)
В методе run_script - реализовать запуск скриптов с передачей им необходимых параметров.
Метод register_script вызывать, и создавать сам CommandManager, можно по-разному. Например сделать синглтон (просто глобальную переменную в модуле, модули в Python - сами по себе синглтоны) и обернуть все скрипты декораторами с указанием списков таблиц. Или в какой-нибудь функции main явно вызвать register_script по определенному там же списку скриптов.
Но, повторюсь, это может быть оверкилл, и всё что тебе не хватало, вероятно, это:
from . import db
if 'table1' not in db.metadata.tables:
db.load_table('table1')
С оглядкой на многопоточность можно обернуть load_table блокировками по ключу.
Исправление ei-grad, :
Просто с большой вероятностью твое dbdata это MetaData.tables, можно не плодить сущности, все нужные методы у тебя уже есть. Если ты не собираешься использовать ORM да ещё с разными реализациями - то дополнительная прослойка не нужна.
общий метод инициализации для всех скриптов, который бы устанавливал то, как скрипт должен работать с БД
Суть в том, чтобы явно перенести логику подготовки БД в отдельный кусок кода, например, класс типа такого:
class CommandManager:
def __init__(self):
self.tables = set()
self.scripts = []
def register_script(self, tables_for_script, script):
self.scripts.append(script)
self.tables.add(tables_for_script)
def run(self):
for table in self.tables:
self.load_metadata(table)
for script in self.scripts:
self.run_script(script)
В методе run_script - реализовать запуск скриптов с передачей им необходимых параметров.
Метод register_script вызывать, и создавать сам CommandManager, можно по-разному. Например сделать синглтон (просто глобальную переменную в модуле, модули в Python - сами по себе синглтоны) и обернуть все скрипты декораторами с указанием списков таблиц. Или в какой-нибудь функции main явно вызвать register_script по определенному там же списку скриптов.
Но, повторюсь, это может быть оверкилл, и всё что тебе не хватало, вероятно, это:
from . import db
if 'table1' not in db.metadata.tables:
load_table('table1')
С оглядкой на многопоточность можно обернуть load_table блокировками по ключу.
Исходная версия ei-grad, :
Просто с большой вероятностью твое dbdata это MetaData.tables, можно не плодить сущности, все нужные методы у тебя уже есть. Если ты не собираешься использовать ORM да ещё с разными реализациями - то дополнительная прослойка не нужна.
общий метод инициализации для всех скриптов, который бы устанавливал то, как скрипт должен работать с БД
Суть в том, чтобы явно перенести логику подготовки БД в отдельный кусок кода, например, класс типа такого:
class CommandManager:
def __init__(self):
self.tables = set()
self.scripts = []
def register_script(self, tables_for_script, script):
self.scripts.append(script)
self.tables.add(tables_for_script)
def run(self):
for table in self.tables:
self.load_metadata(table)
for script in self.scripts:
self.run_script(script)
В методе run_script - реализовать запуск скриптов с передачей им необходимых параметров.
Метод register_script вызывать, и создавать сам CommandManager, можно по-разному. Например сделать синглтон (просто глобальную переменную в модуле, модули в Python - сами по себе синглтоны) и обернуть все скрипты декораторами с указанием списков таблиц. Или в какой-нибудь функции main явно вызвать register_script по определенному там же списку скриптов.
Но, повторюсь, это может быть оверкилл, и всё что тебе не хватало, вероятно, это:
if 'table1' not in shared.metadata.tables:
load_table('table1')
С оглядкой на многопоточность можно обернуть load_table блокировками по ключу.