Define database schema

[pghosh]

Schema to store the action data should be identified. Update the wiki with the fields https://github.com/Data4Democracy/indivisible/wiki/Actions-events-Schema

[pghosh]

event structure should have the following

”event”:{
    "name":"",
    "description":"",
    "date":"",
    "time":"",
    "notes":"",
     "duration":"",
    "location":{
        "zip":"",
        "city":"",
        "state":"",
        "country":""
    }
}

[bonfiam]

Should we include a duration? I was envisioning someone saying, I have 2 hiurs tomorrow, what can I do?

[pghosh]

good point. updated

[sgreene]

I'd like to suggest a few more fields:

• url : a link to the site or page for the action
• email: some email address that can be used to email the organizer of the action?
• tags: An array of tags that would be helpful in searching through actions
• social: A map of any social media urls for an action. Ex:

  {
  "fb" : "facebook.com/thisaction",
  "twitter" : "twitter.com/thisaction",
  "ig" : "instagram.com/thisaction"
  }

And one comment on the existing tags:

• A single datetime field is probably good enough to capture everything and more in the date & time fields. Dynamo only supports strings but that's easily converted to date time. Mongodb has support for date time as well I believe so we should be good there.

[pghosh]

This task is for defining schema, the fields are not finalized. Feel free to add them in the schema. I am adding a wiki page so that we all can add our ideas there

[WanderingStar]

Many Data Science folks are fluent in SQL, which might suggest something like PostgreSQL, rather than Dynamo or Mongo. You can get a hosted RDS Postgres instance in the AWS free tier.

[pghosh]

@WanderingStar while I agree that finding skillset for postgreSQL might be easier, the reason I am in favor of mongo is the super simple schema and index updates. Since this is a evolving website with more features the schema is bound to change. That will be really easy to do with a document store like mongoDB. with a sql store it might not be as much flexible or involve lots of refactoring.

[WanderingStar]

Sounds like solid reasoning. If you create model objects with appropriate persistence methods (e.g. Event has a save(self) method and a @classmethod fetch(...), folks won't even have to think about what the datastore is most of the time and folks who have or want to build Mongo skills can write the necessary queries in those methods.

[nix-bohon]

Please forgive me if this is a completely insane idea, but since the events can be represented as a flat table, why not just store them in tabular format as a bit CSV on data.world. Then we could just pull the info into the Angular2 app through the data.world Rest API without the need of a node.js/express/mongo backend.

[pghosh]

Events are fairly flat. But imagine the upcoming usecases on this ,

1. Create user and track event registration
2. Recommend better events based on user interest (also store user interest)
3. Add action details i.e script to call to senators . Since lot of these details does not change we can just save those blobs with event type or something.

While data.world is super awesome for analyzing data the persistent stores provide more flexibility. Also by using a dao like layer we can easily swap out the store anytime we want incase it is an over kill.

[nix-bohon]

Works for me.