I have been struggling with this for 6 months and found this video today which solved all my issues in 13 minutes. I cannot tell you how grateful I am. Thank you for your concise, cover-all-cases explanation of a concept that no one online seems to be able to explain.
hey Stewart, thanks for the series! you are always my goto source for catching up with the SwiftUI. I love how much better and more modern SwiftData feels compared to the old CoreData.
As always my friend great video. I understand a little bit better, but this will still be a hard concept for me to get, so I’ll have to watch this a few times. I would love to see you add a video to this series demonstrating the other migrations that aren’t lightweight also where you have to put together a migration plan going from V1 to V2.
These are fantastic enablers that make DB easier in programming. Almost as easy as Paradox 3.5, for those who lived in that area. 🙂. Thank you Stewart for this extremely useful part of your series.
You solved something that has been bugging and avoids the need to duplicate a project for small changes to the DB during development. Either method is not a sweat.However, I see its real benefit in making small and incremental improvements to an app, which may require changes to the DB after the app has been published and is being used. Not sure how CloudKit would react to lightweight migrations.
Once the migration from summary to synopsis is done can the @Attribute decorator be removed? If not, what if synopsis should later be changed to "InMyOpinion"? What should the originalName be - summary or synopsis?
That would be unwise because you might have people who have not used your app since the first migration so a lightweight migrtion woud not work for this. YOu would have to use a full migration strategy here. I have yet to do a video on that topic, but it is a good one so I will do that later this year.
From my time working with SwiftData I have only seen usage of storing objects as arrays. How would you handle a user object in SwiftData or is it not really even possible?
A SwiftData object gets stored essentially as a row in a SQlLite table so there is no way around that. If there is only one object in the table you will have to check for that in code.
I don’t like MVVM at all. Way too much code to accomplish something in my opinion. I prefer putting my code for a view in an extension for the view that makes more sense to me. I also agree the view itself is the view model.
I have been struggling with this for 6 months and found this video today which solved all my issues in 13 minutes. I cannot tell you how grateful I am. Thank you for your concise, cover-all-cases explanation of a concept that no one online seems to be able to explain.
Great. Glad to help.
hey Stewart, thanks for the series! you are always my goto source for catching up with the SwiftUI. I love how much better and more modern SwiftData feels compared to the old CoreData.
Following along…. Learning a lot. My favorite kind of tutorial, that is, building up a real use application….
👏👏👏 @6:50 in the video, Stewart uses the Refactor menu item! I knew he'd come around and show how useful it is!
This was so useful, I can't believe that apple's documentation is so bad, you saved me weeks of painful research.
Excellent lessons and series 💯✨ Thank you a lot for incredible efforts Stewart ❤️✨ such amazing content 🙌
Glad you like them!
Great explanation of what I considered a difficult subject with SwiftData
As always my friend great video. I understand a little bit better, but this will still be a hard concept for me to get, so I’ll have to watch this a few times. I would love to see you add a video to this series demonstrating the other migrations that aren’t lightweight also where you have to put together a migration plan going from V1 to V2.
Super insightful video! I would love to see one covering custom migrations as well!
I will do one in the future.
Your videos is very good! I can't afford to miss even a minute. 😄
These are fantastic enablers that make DB easier in programming. Almost as easy as Paradox 3.5, for those who lived in that area. 🙂.
Thank you Stewart for this extremely useful part of your series.
Thanks Lars
Paradox and DB 2,3,4 were the main reasons I went with relational DB's in that "era"
so in time! I love your videos ❤
Glad you like them!
You solved something that has been bugging and avoids the need to duplicate a project for small changes to the DB during development. Either method is not a sweat.However, I see its real benefit in making small and incremental improvements to an app, which may require changes to the DB after the app has been published and is being used. Not sure how CloudKit would react to lightweight migrations.
Thank god for your soul to have incarnated on this planet!
LOL. I take you like my videos.
@@StewartLynch This is just the best explanation of migrations I've seen. Was struggling to grasp the whole subject of Swiftdata, until now :)
Stewart, Have you produced the video which points out the implications to CloudKit yet?
Cloudkit is next week and the week after
Once the migration from summary to synopsis is done can the @Attribute decorator be removed?
If not, what if synopsis should later be changed to "InMyOpinion"? What should the originalName be - summary or synopsis?
That would be unwise because you might have people who have not used your app since the first migration so a lightweight migrtion woud not work for this. YOu would have to use a full migration strategy here. I have yet to do a video on that topic, but it is a good one so I will do that later this year.
From my time working with SwiftData I have only seen usage of storing objects as arrays. How would you handle a user object in SwiftData or is it not really even possible?
A SwiftData object gets stored essentially as a row in a SQlLite table so there is no way around that. If there is only one object in the table you will have to check for that in code.
Hi, can the SwiftData be used in viewmodels only? Carrying over the environment is not ideal I think
Yes, but that is not how Apple wants you to do it. Their recommended way is the way I show.
I don't understand, why Apple want the logic to be in the views? Isn't the ViewModel the best place for that? @@StewartLynch
@arturo7392 the view in SwiftUI is also the ViewModel. There has been a lot of online discussion about this recently
I don’t like MVVM at all. Way too much code to accomplish something in my opinion. I prefer putting my code for a view in an extension for the view that makes more sense to me. I also agree the view itself is the view model.
So you guys are creating extensions that act as the ViewModel? Doesn't that have performance implications? @@StewartLynch