Question

在寻找模型的实际数据库结构时，我已经厌倦了对许多无关的小技巧属性进行分页。普遍使用代理模型只是为了保持我的代码更好地组织/更易读，这会是一件坏事吗？即

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文档所说的用途（在同一数据库表中包装了额外的功能）。

或者还有另一种方式来组织我的代码来完成相同的工作（将基本内容和少量支持位分开）。

[编辑]正在提供一些似乎可以作为自我解答的内容。鉴于Django声明性字段声明具有深厚的魔力，我仍然非常想听到任何知道这一事实的人。

（关于Python我唯一不喜欢的是，它不具有include功能，无法从另一个文件中读取大量代码！）

Answer 1

我想我可能已经找到了答案：使用从object继承的插件类，这是基于类的视图的常识。

考虑到Django声明性字段声明具有深厚的魔力，我仍然非常想听到任何知道这一事实的人。

基本概念证明：

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>]
>>>

Django代理模型有什么缺点吗？

1 个答案: