Remove all old migrations

[josiahseaman]

The current state of the DB schema will be used as the new 'initial' state. Django 1.7 supports migrations without South.

Do #268 first.

[josiahseaman]

I need to finalize our development migrations so that it doesn't take so long to create a new blank scenario and to start the program. So any database changes we still want should go in now. We can have other migrations in production in the future, but they should have version releases. Now is the final opportunity to rename or change anything before we invoke more overhead. A couple things we might address:

1. We use the term "Spread" but the Lexicon uses the term "Transmission"
   • include_direct_contact_spread, include_indirect_contact_spread, include_airborne_spread
   • tables: DiseaseSpread, AbstractSpread, IndirectSpread, DirectSpread, AirborneSpread
2. I have no idea why you'd use _spread_method_code given that they already have their own table:
   class AirborneSpread(DiseaseSpread): _spread_method_code = models.CharField(max_length=255, default='other', help_text='Code indicating the mechanism of the disease spread.', )
3. OutputSettings._scenario can probably just be removed. It's not important.
4. Rename ProductionTypePairTransmission to DiseaseSpreadAssignment if we don't rename the other "Disease Spreads" to "Disease Transmission". This model is clearly an assignment model like ZoneEffectAssignment and DiseaseProgressionAssignment.
5. Remove schema for ReadAllCodes and ReadAllCodeTypes. We've talked about this and this is really documentation for the wiki. I'm going to go ahead and remove these.
6. @ndh2 is there anything more on the Output side to be changed? I'm still not quite understanding the "adequate exposure" fields. Are these fields so superior that we should drop the "exposure" fields entirely?
7. Are there any fields in Outputs that are never used?

[missyschoenbaum]

OK, I see you need a respsonse. Will have to pull a database to look at structure/

[missyschoenbaum]

1) Leave spread - i am guessing that transmission is more international 2) Here's our discussion from March On Fri, Mar 7, 2014 at 7:40 AM, Schoenbaum, Melissa - APHIS Melissa.Schoenbaum@aphis.usda.gov wrote: That’s fine with me – Indirect and Direct overlap completely.

From: Josiah Seaman [mailto:josiah@newlinetechnicalinnovations.com] Sent: Thursday, March 06, 2014 6:48 PM To: Schoenbaum, Melissa - APHIS Cc: Pyle, Alexander - OCIO/EAS; Neil Harvey Subject: InDiseaseSpread

It seems like spread_method_code splits InDiseaseSpread into three distinct classes (direct, indirect, airborne) that have different required fields. In a language like Django I can actually setup inheritance so that we're not repeating overlapping fields.

I've already done this with PDF vs Relational and dropped _ispdf. I'd like to split InDiseaseSpread into three classes and drop spread_method_code. Then spread_method_code will be set automatically according to the class. Is this alright with you? 3) OutputSettings._scenario can probably just be removed. It's not important. yes, I probably has something like this as a primary key once upon a time

4) Rename ProductionTypePairTransmission to DiseaseSpreadAssignment if we don't rename the other "Disease Spreads" to "Disease Transmission". This model could also be called DiseaseTransmission but it's clearly an assignment model like ZoneEffectAssignment and DiseaseProgressionAssignment.

I can't find where we put transmission into this name. My script went with the name as inProductionTypePair. Fine with me to rename.

5) remove schema for ReadAllCodes and ReadAllCodeTypes. We've talked about this and this is really documentation for the wiki. Works for me, I will get to the wiki some day.

6) Neil may be able to explain better, but exposures and adequate exposures are different. , We give a probability that the exposure causes disease and therefore those numbers are not the same unless we have given 100% probability.

7) Are there any fields in Outputs that are never used? I have no idea.

[josiahseaman]

Thanks Missy :) The code has now been modified. I'll start the migration reset process. If there's any .sqlite3 scenarios that you don't want to lose, I need you to upload them to our production server. I'll download and convert all of those and make them available to you.

[josiahseaman]

@ndh2 Can you please recompile adsm.exe with your latest changes?

[ndh2]

I noticed some new branches appear. Should I merge these changes from master into windows-staging and put the executable there too?

[josiahseaman]

Windows-staging is also a fine place to put an executable. Bryan renamed the C Engine to adsm_simulation.exe. ADSM.exe is now the GUI launcher. We need you to change your compile script to reflect this. Master regularly gets merged into Windows-staging.

2 very important things:

• Never Merge Windows-staging (or any OS branch) into master, this will end the world
• Don't checkout Windows branches on a non-windows machine, you will need to delete your repo if you do. Similarly don't checkout the Linux branch on a Windows machine.
• Never talk about Fight Club

[ndh2]

And don't feed them after midnight.

[josiahseaman]

By my test, it looks like adsm_simulation.exe in Windows-staging is still expecting Scenariocreator_productiontypepairtransmission table. That's the most recent migration that it is missing. Specifically, it looks like 8f268960e4cdfff5224e8d222799fbf6a9a31dd1 didn't make it into the compile.

[josiahseaman]

Scratch that, I just didn't pull remote correctly.