Split up views into different ddocs #2849
Description
We should have a proper discussion about the pros and cons of this approach.
I'll go first.
Pros:
- It makes it very clear how large each view is, which helps with keeping track of performance
- It reduces the likelyhood of unused views eating ram / disk space / cpu cycles, since views are only (re)generated when you query them
- Importantly for mobile, it makes sure that views users aren't actually using don't contribute to ram usage. If you never search a report by freetext, it will never get indexed.
- It would make the application snappier, since when (P|C)ouchDB boots and has to start loading views it only builds exactly what is necessary
Cons:
- It makes our code more complicated
- We'd have to work out how to deploy it in a non annoying way (maybe we've already done this re: medic-client)
- It makes it harder to know that you've warmed all the caches, since you have to hit each view individually. This could lead to the application feeling "bursty" and unpredictable.
- It hides issues, and could lead us to be less disciplined in what we put in medic-client.
As a reference, I took an example branch manager's database, and manually put each view in its own ddoc. Here are the sizes.
| view | size |
|---|---|
| contacts_by_freetext | 15.72mb |
| contacts_by_parent_name_type | 2.75mb |
| contacts_by_type | 1.75mb |
| contacts_by_type_freetext | 16.52mb |
| contacts_by_type_index_name | 2.21mb |
| data_records_read_by_type | 0.17mb |
| doc_by_type | 1.56mb |
| doc_summaries_by_id | 4.24mb |
| feedback | 0.01mb |
| forms | 0.01mb |
| help_pages | 0.27mb |
| messages_by_contact_date | 0.26mb |
| people_by_phone | 0.02mb |
| places_by_contact | 2.75mb |
| reports_by_date | 0.14mb |
| reports_by_form | 0.13mb |
| reports_by_form_year_month_places | 0.25mb |
| reports_by_form_year_week_places | 0.26mb |
| reports_by_freetext | 6.85mb |
| reports_by_place | 0.24mb |
| reports_by_subject | 0.20mb |
| reports_by_validity | 0.12mb |
| reports_by_verification | 0.12mb |
| total_clinics_by_facility | 4.60mb |
| Total | 61.5mb |
From this we can make some rough statements:
- If users never search for contacts, they reduce their problem area by ~50%
- If they never search for contacts or reports they reduce their problem area by ~60%
This seems like a pretty worthwhile investment to me. I'm pretty sure contacts_by_type_freetext isn't even really accessible by anyone anymore (because search has been simplified), so it would save us ~25% out of the gate.