apache mod_dav框架的dav_hooks_propdb结构真的烂透了

apache的mod dav框架，其他说来还行，但是对于dead properties的dav_hooks_propdb结构真的烂透了。摘取做更新、删除操作的几个hook函数：

dav_error * remove(...)

dav_error * store(...)

dav_error * get_rollback(...)

dav_error * apply_rollback(...)

看看它框架的处理流程（对应PropPatch请求）：

-->对于客户端请求的所有待remove/update的属性

     调用get_rollback(...)获取rollback结构，以便有失败调用做回滚

     对于remove的属性，调用remove(...)函数

     对于update的属性，调用store(...)函数

     如果失败，结束循环，进入回滚流程

<--结束

-->回滚流程

遍历所有已执行store/remove的请求，逐个调用apply_rollback(...)回滚。

<<--结束

dav协议规定，对于PropPatch更新/删除属性的操作，必须保证完整性，全部成功或者全部失败。

对于每个属性的更新或者删除逐个调用store或者remove，这没什么问题。

以update为例，但是它的框架就要求了，每次更新都必须真正的写入，如果失败再写入原值。很简单，它没有commit(...)函数。

试想假设后台是文件系统，对10个属性的更新就要堆文件执行10次写入操作，如果第3次失败，那么还要把前面两次的值再分别写回去。如果更新时文件写入失败了，怎么能保证回滚写入的时候成功呢，这个时候该怎么办？！

如果后台是一个服务，那岂不是更蛋疼！

这是哪个垃圾设计的垃圾框架！！！

正常的设计应该是：

dav_error * remove(...)

dav_error * store(...)

dav_error * commit(...)

dav_error * apply_rollback(...)

如果更新失败了，直接调用commit回滚。

在store中程序可以缓存住这些属性，在commit中直接提交就好了。结构简单，而且效率更高。apply_rollback都不需要实现。

本来可以在其db close时做最后的补救，可是框架中不对close做任何检查。无语！