swannysec
commented
8 years ago Certainly sounds reasonable to me; I'm glad it keeps it friendly for those wishing to run it locally. Speaking of Heroku, what are your plans for SSL? On Feb 13, 2016 10:01 AM, "Scott J. Roberts" notifications@github.com wrote:
Right now the assumption is people will run Threat_Note on Sqlite. Sqlite has some great characteristics:
- Portable
- Easy to setup
- Scales more than people think
But Postgres is pretty great as well. It's fast, scales really well, supports lots of datatypes, and (and I think most interesting of all) allows applications to run on Heroku. The foundation was already set by @alxhrck https://github.com/alxhrck when things were cut over from direct sqlite queries to SqlAlchemy.
Here are some useful links:
- Heroku: Getting Started with Python on Heroku https://devcenter.heroku.com/articles/getting-started-with-python#introduction
- Flask and PostgreSQL on Heroku http://blog.y3xz.com/blog/2012/08/16/flask-and-postgresql-on-heroku
- How to Setup Postgresql (Python-flask) App on Heroku and Local Machine http://beatofthegeek.com/2013/04/how-to-setup-postgresql-python-flask.html
The key is this should not break the current method of local deploying with Sqlite. This remains useful for people running small instances and development.
Thoughts?
— Reply to this email directly or view it on GitHub https://github.com/defpoint/threat_note/issues/136.
Right now the assumption is people will run Threat_Note on Sqlite. Sqlite has some great characteristics:
But Postgres is pretty great as well. It's fast, scales really well, supports lots of datatypes, and (and I think most interesting of all) allows applications to run on Heroku. The foundation was already set by @alxhrck when things were cut over from direct sqlite queries to SqlAlchemy.
Here are some useful links:
The key is this should not break the current method of local deploying with Sqlite. This remains useful for people running small instances and development.
Thoughts?