I finally ended up in a hole with the migrations - as we can't delete columns currently in the code first DB migrations, I had a few things out there that should be in the classes (i.e. ship tonnage is based on the class, so no need to have it in the ship details). And it was getting mixed up about foreign keys getting added after the fact.
A lot of poking around and I finally found the solution. And it turns out to be simpler than I hoped.
The entire code first migration stuff basically tracks your changes to the DB and creates a SQL script to do the column adds, table creates and all that. But the SQLite version of Entity Framework still has a lot of issues as previously mentioned.
So the easiest thing to do, after more than an hour of poking around, is to simply delete the database, all the migrations, and then just add a new migration to get the DB to where the schema currently is.
So in the main app where normally we process the migrations, we can do: db.Database.EnsureDeleted() and stop processing. This deletes the database.
Then, do the add-migration in the console, and voila, you now have 1 big migration at the current state of your schema.
So, when (and there is a when!) this goes to the App store, I'll do this process to have a single migration rather than a series of migrations. Once it does get published then it is migrations all the way...
So I also took this time to add the Sector and World tables: what will happen is that I'll have this sector & milieu stored in the local DB when you access this. So once I've downloaded the TravellerMap info I also store it in the DB, and when changing sectors or worlds we see if it is there first. This will allow for off-line for some things at least. So the ship class now has a SectorID and a WorldID, although really, just WorldID would really be enough as the World itself has a sector ID...hmm.
I also need to add to my list of options the ability to clear the Sector and World data in case you want to reload that from TravellerMap.
No comments:
Post a Comment