Good day,
I have an app with CoreData that is in the Apps Store. I have now coded some
cosmetic changes in the interface without changing anything in the CoreData model.
I did not add/delete/or change any entity or property. Now, I am ready to upload my
version 2 of the app. I am unsure whether I have to do anything so that the old data
of the users in the first version will not be deleted but will be saved in the
new app (with exactly the same CoreData model). Please be tolerant with this noob.
Great thanks,
Romeo
When someone installs a new version of an app they already have, all the app's data stays where it is-- it doesn't get deleted.
Whether this data is compatible with the new version is a different question. If you haven't made any changes to the data model, then it should be fine. But you should make sure. Testing the upgrade process is one of the most important parts of testing a new version of an app. Install the current version, generate some data, and then install your new version and make sure everything looks OK. As you describe it, there shouldn't be any problems, but you should never just trust that this is the case.
In Marcus Zarra's Core Data Migration Course on iDeveloper TV, he suggests manually locking your xcdatamodel file so that you can't accidentally make updates to it and force a migration when you didn't plan it. But I agree with Tom, test it first.
iDeveloper.TV Core Data Migration
Related
I have a big database of activities which in the LCI have activities from an old ecoinvent version.
Is there a fast and easy way to update all the LCIs in the database so that they use a newer version of ecoinvent?
I suppose there might be problems of activities not existing anymore/changed names, if that can be a case, how do you manage that?
I'm new to Brightway so I have no idea about how to do this ;).
Thanks a lot!
Daina
There isn't yet, but we are working on it. What we normally recommend is to have a reproducible workflow, using whatever data source you prefer. It is very helpful to be able to reproduce your projects if something happens to your computer, and in this case you could re-create your own data and link it to a newer version of whatever database. But you are right, things change from version to version, and this normally requires some metadata on how to handle these changes - hence the library under development.
I published my app on play store and I have made an update that may cause the older one to crash due to some database structure changes that I have made and I have had a hell of hustle trying to automate DB migration upon installation. So I want the to completely auto-uninstall the old one from users phone before new one is installed during update as an easy solution. Is there a way I can include such configurations?
No, there is no way to force uninstallation before installation. But it sounds like you could just delete your DB on upgrade using SQLiteOpenHelper
If you use GreenDAO
you can use the schema version
Schema schema = new Schema(, "greendao");
when increasing the schema version GreenDAO will empty your DB and update the schema, and then you can repopulate it from the server (if applicable)
I have an app in appstore and in which I had setup my magicalrecord using setupCoreDataStack method. I have since then versioned the data model and added an attribute to an existing entity. Now when I use setupCoreDataStackWithAutoMigratingSqliteStoreNamed to perform lightweight migration over the released app, the debug app opens with no data.
The new version of data model is currently selected with the green tickmark in xcode and is based on the old data model. The default value for the new attribute is set. If I install released version again without deleting the debug app from the device then I see the old data, means the old data is never wiped off (which is good), it's just not shown after setting up new version of the model and performing magicalrecord lightweight migration. What am I missing here?
There is no error in debugger while loading new debug version over existing released version. The filemerge diff performed on the contents of the data model versions only show the addition of the new attribute.
Any insight into this problem or pointers will help!
Huh, read somewhere that you can't auto-migrate if the datastore was not setup as an auto-migrate store in the first place. Someone suggested doing it over multiple releases. So assuming that was true, I tried
[MagicalRecord setupAutoMigratingCoreDataStack];
right before
[MagicalRecord setupCoreDataStackWithAutoMigratingSqliteStoreNamed:#"XYZ"];
and it worked.
Anyone else with same problem, no need to delete data store and create new with setupAutoMigratingCoreDataStack or try manual migration. Just setup as auto-migrate store and do auto-migration one after another in the same build. Hope it works for your too!
Is it possible to turn off Entity Framework using the web.config? In the application I'm developing we have the following environments
Development
Continuous Integration
Integration Testing
Production
The Integration Testing and Production databases are managed by a database administrator, so we have to send them a script to make changes to the database.
I've spent hours Googling and looking through old projects, and I can't find how to do this or remember if we ever turned off migrations on the old projects in the first place.
From the lack of information I'm doubting if what I'm asking is needed or possible, but there is something in the back of my head that's annoying me about this so I thought I'd ask the experts.
The easiest method is to simply delete the dbo._MigrationHistory table from these environments. If that table doesn't exist, then only an "initial" migration can ever be generated against that database, which will fail if someone tries to actually apply it to a database with existing tables.
You could set the database initializer in the config file as described at the bottom here, so you can have an updating initializer in the environments you want
I am using MVC5 and EF6 CodeFirst migrations. My model is in a separate project from my MVC web app and I keep getting this error when trying to access the model classes. I have automatic migrations already enabled. I can drop the entire database and then using update-database to regenerate everything I still get this error. The error is wrong because the context has not changed since I created the database. Also, through a Unit Test project, using the same calling code as I have in my MVC app, I can reference the same Model project, access the model classes and data. I have the Model separate from the MVC project because I need to be able to reuse the Model outside of the web.
The model backing the "xx" context has changed since the database was created. Consider using Code First Migrations to update the database
Database.SetInitializer<DbContext>(null);
http://patrickdesjardins.com/blog/the-model-backing-the-context-has-changed-since-the-database-was-created-ef4-3
I got a similar problem :
The model backing the 'ApplicationDbContext' context has changed since
the database was created. Consider using Code First Migrations to
update the database
I have one project for MVC and another project for the model, context and repositories. I've been working on it for weeks but today it said stop.
I have tried to delete database, enable-migration, add-migration and update-database so many times that I've lost count. I've added initializers to MigrateDatabaseToLatestVersion as well as DropCreateDatabaseIfModelChanges.
What finally made it work was to move model, context and repositories into the MVC project (not something I was keen on)...then it worked right out of the box without any code changes at all (besides namespaces)! Very strange...
I've read so many blog posts during the day trying to solve this problem. One of them (I don't know which one) mentioned a bug in Visual Studio 2013 where reference to DLL files weren't always updated as they should, suggesting that my MVC project missed out something when I was running add-migration and update-database in my separate project. But it's just a guess.
I'm using EF 6.1 and .Net 4.5.1 in my solution.
Just to elaborate on RouR's answer:
I had an MVC web project that had a model attached.
I then created a console app that consumes this model.
My console app, only is aware of the connection string and has EF reference, just doesn't know how to let each one communicate.
Hence, the model backing database changed error appears
The engine is just confused how to proceed it sees and expects an entity, as was reference, just losses it when it fails to find the proper context, and assumes context wan't migrated properly.
So here we are,
Database.SetInitializer<MyProject.Models.MyModel>(null);
We are having the same issue. What solved it for me was not necessarily to move the Model, Context into the MVC project, but move my seperate project to the same solution as the MVC project and reference it by project folder.
This worked, but referencing a DLL instead of a project did not work.
Funnily enough, when creating a new Console Application and referencing the DLL assembly, we did not get this issue... only from an MVC project
We use EF code migrations to keep databases schemas up to date. The other day I had the same problem, in my case I was working with 2 database instances (QA and DEV databases of the same client with exact same data however QA environment was throwing this error. I've fixed the problem by deleting the _MigrationHistory folder and problem solved.