15-10-10
1

saveInBackgroundWithBlock是一个常用的接口，当一致都正常的时候，没有问题

但是当前出现问题的时候，本次操作的数据没有得到回滚，那么就会出现本地数据和服务器数据不一致的问题，看个例子：

leancloud_saveInBackground.png2392x1312 461 KB

程序尝试给一个badges的array添加一个新的值，但是网络问题，失败了
但是我们可以看到，在回调中，本地的数据被更新了，没有被回滚

当前其他的地方试图使用这个数据的时候，那问题就来了，因为这个object作为常用的object，且不存在多个终端更新的情况，不会每次都去更新，而且当前的网络也没有办法更新成功，就会导致用到了这份脏数据

15-10-10

你好，对象在保存失败时是否需要回滚值得讨论，有利有弊。有很多场景都需要以本地的最新数据为准。另外，我们提供了 saveEventually 这样的方法，来保证网络恢复时，重新保存对象。

15-10-11
1

saveEventually我知道，但是你说的很多场景时以本地数据为准，实在不敢苟同
你说的情况，存储会分为两种：
用本地存储的，而非服务器，因为不需要存储共享或者永久存储
saveEventually的确也满足了部分情况，（比如用户的一些实用习惯），但是实际上并不能覆盖所有的
这个就是为什么要有saveInBackgroundWithBlock，不然为什么要设计这个接口呢？
这个难道不是为了达到，不存储就丢弃的目的吗？

举个例子，比如用户下单买东西，要么下单成功，要么下单失败，而不是，等网络或者系统恢复的时候再决定他是否成功了；
或者，你去银行存钱，ATM机坏了，也让你去存，等ATM好了，再给你保存到系统去，请问你敢用吗？（不知道你能否接受，告诉你存储失败了，然后你在哪台ATM上面一查，发现钱多了，但是换台一看，没有）

15-10-11

还有，我花了一些时间来证明问题
而你用很含糊的回答，和不是解决问题的方案
略感失望

15-10-12

非常感谢你的反馈和讨论。

设想一下，如果你正在使用 Microsoft Office Word 起草一份商业计划书，快写完的时候点击保存，这时保存失败，Word 将你之前所有的工作都丢弃了，你会接受吗？

我们讨论的场景大概分两类：

  1. 原子性（例如 ATM、下单等操作）
  2. 非原子性（例如你提到「实用习惯」）

对于原子性的操作，保存失败时可以回滚。但是对于很多非原子的操作，不回滚仍然是合理的。

如果有必要，我们可以新增一个接口，例如：

- (void)saveAndDiscardChangeIfSavingFailed;
15-10-12
1

然而就没有了下文