Lightweight migration in core data tutorial swift iOS in Hindi

hey there welcome to another episode of coding with codecat15 this is ravi there are many features in core data which makes developers work easy and lightweight migration is one of those features in today's session we are going to understand what are lightweight migrations there won't be any code in today's session as everything is just configuration based before we begin with this session, if you like the work that I am doing if you are learning something from my videos then I would request you to please do subscribe to the channel and share it with your iOS group that being said, let's begin our today's session when we get changes in development mode then we can easily perform those changes without worrying about anything because your application is not yet released on app store but once your app gets released on the app store and people start using your application the story does not end there you want to add more good features to the application and probably some bug fixes from the previous version to improve your application in the next version you make code changes, or you improve performance if your application is using a database, mostly due to new changes sometimes you have to make changes to your database as well here are the different types of changes that occur in database adding a new table renaming a column of an existing table or you are creating new column in the existing table and sometimes you even delete an existing table and there can be number of changes like these in a database for new version you can easily do these changes in development mode but we have a small problem the application which is already on the app store suppose it has a table in it's database with the name employee the users of this application they might have saved some records in this employee table in new version you have to add a new column in the employee table and a new table named department the version 1 database has no idea when a new update comes what it has to do?, how many columns it has to add? or delete because changes in a database are not done automatically you have to execute those queries to make those changes it's pretty easy to make those changes in development because we have the control and we execute these queries manually but for the application which is already there on the app store we have to write some code to make changes to it if I was using SQLite I would have wrote some code on application load, which would tell me the version of the database and if I detect an old version, I would have executed queries for the new changes I have to write all these code here because when I release a new version of the app the old database present in users phone should have all these new changes and without executing any queries we cannot make any changes in a database if you don't make such changes when user tries to use the new features from the new update the application may crash at that time so now with new features I have to write code to update user's database as well which means double the work, double coding, and double testing but this is not true with core data in core data majority of the code is handled by the framework itself to handle any new changes for your new version core data has a feature called as migration there are two types of migration, one is a lightweight migration and the other is a heavyweight migration majority of the time we will be using the lightweight migrations in this session we will understand when to use lightweight migration as per apple developer documentation core data will perform the lightweight migration under the following condition too many points right but let me highlight few important points for you when you rename your entities, attributes or relationship and for renaming we have to use the renaming identifier which is just a simple configuration which we will see in today's demo when you add an entity, attribute or relationship when we delete an existing entity, attribute or relationship and there's one more highlight which is when you change a relationship type from one to one to one to many so these are some of the criteria where core data will try to do a lightweight migration if data of one entity is being transferred to a different entity then in that case we should choose to perform heavy weight migrations let's say you want to change the type of an attribute so in this case I have an id attribute who's type is UUID if I want to change the type from UUID to an integer then in that case you have to create a mapping model the process of that is a little different we will learn to use the mapping model in the heavyweight migration demo to know more if your changes fit the lightweight migration criteria I would recommend visiting the apple's developer documentation for more details the link of this documentation is mentioned in the video description please do check this out let's assume that our application is already on the app store and we have to make new changes for our new release in version 1 we just had one entity in our app which is employee but now in this employee entity we have to add a new attribute which is jobtitle we will be renaming the existing attribute firstname attribute to name we will add a new entity with the name department which will have relationship with the entity employee interesting part is all these changes in core data are configuration based so let's switch to XCode and start configuring our XCDataModel for our new release so as of now in my database I just have one table which is CDEmployee I can see that the employee table has two records ravi and codecat15 so right now inside the xcdatamodel we have an entity that is CDEmployee and we have to make changes in this employee entity over here you can see, we have an arrow besides the XCDataModel and now you can see there's a migrationdemo.xcdatamodel and there's a migration demo v2.Xcdatamodel notice one thing in the migrationdemo.xcdatamodel it has a green tick over here which means that this is the current model version which means whatever changes you make core data will use this model version so we have to make sure the green tick is not on migration demo but on migration demo v2 because we will be using v2 version for our next release and over here you have an option named model version the current model version is set to migration demo so change it to migration demo v2 and now the green tick is on migration demo v2 this is the first step of migration if you skip this step, then you may get issues in testing so don't rush to code like creative developer make sure you complete this step first and see the green tick mark on your new model version there could be one question here, which is why we created this model version why can't we directly make changes to answer that let me give you an example with my home keys I can unlock my home door I cannot unlock someone else door with my home keys and even if i tried the door won't open because the key is not compatible with that lock here too we have the same situation as we have seen in the core data introduction video the persistent container uses the xcdata model to create and manage the core data stack suppose we made changes to the same XCDatamodel the core data store would not have opened because you have changed the identity of the same xcdatamodel that core data used to perform its operation and this may cause a crash in our application once again i would like to say today's demo it's based on the assumption that our application is already on app store and we are making changes for the new version so now let's go ahead and make changes to our entity so i am going to select migration demo v2 and over here you can see just like we had an entity in migration demo with the name cdemployee similarly in migration demo v2 we have an entity cdemployee and since one department can have more than one employee and since one employee belongs only to one department the relationship type is set to one so one thing over here is a department can contain multiple employee and i have just named it toemployee which is singular so let us go ahead and change that to plural i.e. toEmployees over here one last change I have to do is I have to rename the firstname to name in your next version if you have to rename your entity, attribute or relationship we have to use the renaming identifier in this case i want to rename this firstname attribute to name so i am going to select this attribute i am going to go inside the data model inspector and over here you can see we have something called as the renaming id which is the renaming identifier core data uses this renaming identifer to detect name changes renaming identifiers are case sensitive so it has to match the same name of the attribute which you want to rename i think we have everything in place and all that's left is creating the managed object subclass so let me save this first over here inside the core data support files group there are some managed object subclass which are created let us go ahead and delete that now you will get two options here i.e. migration demo v2 and migration demo since we are using v2, i'll just make sure that the checkbox here is checked here inside view controller, we have some code so we are getting some error because the firstname we used earlier is now replaced with name and here I am going to print the new attribute that we added which is employee jobtitle now let me build the application we are actually done with the migration and this is all you have to do for lightweight migration but there's one thing which i want to share if you have read somewhere about migration in blog or saw a video on it there's one code which is always there in them which is let me switch to persistent storage for that over here you can see there's a description which is of the type persistent store description so over here you can see i am setting some properties to true which is should migrate to store automatically and the second one is should infer mapping model automatically and to be honest you don't really need this code because as per apple's developer documentation should infer mapping automatically the default value is already set to true and in the case of should migrate store automatically the default value is also set to true so if the values of these options are already set to true by default why do you want to set it to true explicitly why be creative when things are already simplified so over here we can go ahead and get rid of this code so now let me just run the application over here you can see the name is printed and nil is basically the job title in our previous version we did not have any attribute named jobtitle and that's the reason when we print the jobtitle, the jobtitle gets printed as nil but what i am really interested is, how does our database look so let me just copy this and let us go to the database here you can see we have two new tables actually only one new table because the employee table was already there let us see how this employee table looks like let me browse the data, this is the department table let me switch to employee here you can see we have the new relationship we have a new attribtute that is jobtitle and the first name column is now changed to name and the data is same intact i.e ravi and codecat15 so as you can see how easy it is to do lightweight migration and it is just configuration now developers can actually focus on their application and business logic than worrying about migration because with core data things are actually very simple and easy I really hope you enjoyed the session, if you like this video then please give a thumbs up and if you are new to the channel then please subscribe that being said, thank you so much for watching this. Have a nice day and Happy iCoding bye bye :)

Channel: Code Cat

Views: 3,640

Keywords: migration in core data, migration core data, core data migrations, lightweight migration in core data, lightweight migration core data swift 5, lightweight migration core data hindi, core data migration, lightweight migration hindi swift tutorial, ios 13 core data tutorial, core data tutorial swift, coredata in ios swift 5 hindi, core data migrations hindi, migration core data swift, core data migration tutorial, core data migration ios

Id: YPEX9twI-zU

Length: 13min 51sec (831 seconds)

Published: Sat Aug 01 2020