CAME_FROM Party-to-Party

Description

Describes what agency a client came from before they signed with UTA. We use this relationship only for parties with a client role.

Label

:CAME_FROM

Valid nodes

From	Relationship	To	Cardinality
Party Party with a :HAS_ROLE relationship to a :Role {name: "Client"}	:CAME_FROM	Party Party with a HAS_ROLE relationship to a :Role { name: "Agency" }	0..n

Properties

CAME_FROM uses the standard relationship properties.

CREATE

If the...	...party node is...	The ACID transaction should be...
To	not an organization with an active Agency role	Reject A party can only come from another party with a :Role { name: "Agency" }
To	United Talent Agency	Reject A party can not come from UTA
From	not a person or organization with a Client role	Reject A party can only come from another party with a :Role { name: "Client" }

We should not enforce any sequencing of the timeline of CAME_FROM relationships. We expect our data here is currently very spotty and thus it may be difficult to create the full picture without leaving gaps or overlaps in the sequencing. We will therefore allow authorized users to create any CAME_FROM relationships they wish, as long as they meet the business rules described above. It is very possible users will create duplicate and overlapping relationships. This is a tradeoff we will make in order to encourage data collection.

The active relationship property should be set to true as default on all CREATES. In inactive CAME_FROM relationship indicates a deletion.

TIP

Application developers are encouraged to make the timeline sequencing for this relationship very visible to the end user, so they will be motivated to correct it.

UPDATE

Updates are freely allowed for authorized users, with the exception of any change to the relationship properties id and active.

DELETE

On a DELETE the relationship should be deactivated with the termReason and thruDate required. Note that it is not semantically correct to say the CAME_FROM relationship "ended" on a certain date -- only the fromDate makes sense. Therefore, a deactivated relationship is treated as a deletion and the deactivated relationships should not be shown in most applications.

Examples

A client comes from another agency

// Note in this example we are requiring the client and the
// agency to have active roles. This isn't really required;
// it may make sense to add a CAME_FROM relationship for 
// former clients, or from agencies that are no longer in business.

MATCH       (client:Party { id: $id })
        -   [:HAS_ROLE { active: true }]
        ->  (:Role { name: "Client" })
MATCH       (agency:Party { id: $agencyId })
        -   [:HAS_ROLE { active: true }]
        ->  (:Role { name: "Agency" })
MERGE       (client)-[newRel:CAME_FROM { 
              id: randomUuid(),
              subType: "",
              active: true,
              private: false,
              fromDate: $fromDate,
              thruDate: "",
              termReason: ""
            }]->(agency)
RETURN      newRel{.*}