CRM Relationship cache

Is an example of the reason to do this creating a view that lists a contact's siblings and having a single table to join to find all the siblings?

Is an example of the reason to do this creating a view that lists a contact's siblings and having a single table to join to find all the siblings?

No, this is to get all the relationships for a contact.

Do you think we should add the bundle name?

Sorry, my previous question was unclear. I now get what we're doing here. This addresses my concern about creating Views showing a Contact's relationships so long as the table can be relied upon to be up-to-date. The term "cache" implies to me that it can't. Assuming that this table is always updated whenever relationships are added/removed/updated, I think it might make sense to find a name without "cache".

I don't think it's necessary to add the bundle name. A given Contact is unlikely to have a ton of Relationships so an extra join from this table to the Relationships table to filter by Relationship Type won't be too onerous. However, I'm not opposed to including it and, eventually, performance testing might suggest doing so.

Given the apparent need for this table, I wonder whether it would make sense to revisit the concept of one Relationship entity per direction of the relationship. Only because it would eliminate the need for this table.

I am not sure if this table is necessary. I created the issue to have the discussion.

What if contact_a and contact_b fields where replace with a contacts field. It will still be two contacts, and the contact ids are in the same column. This would serve the same purpose as the cache table.

That makes sense. I assume delta 0 would be Contact A, delta 1 would be Contact B, and the corresponding label fields would remain?