Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Store different report types in different collections #15

Open
kynan opened this issue Apr 14, 2014 · 4 comments
Open

Store different report types in different collections #15

kynan opened this issue Apr 14, 2014 · 4 comments
Assignees

Comments

@kynan
Copy link
Member

kynan commented Apr 14, 2014

No description provided.

@kynan kynan added this to the Developer beta milestone Apr 14, 2014
@kynan kynan self-assigned this Apr 14, 2014
@dgorissen
Copy link
Member

in particular: currently waterpoints are stored as reports, this does not make sense as they are not reports, belong in separate db, outside of core taarifa

@nicowe
Copy link
Member

nicowe commented Apr 15, 2014

What exactly are we trying to achieve?
@dirk: do you mean a seperate database or a seperate mongo collection?

Currently Waterpoints are a subclass of the generic baseclass report in the ODM. Do you want to change this?

@dgorissen
Copy link
Member

Its just subtle semantics. See my (crappy) picture I emailed a couple days ago about the high level picture.

Right now submitting a new report is equivalent to submitting a new waterpoint (you enter location, ward name, technology, village, etc). While actually a report about about a waterpoint should contain, for example, waterpoint id, who reported by, date, problem recorded, comments, ...

So ideally a Taarifa report just refers to a particular waterpoint (by id) as stored in openstreetmap (where the waterpoint data should ideally end up) and does not duplicate waterpoint attributes in the reports collection. Of course for now we have to store the waterpoint CSV data somewhere. We can keep it in the same db but I would store it in a separate collection to keep the semantic distinction.

@dgorissen
Copy link
Member

Just to detail, given an empty, raw, database the upload script should:

  • create a waterpoints collection and upload the waterpoint csv data into it. See if a sensible _id field can be generated. This collection is essentially read-only and not changed.
  • create the usual reports/services collections and create a couple of sample/dummy reports. Each report refers to a particular waterpoint id with fields such as: timestamp, waterpoint id, reported by, status, comment, ... The service/report schema definitions will thus have to be updated. Care must be taken to ensure referential integrity (this is where mongo worries me).
  • update the UI so it pulls data from the waterpoints collection and reports collection, joined on waterpoint id

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants