search

arsturges / RVB

A DOE tool to map appliance efficiency legislation to CO2 reductions.
ead5.lbl.gov
1 stars 0 forks source link

revision_number bad logic somewhere #41

Closed arsturges closed 6 years ago

arsturges commented 13 years ago

If new milestones data is loaded and a new revision_number isn't created, no data shows up. E.g. I loaded in new data with revision_number = 17, but in the revisions table only existed up to revision_number 14. Not until I added all the way up to 17 did anything show up. It's probably pulling the max revision_number from the MySQL data instead of from the revisions table, and then not loading it into the view because the max milestone revision_number doesn't have a corresponding revision_date to it. Fix this. Ideally find a way to eliminate revision numbers, and just use ids.

arsturges commented 13 years ago

Upvoting my own suggestion to remove revision_number, and just perform logic on the revision_date field (like find max revision_date). Then we would have a "revisions" table with fields 'id' and 'revision_date.' Then default data would load the most recent revision date, not the highest revision_number. Drop-downs would still work. Old revisions could be inserted into the queue.

arsturges commented 13 years ago

To do this we'll have to replace the 'milestone/revision_number' field with a 'milestone/revision_date' field. That's why we have revision_number in the first place. So instead, leave the revision_number in the table, but just use it to match revision_number with date. Then do all the logic on the date field.