Nano Hash - криптовалюты, майнинг, программирование

Указание метаданных модели через декораторы (django)

Проблема: я хочу использовать схемы Postgres для разделения таблиц разных частей моего приложения django на уровне базы данных.

В сторону

Вы можете пропустить этот раздел, но я думаю, что полезно добавить контекст к этим вещам. Мое приложение работает с базой данных существующих данных (полезно хранящихся в схеме public), которые очень важно не изменять. Таким образом, я хочу разделить «мои» данные в отдельную схему (к которой django будет предоставлен доступ для чтения/записи/воспроизведения в песке), ограничивая доступ к схеме public только для чтения. Первоначально я пытался решить эту проблему, выделив свои данные в отдельную базу данных и используя маршрутизацию базы данных, но оказалось (если бы я только прочитал документацию), что django не поддерживает зависимости между базами данных (что достаточно справедливо, я полагаю ), и мои модели имеют внешние ключи в данных только для чтения.

Мясо

Существует обходной путь для отсутствия поддержки схемы в Django (о котором вы можете прочитать здесь), который заключается в укажите атрибут db_table в метаданных вашей модели, например:

class MyModel(models.Model):
    attribute1 = models.CharField()

     #Fool django into using the schema
    class Meta:
        db_table = 'schema_name\".\"table_name'

Это здорово, но я действительно не хотел писать это для каждой отдельной модели в моем приложении - для начала это не кажется питоническим, а также есть все шансы, что я забуду, когда мне нужно добавить новый модель.

Моим решением был следующий фрагмент:

def SchemaBasedModel(cls):
    class Meta:
        db_table = '%s\".\"%s' % (schema_name, cls.__name__)
    cls.Meta = Meta
    return cls

@SchemaBasedModel
class MyModel(models.Model):
    attribute1 = models.CharField()
    ...

Когда я запускаю python manage.py shell, я получаю следующее:

>>> from myapp import models
>>> myModel = models.MyModel
>>> myModel.Meta.db_table
'myschema"."mymodel'
>>> 

«Выглядит хорошо для меня», — подумал я. Затем я побежал: python manage.py sqlall myapp. К сожалению, это дало исходные имена таблиц, то есть имена таблиц, какими они были до того, как я применил эту метаинформацию. Когда я вернулся и применил метаинформацию «вручную» (то есть, добавив Meta внутренних классов ко всем моим моделям), все было так, как и ожидалось (новые имена таблиц).

Я надеялся, что кто-нибудь может просветить меня относительно того, что здесь происходит? Или, что более полезно, как это сделать "правильно"? Я думал, что шаблон декоратора, о котором я здесь говорил, будет как раз билетом для этой проблемы, но, по-видимому, это не начало. Как я могу быстро и легко применить эту метаинформацию ко всем своим моделям, не вводя ее каждый раз?

Редактировать: возможно, я был немного неясен, когда спрашивал об этом — мне также интересно знать, что «на самом деле происходит» (т. Я неправильно понимаю здесь?) как решить мою проблему (четкое разделение "моих" данных от устаревших данных, желательно на уровне схемы - но это не конец света, если я должен свалить все в схему public и управлять разрешениями в расчете на стол).

Второе редактирование: принятый ответ не обязательно говорит мне то, что я действительно хочу знать, но он является, вероятно, правильным решением для реальной проблемы. Краткий ответ: не делайте этого.

23.08.2011

Ответы:


1

Я действительно не хотел писать это для каждой отдельной модели в моем приложении - для начала это не кажется питоническим,

Это неверно. Некоторые вещи должны быть записаны явно. «Явное лучше, чем неявное».

а также есть все шансы, что я забуду, когда мне нужно добавить новую модель

Это также неверно.

Вы не «забудете».

Итог: не связывайтесь с такими вещами. Просто включите две строки кода там, где это необходимо.

У вас не так много столов.

Вы не забудете.

Также обязательно используйте разрешения БД. Предоставьте разрешение SELECT только для ваших «устаревших» таблиц (таблиц, в которые вы не хотите писать). Тогда вы не сможете им написать.

23.08.2011
  • Хотя это не совсем объясняет, что здесь происходит. Я прибегал к явному добавлению метаданных к каждой отдельной модели, но я действительно думаю, что декоратор был бы более аккуратным. Даже если нет, вопрос остается в силе: что означает, что это не работает так, как я думал? И до тех пор, пока поддержка Schema не станет частью Django, как правильно их использовать, предпочтительно для каждого приложения? 23.08.2011
  • Я действительно думаю, что декоратор был бы аккуратнее. Это спорно. Подкласс был бы более аккуратным. Декоратор вообще не очень удобен, поскольку вы должны явно добавлять декоратор к каждой отдельной модели. как правильно их использовать? Под ними вы подразумеваете явные имена таблиц? Они полностью поддерживаются. Под ними вы подразумеваете имена схем? Мы используем их как часть настроек Django при идентификации БАЗЫ ДАННЫХ. 25.08.2011
  • Я думал о подклассах, но мне все равно придется переопределять поле db_table в каждой модели, поэтому, похоже, это не имеет значения (если я не ошибся?). Об именах схем: когда вы говорите, что используете их как часть настроек Django в идентификации DATABASE, вы не имеете в виду словарь DATABASES в файле settings.py проекта, не так ли? Просматривая документы, я не понимаю, как можно указать там имена схем. 26.08.2011
  • @jelford: элемент NAME в базе данных — это схема. 29.08.2011
  • И теперь я чувствую себя дураком. Спасибо за терпеливость. 30.08.2011
  • Новые материалы

    Кластеризация: более глубокий взгляд
    Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..

    Как написать эффективное резюме
    Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..

    Частный метод Python: улучшение инкапсуляции и безопасности
    Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..

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

    Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
    Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..

    Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
    В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..

    Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
    В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..