我的编程空间,编程开发者的网络收藏夹
学习永远不晚

Django框架ORM操作数据库不生效问题示例解决方法

短信预约 -IT技能 免费直播动态提醒
省份

北京

  • 北京
  • 上海
  • 天津
  • 重庆
  • 河北
  • 山东
  • 辽宁
  • 黑龙江
  • 吉林
  • 甘肃
  • 青海
  • 河南
  • 江苏
  • 湖北
  • 湖南
  • 江西
  • 浙江
  • 广东
  • 云南
  • 福建
  • 海南
  • 山西
  • 四川
  • 陕西
  • 贵州
  • 安徽
  • 广西
  • 内蒙
  • 西藏
  • 新疆
  • 宁夏
  • 兵团
手机号立即预约

请填写图片验证码后获取短信验证码

看不清楚,换张图片

免费获取短信验证码

Django框架ORM操作数据库不生效问题示例解决方法

本文详细描述使用Django 的ORM框架操作PostgreSQL数据库删除不生效问题的定位过程及解决方案,并总结使用ORM框架操作数据库不生效的问题的通用定位方法

问题描述

最近使用Django 的ORM框架操作PostgreSQL数据库总是出现删除不生效(尤其是在并发的时候)。业务代码中也没有任何报错。

定位过程 首先,我们怀疑是SQL语句拼装错误(比如ID不对),导致了删除不生效

通过在Python日志中打印ORM框架的SQL以及返回的操作结果,发现delete操作返回的记录数是1。且SQL中的ID符合业务逻辑,说明相应SQL语句是执行成功的。排除了这条猜测

接着我们怀疑DELETE操作后,数据又被其他业务CREATE回来了

通过在数据库中增加触发器,将nfinst表的写操作记录到nfinst_audit表,发现没有删除操作。排除了这条猜测

create table nfinst_audit(
operation       char(1)   not null,
stamp           timestamp not null,
userid          text      not null,
nfinstid        text      not null,
order_id        SERIAL    ,
addr            text      not null,
port            text      not null
);
--将DELETE、UPDATE、INSERT操作记录到nfinst_audit表中
create or replace function process_nfinst_audit() returns trigger as $nfinst_audit$
begin
   if (TG_OP = 'DELETE') then
     insert into nfinst_audit(operation,stamp,userid,nfinstid,addr,port) VALUES('D',now(),user,old.nfinstid,inet_client_addr(),inet_client_port());
     return old;
   elsif (TG_OP = 'UPDATE') then
     insert into nfinst_audit(operation,stamp,userid,nfinstid,addr,port) VALUES('U',now(),user,new.nfinstid,inet_client_addr(),inet_client_port());
     return new;
   elsif (TG_OP = 'INSERT') then
     insert into nfinst_audit(operation,stamp,userid,nfinstid,addr,port) VALUES('I',now(),user,new.nfinstid,inet_client_addr(),inet_client_port());
     return new;
   end if;
   return null;
end;
$nfinst_audit$ language plpgsql;
--创建触发器
create trigger nfinst_audit 
before insert or update or delete on nfinst
for each row execute procedure process_nfinst_audit();
  • 结合以上2点,猜测是事务没有commit导致

Django默认的事务模式是autocommit,每一次数据库操作执行后都会自动提交。项目使用的SQLAlchemy库的StaticPool连接池,配合gevent使用,一个进程中的所有协程串行复用一个数据库连接。

(这里解释一下为什么要一个进程中的所有协程复用一个连接,因为Python的PostgreSQL驱动pyscopg2是由c语言编写,协程在与数据库交互时,并不会因为io操作而切走,所以即使使用多个连接,也无法带来并发能力的提升,反而会增加维护多个连接的消耗)

查看delete操作的源码,delete操作是在一个事务中执行了pre_delete signal、删除表记录、post_delete signal等操作,执行完成后自动commit或者rollback。

def delete(self):
        for model, instances in self.data.items():
            self.data[model] = sorted(instances, key=attrgetter("pk"))
        self.sort()
        deleted_counter = Counter()
        # 开启事务,语句块执行结束后会根据执行结果选择commit或者rollback
        with transaction.atomic(using=self.using, savepoint=False):
            for model, obj in self.instances_with_model():
                if not model._meta.auto_created:
                    signals.pre_delete.send(
                        sender=model, instance=obj, using=self.using
                    )
            for qs in self.fast_deletes:
                count = qs._raw_delete(using=self.using)
                deleted_counter[qs.model._meta.label] += count
            for model, instances_for_fieldvalues in six.iteritems(self.field_updates):
                query = sql.UpdateQuery(model)
                for (field, value), instances in six.iteritems(instances_for_fieldvalues):
                    query.update_batch([obj.pk for obj in instances],
                                       {field.name: value}, self.using)
            for instances in six.itervalues(self.data):
                instances.reverse()
            for model, instances in six.iteritems(self.data):
                query = sql.DeleteQuery(model)
                pk_list = [obj.pk for obj in instances]
                count = query.delete_batch(pk_list, self.using)
                deleted_counter[model._meta.label] += count
                if not model._meta.auto_created:
                    for obj in instances:
                        # 执行post_delete后置处理
                        signals.post_delete.send(
                            sender=model, instance=obj, using=self.using
                        )

这里的pre_delete signal跟post_delete signal类似于数据库的触发器,不过是在Python代码层面实现的。问题就出在这个post_delete signal上面,出错的数据表注册了post_delete signal,并在其中调用了REST接口,而调用REST接口会导致协程发生切换,如果切换后的协程也操作了数据库,会将现有的事务回滚。(因为从连接池新拿到的连接,应该保证是没有事务在执行的,如果有,就认为该连接上一次被使用时出现了异常,需回滚事务)
将post_delete相关逻辑注掉后,问题消失

解决方案

解决方法有如下几种:

  • 直接修改Django源码,将post_delete signal的逻辑移除到事务外面(Django将post_delete的逻辑放在事务里确认有点坑,一旦post_delete出现异常就会导致事务回滚,并且事务过长也会消耗数据库资源)
  • 修改业务代码,将delete成功后的处理逻辑由使用signal完成,改为重写Django Model的delete方法(先调用父类的delete方法,成功后再执行后置处理逻辑)
  • 重写signal机制,post_delete使用自己实现的signal机制

最终综合考虑对业务代码的侵入性,以及后续的可维护性,我们选择了方案3来解决数据库删除不生效的问题。但在实施的时候,又发现了新的问题:django从数据库删除完数据后,会将Model对象也删除,从而导致post_delete无对象可操作。考虑到delete操作几乎不会出现rollback的情况,将post_delete移到了实际delete操作前面,类似于pre_delete。没有直接使用pre_delete是为了减少对业务代码的入侵。另外django自带的pre_delete也在事务中,而我们的改法是将signal操作移到事务外,以降低数据库压力

在models.py中做了如下修改

  • 定义了自己的post_delete,并将业务代码中注册post_delete信号量改为从models.py导入post_delete变量
post_delete = ModelSignal(providing_args=["instance", "using"], use_caching=True)

Django Model有2种方式进行删除操作,分别是直接对一条Model记录删除,以及对QuerySet进行删除。所以需要定义自己的Model类以及QuerySet基类,并让需要进行post_delete操作的Model类继承前面自定义的基类

class CModel_QuerySet(models.query.QuerySet):
    def delete(self):
        # 将post_delete信号量触发操作移到了事务外面
        for inst in self:
            post_delete.send(
                sender=self.model, instance=inst, using=None
            )
        super(CModel_QuerySet, self).delete()
class CModel_CustomManager(models.Manager):
    # custom QuerySet for snap QuerySet.update operations
    def get_queryset(self):
        return CModel_QuerySet(self.model, using=self._db)
# 自定义的Model基类
class CModelWithUpdateSignal(models.Model):
    class Meta:
        abstract = True
    # custom models.Manager for snap QuerySet.update operations
    objects = CModel_CustomManager()
    def delete(self, *args, **kwargs):
        # 将post_delete信号量触发操作移到了事务外面
        post_delete.send(
            sender=self.__class__, instance=self, using=None
        )
        super(CModelWithUpdateSignal, self).delete(*args, **kwargs)
# 需要进行post_delete操作的Model类
class NfInstModel(CModelWithUpdateSignal):
    ……

总结

ORM框架操作数据库,可以抽象至如下流程

如果出现操作数据库不生效,但是也没有报错的情况。可以从以下几个方面来排查问题 

是否SQL本身执行未生效(通常是业务逻辑导致,比如DELETE操作传错了ID),可以在ORM框架源码中加日志,将SQL执行结果打印出来
是否本次操作被其他操作覆盖,可以对数据表增加触发器,将CREATE、UPDATE、DELETE操作记录到另一张表。通过查看操作记录来确认是否是业务逻辑覆盖的问题
是否是事务没有COMMIT,可以在ORM框架源码中COMMIT操作前后增加日志,如发现确实没有COMMIT,需要排查在事务执行过程(包含前置signal、执行SQL、后置signal等处理)中,是否出现异常,以及数据库连接在中途有没有被其他线程使用

到此这篇关于Django框架ORM操作数据库不生效问题的定位示例的文章就介绍到这了,更多相关django orm操作数据库不生效内容请搜索编程网以前的文章或继续浏览下面的相关文章希望大家以后多多支持编程网!

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

Django框架ORM操作数据库不生效问题示例解决方法

下载Word文档到电脑,方便收藏和打印~

下载Word文档

猜你喜欢

Django框架ORM操作数据库不生效问题示例解决方法

本文详细描述使用Django的ORM框架操作PostgreSQL数据库删除不生效问题的定位过程及解决方案,并总结使用ORM框架操作数据库不生效的问题的通用定位方法,感兴趣的朋友跟随小编一起看看吧
2023-01-07

编程热搜

  • Python 学习之路 - Python
    一、安装Python34Windows在Python官网(https://www.python.org/downloads/)下载安装包并安装。Python的默认安装路径是:C:\Python34配置环境变量:【右键计算机】--》【属性】-
    Python 学习之路 - Python
  • chatgpt的中文全称是什么
    chatgpt的中文全称是生成型预训练变换模型。ChatGPT是什么ChatGPT是美国人工智能研究实验室OpenAI开发的一种全新聊天机器人模型,它能够通过学习和理解人类的语言来进行对话,还能根据聊天的上下文进行互动,并协助人类完成一系列
    chatgpt的中文全称是什么
  • C/C++中extern函数使用详解
  • C/C++可变参数的使用
    可变参数的使用方法远远不止以下几种,不过在C,C++中使用可变参数时要小心,在使用printf()等函数时传入的参数个数一定不能比前面的格式化字符串中的’%’符号个数少,否则会产生访问越界,运气不好的话还会导致程序崩溃
    C/C++可变参数的使用
  • css样式文件该放在哪里
  • php中数组下标必须是连续的吗
  • Python 3 教程
    Python 3 教程 Python 的 3.0 版本,常被称为 Python 3000,或简称 Py3k。相对于 Python 的早期版本,这是一个较大的升级。为了不带入过多的累赘,Python 3.0 在设计的时候没有考虑向下兼容。 Python
    Python 3 教程
  • Python pip包管理
    一、前言    在Python中, 安装第三方模块是通过 setuptools 这个工具完成的。 Python有两个封装了 setuptools的包管理工具: easy_install  和  pip , 目前官方推荐使用 pip。    
    Python pip包管理
  • ubuntu如何重新编译内核
  • 改善Java代码之慎用java动态编译

目录