moving from local terminal interface with CSV to web interface with a database backend
The existing Physics Derivation Graph is centered on command-line input with PNG output. Recently I've been exploring use of d3js as a web frontend.
Published 2015-11-30T16:09:00Z by Physics Derivation Graph
I'm considering moving the Physics Derivation Graph to something which supports a web frontend connected to a hosted database backend. No command-line interaction or installation required.
I've been using CSV to store the data because it is the most common format. That works fine as long as the PDG is local and command-line driven. Now I want to move to a website, (ie openshift --
https://openshift.redhat.com/ ) app/console/application_type/
I've set up a Django cartridge
I realized I don't need to sketch a design for the PDG web interface. Instead, I can start with determining minimum functionality:
I've used Flask previously, but I think the functionality I want is sufficiently complex that Flask wouldn't be enough. user login (don't want spammers writing to the database)
user view existing content
user add new content
Vision: enable users of the PDG to interact with content in a web interface
Goal: use Django on Openshift to enable authentication, storage of content, and manipulating content
Flask local instance
Flask read values from database - CSV
convert PDG CSV to local SQL database
read from local SQL database
write to local SQL database -
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/sqlite3.1.html Flask read values from database - SQL
Django local instance
Django local instance read values from database
Django local instance write values from database
Django on Openshift -
http://physicsderivationgraph.blogspot.com/2015/11/django-and-openshift.html Django on Openshift read values from database
Django on Openshift write values from database
Django on Openshift write values from database by authenticated user
SQLite only supports a single writer at a time (meaning the execution of an individual transaction). SQLite locks the entire database when it needs a lock (either read or write) and only one writer can hold a write lock at a time.
SQLite 3.7.0 added a new journal mode called Write Ahead Locking that supports concurrent reading while writing.
Rendered in 0.00302 seconds using