19
docs/adrs/003-database.md
Normal file
19
docs/adrs/003-database.md
Normal file
@@ -0,0 +1,19 @@
|
||||
# ADR 003: database type & selection
|
||||
|
||||
There are multiple different database systems that exist with Python integration in them. Both NoSQL and SQL. This will be an effort to select the correct one for the application.
|
||||
|
||||
## Decision
|
||||
|
||||
After review of the options, the database that was selected was PostgreSQL. It is a relational SQL database, which is very mature and is a very good system to use for things.
|
||||
|
||||
## Rationale
|
||||
|
||||
There are questionable and uncertain problems with using a NoSQL system, and it really doesn't lend itself to being used in this particular application, so it was determined to not use NoSQL as it doesn't give any benefits and has a possiblity to make things harder/more complicated. PostgreSQL was selected as it has some very good asynchronous drivers for Python and will make using it simpler. Plus the developer is far more familiar with it than other systems.
|
||||
|
||||
## Status
|
||||
|
||||
Accepted
|
||||
|
||||
## Consequences
|
||||
|
||||
At this time, it isn't certain what negative consequences will arise. Code will be implemented in as database-agnostic a way as possible in order to facilitate a switch of backend if needed.
|
||||
19
docs/adrs/004-sql-api.md
Normal file
19
docs/adrs/004-sql-api.md
Normal file
@@ -0,0 +1,19 @@
|
||||
# ADR 004: select SQL API to use to build database code with
|
||||
|
||||
SQL should be implemented in such a manner as to be databaase-agnostic, so the correct selection of a SQL tool is essential. Further, it needs to be something that can work asynchronously in Python.
|
||||
|
||||
## Decision
|
||||
|
||||
SQLAlchemy 2+ is selected.
|
||||
|
||||
## Rationale
|
||||
|
||||
This is the future of SQLAlchemy, it combines the Core and ORM components making it easier to build out SQL code.
|
||||
|
||||
## Status
|
||||
|
||||
Accepted
|
||||
|
||||
## Consequences
|
||||
|
||||
SQLAlchemy 2's async functionality is still a bit rough, but will improve over time. As such it might be a little finicky in making things work. This is an accepted tech debt.
|
||||
19
docs/adrs/005-crytography.md
Normal file
19
docs/adrs/005-crytography.md
Normal file
@@ -0,0 +1,19 @@
|
||||
# ADR 005: select cryptographic library
|
||||
|
||||
It is important to be able to encrypt data to be stored in the database to protect it from being accessed by bad actors.
|
||||
|
||||
## Decision
|
||||
|
||||
The cryptography library was selected.
|
||||
|
||||
## Rationale
|
||||
|
||||
The cryptography library is a pretty standard library to use in Python for cryptographic purposes.
|
||||
|
||||
## Status
|
||||
|
||||
Accepted
|
||||
|
||||
## Consequences
|
||||
|
||||
This is not an asynchronous library. As syuch, we will need to make it non-blocking with the use of a ThreadPool while cryptographic functions are called.
|
||||
19
docs/adrs/006-plex-api.md
Normal file
19
docs/adrs/006-plex-api.md
Normal file
@@ -0,0 +1,19 @@
|
||||
# ADR 006: choose plex api for Python
|
||||
|
||||
As this project is to use the Plex system to interact with and make a playlist for, it needs to be able to access the Plex server.
|
||||
|
||||
## Decision
|
||||
|
||||
plexapi will be used.
|
||||
|
||||
## Rationale
|
||||
|
||||
There really is only one api for Plex in Python.
|
||||
|
||||
## Status
|
||||
|
||||
Accepted
|
||||
|
||||
## Consequences
|
||||
|
||||
This is not an asynchronous API, it is going to need to have parts of it wrapped with a ThreadPool to run savely and without blocking the rest of the application.
|
||||
Reference in New Issue
Block a user