工作记录
Todo
- onboarding: 完成 domain model 的构建，流程跑起来，screen 先简单写写
Process
- 浪费大量时间在写支持多数据库存储的情况（一个用户一个数据库）
支持多用户下， 全局 db + 每个用户单独 1 个 db
local app, 支持多用户，直观看有 2 种数据存储方式：
1. 一个数据库存，所有 user 的数据都存到一起即可
2. 多个数据库存，各自 user 的数据单独存到自己的里面
理论上每个用户分数据库存更简单、查询效率更高？
但其实经过 3 小时以上的实践，感觉不值得：
1. 这让代码复杂度急剧提升
1. 用户数据库文件、数据库实例需要在初始化用户时单独创建，这就需要处理 1. 创建和使用的时序问题。解决方案要么是每次查询时检查+建立；要么是用 Flow； 2. app 不同状态时的分支处理：用户没有登录；用户已经登录
2. 数据库实例带来的内存泄露问题：如果只维护 1 个用户数据库实例，那么没法处理后台任务的情况（比如 Worker 还在跑 save media 的逻辑）； 如果维护多个，那什么时候销毁？这就得引入引用计数，编写、使用的复杂度都提升了
3. 跨数据库操作的一致性问题：比如新增、删除 user，跨数据库要像保证 transaction 一致性，要写很多代码，效果还不一定 stable
2. 与 powersync 策略并不适配：其实并不能让 powersync 更简单…
3. 性能提升其实基本忽略不计：本地多用户，本来其实概率就小；多用户时也不可能引入太多的额外数据（肯定一个是主，其他是副）；为了这种小事件引入这么大的复杂度，实在是得不偿失
4. 可能的安全性问题？扯淡的，db 本身不能别别人读；media 数据本来就已经按 user 存了。所以不存在这个问题
5. 之前的数据库设计已经是在“一个数据库“的 concept 下设计的，所以已经可以支持多用户了。
所以说，从一个数据库存改成多个数据库存，纯粹是没事找事。浪费时间了。
生活记录
睡到 8 点才起，最近睡得最好的一次。难不成带上眼罩有奇效？
上午去幼儿园外边玩了滑滑，回来路上逛了零食有鸣，原来就是类似便利店的东西。
情绪记录
Good
Bad
Reflect
晚上莫名其妙搞单数据库向多数据库迁移，最后太麻烦，反过来想有必要吗？ 最后觉得还是没必要。
做事情还是有点太随意了啊。现在就是想着哪里做哪里，不能这样呢。