Есть ли недостатки у прокси-моделей Django? - PullRequest
1 голос
/ 11 июля 2019

Я довольно устаю от постраничного перелистывания множества нерелевантных маленьких неудобных свойств при поиске реальной структуры базы данных моих моделей. Было бы плохо использовать универсальные прокси-модели просто для того, чтобы мой код был лучше организован / более читабелен? * 1001 Т.е. *

class Foo_Base( models.Model):
    title = models.CharField( ...)
    # other DB fields. As little as possible anything else.
class Bar_Base( models.Model):
    foo = models.ForeignKey( Foo_Base, ... )

и т.д.. не намного больше строк, чем столбцов в таблицах БД. Затем внизу или в другом месте,

class Foo( Foo_Base):
    class Meta:
        proxy=True

    @property
    def some_pseudo_field(self):
        # compute something based on the DB fields in Foo_Base
        return result
    @property
    # etc. pages of etc.

Тот факт, что makemigrations и migrate отслеживают модели прокси, вызывает у меня некоторую обеспокоенность, хотя, похоже, именно это использование и соответствует документации Django (наложение дополнительных функций на одну и ту же таблицу базы данных).

Или есть другой способ организовать мой код, который выполняет то же самое (сохраняя фундаментальные вещи и небольшие кусочки поддержки друг от друга).

[Изменить] Я предлагаю что-то, что, кажется, работает как самоответ ниже. Я все еще очень хотел бы услышать от любого, кто знает наверняка, что это нормально, учитывая глубокую магию Джанго в декларациях декларативного поля.

(Единственное, что мне не нравится в Python, это то, что он не имеет include функциональности для чтения кучи кода из другого файла!)

1 Ответ

0 голосов
/ 11 июля 2019

Я думаю, что, возможно, нашел ответ: используйте класс плагина, унаследованный от object, что является обычным явлением для представлений на основе классов.

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

Минимальное доказательство концепции:

class PenMethods1( object):
    @property
    def namey(self):
        return format_html('<div class="namey">{name}</div>', name=self.name )

class PenTest1(PenMethods1, models.Model):
    name = models.CharField( max_length=16, blank=True )
    def __repr__(self):
       return f'<Pentest1 object id={self.id} name={self.name}>'

Первоначальная миграция прошла успешно.Затем я добавил

pnum = models.ForeignKey( 'Pennum', models.SET_NULL, null=True)

(Pennum что-то уже лежало в моем манеже) и побежал makemigrations и migrate.Снова все в порядке и основные функции проверяются ...

>>> from playpen.models import PenTest1, Pennum
>>> n = Pennum.objects.last()
>>> n
<Pennum object id=3 name="t3" num=14 >
>>> p = PenTest1.objects.get(name='bar')
>>> p
<Pentest1 object id=2 name=bar>
>>> p.namey
'<div class="namey">bar</div>'
>>> p.pnum=n
>>> p.save()
>>> n=Pennum.objects.last()
>>> list(n.pentest1_set.all())
[<Pentest1 object id=2 name=bar>]
>>> 
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...