-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use postgres for backend #44
Conversation
1cc68d0
to
1fb282e
Compare
Where to go from here?As it stands, this PR is not ready to merge. Here is what needs to be done: Actually make torquedata use PostgresCurrently torquedata is using an Sqlite3 database for development purposes. Changing the database engine to postgres should be trivial (documented here). ( Configure file handlingMEDIA_ROOT is not currently configured in Issue #20 mentions using Backblaze to store attachments. pyutil/django-b2 would probably work well for this purpose. It seems relatively well-maintained but documentation is sparse. It exposes a custom storage backend called B2Storage which can replace Django's default FileSystemStorage (see documentation on the FileField storage parameter). Add Edit modelDiscussed in DESIGN.md
Add PostgreSQL Text SearchDiscussed in issue #45. Currently spreadsheet/proposal data is stored in a JSONField (see documentation on querying JSONField) which might not be amenable to this solution. More
|
32e44c4
to
bb60339
Compare
aac4c1b
to
26ded06
Compare
This is related to issue #26 This is finishing up the existing work started by YaxelPerez. With this commit torque now uses postgres and django for all API endpoints except search and editing.
This is related to issue #26 With this commit torque's search API endpoint now uses postgres' Full Text Search feature to perform search queries.
This resolves issue #26 This is a re-implementation of all edit functionality but now using django and postgres
26ded06
to
cee453d
Compare
(in progress)
This PR replaces filesystem persistence with a Postgres backend using the Django ORM. More discussion in issue #26.