Next feature: Dream endpoints

[lfborjas]

Dream endpoints!

Some notes from Tina:

Dreams:
id,
title,
date,
text,
emotions (as an array of strings),
lucid (as a boolean),
nightmare, (as a boolean)
recurring (as a boolean),
private (as a boolean),
starred (as a boolean)

Actions
- Get a person’s dreams
    - Option: Private or not
    - Use cases: pulling your own dreams (including private), looking at a specific user’s dreams (excluding private)
- Get dreams for everyone
    - Always non-private dreams
    - Include optional ability to pass dream property (lucid, nightmare, recurring, emotion, keyword, etc) OR user property (country, zodiac sign, gender you identify as), OR date range OR most recent X dreams
    - Use cases: setting the color of the sphere, viewing most recent dreams, getting the most recent dreams dream property
- Login / Logout / Change User Details (Name, email, password, birthday)
- Delete a user’s dreams
- Edit a user’s dreams
- Get statistics we’re pulling and usually calculating on the front end…
    - Most common words / topics - day / week / month / year
        - Lucid percent
        - Nightmare percent
        - Total dreams
        - Most common emotion
    - Most common emotions -  day / week / month / year
- Search public dreams

I feel a little poo poo because it looks like another app is already doing this pretty well:
https://play.google.com/store/apps/details?id=com.vojtkovszky.dreamcatcher&hl=en_US

---

list of emotions:

'joy', 'trust', 'anticipation', 'surprise', 'disgust', 'sadness', 'fear', 'anger', 'acceptance', 'admiration', 'affection', 'annoyance', 'alienation', 'amazement', 'anxiety', 'apathy', 'awe', 'betrayal', 'bitter', 'bold', 'boredom', 'bravery', 'brooding', 'calm', 'cautious', 'cheerful', 'comfortable', 'confused', 'cranky', 'crushed', 'curious', 'denial', 'despair', 'disappointed', 'distress', 'drained', 'eager', 'embarassed', 'empty', 'energized', 'envy', 'excited', 'foreboding', 'fulfilled', 'grateful', 'guilt', 'hatred', 'shame', 'helpless', 'hollow', 'hopeful', 'humiliated', 'hurt', 'inspired', 'intimidated', 'irritated', 'jealous', 'lazy', 'lonely', 'longing', 'love', 'lust', 'mellow', 'nervous', 'numb', 'panic', 'paranoia', 'peaceful', 'pity', 'powerful', 'powerless', 'protective', 'proud', 'reluctance', 'remorse', 'resentment', 'self-conscious', 'sensitive', 'shock', 'sick', 'shy', 'stressed', 'tired', 'alert', 'vigilant', 'weary', 'worry'

Notes from Luis:

• Dreams would have an FK from user, for Dreams and Emotions, I'd want to use an enum type for the emotion's label, and then a join table for DreamEmotion to be able to do aggregates easily (e.g. most common emotions appearing in dreams in the past week.) As such, we need the Dream, Emotion and DreamEmotion tables, and a custom EmotionLabel type with the pre-defined ones. At the API level, we can have a type that can receive an array of EmotionLabels when submitting a dream, and do the right inserts (note that persistent has a useful insertMany) fn -- example here. It's important that DreamEmotion entries have a createdAt timestamp, to be able to do time series queries.
• Persistent has support for the aforementioned relations, see: https://www.yesodweb.com/book/persistent#persistent_relations
• For querying, we may go far with just persistent, but esqueleto is not a bad library to look into! -- in the linked article, it also seems like moving some of the more complex queries out of the handlers into functions in Models.hs may help with things; that way testing can happen more heavily in the ModelsSpec without having to do any complex setup of the app's monad in the API integration tests. Another example of esqueleto + persistent usage is here

[lfborjas]

Some investigation

• Postgres has nice facilities for text search that seem to be supported in Heroku. Found a way that may give us the "most common words" across titles/text
• I do need a better migration situation, to be able to set all of this up programmatically. Maybe postgresql-simple-migrations or drifter would do the job? It's just for this one schemata though?
• If I'm moving to a "rawer" migration strategy, maybe I also need more powerful querying? Could it be that opaleye fits the bill? It already aligns with some of my preferences (timestamps, etc.) -- here's an implementation. And here's a (rather scary) thread of implementing enums](https://github.com/tomjaguarpaw/haskell-opaleye/issues/197) -- it would really only help in one query (most common dreams,) for most common words I would still need raw sql -- opaleye doesn't really help with this feature.

[lfborjas]

Some notes/examples of advanced esqueleto/persistent use:

• https://gist.github.com/bitemyapp/89c5e0663bddc3b1c78f5e3fa33e7dc4
• https://gist.github.com/bitemyapp/2445f6f4a24a42560b270bc2b41a9163
• https://www.reddit.com/r/haskell/comments/4vh4sg/recommended_way_of_dealing_with_db_associations/d5yew8f/

[lfborjas]

Some notes on timestamps and triggers:

https://stackoverflow.com/questions/35231697/how-to-let-default-values-come-from-the-database