停止运行应用程序后领域无法正常工作？(Realm not working after stoping running app?)

 我认为您的结构可能比您最初设计的更简单，并且更贴近您在帖子底部提到的内容。 我还建议您阅读http://blog.getstream.io/best-practices-for-instagram-style-feeds/ ，这听起来与您想要在这里做的相似。 
 
 有关Feed类型的简化细分： 
 
 
 
 通知Feed适用于内容创作者（“15个人喜欢你的帖子”）。 
 
 
 聚合Feed适用于粉丝（“添加了12个帖子”）。 
 
 
 平面Feed是添加核心活动（在您的案例中为“实体”）的好地方，但您也可以使用活动模型上的“收件人”字段将这些活动的其他副本保存到其他聚合和通知订阅源，类似于CC发电子邮件 
 
 
 任何Feed类型都可以遵循Flat Feed，但我们通常建议只有平面Feed和聚合Feed会跟随其他平面Feed。 通知源通常是独立的，我将在下面描述。 
 
 让我们做出以下假设： 
 
 
 
 有一个名为“Silverthorne”的管理员用户，ID为12 
 
 
 组织机构ID 56是“Acme Inc” 
 
 
 Ian是ID为74的普通用户 
 
 
 Silverthorne准备一些实体内容，当保存到您自己的数据库时，其ID为63 
 
 
 让我们创建一个名为org的平面Feed，其中将进行实体活动，并为聚合数据创建名为org_aggregated的聚合Feed，称为notifications Feed，称为timeline用户平面Feed。 如果您的用户可以看到其他用户（而不是组织）创作的所有内容的Feed，那么我建议使用另一个名为usercontent平面Feed。 
 
 对于Silverthorne将此​​活动发布到GetStream，活动actor将是"user:12" ，动词可以是"post" ，对象将是"entity:63" 
 
 为了解决这个问题，因为我不知道你正在使用哪个SDK，它将是： 
 
# acme inc gets created as an organization, and so its aggregated feed
# should follow the org's flat feed
acme_org_feed = getstreamClient->feed('org', '56')
acme_org_agg_feed = getstreamClient->feed('org_aggregated', '56')
acme_org_agg_feed->follow(acme_org_feed)
 
 此时，添加到Acme的org flat feed的每个实体也将被聚合。 您可以设置如何在GetStream仪表板上汇总这些内容。 
 
 现在，我们让Ian关注Acme： 
 
# ian is a member of Acme Inc, so follow their entity feed
ian_feed = getstreamClient->feed('timeline', '74')
ian_feed->follow(acme_org_feed)
 
 如果Ian是新注册，您可以向Acme的通知Feed发送活动，如下所示： 
 
acme_notif_feed = getstreamClient->feed('org_notification', '56')
acme_notif_feed->addActivity({
  'actor': 'user:74',
  'verb': 'registration',
  'object': 'user:74'
})
 
 稍后检索此通知Feed时，它会将所有谓词组合在一起，然后细分通知活动，以便您可以选择以不同方式报告这些通知。 
 
 现在让我们让Silverthorne将实体添加到GetStream：#Silverthorne为Acme Inc的实体Feed添加了一项活动＃我们将“cc”活动添加到聚合Feed acme_org_feed-> addActivity（{'actor'：'user：12'，'动词'：'post'，'object'：'entity：63'，'to'：['usercontent：12']，...要跟踪的任何其他元数据}） 
 
 保存时，GetStream会执行以下操作： 
 
 
 
 它将活动存储在Acme的org平面饲料中（ org:56 ） 
 
 
 它将副本保存到Ian的时间线中，因为user:74跟随org:56的平面馈送org:56 
 
 
 它还从'To'字段中将副本保存到Silverthorne的feed（ usercontent:12 ）; 这完全是可选的 
 
 
 它将副本保存到Acme的聚合Feed中（ org_aggregated:56 ），因为聚合的Feed跟随平面Feed 
 
 
 当Ian登录时，您的应用程序现在有几个可能的供稿和选项显示，这完全取决于您的应用： 
 
 
 
 如果Ian应该看到他所遵循的所有内容的时间表，你将获取timeline:74 feed，它将有一个实体＃63的副本 
 
 
 如果Ian应该看到他所遵循的所有组织的列表，您可以获取ian_feed->followed()以获取Ian所遵循的每个Feed的列表 
 
 
 对于Ian所遵循的每个提要，您可以获取该组织的聚合提要以查看摘要（即，获取org_aggregated:56和Ian可以看到one new entity added in the past day如果这是您聚合内容的方式） 
 
 
 这里的关键是Ian不必关注Feed以查看内容，您的应用可以将任何Feed提取给任何用户。 
 
 如果Ian要“分享”或“喜欢”Silverthorne发布的实体，您可以在'org_notification：56'Feed中添加一个新活动，其中'user：74'作为Actor，'entity：63'是对象，动词是你想要的任何字符串（最多20个字符）。 如果您希望您的应用看到其他用户如何与组织的帖子互动，您可以获取org_notification:56并且所有用户都可以看到“Ian org_notification:56 entity 63”，或者您的UI需要提供该信息。 
 
 希望有助于澄清事情并为您提供一些额外的细节。 如果您需要进一步的帮助或想法，请通过电子邮件联系我们的支 
 
 作为最后一点，我不认为我会做$userId-$orgId ...我们的一些SDK（即Rails和Django）将自动尝试“丰富”数据库中的那些值，所以你要需要额外的逻辑来尝试稍后拆分这些值。 我们建议使用UUID作为无冲突标识符，但这完全取决于您控制。 如果用户真的可以成为多个组织的一部分，那么您可以让该用户“关注”该组织的Feed。 

I think your structure could be simpler than you initially designed, and be closer to what you mention at the bottom of your post. I'd also recommend you have a read through http://blog.getstream.io/best-practices-for-instagram-style-feeds/ which sounds similar to what you're wanting to do here.
 
For a simplified breakdown of our feed types:
 
 
 
Notification feeds are meant for the creators of content ("15 people liked your post"). 
 
 
Aggregated feeds are meant for followers ("12 posts were added").
 
 
Flat feeds would be great places to add the core activities ("entities" in your case?), but you can also save additional copies of those activities to other aggregated and notification feeds using the "To" field on the activity model, similar to CC'ing an email
 
 
Any feed type can follow a Flat feed, but we generally recommend that only flat feeds and aggregated feeds follow other flat feeds. Notification feeds generally stand alone, which I'll describe below.
 
Let's make the following assumptions:
 
 
 
There's an admin user named "Silverthorne" with an id of 12
 
 
Organization ID 56 is "Acme Inc"
 
 
Ian is a regular user with an ID of 74
 
 
Silverthorne prepares some Entity content that, when saved to your own database has an ID of 63
 
 
Let's create a flat feed called org where entity activities will be made, and aggregated feed called org_aggregated for aggregated data, a notification feed called notifications, a flat feed for users called timeline. If your users could see a feed of everything authored by another user (not by organization) then I'd recommend another flat feed called usercontent.
 
For Silverthorne to post this activity to GetStream, the activity actor would be "user:12", the verb could be "post", the object would be "entity:63"
 
To pseduocode this, since I don't know which SDK you're using, would be something like:
 
# acme inc gets created as an organization, and so its aggregated feed
# should follow the org's flat feed
acme_org_feed = getstreamClient->feed('org', '56')
acme_org_agg_feed = getstreamClient->feed('org_aggregated', '56')
acme_org_agg_feed->follow(acme_org_feed)
 
At this point, every entity that gets added to Acme's org flat feed will also get aggregated. You can set how these get rolled up on your GetStream dashboard.
 
Now, let's have Ian follow Acme:
 
# ian is a member of Acme Inc, so follow their entity feed
ian_feed = getstreamClient->feed('timeline', '74')
ian_feed->follow(acme_org_feed)
 
If Ian is a new registration, you could send an activity to Acme's notification feed like this:
 
acme_notif_feed = getstreamClient->feed('org_notification', '56')
acme_notif_feed->addActivity({
  'actor': 'user:74',
  'verb': 'registration',
  'object': 'user:74'
})
 
When you retrieve this notification feed later, it will group all verbs together, and then break down the notification activities, so your UI could report those differently if you choose.
 
Now let's have Silverthorne add that Entity to GetStream: # Silverthorne adds an activity to Acme Inc's entity feed # we'll "cc" the activity to the aggregated feed acme_org_feed->addActivity({ 'actor': 'user:12', 'verb': 'post', 'object': 'entity:63', 'to': ['usercontent:12'], ... any other metadata you want to track })
 
When this is saved, here's what GetStream would do:
 
 
 
it stores the activity in the org flat feed for Acme (org:56)
 
 
it saves a copy into Ian's timeline, since user:74 follows the flat feed for org:56
 
 
it also saves a copy to Silverthorne's feed (usercontent:12) from the 'To' field; this is entirely optional
 
 
it saves a copy into the aggregated feed for Acme (org_aggregated:56) since the aggregated feed follows the flat feed
 
 
When Ian logs in, your app now has several possible feeds and options to show, and this is entirely up to your app:
 
 
 
if Ian should see a timeline of everything he follows, you'd fetch the timeline:74 feed, which will have a copy of Entity #63
 
 
if Ian should see a list of all organizations he follows, you can fetch ian_feed->followed() to get a list of every feed that Ian follows
 
 
for each of those feeds Ian follows, you could fetch that org's aggregated feed for Ian to see a summary (ie, fetch org_aggregated:56 and Ian could see one new entity added in the past day if that's how you aggregate your content)
 
 
The key here is that Ian doesn't have to follow a feed in order to see the content, your app can pull any feed to display to any user.
 
If Ian were to 'share' or 'like' that entity that Silverthorne posted, you'd add a new activity to the 'org_notification:56' feed with 'user:74' as the Actor, 'entity:63' is the object, and verb is whatever string you want (up to 20 characters). If you want your app to see how other users interact with the org's posts, you could fetch org_notification:56 and all users could see "Ian liked entity 63", or however your UI needs to present that.
 
Hope that helps to clarify things and give you some additional details. Contact our support team via email if you want further help or ideas.
 
As a final note, I don't think I'd do $userId-$orgId ... some of our SDKs (ie, Rails and Django) will automatically try to 'enrich' those values in your database, so you'd need additional logic to attempt to split apart those values later. We recommend using a UUID for a collision-free identifier, but that's entirely up to you to control. If a user can really be part of multiple organizations, you can just have that user 'follow' the organization's feed.