[BDMS-690 & BDMS-689]: Update the columns on the Wells list page to include contact info

[TylerAdamMartinez]

Why

This PR addresses the following problem/context:

• The API did not include associated contacts for Things/Water Wells, even though relationships exist in the data model

How

Implementation summary - the following was changed/added/removed:

• Added optional include_contacts query parameter to relevant endpoints (/thing and /thing/water-well)

Notes

Any special considerations

⚠️ DO NOT MERGE WITHOUT MERGING THE FRONTEND CODE WITH IT. DataIntegrationGroup/OcotilloUI#242

[jirhiker]

@TylerAdamMartinez before merging can you make sure adding contacts did not degrade performance too much

[jirhiker]

performance test

[TylerAdamMartinez]

@jirhiker

The 'test':

time curl "http://localhost:8000/thing/water-well?page=1&size=50" > /dev/null

time curl "http://localhost:8000/thing/water-well?page=1&size=50&query=ar-0" > /dev/null

time curl "http://localhost:8000/thing/water-well?page=1&size=50&include_contacts=true" > /dev/null

time curl "http://localhost:8000/thing/water-well?page=1&size=50&query=ar-0&include_contacts=true" > /dev/null

The results:

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  166k  100  166k    0     0   973k      0 --:--:-- --:--:-- --:--:--  978k

________________________________________________________
Executed in  178.03 millis    fish           external
   usr time    2.67 millis  137.00 micros    2.53 millis
   sys time    2.91 millis  518.00 micros    2.39 millis

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  214k  100  214k    0     0  1128k      0 --:--:-- --:--:-- --:--:-- 1133k

________________________________________________________
Executed in  196.40 millis    fish           external
   usr time    2.43 millis  187.00 micros    2.24 millis
   sys time    2.85 millis  562.00 micros    2.29 millis

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  166k  100  166k    0     0   984k      0 --:--:-- --:--:-- --:--:--  990k

________________________________________________________
Executed in  175.64 millis    fish           external
   usr time    2.55 millis  178.00 micros    2.37 millis
   sys time    2.87 millis  511.00 micros    2.35 millis

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  214k  100  214k    0     0  1144k      0 --:--:-- --:--:-- --:--:-- 1139k

________________________________________________________
Executed in  193.96 millis    fish           external
   usr time    2.53 millis  167.00 micros    2.36 millis
   sys time    2.86 millis  475.00 micros    2.39 millis

The bottom line:

• baseline: 178 ms, 166 KB
• baseline plus query only: 196 ms, 214 KB
• baseline plus contacts only: 176 ms, 166 KB
• baseline plus query and contacts: 194 ms, 214 KB

That is a very clean result:

• include_contacts=true changed almost nothing: 178 → 176 ms
• The query=ar-0 added only a significant amount of time. However, this feature is an opt-in feature.

[jeremyzilar]

Are you sure that your tests are including well records that have contacts attached? Only asking because the size of the payload didn't get any bigger.

[jeremyzilar]

🌶️ 🔥

[TylerAdamMartinez]

@jeremyzilar, yes, the response contains contact information for all wells that have associated contacts. For example, here is the response for the http://localhost:8000/thing/water-well?page=1&size=50&include_contacts=true
well-list-page-main-query.json

[TylerAdamMartinez]

@jirhiker and @jeremyzilar, important note: this response includes contacts for the wells regardless of the contact release_status.

[jirhiker]

@TylerAdamMartinez thanks. Thats something to be resolved later when we refactor the data visibility model