提交前确认 / Pre-submission Checklist
问题描述 / Problem Description
当我想要备份或者恢复我的账单数据的时候,我发现,如果我的账单比较丰富,历史包袱比较大(比如近两三年的记账都在),这时每次记账或者每次云端同步的时候都是全量更新,会比较卡,和慢
期望的解决方案 / Desired Solution
当前云存是通过将每个账本记录为json文件,存储到云端的,所以无法避免肯定是要全量更新的
如果换一种存储方式呢?
结合大家对协同管理账本的需求呼声比较高,我觉得在完成这个功能开发的时候,全量更新的问题自然就没了
比如自建API+SQL(适合自己有公网的服务器,或者只在内网同步)
或者直接gitee建仓库,用git的方式来解决冲突(直接免费,更新时git pull,修改时git push)
或者CouchDB + PouchDB(这个是才了解到的,可能是可以复用)
替代方案 / Alternative Solutions
No response
参考示例 / Reference Examples
No response
优先级 / Priority
很重要 / Important
贡献意愿 / Contribution Willingness
补充信息 / Additional Information
No response
提交前确认 / Pre-submission Checklist
问题描述 / Problem Description
当我想要备份或者恢复我的账单数据的时候,我发现,如果我的账单比较丰富,历史包袱比较大(比如近两三年的记账都在),这时每次记账或者每次云端同步的时候都是全量更新,会比较卡,和慢
期望的解决方案 / Desired Solution
当前云存是通过将每个账本记录为json文件,存储到云端的,所以无法避免肯定是要全量更新的
如果换一种存储方式呢?
结合大家对协同管理账本的需求呼声比较高,我觉得在完成这个功能开发的时候,全量更新的问题自然就没了
比如自建API+SQL(适合自己有公网的服务器,或者只在内网同步)
或者直接gitee建仓库,用git的方式来解决冲突(直接免费,更新时git pull,修改时git push)
或者CouchDB + PouchDB(这个是才了解到的,可能是可以复用)
替代方案 / Alternative Solutions
No response
参考示例 / Reference Examples
No response
优先级 / Priority
很重要 / Important
贡献意愿 / Contribution Willingness
补充信息 / Additional Information
No response