Open DigitalPlatform opened 4 months ago
dp2library 此前版本设计了多种日志恢复模式，包括： 1) 快照模式 2) 逻辑模式 3) 逻辑+快照模式 4) 健壮(容错)模式
感觉模式数量有点多了。另外逻辑模式和容错模式之间到底什么区别？可能需要从理论上再厘清一下。最后，“逻辑+快照”模式可能是一种矛盾的模式，因为逻辑和快照本来是不相容的，如果某些动作因为逻辑失败再自动改为用快照恢复，可能会产生问题(比如逻辑倾向于自动安排记录 ID，然而快照倾向于暴力用既定的 ID 覆盖，那么快照可能覆盖了其它逻辑动作产生的记录)。
所以设想，第一可否把模式数量减少，比如只留下快照和容错两种模式；第二，出于开发和测试成本考虑，近期主要确保快照模式能完美工作即可，以后再逐步完善容错模式。当然，容错模式可能永远也无法达到一百分，它本身的行为如何设计定义就是个难题。
当初设计容错模式的动因，主要是面对一种日志记录发生严重错乱的情况，尝试从这些错乱的日志记录中尽量恢复出一个可用的结果。所谓错乱，就是这些日志记录实际上是一些读者记录之间证条码号重复冲突、册记录之间册条码号重复冲突代表的日志动作，如果按照快照恢复，只能恢复回到一个错乱的状态，而使用容错模式恢复，所谓容错就是它带有一种纠错的效果，比如它优先利用证条码号或者册条码号进行定位判断，而不是像快照那样直接用记录路径进行定位判断。
结合最近的借阅信息链改进，强化记录的参考 ID，那么上述容错模式应该进化为优先利用参考 ID 进行定位判断。
dp2library 此前版本设计了多种日志恢复模式，包括： 1) 快照模式 2) 逻辑模式 3) 逻辑+快照模式 4) 健壮(容错)模式
感觉模式数量有点多了。另外逻辑模式和容错模式之间到底什么区别？可能需要从理论上再厘清一下。最后，“逻辑+快照”模式可能是一种矛盾的模式，因为逻辑和快照本来是不相容的，如果某些动作因为逻辑失败再自动改为用快照恢复，可能会产生问题(比如逻辑倾向于自动安排记录 ID，然而快照倾向于暴力用既定的 ID 覆盖，那么快照可能覆盖了其它逻辑动作产生的记录)。
所以设想，第一可否把模式数量减少，比如只留下快照和容错两种模式；第二，出于开发和测试成本考虑，近期主要确保快照模式能完美工作即可，以后再逐步完善容错模式。当然，容错模式可能永远也无法达到一百分，它本身的行为如何设计定义就是个难题。
当初设计容错模式的动因，主要是面对一种日志记录发生严重错乱的情况，尝试从这些错乱的日志记录中尽量恢复出一个可用的结果。所谓错乱，就是这些日志记录实际上是一些读者记录之间证条码号重复冲突、册记录之间册条码号重复冲突代表的日志动作，如果按照快照恢复，只能恢复回到一个错乱的状态，而使用容错模式恢复，所谓容错就是它带有一种纠错的效果，比如它优先利用证条码号或者册条码号进行定位判断，而不是像快照那样直接用记录路径进行定位判断。
结合最近的借阅信息链改进，强化记录的参考 ID，那么上述容错模式应该进化为优先利用参考 ID 进行定位判断。