ObjectBox 多人 git 提交 数据模型冲突解决（翻译）

多人开发下，用Objectbox，肯定会有冲突问题，
原文链接

Resolving Meta Model Conflicts
In the section on UIDs, we already hinted at the possibility of meta model conflicts. This is caused by developers changing the meta model concurrently, typically by adding entities or properties. The knowledge acquired in the previous paragraphs helps us to resolve the conflicts.

解决基本元数据模型冲突
在本章节的UIDs部分，我们已经提示了可能的meta数据模型冲突。这是因为不同开发者在同时更改数据模型导致，比如添加表字段或者添加一个新表。前面章节的知识可以帮助你解决这写冲突。

The Nuke Option
During initial development, it may be an option to just delete the meta model and all databases. This will cause a fresh start for the meta model, e.g. all UIDs will be regenerated. Follow these steps:
Delete the JSON file (objectbox-models/default.json)
Build the project to generate a new JSON file from scratch
Commit the recreated JSON file to your VCS (e.g. git)
Delete all previously created ObjectBox databases (e.g. for Android, delete the app’s data or uninstall the app)
While this is a simple approach, it has its obvious disadvantages and is completely useless once an app has been published.
Pitfall: If the database file does not seem to get deleted, check for the presence of android:allowBackup=“true” in your Android manifest. Backups may resurrect old files and thus should be off for this approach.

暴力的做法
在初始开发的时候，删除meta数据或者整个数据库是可以的，所有UIDs，元数据都会重新生成，像新定义的一样。你可以如下操作：
删除json文件（位于objectbox-models/default.json）
编译项目重新生成新的json文件
提交你的新生成的json到版本管理仓库（比如git）
删除所有已经创建的数据库（安卓下，可以通过删除app 或者app的数据文件 ，译者注 一般是是在目录 data/data/包名/file/objectbox）
然而这时一种简单的做法，明显的缺点是对已经发布的app，完全不能用。
如果数据库文件不可见或者被删，检查一下manifest文件中的android:allowBackup=“true”，这个选项可能会保存数据库文件，应当设置为false。

Manual conflict resolution
Usually, it is preferred to edit the JSON file to resolve conflicts and fix the meta model. This involves the following steps:
Ensure IDs are unique: in the JSON file the id attribute has values in the format “ID:UID”. If you have duplicate IDs after a VCS merge, you should assign a new ID (keep the UID part!) to one of the two. Typically, the new ID would be “last used ID + 1”.
Update last ID values: for entities, update the attribute “lastEntityId”; for properties, update the attribute “lastPropertyId” of the enclosing entity
Check for other ID references: do a text search for the UID and check if the ID part is correct for all UID occurrences

手动解决冲突
一般来说，更推荐编辑json文件来解决meta数据模型的冲突，方法如下几步：
1.首先确保字段的IDs是唯一的： json文件中描述数据表的字段是“ID:UID”这种格式，如果有git合并后有重复的，应当指定一个新的ID，典型做法是新ID 等于 旧ID + 1
2.更新可能冲突的 ID的值： 对数据表来说，更新最后一个属性 “lastEntityId”; 对属性来说，更新此实体数据表范围内的 “lastPropertyId”
3。检查一下其他ID的引用：手动搜索UID的引用 并检查所有UID出现的敌法是否ID是否正确

To illustrate this with an example, let’s assume the last assigned entity ID was 41. Thus the next entity ID will be 42. Now, the developers Alice and Bob add a new entity without knowing of each other. Alice adds a new entity “Ant” which is assigned the entity ID 42. At the same time, Bob adds the entity “Bear” which is also assigned the ID 42. After both developers committed their code, the ID 42 does not unique identify an entity type (“Ant” or “Bear”?). Furthermore, in Alice’s ObjectBox the entity ID 42 is already wired to “Ant” while Bob’s ObjectBox maps 42 to “Bear”. UIDs make this situation resolvable. Let’s say the UID is 12345 for “Ant” and 9876 for “Bear”. Now, when Bob pulls Alice’s changes, he is able to resolve the conflict. He manually assigns the entity ID 43 to “Bear” and updates the lastEntityId attribute accordingly to “43:9876” (ID:UID). After Bob commits his changes, both developers are able to continue with their ObjectBox files.

举例说明，假设最后指定的实体数据表的ID是41，按道理下一个ID应该是42， 两个开发者小A和小B在互不了解的情况下都添加了一个新实体数据表，小A添加的是一个名为“Ant” 的表，ID自动指定为42.同时小B添加了一个名为“Bear” 的表，ID也自动指定为42. 他俩都提交代码后， ID 42不再唯一能定义实体了。（会导致不知道指向“Ant” 还是“Bear”）。更进一步讲，小A的数据库实体ID已经指向“Ant” 然而小B的指向“Bear”. 这种情况下可以用UIDs来解决。比如说UID 12345 已经给了 Ant”， UID 9876已经给了“Bear”， 现在 当小B 拉取小A的代码更改时，他就可以来解决这个冲突， 他可以手动指定一个ID 43给 “Bear”， 然后更新lastEntityId的属性为“43:9876” (ID:UID)，在小B 提交代码后，两边都不会冲突了。