APIv4 - Specify BridgeEntities to assist with joins

[colemanw]

Overview

In our schema we have these tiny tables like civicrm_entity_tag which serve no purpose other than to "bridge" 2 other tables together. Arguably they don't deserve to be their own API entities, but what I've done here is to at least distinguish them as "bridge" entities so they can receive separate treatment in search screens.
I've also taught the API to create joins through these bridge entities with a fairly simple syntax that, to the API consumer, only feels like 1 join, when behind the scenes the api constructs both joins and figures out which FKs link the 3 tables together.

Comments

This gets us closer to having things like Activities and Tags in the new SearchCreator. It still doesn't solve the problem of groups, which use 2 tables + caching to deal with smart groups. It also doesn't yet solve the problem of getting these things easily discoverable in the SearchCreator UI, but it's a step in the right direction.

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[eileenmcnaughton]

I think the test cover is appropriate to this change

[MegaphoneJon]

@colemanw With regard to groups in APIv4 - there was some discussion some years back and some folks thought it made sense to get rid of civicrm_group_contact_cache, and store smart group contacts in civicrm_group_contact.

I think that would simplify your APIv4 work, simplify code generally, and solve some performance issues (e.g. a query that searches for members of a smart group and a static group will always involve an unindexed join).

[eileenmcnaughton]

@MegaphoneJon any idea where the links are - I recall some discussion

[MegaphoneJon]

@eileenmcnaughton They're on JIRA on CRM-18146. Nicolas was advocating for this as a deadlock improvement issue; I'm suggesting it as a way to simplify queries (and also address issues like CRM-20049.

I have several ideas for improving smart group performance, but at the moment I think it makes sense to focus on whether this makes sense as a way to save effort on APIv4, similar to the relationship vortex table.

[mattwire]

@MegaphoneJon Funnily enough I suggested the opposite - storing everything in civicrm_group_contact_cache :-) but I don't think it matters which way it happens - it would certainly significantly simplify group checking from a query perspective.

[colemanw]

@MegaphoneJon yes we've been discussing that. @totten has captured some possible approaches:
https://gist.github.com/totten/93350feec3d11c7c3ca48d2cc086a608