Add created_date & modified_date to civicrm_relationship

[eileenmcnaughton]

Overview

Add created_date & modified_date to civicrm_relationship

As with other tables we have done this to, knowing when we added a record to the
DB is useful (and differs from the relationship start_date).

I'm not sure yet if I will try to expose in the UI or whether search-kit
is all we need

Before

void

After

Tracking

Technical Details

This is consistent with similar changes made for other tables

Comments

[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).

[demeritcowboy]

5.47

[eileenmcnaughton]

opps

[eileenmcnaughton]

fixec

[colemanw]

This will work, but by itself it will not be available to SearchKit, because the civicrm_relationship table is not available to SearchKit (it queries the civicrm_relationship_cache table).

On a related note, @MegaphoneJon requested a few other columns be searchable. https://lab.civicrm.org/dev/core/-/issues/3019

With all of these, there are 2 possible solutions:

1. Add the mirror column to civicrm_relationship_cache
2. Add a calculated field to the APIv4 RelationshipCache entity which performs a subquery join to fetch the value.

The 1st is probably faster to query (though maybe not by a wide margin), but the 2nd would keep the size of the civicrm_relationship_cache table down. I think I'll take a stab at the 2nd, as it can always be switched over to the 1st later without SearchKit noticing the difference, as the field names would be the same.

[demeritcowboy]

I don't have a specific example where start_date is less than 1970-01-01 GMT but I've seen it elsewhere and know how to make it. This should then crash because timestamp can't be less than that, whereas start_date is a date which can be.

It's escaping me at the moment but something like UPDATE ... SET created_date = MAX('1970-01-01', start_date)... would work except there is no such SQL function.

[eileenmcnaughton]

Good spotting - since the update is just updating to have a more useful starting value than 'right now' I added to the WHERE clause WHERE start_date IS NOT NULL AND start_date > "1970-01-01"

[eileenmcnaughton]

it's arguabe that I should update it at all - but I think it's fine with the update

[colemanw]

Yea I guess start_date often does correspond to when the relationship was created... but sometimes it doesn't.
But for sites with advanced logging enabled, both created and updated dates should be available in the log tables somewhere. Wouldn't that be more accurate?

[eileenmcnaughton]

@colemanw yes they are there - but it is a bit of a PITA to grab them - do you think it is that important to get the starting value right - it will be right going forwards & that will date quickly enough

[colemanw]

It's not that important imo, no

[eileenmcnaughton]

OK _ I think this is mergeable - it adds the columns - but it doesn't expose them anywhere....

[colemanw]

@eileenmcnaughton this exposes the fields to SearchKit: #22606