前言
用Python从事后端开发的同学应该都很熟悉大名鼎鼎的Django吧, Django开发中我们常会在models.py
文件中编写我们的数据模型类,在编写模型类的时候我们常常会根据需求用到各种Field
字段用以映射对应的数据表列。
于是,掉坑之旅了开始
鄙人不才,于某日一个神志不清的下午写下了如下代码:
class ActApplicant(Model):
status_choices = {
(0, '未通过'),
(1, '已通过'),
(2, '申请中')
}
act = ForeignKey(Act, verbose_name='活动', on_delete=CASCADE)
applicant = ForeignKey(Applicant, verbose_name='申请人', on_delete=CASCADE)
apply_time = DateTimeField('申请时间')
status = SmallIntegerField('申请状态', choices=status_choices, default=2)
def __str__(self):
return self.act.title
class Meta:
unique_together = ('act', 'applicant')
verbose_name = verbose_name_plural = '活动申请'
细心的童鞋可能已经发现了代码的问题,啧啧啧,好吧,塞心仔,这篇文章可能不适合你们...
什么!?你左看右看上看下看就是没发现有啥不对,哈哈 ,看来我并不孤独呐,如果你是后者,那这篇文章简直就是为你而写啊!
苦逼回忆开始...
那天写完上面代码之后接下来的整整三个多小时里,我被一个奇怪的现象困扰,在执行数据库同步变更操作的时候,这个表竟然一直提示有变动,而通常情况下我们在执行python manage.py makemigrations
命令之后继续重复执行该命令就会提示No changes detected
最终,在“小样儿,我还治不了你了"
的精神力驱动下,顽强滴我选择了一个字一个字
去死抠代码
咦~~ 这里的status_choice
怎么是个花括号,记得好像应该是圆括号啊,改过来试试....改完执行python manage.py makemigrations
,嗯,还是提示有变化,再执行,No changes detected
什么?!就这样好了 !!!
改动后的status_choice
status_choice=(
(0,'即将开始'),
(1,'进行中'),
(2'已结束'),
)
改完之后运行:
终于正常了
网友评论