解决用户升级插件时，数据库文件不会被替换问题

[eiriksgata]

问题回顾
随着功能的增加，导致数据库文件的变化频繁。用户升级插件时，因为数据库文件已经存在，因此没有重新生成新的数据库文件。
同时也不可以直接替换数据库文件，因为原本的数据库文件中存在了用户本身的一些数据，如果直接替换掉，将会导致数据丢失的情况。

解决办法

1. 当系统启动时，应当检查一遍数据库文件表是否完整，发现数据库的表不存在时，应当由系统主动创建表格。
2. 当系统使用到某个表时，如果不存在则自动生成该表的结构。

[eiriksgata]

该问题没有那么容易解决，因为涉及到日后如果拓展搜索功能的库，那么单纯构建表结构是没有意义的，而且还需要导入相应的查询数据。因此该问题还会涉及到数据同步的问题。但是如果用户暂且舍弃一些保存数据，那么替换数据库文件将会是没有问题的。

最好的解决办法其实是直接建一个API的网络接口数据调用服务，这样就可以使得任何的查询数据，服务器修改后，所有的客户端Rulateday-dice插件都可以同步数据，而本地只存储一些用户使用的存储数据。

但是这样做无疑是增加了该项目的维护成本，日后一旦没有服务器，那么所有的查询功能都将作废。

有以下讨论：

1. 应当把用户存储数据与查询数据独立开数据文件。那么日后所有的查询数据文件都应当以Github项目中的文件同步更新。并且就不提供给客户端自行添加内容，自行添加也可以，但是可能会导致升级Rulateday版本时导致数据丢失的问题。
2. 或许应当无视掉用户的暂且保留数据。目前暂且保留的一些数据有：忽略群名单列表，会话状态列表，用户属性列表。这些数据其实并不是很有保留的价值和意义。
3. 我们应当寻求一种，同步数据的方式来合并处理数据。

[eiriksgata]

从0.3.4开始，数据库文件将会按照软件版本进行更替，以确保用户每次升级能正常使用正确的数据库文件。
如何管理历史的数据库文件，以待后续调查开发。

[eiriksgata]

需要考虑继承用户数据的问题，原因如下：每次升级插件都会导致群内自动发言开关打开。因为系统默认骰子机器人是开启状态。
除了该原因之外还有其他更多的原因，以下是罗列出的包括且不限于需要集成的数据表格名称：

• cards_group_data
• cards_type_list
• speakers_group_list
• user_conversation
• user_initiative_data
• user_temp_data