i am having some issues with Core data migration. i am having 3 versions of my app 1.0, 1.1, 1.2.
for the 1st two versions(1.0 and 1.1), i am having the same data model, but for third version(1.2) i have done some changes in my data model. Now i am getting incompatible issue at version 1.2 of my app(though its a light weight changes).
I am thinking that i have missed the data model version at version 1.1 of my app, as there is no change in the datamodel for 1.0 and 1.1, i havent created another data model version.
Do we need to create a data model version for new app version, even there is no change in the data model between the versions.
sorry if my query is too dum... please suggest..
No, you don't need to have a data model version for each app version.
Just to be sure: when you went from 1.1 to 1.2, did you create a new data model version? Or did you simply modify the existing data model? Because for (lightweight) migrations to work, you're supposed to have different versions of the data model; you should NOT just modify the existing model.
Also, you did write the code to perform the automatic lightweight migrations, right?
If you want to change the model but also retain the ability to open stores created using a previous version of the model, you must keep the previous version of the model (as a version in a versioned model). Core Data cannot open a store for which it has no compatible model. Thus, if you want to change
the model but also retain the ability to open existing stores, you must:
Ensure that you have a versioned model—if you don’t, make the current model into a versioned model.
Before editing the schema , create a new version of the current model.
Edit the new current version of the model, leaving the old version unaltered.
Please refer the
link
for step by step procedure of versioning
Related
I am working with classes generated by jOOQ based on a schema maintained by Liquibase. I am looking for a way to ensure that the jOOQ classes remain consistent with the actual database. The preferred approach is to create a test that can be run by our CI tool when pull requests are created.
Is there a tool to verify that the jOOQ generated definitions are still correct?
Two obvious approaches involving your build setup are:
To check in generated sources (get a diff when they're not up to date). See also the manual section about code generation and version control.
To include both Liquibase migrations and jOOQ code generation in your build. That way, the generated sources and the database are always up to date with what is defined in your Liquibase migration scripts. You can also base your code generation directly on your Liquibase files using the LiquibaseDatabase, if you're not doing anything fancy, vendor specific.
A less obvious way using programmatic jOOQ API is to compare two versions of Meta using Meta.migrateTo(Meta):
// This corresponds to the meta data from your live connection
Meta m1 = ctx.meta();
// This corresponds to the meta data from your generated catalog (or schema, table, etc)
Meta m2 = ctx.meta(catalog);
// This is a generated migration script between the two versions, should be empty
Queries queries = m1.migrateTo(m2);
The approach might work, though it has a lot of caveats, which are still being fixed as of jOOQ 3.14, 3.15. Work in progress can be seen here: https://github.com/jOOQ/jOOQ/projects/1, bug reports very welcome!
I removed a model fully from my app: deleted the model.js and model.json from models, deleted a relation in another model, and erased it from model-config.json.
However, the table created for the model, and the column in the other model remain in the DB (in all environments). I tried auto-migrating, but they're still there.
Do I need to manually go through all databases and drop the table and column manually, or can I tell LB to pick up the changes on its own somehow?
Do I need to manually go through all databases and drop the table and column manually, or can I tell LB to pick up the changes on its own somehow?
LoopBack is not able to detect which models were removed and drop the corresponding database tables.
As you have discovered yourself, the solution is to go through the databases and drop the tables manually.
BTW I don't recommend using LoopBack's autoupdate/automigrate functionality in production and highly advocate for maintaining a set of migration scripts as described e.g. in Martin Fowler's excellent article Evolutionary Database Design.
LoopBack does not support migration scripts yet, but we are discussing how to implement them for LoopBack 4+, see https://github.com/strongloop/loopback-next/issues/487
Have you looked into using the built-in API?
https://apidocs.strongloop.com/loopback/#app-deletemodelbyname
Ended up doing it manually - in 3 databases :(
I'm closing the question, but willing to reopen if someone had a good answer.
We use model first for tables and relations and database first for views and stored procedures.
If we change the model we have to:
-generate database
-create views and procedures
-add the procedures and the views to the model
-remap function call of procedures manually
This costs much time because the model changes often or has failures.
Does anyboy knows a workaround to automatically integrate the views and procedures in the model?
You could automate the process by creating your own template for generating DDL from SSDL. By default EF designer uses SSDLToSQL10.tt file but you could create your own .tt file which would generate DDL that better suits your needs. This should address 1) and 2). Once you have the database you could now update your model from the database. This should adress 3). Finally to address 4) you could write a Model Generation Extension that would tweak the model the designer builds from the database in the OnAfterModelGenerated/OnAfterModelUpdated method. (Be aware - some of the extension points in the designer are weird to say the least and might be confusing/hard to implement).
Another option you may want to explore is to use Code First and Migrations. With Migrations you could evolve your database instead of constantly creating/deleting it. If you need, you can use SQL to define a migration so you have full control of how your database looks like. Code First does not support some of the features supported by ModelFirst/DatabaseFirst (e.g. TVFs/FunctionImports) so you may want to check first if what's supported is enough for you.
I have four versions of my CoreData model. I've just added the fourth with a small change, a new optional attribute in one entity. Between version 2 and 3, I've made a mistake and made a change to the existing model instead of creating a new version. I restored version 2, added the version 3 and forced a delete of the store, so the users that were updating the app were re-generating the store and not performing a migration.
This worked well, but now I'm trying to perform a lightweight migration with CoreData plus MagicalRecord, from version 3 to 4 of my store and I'm always getting a Can't find or automatically infer mapping model for migration error. I would like not to force the delete again, but I'm stuck at what else can I do to solve the lightweight migration. I'm starting to suspect that the problem still lies between version 2 and 3, but I can't confirm that.
The code I'm using to set up my store is quite simple:
[MagicalRecord setupCoreDataStackWithAutoMigratingSqliteStoreNamed:#"Store.sqlite"];
This error message usually means that you have either deleted or not included either the source or destination model in your app bundle, so core data cannot build a mapping model for you. The way to see what entities are effected is to print out the model hashes to the console and compare to see which entities have changed. From there you can determine how you need to build your mapping model. Also remember that migrations aren't sequential. You have 4 versions of your model which means you now have 4 x 3 x 2 migration combinations. Core data will only do one, from the version your source store is at, and the latest version. So you also need to test migrations from v1 to v4, v2 to v4 etc to cover all your bases.
I am facing a really weird problem! In my application which is using CoreData, I created a model. When the application ran the database was created. I openend the database using Firefox SqliteManager and added another column to it "ZABOUT" (For some reason the Core Data prefix columns with Z). Anyway, I also populated the ZABOUT column with some data. But now when I retrieve the object from within the app and display the value of ZABOUT it displays null. Any ideas what is going on.
If I set the value from within the iPhone application then it prints out okay.
Core Data and SQLite are separate technologies, and you can't mix them that way. If you want to add another entity, you need to do it through your Core Data model, not through SQLite.
Core Data configures the sqlite file it uses as a backing store with a private schema that is derived from it's data model. Because the Core Data framework is controlling the schema and contents of the .sqlite file, it's best not to think of it as an sqlite file. The fact that SQLite is used is essentially an implementation detail.
More on Core data, and what Core Data is Not. Core Data is not a relational database, and if that's what you're looking for, you might consider just using SQLite directly. XMLPerformance is probably the best sqlite-on-iOS sample.