序

上一篇讲的是swift,这一篇我就来回忆一下我之前的flutter项目.

社交类型的项目,自然是离不开聊天,涉及到聊天,自然少不了数据库存储等操作,flutter数据库也是比较成熟的,比如对象型objectbox,realm,又比如sqlite,我在flutter项目中考察了很久,最终决定使用的还是sqlite3.争议来争议去,发现,其实sqlite用起来还是十分的顺手的.

写博客这方面, 我个人对老老实实一点点地去写技术流程确实没啥耐心,因为整篇的技术文,大部分的文字都比较水,其实重要的点也就那么一两个,所以本篇,我就当一个回忆问,挑几个我当时印象比较深的,读者可能会碰到的一些问题来讲好了

数据库操作

db的创建流程也没啥好说的 其实在数据库操作这块,没啥好说的,也就是表升级的时候麻烦,不过sqlite这块的升表操作,我很早以前也过一篇blog. 不过如果你本身对数据库字段改动不大的话,sqlite就已经十分足够用的.

表操作

表的操作也没啥好说的,flutter是单线程的操作,基本不会有并发的资源抢夺发生.但是sqlite有一些要注意. 我这里提一个点,就是事务. 举例一个场景,聊天业务,当你回复某个陌生人的一条消息,你需要做的操作有:

1. 写入本身的这条消息
2. 将这个陌生人的会话移出陌生人列表
3. 消息列表的陌生人未读数总计需要减少
4. tab上的总未读数要减少
5. 这个陌生人在消息列表中的数据要按时间顺序排到第一

如果中间出了什么问题,需要将整体的事务回滚. 这里如果滥用事务的话,可能会抛异常 "在事务中开启事务等等什么的", 异常一下子没找到,就这样理解算了,这个方式,我个人的解决办法就是,在顶层的api中,调用数据库操作,执行txn,然后在后续所有的业务逻辑操作中,统一使用该事务对象,这样就可以解决了.比如这样

中间的任何数据库操作逻辑,都传递该事务进行即可.

字段设计

我将表的每个字段都单独建立成常量属性,这样在做sql语句的操作的时候,就完全不会有写错字段的问题出现. 需要注意的是,不要把参数直接拼接到语句中,建议是使用whereArgs来操作,如果你用占位语句,string类型会出问题的.

sqlite的一个小优点

在聊天场景中,对会话字段的更新非常的好写,比如获取未读总数等等.

结尾

本篇文章确实也没啥营养,主要是我个人的回忆记录,读者看个乐即可,也别太当个技术文.顺便吐槽下,现在人越来越浮躁了,愿意静下心来写文章分享的人越来越少了. swiftui的文章写的人也特别少,一不小心就点到cs&&&dn里去,然后这货全是付费文章,真是无语,我个人虽然不排斥知识付费,但是你丫的什么blog都付费,要不要点脸,能不能屏蔽掉这个网站啊囧.