You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Per @sgoggins' request, this feature would alter the tables to store the committer and author dates in a DATETIME column instead of VARCHAR. The context of the original decision is that the date info comes in as text from git log, and there wasn't any reason to do it otherwise. So, basically, laziness on my part...
Sean now has a reason, so this issue will track the downstream consequences of storing this commit data as a DATETIME. At minimum, it will require:
Changing the column definitions for data and cache tables in setup.py
Adding a clause to the function update_db() in facade-worker.py so that existing instances are properly updated
Making sure everything displays properly in the web and cli views
A new major release.
There are a few ways to do this. One is to alter the analysis_data table in-place, and force a recreation of the data. Another way is to split this data out separately (this appears preferable, as it will come with other benefits, and is tracked in a different issue).
The text was updated successfully, but these errors were encountered:
Please consider using TIMESTAMP in Mysql which represents a well defined point in time unambiguously just as the git log data does -- both include a timezone offset.
Per @sgoggins' request, this feature would alter the tables to store the committer and author dates in a DATETIME column instead of VARCHAR. The context of the original decision is that the date info comes in as text from
git log
, and there wasn't any reason to do it otherwise. So, basically, laziness on my part...Sean now has a reason, so this issue will track the downstream consequences of storing this commit data as a DATETIME. At minimum, it will require:
setup.py
update_db()
infacade-worker.py
so that existing instances are properly updatedThere are a few ways to do this. One is to alter the
analysis_data
table in-place, and force a recreation of the data. Another way is to split this data out separately (this appears preferable, as it will come with other benefits, and is tracked in a different issue).The text was updated successfully, but these errors were encountered: