Add follow up data model

[rmehner]

Going forward we'll split out the followups from Person into this separate document which can be found by their _id, which will be in the format contactId/dateOfVisit. We also savecontactId and dateOfVisit directly in the document, but this is up for discussion. I didn't do a fancy RegEx for the _id as this is quite complex. But the way we'll have the id allows us for easy range queries (get all followups of a person) and also allows ordering by Couch (simply by ordering by key).

/cc @jo

[rmehner]

This doesn't reflect changes to the Person schema for now, as our learning from that other migration was, that we always should reflect the production state in the data model :) The change needed there is simply dropping the followUps attribute from contact.

[jo]

I can't find the contactId in the example - is this optional?

[jo]

how about a regexp that checks for the presence of a single /? eg

{ "pattern": "^[^/]+/[^/]+$" }

[jo]

Why is it called doc_type and not docType, like all the other properties?

[rmehner]

Why is it called doc_type and not docType, like all the other properties?

Because it's like that everywhere else and the whole library relies on that property :)

[rmehner]

how about a regexp that checks for the presence of a single /? eg

{ "pattern": "^[^/]+/[^/]+$" }

Fixed in 9d9223dd6c676a27ff35b0faa8abbb9f33c7ae36

[rmehner]

I can't find the contactId in the example - is this optional?

It's optional, yes. But for clarity I added it here 5b0efe8318f18ab1d67130335410e5b09b832928

[jo]

I can't find the contactId in the example - is this optional?

It's optional, yes. But for clarity I added it here 5b0efe8318f18ab1d67130335410e5b09b832928

If its optional we can't rely on it. And if we can't rely on it - whats the use case then? I would either make it required or leave it out here.

[jo]

Why is it called doc_type and not docType, like all the other properties?

Because it's like that everywhere else and the whole library relies on that property :)

Thanks, good to know!

[rmehner]

If its optional we can't rely on it. And if we can't rely on it - whats the use case then? I would either make it required or leave it out here.

Changed the name to personId (because we're referring to a Person, not a Contact), also made it required: https://github.com/eHealthAfrica/data-models/commit/ef4aae4c9eae7589065e4d7e514f9f0731884df4

[jo]

cool!

[danse]

@rmehner for me this is :+1:, just one note ... before starting, let us design how will the apps adapt, and let us write a small document in this repo ... i will start with it straight away ...