-
Notifications
You must be signed in to change notification settings - Fork 2
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
14 additions
and
10 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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. |