同步服务中的身份属性
有人可以帮助我理解实体属性的身份属性吗？我将身份属性视为关系数据库中的表“键”，但我猜这不是它。 我使用核心数据，在我的实体中我没有定义任何“关键”列，并且一切正常。 但现在我已经向我的应用程序添加了同步服务，我不确定如何使用此同步属性。我的应用程序是一个任务管理计划程序，因此我有一个名为任务的实体。我有一个名为“姓名”、“截止日期”的属性和其他可选属性。如果我有两个同名的任务，我希望它们都同步，所以我猜如果我将它设置在属性“名称”上，身份属性不会对我有好处。现在我还没有使用它，同步服务工作正常...... 所以我的问题是，在哪些其他场景中我应该使用 Identity 属性？
can someone help me understand the identity property on an entity attribute? Im thinking of the identity property as a table "key" as in a Relational Database, but I'm guessing this is not it.
Im using core data and in my entities I have not defined any "Key" columns, and all is working fine.
But now that I have added sync services to my app, Im not sure how to use this sync attribute. My app is a task management planner, so I have an entity called task. I have an attribute called "name" , "due date" and other optional attributes. If I have 2 tasks with the same name, I want them both sync, so Im guessing the identity property wont do me good if I set it on the attribute "name". Right now I have not used it, and sync services is working fine...
So my question is, in what other scenarios should I use the identity property?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您是否使用同步服务中任务实体的标准定义？ Apple 定义得相当好：
http:// 。
如果是这样，则存在三个身份属性（摘要、记录 ID 和日历）
如果您正在定义自己的实体（不与系统实体共享），您可以创建其他属性身份属性 - 我肯定会选择“名称”和“截止日期”；您还可以添加“创建日期”，以确保您能够真正创建一个唯一的值来比较使用的记录。
然而，根据我的经验，同步服务在使用系统架构的身份属性跟踪任务方面做得很好 - 我不记得上次看到来自我自己或用户的数据的重复任务是什么时候。
告诉我更多关于为什么您可能不想使用系统模式而是推出自己的模式的信息 - 我可以想到每种模式的优点和缺点。
Are you using the standard definition of a task entity from Sync Services? Apple defined one fairly well:
http://developer.apple.com/library/mac/#documentation/AppleApplications/Reference/SyncServicesSchemaRef/Articles/Calendars.html
If so, there are three identity properties (summary, record id and calendar).
If you're defining your own entity (not sharing with the system entity) you can make additional attributes identity properties - I'd probably go with "name" and "due date" for sure; you could also add in a "created date" to ensure that you are able to truly create a unique value to compare records using.
In my experience, however, Sync Services has done a good job keeping track of tasks with the identity properties of the system's schema - I can't remember the last time I saw duplicate tasks coming through my own or user's data.
Tell me more about why you might not want to use the system schema but instead roll your own - I can think of pros and cons to each.