Skip to content

Commit

Permalink
Update decision doc.
Browse files Browse the repository at this point in the history
  • Loading branch information
zorn committed Jun 25, 2024
1 parent 3f406e6 commit 9e612ad
Showing 1 changed file with 14 additions and 10 deletions.
24 changes: 14 additions & 10 deletions docs/decisions/2-vote-data-shape.md
Original file line number Diff line number Diff line change
@@ -1,21 +1,25 @@
# Decision: Vote Data Shape

## Context
## Ballots

To keep the `Flick.Ballots.Ballot` schema more straightforward when it embeds a `Flick.Ballots.Question` value, we store the `possible_answers` as a simple string. We expect it to include comma-separated values and have some basic validations around this.
`Flick.Ballots.Ballot` entity values have many `Flick.Ballots.Question`s and each question needs a list of possible answers.

This decision was made with practicality in mind. By simplifying the frontend UI, we've eliminated the need for a second layer of `inputs_for` for answers. Instead, we ask the user to input a simple comma-separated list of values.
We could solve "possible answers" in the data model in multiple ways but have picked a specific style with intent.

## Problem Statement
While a more normalized implementation of this relationship would have a dedicated embedded schema for `PossibleAnswer` to keep the `Flick.Ballots.Ballot` schema more aligned with expected frontend needs when the ballot embeds a `Flick.Ballots.Question` value, we'll store the `possible_answers` as a simple string value.

When capturing the votes, one might imagine a vote to have a `ballot_id` and then a list of ordered `answer_id` values for each question. Given the storage of `possible_answers`, we don't have answers withs id values.
We expect `possible_answers` to be a comma-separated list of values and have some basic validations around this inside of `Flick.Ballots.Question`.

## Solution
This decision was made with frontend practicality in mind. We've simplified the frontend UI by eliminating the need for a second layer of `inputs_for` for an alternative `PossibleAnswer` schema design.

When we capture a vote, we will store a list of string values. This will duplicate the answer strings many times in the database; however, given the expected early usage of this app and the fact that a UUID can cost as much as many of these answer values, this seems like an acceptable tradeoff for now.
Instead, we ask the user to input a simple comma-separated list of values as part of a more simple UI experience.

## Other Solutions Considered
## Votes

When a ballot is published, we could generate a list of possible answer entities with identities. When votes are recorded, we would then reference these identities as part of the persistence. This could result in more streamlined storage and better querying down the road.
When capturing the votes, one might imagine a vote to have a `ballot_id` and then a list of ordered `answer_id` values for each question. Given the above-described storage of `possible_answers`, we don't have answer id values.

Maybe someday, when the answers are more complex than a simple string, this will make sense, but for now, we will not choose this path.
When we capture a vote, we will store an answer as a string value, the exact same string that makes up the possible answer.

This will duplicate the answer strings many times in the database; however, given the expected early usage of this app and the fact that a UUID can cost as much as many of these smaller answer values, this seems like an acceptable tradeoff for now. If we want to refactor, we can do so in the future.

To prevent recorded votes from becoming misaligned with edited answers, we'll introduce a publish event for a ballot, making it non-editable by users.

0 comments on commit 9e612ad

Please sign in to comment.