mirror of
https://github.com/bigchaindb/bigchaindb.git
synced 2024-10-13 13:34:05 +00:00
8a7650c13a
* Problem: `ValidatorElection` and `MigrationElection` need to inherit from a common `Election` class Solution: Factored the common logic out of `ValidatorElection` and moved it to `Election` parent class * Problem: Adding base58 as a requirement seems to break the build... Solution: Reverting the changes * Problem: Responding to a suggestion for improved method naming Solution: Refactored `get_result_by_election_id` to `get_election_result_by_id` * Problem: No need to store different types of elections in their own tables Solution: Remove `DB_TABLE` property from `Election` class * Revert "Problem: No need to store different types of elections in their own tables" This reverts commit db45374d3c690429d18a25bcc319f8056c016500. * Problem: Missed a method in `Bigchain` class when updating the naming for an election method Solution: Finished the refactoring * Problem: Need a table to store data for all elections Solution: Created the `elections` table with secondary_index `election_id` * Problem: `Election` class needs to be updated to store concluded elections in the `elections` table Solution: Updated the class to use the new table * Problem: `UpsertValidatorVote` can be generalized to just be `Vote` Solution: Renamed, refactored and moved the `Vote` class to tie in with the more general `Election` base class * Problem: Error in docstring return signature Solution: Fixed the docstring * Problem: Hardcoded reference to the `VOTE_TYPE` in `Election` base class Solution: Pointed the reference to the class variable * Problem: Schema still refers to `ValidatorElectionVote` instead of `Vote` Solution: Renamed `TX_SCHEMA_VALIDATOR_ELECTION_VOTE` as `TX_SCHEMA_VOTE` * Problem: `Election` class variable `ELECTION_TYPE` is overly specific Solution: Renamed `ELECTION_TYPE` to `OPERATION` * Problem: Command line options for `upsert-validator` can be generalized to manage any type of election Solution: Refactored the CLI to manage generalized elections * Problem: Default for `show_election` not implemented for `Election` class Solution: Create a default method that work if all fields in the 'asset[data]' can be displayed without additional formatting * Problem: Multiple small issues with style etc. Solution: Addressed comments from PR * Problem: `Election` class variable to `VOTE_TYPE` unnecessary Solution: Removed the variable and hardcoded everything to use the `Vote` class * Problem: Minor style issues with PR Solution: Addressing comments * Problem: Changes to format for validator keys broke some tests Solution: Aligned the tests to reflect the changed key format * Problem: `election show` command displaying the base56 public key Solution: Cast any public key to base64 * Problem: `election_parser` help message still refers to upsert-validator Solution: Updated the help message
The BigchainDB Documentation Strategy
- Include explanatory comments and docstrings in your code. Write Google style docstrings with a maximum line width of 119 characters.
- For quick overview and help documents, feel free to create
README.mdor otherX.mdfiles, written using GitHub-flavored Markdown. Markdown files render nicely on GitHub. We might auto-convert some .md files into a format that can be included in the long-form documentation. - We use Sphinx to generate the long-form documentation in various formats (e.g. HTML, PDF).
- We also use Sphinx to generate Python code documentation (from docstrings and possibly other sources).
- We also use Sphinx to document all REST APIs, with the help of the
httpdomainextension.
How to Generate the HTML Version of the Long-Form Documentation
If you want to generate the HTML version of the long-form documentation on your local machine, you need to have Sphinx and some Sphinx-contrib packages installed. To do that, go to a subdirectory of docs (e.g. docs/server) and do:
pip install -r requirements.txt
If you're building the Server docs (in docs/server) then you must also do:
pip install -e ../../
Note: Don't put -e ../../ in the requirements.txt file. That will work locally
but not on ReadTheDocs.
You can then generate the HTML documentation in that subdirectory by doing:
make html
It should tell you where the generated documentation (HTML files) can be found. You can view it in your web browser.
Building Docs with Docker Compose
You can also use Docker Compose to build and host docs.
$ docker-compose up -d bdocs
The docs will be hosted on port 33333, and can be accessed over localhost, 127.0.0.1 OR http:/HOST_IP:33333.