Server sqlalchemy

[cloudiirain]

Rebased as per @ccubed's request. A more detailed history of individual commits can be found here.

Summary of Changes:

Dependencies:

• Database: postgresql
• Added a dependency on Flask-SQLAlchemy
• Added a dependency on Flask-RESTful
• Added a dependency on Flask-Migrate (for database migrations)
• Added a dependency on Flask-Script (for running Flask-Migrate and manage.py)
• Added a dependency on psycopg2 (needed for postgresql compatibility)

  Changes to Application Structure/Organization:

• Using the recommended structure in the flask docs. As such, views.py was split into __init__.py (for startup code) and views.py (for base routes). The app should be started by a script outside of the main package (e.g. runserver.py).
  • Since the app is started from a script outside the main package, absolute imports must be prefixed by the package name (RanobeHonyaku). As per @ccubed's comment, absurdly long absolute imports have been changed to relative imports. Unsure whether we want to establish a convention about whether absolute or relative (or mixture) is preferred.
• Use manage.py runserver to start app. Manage.py (from Flask-Script) was added to perform/automate all of the necessary database initializations, migrations, etc. This strategy adopted from @SunDwarf's kcsrv repo.

  Major Changes:

• models/ was created (SQLAlchemy), and very minimalistic models were made for:
  • Series (fields: title)
  • Chapter (fields: title, body, series_id)
• api/v1/ was created (Flask-RESTful), and functioning but minimalistic endpoints were made:
  • Series (basic CRUD written and working; curl requests will save changes to db)
  • Chapter (not done)
• Database (postgresql) was added
• Support for migrations was written

  Memos on Added Extensions:

  Flask-SQLAlchemy

• Needed for ORM and models and the database.
• Added psycopg2 because using a postgresql database wouldn't work without it

  Flask-RESTful

• This extension was chosen because it seemed more flexible and customizable than alternatives (e.g. Flask-RESTless). @GetRektByMe expressed a desire to be able to define routes with customized behavior, parse request headers. This framework appears to be capable of this.
• Advantages of this extension is that it can simplify the serialization of models, improve the maintainability of code (as opposed to serializing ourselves from scratch), and save effort on implementing our own error handler. It also comes with a request parser, but I personally think it may be more advantageous to just use Flask's native request.

  Flask-Migrate

• Migrations are necessary. Automatically generated migrations are included in this PR.
• Flask-Script was installed to help perform migrations. See the Flask-Migrate manual.

[Fuyukai]

Jesus fucking christ that's a terrible reasoning to switch away from Flask-SQLAlchemy.

If you have a circular import in that case, fix your design, don't switch away from a library.

Oh, and db.Model is a declarative base.

[ghost]

What's the point in rebasing while a PR is still under development? You rebase it once it's been approved prior to accepting...

[cloudiirain]

Commit is rebased. PR description is updated with a better summary.

In addition, I've addressed/fixed the suggestions by @SunDwarf and @ccubed.

[cloudiirain]

Made all changes recommended by @zelya and updated PR.