Closed michaelhiiva closed 4 years ago
(This PR fixes #120 btw)
Ok I was holding it wrong. After getting the new schema file sorted, this works great.
I have tried multiple methods for changing this, but django seems to only like the YYYY-MM-DD format. I am wondering if we should disable this for development or ignore the error for now.
Changing the datetime format to add a timezone results with the following error:
app_1 | django.core.serializers.base.DeserializationError: Problem installing fixture '/tmp/fake_agagd_data.json': [u"'2020-02-26 19:16:46.346969+00:00' value has an invalid date format. It must be in YYYY-MM-DD format."]: (agagd_core.member:pk=1) field_value was '2020-02-26 19:16:46.346969+00:00'
Also there are a lot of:
RuntimeWarning: DateTimeField Member.last_changed received a naive datetime (2020-07-18 00:00:00) while time zone support is active.
which might be worth dealing with.
I think this is semi-stable enough to look at moving to the master branch and running a test deployment of the database changes. It is seems to be used for other issues ie., #107 and #129, so it would be nice to have this on the master branch.
@annabunches That sounds fine. I am going to merge this for now.
As mentioned in #129, there's a flaw in commit 47fcab7
that should be addressed. I've opened issue #130 to track this so we don't both work on it.
That is fine. I added #131 to track the issue regarding datetime within the fixtures.
Overview
Major changes and some minor changes to the agagd. One of the main changes is with the fixtures being added to the entrypoint. These changes will require an update to the agagd db ratings table that will be irreversible when running in production.
Summary of Changes
Notes:
Fixtures requires and update schema that provides changes in the ratings table. Must be thoroughly tested before deploying to production.