00:00:04.951 --> 00:00:08.026 Umm, but if anybody has any questions on migrations or
00:00:08.026 --> 00:00:11.214 schema changes in the latest version of CEF, I know that
00:00:11.214 --> 00:00:14.513 there's some some changes and I know we're also working on
00:00:14.513 --> 00:00:17.421 generating up to date documentation for this stuff.
00:00:18.201 --> 00:00:19.811 Umm but.
00:00:21.011 --> 00:00:24.372 If anybody has questions that can kind of get me a a starting
00:00:24.372 --> 00:00:27.191 point to start answering questions that would help.
00:00:29.261 --> 00:00:32.471 And uh, just OK, go ahead, Jeremy. And then just the note,
00:00:29.441 --> 00:00:29.851 Yeah.
00:00:31.771 --> 00:00:32.271 No.
00:00:32.471 --> 00:00:35.627 I believe there was a front end developer or two that had
00:00:35.627 --> 00:00:38.674 questions about migrations, which is the other piece of
00:00:38.674 --> 00:00:40.361 would be able to talking about.
00:00:39.701 --> 00:00:43.418 OK, alright. So specifically specifically around migrations,
00:00:43.418 --> 00:00:43.601 OK.
00:00:44.231 --> 00:00:45.981 Perfect. There you go, Michael, and go ahead, Jeremy.
00:00:49.971 --> 00:00:55.791 Umm, so I think mine was around uh. How the T force generate.
00:00:56.861 --> 00:01:00.494 So let's say for example, you're going to do a schema change that
00:01:00.494 --> 00:01:03.081 involves creating something like user product.
00:01:03.781 --> 00:01:10.212 And the the T fours may want that to be product user and if
00:01:10.212 --> 00:01:12.141 this isn't like 2.
00:01:13.511 --> 00:01:17.289 Deep into that kind of thing, maybe if you could tell some of
00:01:17.289 --> 00:01:18.691 those newer developers.
00:01:21.191 --> 00:01:23.956 You know what, what? The correct solution to that is. I
00:01:23.956 --> 00:01:25.141 understand that you can.
00:01:26.261 --> 00:01:28.431 Sometimes edit the TTN clude.
00:01:29.761 --> 00:01:30.091 Umm.
00:01:31.081 --> 00:01:33.393 I think it was actually user category which one of these I
00:01:33.393 --> 00:01:35.549 apologize if this if this question isn't really clear.
00:01:35.549 --> 00:01:37.431 Hopefully you're understanding what I'm asking.
00:01:37.081 --> 00:01:40.863 No. Yeah, yeah, I know exactly what you're asking. I will, if
00:01:40.863 --> 00:01:44.583 you don't mind. Put a pin on that one and we'll jump back to
00:01:44.583 --> 00:01:48.487 that one after we cover some of the other stuff. Because that's
00:01:46.251 --> 00:01:47.371 Cool. Yeah, that's fine.
00:01:48.487 --> 00:01:52.208 that's gonna be diving pretty deep into some of the T fours,
00:01:52.208 --> 00:01:52.391 so.
00:01:53.041 --> 00:01:53.691 Yeah, no worries.
00:01:54.111 --> 00:01:57.286 But yeah, definitely I will try to answer that one and then
00:01:57.286 --> 00:02:00.461 Michael, what was did you have a specific question as well?
00:02:02.441 --> 00:02:02.971 Yeah.
00:02:05.031 --> 00:02:05.941 The.
00:02:06.841 --> 00:02:10.311 Every time I create a migration and I move it over to.
00:02:11.211 --> 00:02:17.334 Not the one that a defaults on. I always have to go into another
00:02:13.671 --> 00:02:14.101 Umm.
00:02:17.334 --> 00:02:20.161 file and attach like the resx.
00:02:20.681 --> 00:02:21.201 Umm.
00:02:20.941 --> 00:02:25.294 Files to it. Is that the proper way to do it or is there like
00:02:25.294 --> 00:02:27.751 something a little more automated?
00:02:28.741 --> 00:02:31.151 Unfortunately, as far as I'm aware.
00:02:31.901 --> 00:02:35.498 About 90% of the time it you have to do it that manual way
00:02:35.498 --> 00:02:39.462 every now and then. When if I do it in Visual Studio it will. It
00:02:39.462 --> 00:02:42.511 will set up the like associations and those files
00:02:42.511 --> 00:02:43.121 correctly.
00:02:43.941 --> 00:02:46.953 But most of the time, unfortunately, I have to go and
00:02:46.953 --> 00:02:50.132 manually modify that, and if anybody's curious what what
00:02:50.132 --> 00:02:51.471 Michael's talking about.
00:02:52.211 --> 00:02:55.174 And I'll I'll give a little bit more description on this once we
00:02:55.174 --> 00:02:57.727 really start talking about migrations. But whenever you
00:02:57.727 --> 00:03:00.645 create a migration, it's gonna land in this 01 clarity commerce
00:03:00.645 --> 00:03:01.511 data model project.
00:03:02.181 --> 00:03:05.695 But it's supposed to technically live in the data model dot
00:03:05.695 --> 00:03:09.325 shared project with the rest of the migrations. When you copy
00:03:09.325 --> 00:03:11.961 that file from this project to this project.
00:03:13.421 --> 00:03:16.348 It will actually come up. Unfortunately, that didn't work
00:03:16.348 --> 00:03:16.701 for me.
00:03:18.421 --> 00:03:21.121 Uh dude this.
00:03:24.741 --> 00:03:25.941 Open it over here.
00:03:31.611 --> 00:03:36.342 Whenever you copy that file, it will come up and show a
00:03:36.342 --> 00:03:37.441 modification.
00:03:38.871 --> 00:03:43.059 In this SSH prod, the 01 clarity commerce data model shared dot
00:03:43.059 --> 00:03:47.181 SH prod our sorry project items will be the one that modifies.
00:03:47.181 --> 00:03:50.911 It's not the stage project it'll it'll modify this file.
00:03:52.371 --> 00:03:55.919 But it won't look like the rest of these migrations, so you can
00:03:55.919 --> 00:03:59.412 see that these migrations, as they say, like embedded resource
00:03:59.412 --> 00:04:02.517 dependent upon whatever. And then there's another one a
00:04:02.517 --> 00:04:06.010 little bit further up of this designer dot CS. It's also got a
00:04:06.010 --> 00:04:09.171 dependent upon when you copy it over from Visual Studio.
00:04:09.931 --> 00:04:13.262 Sometimes like 90% of the time it doesn't set up these
00:04:13.262 --> 00:04:17.079 dependent upon parts correctly and so you just have to come in
00:04:17.079 --> 00:04:20.168 and do it manually and that's really annoying, but
00:04:20.168 --> 00:04:21.501 unfortunately that is.
00:04:22.241 --> 00:04:23.051 How it is?
00:04:24.691 --> 00:04:25.301 And.
00:04:26.321 --> 00:04:30.488 And if anybody and most of the reason that we have the shared
00:04:30.488 --> 00:04:31.631 project was from.
00:04:32.411 --> 00:04:36.981 A sort of previous modernization move that.
00:04:37.641 --> 00:04:41.106 We're not doing as much anymore, so it's very possible that we
00:04:41.106 --> 00:04:44.406 could also just not have the shared project anymore and put
00:04:44.406 --> 00:04:45.451 it all back in one.
00:04:47.571 --> 00:04:49.511 And that would make things a lot easier.
00:04:51.211 --> 00:04:53.481 That could very well be something that we.
00:04:55.551 --> 00:04:59.074 That we can discuss in the future, Eric, if you want to put
00:04:59.074 --> 00:05:01.951 a reminder for us to discuss that at some point.
00:05:03.901 --> 00:05:08.603 Because yeah, I think that would probably that would alleviate a
00:05:08.603 --> 00:05:12.075 lot of confusion and annoyingness around schema
00:05:12.075 --> 00:05:12.871 changes so.
00:05:15.311 --> 00:05:19.531 But yeah, when you copy it most of the time you have to do it.
00:05:20.521 --> 00:05:24.199 Or fix it up manually and either way you need to check if it
00:05:24.199 --> 00:05:26.431 worked or didn't work by looking at.
00:05:27.501 --> 00:05:30.251 The diff, which personally I always use VS code to do.
00:05:31.721 --> 00:05:32.091 So.
00:05:33.781 --> 00:05:36.911 But uh, assuming assuming that that is.
00:05:38.401 --> 00:05:41.954 All the specific questions people have, I can start kind of
00:05:41.954 --> 00:05:45.626 going over UM, some basics of entity framework and migrations
00:05:45.626 --> 00:05:46.811 and stuff like that.
00:05:47.341 --> 00:05:51.168 Umm. And a lot of the front Enders, I say a lot of them. I
00:05:51.168 --> 00:05:52.531 think it was just uh.
00:05:53.691 --> 00:05:58.255 Alex and Michael last week, uh got to hear a lot of this. Uh,
00:05:58.255 --> 00:06:02.892 already, so I'll be a little bit of a little bit of review for
00:06:02.892 --> 00:06:07.530 them, but I'll probably try to get a little bit more in detail
00:06:07.530 --> 00:06:07.751 so.
00:06:08.851 --> 00:06:11.868 You guys have, I mean, especially back Enders, but but
00:06:11.868 --> 00:06:15.269 most of the front edges too have probably heard us talk about
00:06:15.269 --> 00:06:16.421 entity framework and.
00:06:17.161 --> 00:06:22.184 Uh, migrations and maybe you've heard the phrase code first and
00:06:22.184 --> 00:06:27.051 you don't know what any of it means. UM, and that's perfectly
00:06:27.051 --> 00:06:31.211 fine. I didn't either when I started, but basically.
00:06:32.561 --> 00:06:38.532 Entity framework is a library created by Microsoft that allows
00:06:38.532 --> 00:06:39.101 us to.
00:06:39.881 --> 00:06:45.171 Uh query against a database using C#, so instead of having
00:06:45.171 --> 00:06:47.951 to physically write actual SQL?
00:06:49.841 --> 00:06:52.962 And target specific types of databases. Entity framework is
00:06:52.962 --> 00:06:56.239 kind of an abstraction over that where you can just write your
00:06:56.239 --> 00:06:59.464 queries and regular looking C and it converts it into SQL for
00:06:59.464 --> 00:07:02.845 you and it knows how to talk to different types of databases and
00:07:02.845 --> 00:07:06.278 things like that. So really it's just a helper for you to be more
00:07:06.278 --> 00:07:09.451 performant and efficient when you're working with databases.
00:07:10.051 --> 00:07:13.956 Umm. What? That actually what that actually looks like? If
00:07:13.956 --> 00:07:17.795 anybody looked at back in code, it's anytime you see that
00:07:17.795 --> 00:07:22.097 context dot products dot filter by active all that kind of stuff
00:07:22.097 --> 00:07:25.936 that's actually using entity framework and building a SQL
00:07:25.936 --> 00:07:26.731 query in C#.
00:07:28.351 --> 00:07:32.611 And so, uh, we use entity Framework version 6.
00:07:34.371 --> 00:07:38.376 It's it's an older version just because we're on NET Framework,
00:07:38.376 --> 00:07:42.131 but it's largely equal and it's feature set compared to any
00:07:42.131 --> 00:07:45.761 framework core and most of the documentation for them is.
00:07:46.521 --> 00:07:49.210 Sort of kind of interchangeable as far as the query language
00:07:49.210 --> 00:07:49.431 goes.
00:07:52.401 --> 00:07:54.401 We use a.
00:07:55.451 --> 00:07:58.751 They practice called code first and so.
00:08:00.231 --> 00:08:05.008 What that means basically is rather than building a database
00:08:05.008 --> 00:08:10.020 itself and then writing C code that queries against the tables,
00:08:10.020 --> 00:08:15.189 we build C# classes that sort of represent the database, and then
00:08:15.189 --> 00:08:20.044 we allow entity framework to generate a database that matches
00:08:20.044 --> 00:08:21.141 our C classes.
00:08:22.381 --> 00:08:25.933 And so if any of you have ever looked in the models folder
00:08:25.933 --> 00:08:28.161 under the data model shared project.
00:08:28.951 --> 00:08:32.308 These are where all those tables are. So when you're looking in
00:08:32.308 --> 00:08:35.507 the database and you've got products dot product or contacts
00:08:35.507 --> 00:08:38.602 dot user, all that stuff is defined in this models folder.
00:08:38.602 --> 00:08:41.749 So you've got the contacts dot user and you can see all the
00:08:41.749 --> 00:08:43.061 columns that are on that.
00:08:43.821 --> 00:08:46.141 Uh on that table are in here.
00:08:46.911 --> 00:08:47.521 Umm.
00:08:48.331 --> 00:08:51.043 And obviously there's a lot of extra these attributes and stuff
00:08:51.043 --> 00:08:53.713 that I won't go over now because there's a lot of detail there
00:08:53.713 --> 00:08:56.341 that are, it's not really super necessary at the moment, but.
00:08:58.571 --> 00:09:01.856 Uh. Suffice to say, you can see all the things that you would
00:09:01.856 --> 00:09:03.711 see on that table in the database.
00:09:04.031 --> 00:09:08.028 Umm. And so effectively what we're doing with these files is
00:09:08.028 --> 00:09:09.011 we're defining.
00:09:09.831 --> 00:09:13.776 How a sequel table would look for a class that's shaped like
00:09:13.776 --> 00:09:17.787 this and then Andy Framework handles looking at these classes
00:09:17.787 --> 00:09:20.051 and generating an actual database.
00:09:20.751 --> 00:09:23.071 The way that it does that is through migrations.
00:09:23.791 --> 00:09:24.581 And.
00:09:25.291 --> 00:09:29.516 What a migration actually does is each individual migration
00:09:29.516 --> 00:09:32.121 encapsulates the difference between.
00:09:32.881 --> 00:09:36.667 What was there at the time of the last migration and was there
00:09:36.667 --> 00:09:39.311 now? So if I were to go and add a property?
00:09:40.191 --> 00:09:43.613 Onto products dot product and you know whatever we wanted to
00:09:43.613 --> 00:09:47.034 call it, uh date available or something like that and then I
00:09:47.034 --> 00:09:50.232 created a migration it would create a new migration that
00:09:50.232 --> 00:09:53.485 would have something like add column as a perfect example
00:09:53.485 --> 00:09:57.075 right here add column products dot product grade. So this looks
00:09:57.075 --> 00:10:00.665 like somebody added a call into the products table called grade
00:10:00.665 --> 00:10:02.741 and I know that that's the thing so.
00:10:03.301 --> 00:10:07.454 Umm. And it's the property. Is a string with a Max length of 128
00:10:07.454 --> 00:10:10.201 characters and it's and it is not Unicode.
00:10:10.931 --> 00:10:11.721 Umm so.
00:10:12.451 --> 00:10:16.303 Uh, this migration code is auto generated by entity framework.
00:10:16.303 --> 00:10:20.156 It's not something that we at clarity will really ever have to
00:10:20.156 --> 00:10:20.951 modify, it's.
00:10:21.841 --> 00:10:23.451 It's not completely.
00:10:24.291 --> 00:10:27.359 Out against the rules to modify migration, especially in terms
00:10:27.359 --> 00:10:30.329 of a new framework itself, but at clarity it's not something
00:10:30.329 --> 00:10:33.397 that we really ever do, and if you find yourself needing to do
00:10:33.397 --> 00:10:33.641 that.
00:10:34.671 --> 00:10:37.886 That's probably a sign that something's gone wrong, and you
00:10:37.886 --> 00:10:39.441 should probably ask for help.
00:10:40.101 --> 00:10:42.651 UM, generally speaking.
00:10:43.501 --> 00:10:46.155 This file generates with all the changes and things that it needs
00:10:46.155 --> 00:10:48.246 to have in it, and we don't really need to make any
00:10:48.246 --> 00:10:49.251 additional modifications.
00:10:50.551 --> 00:10:54.069 So, but you can kind of see that what it's doing is it generates
00:10:54.069 --> 00:10:57.532 these custom calls of like add column and it's got the table to
00:10:57.532 --> 00:11:00.455 add the column to the name of the column and then the
00:11:00.455 --> 00:11:03.972 information about it. It's also got stuff like creating indices,
00:11:03.972 --> 00:11:07.490 creating foreign keys, creating entire new tables and stuff like
00:11:07.490 --> 00:11:07.761 that.
00:11:08.291 --> 00:11:12.114 Umm. And so that's basically what these migrations actually
00:11:12.114 --> 00:11:16.064 do is each of these calls inside of entity framework converts
00:11:16.064 --> 00:11:20.206 into SQL of like create table or alter table and stuff like that
00:11:20.206 --> 00:11:24.093 for each of these calls it's again same as it is when at the
00:11:24.093 --> 00:11:27.916 runtime when we write context dot products dot whatever and
00:11:27.916 --> 00:11:31.739 that translates into SQL all these add columns create index
00:11:31.739 --> 00:11:35.626 add foreign key. These are the same thing, they translate to
00:11:35.626 --> 00:11:35.881 SQL.
00:11:36.731 --> 00:11:38.241 Umm so.
00:11:39.251 --> 00:11:41.281 Before I get to uh.
00:11:41.981 --> 00:11:44.323 Complicated. I see. Justin, you've got your hand up. And
00:11:44.323 --> 00:11:46.706 then if anybody else has any questions at this time, feel
00:11:46.706 --> 00:11:48.021 free to raise your hand as well.
00:11:49.681 --> 00:11:52.871 Yeah, you may have already answered this and maybe more of
00:11:52.871 --> 00:11:56.386 a general question, but like the the concept of using migrations
00:11:56.386 --> 00:11:59.631 is that only used when we're using the code first approach.
00:12:00.291 --> 00:12:00.741 Yes.
00:12:01.321 --> 00:12:06.443 Umm, the reason for that is that or I guess the the the reason
00:12:01.511 --> 00:12:01.901 OK.
00:12:06.443 --> 00:12:11.241 that migrations exist is that something has to be able to.
00:12:12.421 --> 00:12:15.243 Uh, what sort? I'm looking for incrementally generate the
00:12:15.243 --> 00:12:15.681 database.
00:12:16.841 --> 00:12:20.651 So whenever I change a class, uh, that represents like a
00:12:20.651 --> 00:12:24.863 database table, there has to be some sort of basically running
00:12:24.863 --> 00:12:25.331 record.
00:12:26.201 --> 00:12:29.894 Of how much has changed in the date in the in the data model
00:12:29.894 --> 00:12:31.831 based on my classes, the models.
00:12:32.321 --> 00:12:36.752 Umm so that entity framework knows how to update a database
00:12:36.752 --> 00:12:40.739 to match my changes. Now obviously if you didn't care
00:12:40.739 --> 00:12:44.801 about the data that was in a database, you could just.
00:12:45.481 --> 00:12:48.301 You could just drop your whole database and have it generate a
00:12:48.301 --> 00:12:50.271 new one that matches your model every time.
00:12:50.971 --> 00:12:54.434 Umm, but then you'd lose all your data unless you manually,
00:12:54.434 --> 00:12:58.012 you know, keep it up to date. Migrations allow us to not lose
00:12:58.012 --> 00:12:58.301 data.
00:12:59.561 --> 00:13:04.047 But still define the structure of the database in code and it
00:13:04.047 --> 00:13:05.711 does that by basically.
00:13:06.741 --> 00:13:10.996 Uh, you can think of each of the migrations as a sort of like
00:13:10.996 --> 00:13:15.527 restore point or like a snapshot of the structure of the database
00:13:15.527 --> 00:13:19.783 at any given time, and in fact the time is right there in the
00:13:19.783 --> 00:13:20.881 name. Go figure.
00:13:19.831 --> 00:13:24.011 Have them set. If we use the. If we use the database.
00:13:26.011 --> 00:13:30.042 There options for generating this we would have to manually
00:13:30.042 --> 00:13:31.991 track this and manually keep.
00:13:30.441 --> 00:13:30.851 Right.
00:13:32.841 --> 00:13:38.881 Hey Scaffolded you know snapshot of the database structure.
00:13:39.951 --> 00:13:42.647 One major using configuration, probably one of the major
00:13:42.647 --> 00:13:43.641 reasons why we do it.
00:13:51.071 --> 00:13:53.641 Yeah. So yeah, that's exactly right.
00:13:55.461 --> 00:13:59.176 Database first is is nice in situations where you've got one
00:13:59.176 --> 00:14:02.891 sort of definitive database structure that you know is gonna
00:14:02.891 --> 00:14:06.301 be pretty set in stone, or you're building a data mine.
00:14:06.301 --> 00:14:09.590 You're gonna use entity framework against an existing
00:14:09.590 --> 00:14:13.183 database, and you just want to be able to query against it
00:14:13.183 --> 00:14:16.471 using C but code first is fantastic for us because it
00:14:16.471 --> 00:14:20.065 allows multiple people to work on the project and multiple
00:14:20.065 --> 00:14:23.779 people to iterate on the schema. And for us to have multiple
00:14:23.779 --> 00:14:26.642 copies of the site with databases that sort of
00:14:26.642 --> 00:14:27.251 different.
00:14:28.111 --> 00:14:31.139 Levels of migration, if you will, you know, QA sites
00:14:31.139 --> 00:14:34.625 probably gonna be more bleeding edge, have more, more recent
00:14:34.625 --> 00:14:37.311 migrations than your staging site for example.
00:14:38.851 --> 00:14:42.806 And doing it with code first means that we can just have the
00:14:42.806 --> 00:14:46.761 exact versioning of the database handled by the code itself.
00:14:47.481 --> 00:14:48.611 And we can sort of.
00:14:49.311 --> 00:14:52.011 Have a more well defined relationship between the
00:14:52.011 --> 00:14:55.305 structure of the database and the version of the code that's
00:14:55.305 --> 00:14:56.331 running against it.
00:14:58.131 --> 00:15:01.507 So I know that I I'm I'm trying not to. I'm trying not to to let
00:15:01.507 --> 00:15:04.623 this get overcomplicated and have people's eyes glaze over.
00:15:04.623 --> 00:15:07.999 Cause yeah, I think it's really important that people understand
00:15:07.999 --> 00:15:11.115 at least the basics of this. So am I losing anybody at this
00:15:11.115 --> 00:15:14.335 point? Is there anything I've said that people are just like,
00:15:14.335 --> 00:15:16.101 yeah, that sounds like something.
00:15:19.301 --> 00:15:22.064 And if if so, please let me know. I'm I'm glad to try to
00:15:22.064 --> 00:15:24.731 find a better way to word it cause I know sometimes I.
00:15:26.901 --> 00:15:27.951 Start spiralling.
00:15:29.851 --> 00:15:32.225 I know you're showing. I know you showed on the screen
00:15:32.225 --> 00:15:35.032 technically what it's doing, but can you just talk about the the
00:15:35.032 --> 00:15:37.709 UP method and the down method and how that actually interacts
00:15:37.709 --> 00:15:40.342 and what that what that's doing under the hood? I think that
00:15:40.342 --> 00:15:41.681 will help people understand it.
00:15:40.521 --> 00:15:40.831 Yeah.
00:15:42.041 --> 00:15:46.019 Yeah, definitely. So yeah, like I said, if I were to create a
00:15:46.019 --> 00:15:50.253 migration that added a column to the product table that's called,
00:15:50.253 --> 00:15:53.141 you know, date available, then we would see.
00:15:53.861 --> 00:15:57.220 Uh, this you know you have your your schema. This one called
00:15:57.220 --> 00:16:00.690 schema change. One for PCs, but whatever I called my migration
00:16:00.690 --> 00:16:04.269 would be the name of this class. This class will always have two
00:16:04.269 --> 00:16:05.371 methods up and down.
00:16:06.101 --> 00:16:09.665 Umm, so first we'll look at the UP method. What's happening here
00:16:09.665 --> 00:16:12.955 is whenever you run entity framework update database entity
00:16:12.955 --> 00:16:15.806 framework is gonna go in and find all this. All the
00:16:15.806 --> 00:16:19.205 migrations that aren't already in the database and it's gonna
00:16:19.205 --> 00:16:20.741 call this up method on them.
00:16:21.491 --> 00:16:24.554 And so in this up method, it's going to say, oh, I need to go
00:16:24.554 --> 00:16:27.371 add a column to the product table called date available.
00:16:28.691 --> 00:16:32.636 And again, that translates down into SQL. That's like alter
00:16:32.636 --> 00:16:36.779 table whatever to generate the new columns that it needs to do
00:16:36.779 --> 00:16:38.621 based on your schema change.
00:16:39.871 --> 00:16:43.190 And then it will go and execute that SQL against the database
00:16:43.190 --> 00:16:45.921 and that'll basically update it to that migration.
00:16:47.341 --> 00:16:50.244 If there are multiple migrations you're applying, then it will do
00:16:50.244 --> 00:16:52.840 them in order from the oldest to the newest, because every
00:16:52.840 --> 00:16:55.743 migration and I'll I'll touch on this a little bit more a minute.
00:16:55.743 --> 00:16:57.591 Every migration builds upon the last one.
00:16:58.341 --> 00:16:59.441 And so.
00:17:00.031 --> 00:17:04.090 Uh, a migrate any any given migration is basically telling
00:17:04.090 --> 00:17:08.632 entity framework. Here's how you update from the migration before
00:17:08.632 --> 00:17:12.691 me to me to the latest version of what you know as of this
00:17:12.691 --> 00:17:13.311 snapshot.
00:17:14.461 --> 00:17:18.243 And so I'll talk about that a little bit more in a minute, but
00:17:18.243 --> 00:17:21.426 that's what the up method is doing is it's basically
00:17:21.426 --> 00:17:24.728 instructions for entity framework to take the database
00:17:24.728 --> 00:17:28.571 as it was and the last migration and make it match the current.
00:17:29.241 --> 00:17:29.961 Data model.
00:17:31.311 --> 00:17:35.609 And then the inverse of that is the down method. The down method
00:17:35.609 --> 00:17:39.443 has a drop column call for the same thing. So here's drop
00:17:39.443 --> 00:17:43.212 column products dot product grade. So this is if you are
00:17:43.212 --> 00:17:44.601 reverting migrations.
00:17:44.701 --> 00:17:47.733 Umm, which is relatively uncommon but can happen if
00:17:47.733 --> 00:17:51.349 there's like some some schema change issues or you needed to,
00:17:51.349 --> 00:17:54.557 you know, remake a migration because it didn't work or
00:17:54.557 --> 00:17:58.406 whatever. This is telling it any framework. Here's how to undo my
00:17:58.406 --> 00:18:00.681 schema changes in the actual database.
00:18:00.841 --> 00:18:03.706 Umm. And so this will go in and remove the column from the
00:18:03.706 --> 00:18:06.716 products table that you created or it'll drop the whole table
00:18:06.716 --> 00:18:09.629 categories dot category user that you made all that kind of
00:18:09.629 --> 00:18:09.921 stuff.
00:18:10.521 --> 00:18:12.491 Umm so.
00:18:13.601 --> 00:18:16.748 Basically, you can think of this as. Apply the schema changes to
00:18:16.748 --> 00:18:19.265 the database and remove the schema changes from the
00:18:19.265 --> 00:18:19.701 database.
00:18:21.431 --> 00:18:25.133 Important note here, it's in case anybody's confused about
00:18:25.133 --> 00:18:29.023 it. The UP method doesn't change anything about your code. It
00:18:29.023 --> 00:18:32.975 doesn't change anything about the models files you've written,
00:18:32.975 --> 00:18:36.865 or the migration itself. It's analyzing that code to generate
00:18:36.865 --> 00:18:40.630 SQL that alters the database itself, and it will only alter
00:18:40.630 --> 00:18:43.955 the database that your connection string is pointing
00:18:43.955 --> 00:18:47.720 at. So if you make a migration on your local and you update
00:18:47.720 --> 00:18:51.484 your local database and the sites working and everything is
00:18:51.484 --> 00:18:51.861 great.
00:18:52.561 --> 00:18:56.060 That's awesome. Fantastic. When you push this to QA, this
00:18:56.060 --> 00:18:57.991 migration doesn't automatically.
00:18:58.831 --> 00:19:01.571 You know, fix up everyone's local and everything like that.
00:19:02.351 --> 00:19:05.675 99% of the time, they're still gonna need to go run a migration
00:19:05.675 --> 00:19:08.687 as well to get their local database or the QA database up
00:19:08.687 --> 00:19:11.959 to date to match this, because something has to go tell the QA
00:19:11.959 --> 00:19:14.815 database that there's changes and that they need to be
00:19:14.815 --> 00:19:15.231 applied.
00:19:16.691 --> 00:19:17.501 I think.
00:19:18.331 --> 00:19:21.960 In some of the most recent version of Steph, I think in
00:19:21.960 --> 00:19:25.525 2022.4 we might have actually made it automatic in the
00:19:25.525 --> 00:19:27.081 storefront API to apply.
00:19:28.071 --> 00:19:31.899 Migrations. Yeah. OK, cool. So at the very least, I think in
00:19:31.899 --> 00:19:35.727 2022.4 newer, if you're loading up the storefront, it should
00:19:35.727 --> 00:19:39.304 automatically apply migrations for you now. Now, if that
00:19:39.304 --> 00:19:43.258 process fails, your site's gonna not load, obviously, and then
00:19:43.258 --> 00:19:46.961 you'll just have to get some help, but generally speaking.
00:19:48.321 --> 00:19:51.565 A migration shouldn't fail unless there's some very
00:19:51.565 --> 00:19:54.311 interesting, uh, extenuating circumstances.
00:19:55.751 --> 00:19:56.131 So.
00:19:57.671 --> 00:20:03.361 Uh, yeah. Does anybody have any any questions about any of that?
00:20:07.211 --> 00:20:10.621 I guess just one question, Brendan, like so if you were to
00:20:09.321 --> 00:20:09.531 Hmm.
00:20:10.621 --> 00:20:14.262 do like a update database target migration and say like 2 back
00:20:14.262 --> 00:20:17.845 from the current migration to like roll something back, would
00:20:17.845 --> 00:20:20.331 that essentially be using the down method?
00:20:20.681 --> 00:20:22.191 Yes, that's exactly what it does.
00:20:21.831 --> 00:20:22.141 OK.
00:20:22.881 --> 00:20:24.271 OK. That makes sense.
00:20:23.411 --> 00:20:26.951 So yeah, if so, like my my PCs database, I'm looking at PCs
00:20:26.951 --> 00:20:30.668 here. Obviously my PCs databases on the latest migration. If I
00:20:30.668 --> 00:20:34.208 were to call update database target migration, I don't know
00:20:34.208 --> 00:20:37.807 add price rule franchise then what it's gonna do is starting
00:20:37.807 --> 00:20:41.583 from the most recent and going back. So it doesn't the opposite
00:20:41.583 --> 00:20:44.946 order of the normal adding migrations, it'll remove them
00:20:44.946 --> 00:20:48.664 one at a time. So it'll run the down method for this migration
00:20:48.664 --> 00:20:52.145 which is this piece of code we're looking at here. It will
00:20:52.145 --> 00:20:53.561 drop these foreign keys.
00:20:53.641 --> 00:20:57.034 These indices, these columns and then this table and then it'll
00:20:57.034 --> 00:21:00.215 go and draw. Run this drop method that drops a bunch of or.
00:21:00.215 --> 00:21:03.661 It actually adds columns because they were just removed in this.
00:21:05.261 --> 00:21:08.686 Migration here and then it would drop this core bit updates that
00:21:08.686 --> 00:21:09.951 would do a lot of stuff.
00:21:11.031 --> 00:21:14.092 And then it would drop this credit, Swain and etcetera. So
00:21:14.092 --> 00:21:17.465 it would it basically just runs these from newest to oldest, the
00:21:17.465 --> 00:21:20.371 drop method to revert the changes that these migrations
00:21:20.371 --> 00:21:21.461 made in the database.
00:21:23.001 --> 00:21:26.197 So whenever you're applying new migrations, it applies them
00:21:26.197 --> 00:21:29.447 oldest to newest when you're reverting them, it reverts them
00:21:29.447 --> 00:21:32.803 newest to oldest, so it's always just one taking one step. The
00:21:32.803 --> 00:21:34.401 direction you're trying to go.
00:21:35.101 --> 00:21:35.641 Umm.
00:21:36.531 --> 00:21:38.281 So yeah, what's up?
00:21:40.531 --> 00:21:44.865 So if those migrations have to be called in a specific order,
00:21:44.865 --> 00:21:49.268 so if you rolled back like 5 for example, and then try to call
00:21:49.268 --> 00:21:53.392 update database again, those same 5 have to be recalled in
00:21:53.392 --> 00:21:57.376 the inverse order. Is there ever situation where there's
00:21:57.376 --> 00:22:01.710 migrations could get out of sync and you're trying to apply a
00:22:01.710 --> 00:22:05.974 migration where you're missing one and the migration history
00:22:05.974 --> 00:22:08.211 has one or two entries that say?
00:22:09.101 --> 00:22:11.329 Aren't listed in the code base or something like that where
00:22:11.329 --> 00:22:13.261 they could get out of sync and then calls problems.
00:22:14.271 --> 00:22:18.291 So the only way that that would happen is if you reverted
00:22:18.291 --> 00:22:22.796 migrations and then deleted them and then created new migrations
00:22:22.796 --> 00:22:26.608 further upstream and other people had those migrations
00:22:26.608 --> 00:22:29.381 actually applied to their their locals.
00:22:30.741 --> 00:22:31.451 And so.
00:22:32.481 --> 00:22:36.089 Generally speaking, we would catch something like that in a
00:22:36.089 --> 00:22:39.757 code review. If you're deleting a migration that was already
00:22:39.757 --> 00:22:43.125 that already existed on QA, that's we just we. You just
00:22:43.125 --> 00:22:46.853 can't do that if the intent is to revert the behavior of that
00:22:46.853 --> 00:22:50.161 migration, then you would just need to create a second
00:22:50.161 --> 00:22:53.648 migration that is the opposite of that first one. And the
00:22:53.648 --> 00:22:57.016 reason is it's basically a matter of record. Like I was
00:22:57.016 --> 00:23:00.925 saying earlier, every migration builds upon the last one and the
00:23:00.925 --> 00:23:03.571 database is updated to match that snapshot.
00:23:03.671 --> 00:23:07.391 As it is, if you get rid of one of those snapshots then entity
00:23:07.391 --> 00:23:11.170 framework does no longer knows how to roll the database back or
00:23:11.170 --> 00:23:14.950 bring it forward anymore. You've kind of broken that chain, and
00:23:14.950 --> 00:23:18.316 so then if you try to create another migration on top of
00:23:18.316 --> 00:23:18.611 that.
00:23:19.251 --> 00:23:22.422 There's going to be mismatches because it doesn't. There's a
00:23:22.422 --> 00:23:25.489 missing step there that that was deleted. UM, so if you're
00:23:25.489 --> 00:23:28.452 working on your local and you create a migration and you
00:23:28.452 --> 00:23:31.623 realize, oh crap, I screwed up and you delete, you roll that
00:23:31.623 --> 00:23:34.846 migration back on your local, delete it, you're fine. As long
00:23:34.846 --> 00:23:38.121 as that hasn't been deployed to QA or something like that. But
00:23:38.121 --> 00:23:38.641 if you're.
00:23:39.061 --> 00:23:41.832 If you're looking at a migration that already exists in like the
00:23:41.832 --> 00:23:44.432 QA branch, and it's already been applied to everybody else's
00:23:44.432 --> 00:23:45.711 databases and stuff like that.
00:23:46.381 --> 00:23:50.576 Your your only recourse at that point is to create. Excuse me,
00:23:50.576 --> 00:23:54.505 create a new migration that fixes the problem. You need to
00:23:54.505 --> 00:23:58.501 fix itself without deleting any of the previous migrations.
00:23:59.041 --> 00:24:02.177 Umm. And then I hope that answered the question, but then
00:24:02.177 --> 00:24:05.475 the other kind of half of that question, it sounded like you
00:24:05.475 --> 00:24:08.882 were asking was like if I were to roll back five migration. So
00:24:08.882 --> 00:24:12.342 let's say that I rolled back to this credits migration and then
00:24:12.342 --> 00:24:15.587 I went and made a schema change in my code and tried to run
00:24:15.587 --> 00:24:18.777 update database. What would happen? Well, the good news is
00:24:18.777 --> 00:24:22.183 that the code is already up to date. The code is always there.
00:24:22.183 --> 00:24:25.536 Like I said, these migrations, they're just snapshots for the
00:24:25.536 --> 00:24:28.726 database itself. They don't alter anything about my actual
00:24:28.726 --> 00:24:30.781 code. They're just based on the code.
00:24:31.081 --> 00:24:35.513 So if I roll, I could roll back to, you know, initial create all
00:24:35.513 --> 00:24:37.491 the way at the top from 2016.
00:24:38.621 --> 00:24:43.491 And all my current SEF 2022.4 schema files are still in here.
00:24:44.061 --> 00:24:47.904 Umm. And So what would happen at that point is entity framework
00:24:47.904 --> 00:24:51.388 would detect that you are not your database is not on the
00:24:51.388 --> 00:24:54.931 latest and it would tell you something along the lines of.
00:24:56.151 --> 00:24:58.780 Unable to generate a new migration because there are
00:24:58.780 --> 00:25:01.459 existing migrations that have not been applied to the
00:25:01.459 --> 00:25:04.485 database. So entity framework will actually prevent you from
00:25:04.485 --> 00:25:07.511 creating a migration that's based on an older version. If it
00:25:07.511 --> 00:25:10.587 can determine that your code is not on that, your database is
00:25:10.587 --> 00:25:12.671 not on the latest according to your code.
00:25:19.011 --> 00:25:20.461 Does that answer your question?
00:25:20.851 --> 00:25:22.341 Yes, that does answer my question.
00:25:22.521 --> 00:25:24.741 OK, awesome. And then Michael had something.
00:25:28.081 --> 00:25:31.031 Yeah, every time you run updates.
00:25:33.821 --> 00:25:40.249 Update database is that ND framework updating that DBO dot
00:25:40.249 --> 00:25:42.211 migration history.
00:25:42.691 --> 00:25:43.161 Yes.
00:25:42.891 --> 00:25:43.911 A table.
00:25:44.501 --> 00:25:46.071 Yep, that's.
00:25:45.161 --> 00:25:47.572 And that's that's the piece that's keeping track of it,
00:25:47.572 --> 00:25:47.831 right?
00:25:48.081 --> 00:25:52.005 Exactly. That's exactly right. So basically, uh, if you guys
00:25:52.005 --> 00:25:55.993 have ever noticed that on our databases, there's one singular
00:25:55.993 --> 00:25:59.917 table that doesn't match the naming format of all the others
00:25:59.917 --> 00:26:00.561 and it is.
00:26:01.201 --> 00:26:04.960 Dbo. Migration history and you can feel free to select in here
00:26:04.960 --> 00:26:08.600 and read it all. And would you look at that that these names
00:26:08.600 --> 00:26:12.239 exactly match the names of the code files for the migrations
00:26:12.239 --> 00:26:13.791 that we've created in SEV.
00:26:15.231 --> 00:26:18.444 This table is the one that tracks which migrations have
00:26:18.444 --> 00:26:21.887 actually been applied to the database. So if you rollback a
00:26:21.887 --> 00:26:24.641 migration and the framework handles, obviously.
00:26:25.281 --> 00:26:28.485 Removing the columns or you know reverting the schema itself and
00:26:28.485 --> 00:26:31.442 it also comes in and removes the record that says that that
00:26:31.442 --> 00:26:34.351 schema change or that migration was ever actually applied.
00:26:35.531 --> 00:26:38.948 That's how entity Framework knows which migrations it needs
00:26:38.948 --> 00:26:42.366 to add to a database is it says OK well, the code says that
00:26:42.366 --> 00:26:46.125 there's these 10 migrations that exist in all of history for this
00:26:46.125 --> 00:26:49.542 database, and the migration history table says that it only
00:26:49.542 --> 00:26:53.130 has eight records. OK, so that means that the last two we need
00:26:53.130 --> 00:26:56.491 to apply and what it can do at that point is it can check.
00:26:57.401 --> 00:27:01.306 Do the do the eight that are applied to the database match
00:27:01.306 --> 00:27:02.961 the first eight in order?
00:27:03.761 --> 00:27:07.029 In the code, and if it doesn't then it can give you an error
00:27:07.029 --> 00:27:10.191 that says hey, there's something wrong with your migration
00:27:10.191 --> 00:27:13.727 history and that's kind of where that deleting records comes from
00:27:13.727 --> 00:27:16.513 is is. It can at that point determine that it has a
00:27:16.513 --> 00:27:19.836 migration that no longer exists in the code, and it will give
00:27:19.836 --> 00:27:23.104 you a nice error message that tells you that some wild stuff
00:27:23.104 --> 00:27:26.373 just happened. And then you'll have to go fix that. But yes,
00:27:26.373 --> 00:27:29.802 that's a really good question. The migration history table will
00:27:29.802 --> 00:27:33.285 tell you exactly what migrations have been applied to a database
00:27:33.285 --> 00:27:34.571 now, generally speaking.
00:27:35.761 --> 00:27:40.239 The contents of this table obviously don't ever modify them
00:27:40.239 --> 00:27:40.911 yourself.
00:27:42.231 --> 00:27:43.691 But most of the time.
00:27:44.481 --> 00:27:48.527 If you're having issues with migrations and you're you're
00:27:48.527 --> 00:27:50.201 digging into this table.
00:27:50.781 --> 00:27:51.451 Umm.
00:27:53.211 --> 00:27:56.524 I mean, aside from just looking at the most recently applied one
00:27:56.524 --> 00:27:59.683 and maybe at most validating that the order that these are in
00:27:59.683 --> 00:28:02.181 here makes sense and looks the same as the code.
00:28:03.281 --> 00:28:06.570 Anything further than that indicates that there's something
00:28:06.570 --> 00:28:10.023 more going on with your, your schema, or whatever issue you're
00:28:10.023 --> 00:28:13.531 trying to troubleshoot, to the point that it's not really worth
00:28:13.531 --> 00:28:16.711 syncing the time into just into looking at this stuff and
00:28:16.711 --> 00:28:19.671 looking at these models and these hashes or whatever.
00:28:20.571 --> 00:28:22.261 Just get office hours at that point.
00:28:22.351 --> 00:28:26.551 Umm, because there's there's any number of hours to be lost
00:28:26.551 --> 00:28:30.891 trying to make sense of all this stuff, and usually there's a
00:28:30.891 --> 00:28:33.761 quick fix for these kind of issues that.
00:28:35.501 --> 00:28:37.561 That can just get you unblocked quickly so.
00:28:37.971 --> 00:28:42.155 Umm, I think when it comes to having any issues with with
00:28:42.155 --> 00:28:46.771 migrations and things like that, if it's not an obvious problem
00:28:46.771 --> 00:28:51.028 that you that you can fix quickly, ask for help and if you
00:28:51.028 --> 00:28:54.851 don't get a quick answer just schedule office hours.
00:28:56.221 --> 00:29:00.351 Because like I said, too much time can be lost trying to fix
00:29:00.351 --> 00:29:04.007 confusing and vague error messages from SQL that it's
00:29:04.007 --> 00:29:05.971 better to just get some help.
00:29:14.091 --> 00:29:17.601 Any more questions? If not, I've got one last.
00:29:19.561 --> 00:29:21.781 Little note to to go over here.
00:29:23.031 --> 00:29:23.681 And.
00:29:27.461 --> 00:29:31.321 Cool. Alright, well, the last thing I wanted to cover is.
00:29:32.621 --> 00:29:35.291 Related to something I've mentioned a couple Times Now.
00:29:36.671 --> 00:29:40.524 Because every migration builds off the last one and creates a
00:29:40.524 --> 00:29:43.881 new snapshot of the database as it is at that moment.
00:29:44.741 --> 00:29:48.835 You cannot have two different branches making a schema change
00:29:48.835 --> 00:29:52.731 at the same time based off the same previous migration so.
00:29:54.321 --> 00:29:58.192 Let's let's say that I branch off of PCs right now and I go
00:29:58.192 --> 00:30:01.933 make a migration that adds my date available field to the
00:30:01.933 --> 00:30:05.611 product table, and then Joe developers and the nebulous.
00:30:05.731 --> 00:30:08.641 Uh, you know the nebulous guy that all that I'll pick on?
00:30:09.961 --> 00:30:13.548 He branches off and he goes and makes an A migration as well,
00:30:13.548 --> 00:30:17.193 and neither of us have the other person's migration. Well, our
00:30:17.193 --> 00:30:20.607 locals are gonna work just fine because we are. Migrations
00:30:20.607 --> 00:30:23.905 aren't in each other's code bases. We're not conflicting
00:30:23.905 --> 00:30:24.831 with each other.
00:30:25.491 --> 00:30:28.928 As soon as we try to merge both of those migrations into QA,
00:30:28.928 --> 00:30:32.366 site's gonna build just fine, but it's not gonna run and the
00:30:32.366 --> 00:30:35.803 migrations will not work. And the reason for that is exactly
00:30:35.803 --> 00:30:39.240 what I was saying. If there are two migrations that are both
00:30:39.240 --> 00:30:42.171 trying to alter the schema as it was at this point.
00:30:43.671 --> 00:30:46.123 How it doesn't know how to apply both of those without
00:30:46.123 --> 00:30:47.371 conflicting with each other?
00:30:47.941 --> 00:30:48.501 Umm.
00:30:49.541 --> 00:30:52.730 So it's sort of like a fork in the road if you if you want to
00:30:52.730 --> 00:30:56.073 think about it like that, where each of these is just, it builds
00:30:56.073 --> 00:30:59.210 off of this one, it builds off of this one. It builds off of
00:30:59.210 --> 00:31:02.502 this one. Every single one is an is singular individual step up
00:31:02.502 --> 00:31:04.971 the tree with no forking or anything like that.
00:31:05.891 --> 00:31:09.061 Once you have two migrations that are defined on the same.
00:31:10.121 --> 00:31:13.552 Uh, you know, as basically they had the same original migration
00:31:13.552 --> 00:31:16.661 above them. At that point, there's a fork in the road and
00:31:16.661 --> 00:31:19.824 any framework doesn't know how to handle that. And so it's
00:31:19.824 --> 00:31:22.987 extremely important. And this is almost more of a note for
00:31:22.987 --> 00:31:26.365 project managers, but it's good for developers to know as well
00:31:26.365 --> 00:31:29.420 if you guys see that you have a schema change ticket and
00:31:29.420 --> 00:31:32.583 somebody else on the same project also has a schema change
00:31:32.583 --> 00:31:34.031 ticket and the same Sprint.
00:31:35.351 --> 00:31:38.476 You either need to a tell the project manager that those both
00:31:38.476 --> 00:31:41.299 to those tickets should be assigned to one person to do
00:31:41.299 --> 00:31:44.475 them at the same time, or be you need to communicate with each
00:31:44.475 --> 00:31:47.600 other and one of you needs to block your task until the other
00:31:47.600 --> 00:31:48.961 person schema changes done.
00:31:49.691 --> 00:31:53.049 Umm. And that will just make sure that we don't run into any
00:31:53.049 --> 00:31:56.352 issues where two different schema changes going at the same
00:31:56.352 --> 00:31:59.820 time and then break a site and it's a. It's a real headache to
00:31:59.820 --> 00:32:00.921 fix that problem so.
00:32:01.501 --> 00:32:03.941 Umm. Does anybody have any questions about that?
00:32:02.961 --> 00:32:04.151 And a note on note on.
00:32:05.231 --> 00:32:09.016 A note on that is that with the new architecture process, the
00:32:09.016 --> 00:32:12.680 goal is that we catch as many schema changes as possible up
00:32:12.680 --> 00:32:16.405 front, so there should be one feature with one schema change
00:32:16.405 --> 00:32:20.068 assigned to one person for the entire project schema change
00:32:20.068 --> 00:32:23.915 rather than previous scenarios. We catch a schema change as we
00:32:20.291 --> 00:32:20.521 Yeah.
00:32:23.915 --> 00:32:27.640 got to whatever ticket needed it. The idea is to try and get
00:32:27.640 --> 00:32:31.426 all of those done at the very beginning and one schema change
00:32:31.426 --> 00:32:35.455 one to prevent what Brendan just said. But the second point being
00:32:35.455 --> 00:32:35.761 that.
00:32:37.051 --> 00:32:40.285 That way you don't have as many migrations in in one like
00:32:40.285 --> 00:32:40.731 project.
00:32:40.911 --> 00:32:41.241 Yep.
00:32:42.081 --> 00:32:45.905 Yep, the entire process of doing a schema change is relatively
00:32:45.905 --> 00:32:49.426 time consuming, as those of you that have done it can can
00:32:49.426 --> 00:32:49.851 attest.
00:32:50.491 --> 00:32:54.490 Umm, the joke I like to say is that a schema changes that adds
00:32:54.490 --> 00:32:58.298 a column to a table takes 2 hours and a schema changes that
00:32:58.298 --> 00:33:02.424 adds 12 columns to a table takes 2 hours and 5 minutes. It's not
00:33:02.424 --> 00:33:06.168 like a linear growth in the amount of time. There's like a
00:33:06.168 --> 00:33:09.977 bare minimum cost associated with doing a schema change and
00:33:09.977 --> 00:33:13.595 so if we can batch as much of that work into one shot as
00:33:13.595 --> 00:33:17.530 possible, then it's a lot more time efficient and it avoids a
00:33:17.530 --> 00:33:21.465 lot of problems down the road. Now obviously there's gonna be
00:33:21.465 --> 00:33:23.941 times where we don't catch everything.
00:33:24.411 --> 00:33:29.302 And that's kind of, you know, we're working on it and you know
00:33:29.302 --> 00:33:33.650 something, something can't predict the future etcetera,
00:33:33.650 --> 00:33:33.961 but.
00:33:37.521 --> 00:33:41.017 But yeah, generally speaking, if you know of multiple schema
00:33:41.017 --> 00:33:43.481 changes that need to be done on a project.
00:33:44.201 --> 00:33:48.021 Umm for one reason or another, the more that we can batch those
00:33:48.021 --> 00:33:50.051 the the happier everyone will be.
00:33:51.381 --> 00:33:56.187 So, but any questions on the on anything else with migrations,
00:33:56.187 --> 00:33:58.781 schema changes, entity framework?
00:34:01.491 --> 00:34:04.849 I think we may have a couple of other things that we were gonna
00:34:04.849 --> 00:34:06.161 cover today. Let me look.
00:34:07.631 --> 00:34:08.911 At just.
00:34:10.791 --> 00:34:13.693 OK. We were going to talk about some Docker stuff as well that I
00:34:13.693 --> 00:34:13.961 think.
00:34:15.121 --> 00:34:17.461 I don't know if JLR or Ben was gonna lead.
00:34:19.041 --> 00:34:22.211 But it looks like they might have both dropped.
00:34:26.251 --> 00:34:27.281 Yeah. What's up, nick?
00:34:29.521 --> 00:34:33.001 I was just looking through some of the models in.
00:34:34.141 --> 00:34:38.448 01 clarity ecommerce data model shared which is where where you
00:34:37.361 --> 00:34:37.751 Umm.
00:34:38.448 --> 00:34:42.621 would actually define some of the things that you want in the
00:34:42.301 --> 00:34:42.511 Umm.
00:34:42.621 --> 00:34:46.592 schema change and can you go just go over some of the more
00:34:43.501 --> 00:34:43.701 Yep.
00:34:46.592 --> 00:34:47.131 popular.
00:34:48.251 --> 00:34:52.127 He words and stuff in those definitions like string is
00:34:52.127 --> 00:34:52.691 Unicode.
00:34:53.311 --> 00:34:53.751 Yep.
00:34:53.911 --> 00:34:58.064 When the specify the string length and some of the general
00:34:58.064 --> 00:35:02.359 rules for creating like the column rules and everything like
00:35:02.359 --> 00:35:02.711 that.
00:35:03.061 --> 00:35:05.471 Yep, I can do that.
00:35:05.531 --> 00:35:09.458 Yeah. And in addition, I'm I'm looking at some of them and see
00:35:09.458 --> 00:35:12.201 like don't map in ever, don't map out ever.
00:35:12.261 --> 00:35:13.171 Yep, Yep.
00:35:14.291 --> 00:35:18.340 So great questions. I will, I will go over those. There is
00:35:18.340 --> 00:35:20.811 something Jeremy asked that I said.
00:35:21.561 --> 00:35:26.117 I'd put oh U MT4. Something something. Yes, OK, I will get.
00:35:26.117 --> 00:35:30.826 I will get to that after after this part Jeremy. But yes. For
00:35:30.826 --> 00:35:32.421 for Nick and Michael.
00:35:33.721 --> 00:35:34.271 So.
00:35:36.171 --> 00:35:40.123 A lot of the stuff that that we use is pretty standard entity
00:35:40.123 --> 00:35:40.761 framework.
00:35:42.411 --> 00:35:42.991 Stuff.
00:35:43.711 --> 00:35:45.681 So generally.
00:35:46.511 --> 00:35:49.556 Umm, what? You guys are probably talking about is actually this
00:35:49.556 --> 00:35:52.220 perfect example right here. String length and string is
00:35:52.220 --> 00:35:52.601 Unicode.
00:35:53.241 --> 00:35:56.684 Umm, you guys are familiar with stuff like default value of
00:35:56.684 --> 00:35:56.971 null.
00:35:58.071 --> 00:36:01.204 That's that's just data data annotations that don't have
00:36:01.204 --> 00:36:04.668 really anything to do with with entity framework itself. To my
00:36:04.668 --> 00:36:08.241 knowledge, they don't affect the generated SQL at all, so we can
00:36:08.241 --> 00:36:09.341 kind of ignore that.
00:36:10.981 --> 00:36:15.779 But the these two are some of the specific ones that that Nick
00:36:15.779 --> 00:36:20.348 asked about. And there's also this index one. So we'll talk
00:36:20.348 --> 00:36:22.481 about those 3 real quick so.
00:36:23.271 --> 00:36:28.391 Are you guys familiar with the, you know Unicode versus non
00:36:28.391 --> 00:36:29.671 Unicode string?
00:36:30.141 --> 00:36:33.101 Uh, stuff with, you know, just in general or I guess as it
00:36:33.101 --> 00:36:36.313 relates to storing strings in a database. Is there anybody that
00:36:36.313 --> 00:36:39.173 I guess raise your hand if you're familiar with that and
00:36:39.173 --> 00:36:42.184 don't feel like you have to raise your hand, it's perfectly
00:36:42.184 --> 00:36:43.941 fine to not be familiar with that.
00:36:50.141 --> 00:36:52.471 Cool, alright so.
00:36:53.271 --> 00:36:58.381 Uh, I don't know everything on this topic, so I'm not the I'm
00:36:58.381 --> 00:37:03.078 not the expert that I that I wish I was on this specific
00:37:03.078 --> 00:37:05.551 topic, but generally speaking.
00:37:06.321 --> 00:37:10.756 A. They're obviously there are two modes for a string to be
00:37:10.756 --> 00:37:15.266 stored, either Unicode or non Unicode. A Unicode string will
00:37:15.266 --> 00:37:19.036 allow for a lot more representation of things like
00:37:19.036 --> 00:37:23.028 non Latin characters and alternate languages, so that
00:37:23.028 --> 00:37:26.650 makes sense for things like maybe like names and
00:37:26.650 --> 00:37:30.716 descriptions. Maybe any field where you're going to be
00:37:30.716 --> 00:37:35.078 storing, like user input. So like review fields and things
00:37:35.078 --> 00:37:36.261 like that where.
00:37:36.531 --> 00:37:39.662 You know a user might not be typing in in English with Latin
00:37:39.662 --> 00:37:42.793 characters. They might be typing with accents or Cyrillic or
00:37:42.793 --> 00:37:45.001 Japanese or Chinese or anything like that.
00:37:45.971 --> 00:37:50.153 Those types of characters, they don't work in a non Unicode
00:37:50.153 --> 00:37:50.641 string.
00:37:52.001 --> 00:37:56.141 And so the downside obviously to you there, you don't get if if
00:37:56.141 --> 00:37:59.959 if that's the case, why not store every string is Unicode.
00:37:59.959 --> 00:38:04.035 The downside is that a Unicode string does consume more memory
00:38:04.035 --> 00:38:07.917 as far as I'm aware. So if you don't need Unicode, which is
00:38:07.917 --> 00:38:12.122 generally not needed for things like SKUs and like internal keys
00:38:12.122 --> 00:38:13.481 and things like that.
00:38:14.011 --> 00:38:17.621 Umm. Then you would you would you know, opt to not need it.
00:38:18.821 --> 00:38:22.549 But then in scenarios where you do, you can enable it with. This
00:38:22.549 --> 00:38:25.990 string is Unicode true. To my knowledge, the default if you
00:38:25.990 --> 00:38:28.571 don't specify for a string is Unicode false.
00:38:30.051 --> 00:38:33.674 So if you if you don't specify it, it won't be Unicode. So if
00:38:33.674 --> 00:38:37.121 you do need it, you need to make sure to specify string as
00:38:37.121 --> 00:38:37.881 Unicode true.
00:38:40.011 --> 00:38:45.861 Umm, so that's kind of the general coverage on that topic.
00:38:46.671 --> 00:38:50.368 Also, fun fact to my knowledge a non Unicode string cannot store
00:38:50.368 --> 00:38:54.009 emojis but a Unicode. I know a Unicode one can. I'm pretty sure
00:38:54.009 --> 00:38:57.194 a non Unicode 1 cannot. So if you want if you want your
00:38:57.194 --> 00:39:00.493 database table to be able to store any sort of emojis for
00:39:00.493 --> 00:39:03.281 some reason, you're gonna need Unicode for that.
00:39:04.881 --> 00:39:06.951 So the next one is string length.
00:39:07.091 --> 00:39:12.191 Umm it just it imposes a maximum length limitation on the value
00:39:12.191 --> 00:39:14.981 that can be stored to that column.
00:39:16.441 --> 00:39:16.951 Again.
00:39:17.681 --> 00:39:20.951 Uh, kind of a memory related thing?
00:39:21.701 --> 00:39:22.201 Umm.
00:39:23.221 --> 00:39:26.570 Most of the time you have a pretty good idea of what the
00:39:26.570 --> 00:39:29.331 longest string is gonna be, or a sort of like.
00:39:30.401 --> 00:39:34.453 Same range limitation on a string and doing that is just a
00:39:34.453 --> 00:39:38.573 good way to sort of keep the memory characteristics of your
00:39:38.573 --> 00:39:40.771 database relatively compact. So.
00:39:41.491 --> 00:39:46.057 Uh, without this, the default is an uncapped string. It can be as
00:39:46.057 --> 00:39:49.171 long as it needs to be to serve its purpose.
00:39:50.291 --> 00:39:53.623 So that's good for things like descriptions that could be
00:39:53.623 --> 00:39:56.898 thousands and thousands of characters of complex HTML to
00:39:56.898 --> 00:40:00.345 render on the page to make a nice pretty, you know, product
00:40:00.345 --> 00:40:04.022 description section or something like that. But then for things
00:40:04.022 --> 00:40:04.941 like custom key.
00:40:05.911 --> 00:40:10.546 128 is a lot of characters for like a a skew for a product, so
00:40:10.546 --> 00:40:15.403 odds are that's more than enough and anybody that needs more than
00:40:15.403 --> 00:40:15.771 that.
00:40:17.111 --> 00:40:21.171 I don't know. They got some wild stuff going on so.
00:40:22.511 --> 00:40:25.712 So it makes sense in some scenarios to limit that just in
00:40:25.712 --> 00:40:28.637 cases of like you know, obviously coming up with the
00:40:28.637 --> 00:40:32.169 same limit, that's not gonna be a limitation for people. That's
00:40:32.169 --> 00:40:35.481 not gonna be a problem, but that can help keep that memory.
00:40:37.171 --> 00:40:38.441 Usage a little bit lower.
00:40:39.171 --> 00:40:43.250 Uh, I'm sure that someone smarter than me could explain if
00:40:43.250 --> 00:40:47.605 there is or isn't a performance difference between an uncapped
00:40:47.605 --> 00:40:51.822 string versus a capped string. I'm sure there is. I couldn't
00:40:51.822 --> 00:40:52.721 tell you why.
00:40:54.561 --> 00:40:54.991 But.
00:40:56.271 --> 00:41:00.433 Yeah. So there's there's mostly the main thing to keep in mind
00:41:00.433 --> 00:41:04.463 with stuff like that is just memory and same limitations for
00:41:04.463 --> 00:41:05.851 things like that. So.
00:41:06.591 --> 00:41:10.610 Umm, any questions on those two just the these two string
00:41:10.610 --> 00:41:11.511 related ones?
00:41:18.601 --> 00:41:21.601 If not, I will talk about index, which is a fun one.
00:41:24.431 --> 00:41:28.573 So uh, for most CEF developers, when they hear the word index,
00:41:28.573 --> 00:41:32.847 they probably flinch and prepare to be metaphorically punched in
00:41:32.847 --> 00:41:34.491 the stomach or something.
00:41:35.441 --> 00:41:40.394 Uh, because most of our experience with indexing relates
00:41:40.394 --> 00:41:42.741 to elastic and the catalog.
00:41:44.491 --> 00:41:47.499 Now it's the it's the same word for databases, and it serves a
00:41:47.499 --> 00:41:50.172 similar purpose, but the functionality is just a little
00:41:50.172 --> 00:41:50.841 bit different.
00:41:52.601 --> 00:41:56.431 So when you index data and this is just in the general case, so
00:41:56.431 --> 00:42:00.082 we're not talking about elastic, we're not talking about the
00:42:00.082 --> 00:42:03.613 database, just in general, when you're indexing data, what
00:42:03.613 --> 00:42:07.264 you're effectively doing is you're creating some sort of way
00:42:07.264 --> 00:42:10.915 to access it more efficiently, right? So if I had a bunch of
00:42:10.915 --> 00:42:14.685 like pieces of paper and none of them were labeled whatsoever,
00:42:14.685 --> 00:42:17.917 like could index them by going and giving them unique
00:42:17.917 --> 00:42:20.371 identifiers, you know, calling this one.
00:42:21.291 --> 00:42:24.308 Sheet number one and the next one is sheet #2 and stuff like
00:42:24.308 --> 00:42:27.276 that. And then I can you can develop more complex system of
00:42:27.276 --> 00:42:30.293 saying this sheet is related to finances. So it's F1 and the
00:42:30.293 --> 00:42:33.410 next finance sheet will be F2 and things like that. Then I can
00:42:33.410 --> 00:42:36.328 quickly go and say like OK well if I know I need a finance
00:42:36.328 --> 00:42:39.494 related sheet, it's gonna be one of the ones that starts with F
00:42:39.494 --> 00:42:42.561 that's indexing my thousands of metaphorical pieces of paper.
00:42:43.841 --> 00:42:48.514 Indexing data in a database or in elastic works in much the
00:42:48.514 --> 00:42:52.331 same way it's building a structure or a sort of.
00:42:52.411 --> 00:42:56.959 Uh, yeah, I guess the data structure that allows for more
00:42:56.959 --> 00:43:01.665 efficient querying of that information. And so whenever you
00:43:01.665 --> 00:43:06.370 mark one of these columns as an indexed column in SQL, what
00:43:06.370 --> 00:43:10.605 that's basically doing is it gives, it tells SQL that
00:43:10.605 --> 00:43:15.545 whenever values change in that column for a table, it needs to
00:43:15.545 --> 00:43:20.015 rebuild an index for that column. That will help queries
00:43:20.015 --> 00:43:21.741 against it run faster.
00:43:22.421 --> 00:43:26.119 And it does that by similar to the finance algorithm or that
00:43:26.119 --> 00:43:29.938 kind of example that I gave a minute ago. It can sort of. It's
00:43:29.938 --> 00:43:33.576 got different ways to build indices for strings, for dates,
00:43:33.576 --> 00:43:36.971 for numbers and things like that, where it can sort of.
00:43:37.661 --> 00:43:41.597 Effectively bundled them by like by ranges or do range queries
00:43:41.597 --> 00:43:45.033 against them for things like that that are faster than
00:43:45.033 --> 00:43:48.595 individually checking every single one, and it basically
00:43:48.595 --> 00:43:52.094 helps to narrow down the set of results that have to be
00:43:52.094 --> 00:43:53.281 explicitly checked.
00:43:54.581 --> 00:43:58.080 And so, much like the much like the thing before, if I had a
00:43:58.080 --> 00:44:01.752 stack of 100 sheets of paper and only ten of them were financed
00:44:01.752 --> 00:44:05.195 papers that had an F and the thing well now I don't have to
00:44:05.195 --> 00:44:08.579 go and look at all 100 of those pages to find the specific
00:44:08.579 --> 00:44:12.309 finance paper I'm looking for, I can go ahead and just throw out
00:44:12.309 --> 00:44:16.038 all the ones that don't have an F and then just look at those 10
00:44:16.038 --> 00:44:19.308 and that takes me. That's theoretically 10 times faster.
00:44:19.308 --> 00:44:22.406 I'm looking at 90% less documents. The database works
00:44:22.406 --> 00:44:23.611 exactly the same way.
00:44:24.231 --> 00:44:27.801 And so most of the time when you are.
00:44:28.661 --> 00:44:31.349 Making custom schema changes this isn't something you really
00:44:31.349 --> 00:44:32.231 need to worry about.
00:44:33.831 --> 00:44:37.213 Using or not using the index column isn't something that's
00:44:37.213 --> 00:44:40.767 gonna be it's. It's not gonna make or break the difference in
00:44:40.767 --> 00:44:44.436 your code. And if there ever is a scenario where something like
00:44:44.436 --> 00:44:48.047 this comes up and we're having actually measurable performance
00:44:48.047 --> 00:44:51.601 loss, we can always go back and add index attributes to these
00:44:51.601 --> 00:44:54.983 and create a new migration. So I would say that this isn't
00:44:54.983 --> 00:44:56.531 something you guys need to.
00:44:57.531 --> 00:45:01.641 Factor into your day-to-day schema change lives, but I think
00:45:01.641 --> 00:45:05.685 it is important to understand basically what it's doing and
00:45:05.685 --> 00:45:06.561 how it works.
00:45:07.791 --> 00:45:11.454 And the reason that this exists on things like active and
00:45:11.454 --> 00:45:15.432 created date or a custom key or in or yeah ID is because these
00:45:15.432 --> 00:45:19.095 are the columns that we're querying against and filtering
00:45:19.095 --> 00:45:23.011 against with almost every single database query that we make,
00:45:23.011 --> 00:45:26.737 we're filtering by active all the time. We're filtering by
00:45:26.737 --> 00:45:30.211 custom key all the time, filtering by ID. I mean these
00:45:30.211 --> 00:45:34.189 are basically every query you make against the database and so
00:45:34.189 --> 00:45:37.221 it makes sense that for these bread and butter.
00:45:37.291 --> 00:45:40.291 Fields that were filtering against all the time we want the
00:45:40.291 --> 00:45:42.691 database to do that as efficiently as possible.
00:45:44.971 --> 00:45:48.098 Obviously the next question similar to the string is
00:45:48.098 --> 00:45:51.520 Unicode. One is well, if it makes it better, why wouldn't
00:45:51.520 --> 00:45:55.355 you just put index on literally everything all the time? And the
00:45:55.355 --> 00:45:58.954 answer is there are downsides. They're very small downsides,
00:45:58.954 --> 00:46:02.848 but generally speaking, the more indices you have on a table, the
00:46:02.848 --> 00:46:06.388 longer creating, updating, or deleting those records takes,
00:46:06.388 --> 00:46:09.869 because every time that table changes, the index has to be
00:46:09.869 --> 00:46:10.341 rebuilt.
00:46:11.301 --> 00:46:15.568 Umm so that subsequent queries are up to date and so the more
00:46:15.568 --> 00:46:19.836 indices you impose, the more indices need to be rebuilt every
00:46:19.836 --> 00:46:23.622 time a record is created, updated or deleted, and that
00:46:23.622 --> 00:46:24.861 takes time and so.
00:46:25.711 --> 00:46:29.803 Obviously you sort of get into a into a, a a balancing act where
00:46:29.803 --> 00:46:33.580 you're balancing the time it takes to query for data versus
00:46:33.580 --> 00:46:37.672 the time it takes to modify data and tables where you don't care
00:46:37.672 --> 00:46:41.575 how long it takes to store a record. As long as reading it as
00:46:41.575 --> 00:46:43.401 fast. So things like product.
00:46:45.241 --> 00:46:48.953 That's uh, that's a place where you would probably have a lot of
00:46:48.953 --> 00:46:52.493 opportunity to index a lot of columns because again, we don't
00:46:52.493 --> 00:46:55.920 care if it takes an extra 50 milliseconds to save a product
00:46:55.920 --> 00:46:59.574 record. If I can query against just about anything and get that
00:46:59.574 --> 00:47:00.831 record back instantly.
00:47:01.471 --> 00:47:04.179 But on something where updating is happening a lot like a log
00:47:04.179 --> 00:47:06.538 like a system log table or something like that, where
00:47:06.538 --> 00:47:08.896 inserting records needs to be quick and it's gonna be
00:47:08.896 --> 00:47:09.901 happening all the time.
00:47:10.651 --> 00:47:13.756 Indexing doesn't make as much sense there. It's not something
00:47:13.756 --> 00:47:16.261 that's gonna you're you're querying against that.
00:47:17.421 --> 00:47:20.197 Way less frequently than you're writing to it, and so you want
00:47:20.197 --> 00:47:23.017 your writing to be quick, even if you're querying takes a small
00:47:23.017 --> 00:47:25.661 hit in terms of how long it takes to get your results back.
00:47:26.391 --> 00:47:29.559 And so it's sort of one of those things where you analyze the
00:47:29.559 --> 00:47:32.625 benefits and and costs either direction and and and come up
00:47:32.625 --> 00:47:35.691 with it with what you need to do. But generally speaking, I
00:47:35.691 --> 00:47:39.064 would say for the index when you don't need to do that, you don't
00:47:39.064 --> 00:47:42.130 need to default to using it. It's not even really something
00:47:42.130 --> 00:47:44.941 you need to think about when you're adding new schema.
00:47:46.291 --> 00:47:48.826 So if you're ever like copy pasting one of these and you,
00:47:48.826 --> 00:47:51.449 you know you're adding a new date time to something and you
00:47:51.449 --> 00:47:54.290 copy paste this, you don't need to keep the index attribute. You
00:47:54.290 --> 00:47:55.951 can get rid of it. It doesn't matter.
00:47:57.171 --> 00:48:01.049 And like I said, if it becomes a problem later, we can always add
00:48:01.049 --> 00:48:04.575 these index attributes back in to. You know if there's slow
00:48:04.575 --> 00:48:08.278 querying or something against the table and so don't feel like
00:48:08.278 --> 00:48:10.981 you have to catch every one of these complex.
00:48:11.871 --> 00:48:15.172 Uh, possibilities on the first time you make a schema change,
00:48:15.172 --> 00:48:18.526 that's. That's the nice thing about the code first approach is
00:48:18.526 --> 00:48:21.561 we can always make another migration that fixes problems
00:48:21.561 --> 00:48:21.881 later.
00:48:23.131 --> 00:48:23.521 So.
00:48:25.331 --> 00:48:29.033 So that's some of the basics on on some of these like flat ones
00:48:29.033 --> 00:48:31.521 like string and date time that you'll see.
00:48:32.681 --> 00:48:35.400 The key one and the database generated one are relatively
00:48:35.400 --> 00:48:36.151 straightforward.
00:48:37.231 --> 00:48:40.793 Key tells the database that this is a primary key that give you
00:48:40.793 --> 00:48:44.187 your mouse over. It will tell you that the notes one or more
00:48:44.187 --> 00:48:47.304 properties that uniquely identify an entity. Yep, cool.
00:48:47.304 --> 00:48:50.643 So the key attribute is just telling entity framework, hey,
00:48:50.643 --> 00:48:54.261 this is the primary key of this table. ID is the primary key and
00:48:54.261 --> 00:48:57.822 then this database generated one for identity is. You can mouse
00:48:57.822 --> 00:49:01.106 over and it tells you right there the database generates a
00:49:01.106 --> 00:49:04.779 value when a row is inserted. So the database generated attribute
00:49:04.779 --> 00:49:05.781 itself is telling.
00:49:06.641 --> 00:49:10.621 Entity framework that we want the database to generate the
00:49:10.621 --> 00:49:14.804 value for this column for us and then the option that we pass
00:49:14.804 --> 00:49:18.851 here tells it how. So in this case we're telling it we want
00:49:18.851 --> 00:49:23.034 the database to generate this ID, this property ID every time
00:49:23.034 --> 00:49:26.812 we add the record to the database. So we don't we don't
00:49:26.812 --> 00:49:28.431 generate the IDs in SAF.
00:49:29.141 --> 00:49:31.937 We let the database generate the ID for us and they just tell us
00:49:31.937 --> 00:49:32.411 what it is.
00:49:33.341 --> 00:49:33.771 Umm.
00:49:34.741 --> 00:49:36.991 And again, you guys won't ever have to.
00:49:37.721 --> 00:49:41.963 Put key in database generated on a record. Uh like this or on a
00:49:41.963 --> 00:49:46.072 column because all that stuff is handled by the like the base
00:49:46.072 --> 00:49:50.248 class that we derive from. Or like nameable base and all those
00:49:50.248 --> 00:49:52.701 all handle this basic stuff for you.
00:49:53.601 --> 00:49:54.561 Umm so.
00:49:55.341 --> 00:49:56.771 Uh, Nick, you had a question?
00:49:58.481 --> 00:50:01.978 Yeah, this might not be super important, but what is the
00:50:01.978 --> 00:50:05.843 difference between the two ID columns at the top? The one says
00:50:05.843 --> 00:50:07.561 Jason ignore and not mapped.
00:50:06.301 --> 00:50:09.811 Yeah, and not mapped. Yeah, great question. This is
00:50:09.811 --> 00:50:14.132 something that I was, I was kind of hoping nobody would notice.
00:50:14.132 --> 00:50:18.250 So like scroll a little bit down. So you can't see it. Don't
00:50:18.250 --> 00:50:22.301 worry about this. This is only here because we use ASP .net
00:50:22.301 --> 00:50:23.381 identity as our.
00:50:24.701 --> 00:50:28.714 That's what we generate our user uh schema from. Like all the
00:50:28.714 --> 00:50:32.793 users and roles and permissions and all that stuff. That's all
00:50:32.793 --> 00:50:36.871 based on that ASP .net identity schema and you can see that it
00:50:36.871 --> 00:50:40.949 actually extends from Microsoft dot onto that text is probably
00:50:40.949 --> 00:50:45.028 really small and hard to read, but this extends from Microsoft
00:50:45.028 --> 00:50:48.847 dot Aspinet dot identity dot entity framework dot identity
00:50:48.847 --> 00:50:49.171 user.
00:50:50.691 --> 00:50:54.933 That class defines ID with a lower case D, but that doesn't
00:50:54.933 --> 00:50:57.691 match any of our other stuff anywhere.
00:50:58.351 --> 00:51:02.987 Umm, in terms of the the casing of ID and it doesn't match our
00:51:02.987 --> 00:51:07.403 our I user interface or ibase interface that defines custom
00:51:07.403 --> 00:51:09.611 key and all that stuff and so.
00:51:10.141 --> 00:51:10.901 Uh.
00:51:11.871 --> 00:51:15.746 In entity framework you can use this not mapped attribute and it
00:51:15.746 --> 00:51:19.502 will actually. It tells entity framework. Yes this property is
00:51:19.502 --> 00:51:22.780 technically a valid database column like it could be a
00:51:22.780 --> 00:51:26.477 database column, but we don't want it to be a database column
00:51:26.477 --> 00:51:30.232 and so that's what this is doing is we define custom logic for
00:51:30.232 --> 00:51:33.571 anything in asp.net that is going to be reading this ID
00:51:33.571 --> 00:51:37.267 property. We tell it we just setting a getter and setter that
00:51:37.267 --> 00:51:40.725 uses our actual ID property and then we're telling entity
00:51:40.725 --> 00:51:43.884 framework don't actually map this to a column in the
00:51:43.884 --> 00:51:44.421 database.
00:51:45.221 --> 00:51:45.831 We don't need it.
00:51:47.411 --> 00:51:51.171 So this only happens on a couple of tables and it's not something
00:51:51.171 --> 00:51:54.475 that you guys will ever really run into because we're not
00:51:54.475 --> 00:51:57.551 extending schema like this from really anything else.
00:51:58.821 --> 00:52:03.103 But yeah, it's again a very edge Casey thing. That's what I was.
00:52:03.103 --> 00:52:07.385 I was like kind of trying not to show it because it's like, it's
00:52:07.385 --> 00:52:11.338 confusing to see. So suffice to say, it's not something you
00:52:11.338 --> 00:52:15.357 really need to worry about. And if you are curious, it comes
00:52:15.357 --> 00:52:19.573 from asp.net. And we just handle that our own way. So we ignore
00:52:19.573 --> 00:52:19.771 it.
00:52:25.221 --> 00:52:28.529 So couple more things terminology wise that I'll cover
00:52:28.529 --> 00:52:29.431 really quickly.
00:52:31.311 --> 00:52:34.517 Entity framework describes relationships between tables
00:52:34.517 --> 00:52:35.491 with three terms.
00:52:37.331 --> 00:52:39.991 I forget the first term, which is hilarious.
00:52:40.301 --> 00:52:44.350 And and very unfortunate. So we'll just call that a A a
00:52:44.350 --> 00:52:45.001 property.
00:52:45.651 --> 00:52:48.860 Umm, I don't know what any framework calls. I think it's
00:52:48.860 --> 00:52:52.464 property and that stuff like ID and custom key and created data
00:52:52.464 --> 00:52:54.041 and updated date. These are.
00:52:54.881 --> 00:52:59.571 Actual columns in the database we can go look at it at a table
00:52:59.571 --> 00:53:04.335 over here and go and select from contacts dot user and we'll go
00:53:04.335 --> 00:53:04.931 and see.
00:53:05.881 --> 00:53:09.042 Custom Key ID created date update these map properties
00:53:09.042 --> 00:53:11.571 mapped to an actual column in the database.
00:53:13.271 --> 00:53:16.599 Sorry, wrong window. So that's property that's that's
00:53:16.599 --> 00:53:20.358 relationship type one that's it's not really relationship as
00:53:20.358 --> 00:53:23.501 a singular property. The next is a related object.
00:53:24.721 --> 00:53:29.329 Related objects are a foreign key to another table, so that's
00:53:29.329 --> 00:53:33.491 a good example of that. Here would be if I can find it.
00:53:34.531 --> 00:53:34.931 Umm.
00:53:35.291 --> 00:53:39.245 Umm, early in an objects account? Perfect. UM. So the
00:53:39.245 --> 00:53:43.420 account from the user is a related object because a user
00:53:43.420 --> 00:53:47.740 has one account, it is directly related with a foreign key
00:53:47.740 --> 00:53:49.791 relationship to one account.
00:53:51.051 --> 00:53:53.991 A related object always corresponds.
00:53:54.631 --> 00:53:58.378 To a foreign key property like this one, and that's where
00:53:58.378 --> 00:54:02.061 you'll see this inverse property foreign key stuff here.
00:54:04.961 --> 00:54:05.811 And.
00:54:07.911 --> 00:54:10.742 Yeah. So and again, this property will correspond to an
00:54:10.742 --> 00:54:13.321 actual column in the database somewhere over here.
00:54:14.641 --> 00:54:15.231 Account ID.
00:54:15.871 --> 00:54:20.115 Umm so this this column is defining a relationship between
00:54:20.115 --> 00:54:24.575 the user table and the account table. We can actually in SSMS
00:54:24.575 --> 00:54:28.676 you can go look at keys and you can see foreign key from
00:54:28.676 --> 00:54:32.561 contacts user to accounts that account on account ID.
00:54:34.571 --> 00:54:39.041 So that's actually that's actually saying that this table.
00:54:39.681 --> 00:54:43.471 The column account ID on the table accounts or contacts dot
00:54:43.471 --> 00:54:47.262 user is a foreign key to the table accounts dot account and
00:54:47.262 --> 00:54:51.115 what that means is that this value has to actually relate to
00:54:51.115 --> 00:54:54.969 a record that exists in the accounts dot account table. This
00:54:54.969 --> 00:54:58.885 can't just be any random number. This has to that foreign key
00:54:58.885 --> 00:55:03.055 constraint is saying this has to actually exist in the table that
00:55:03.055 --> 00:55:07.098 it's pointing to and if you try to try to set that to something
00:55:07.098 --> 00:55:09.941 that doesn't exist, you'll get an error. So.
00:55:10.031 --> 00:55:14.563 Yeah, I'm taxed dot user if I can remember how keyboard works,
00:55:14.563 --> 00:55:18.664 set account ID equal to something that I definitely know
00:55:18.664 --> 00:55:19.671 doesn't exist.
00:55:20.191 --> 00:55:23.710 Uh, where ID equals. I don't know one. Sure this will give me
00:55:23.710 --> 00:55:27.457 an error and it will tell you it conflicted with that foreign key
00:55:27.457 --> 00:55:29.841 constraint that exactly we're looking at.
00:55:31.011 --> 00:55:34.700 And the reason that it conflicts is because there's no account in
00:55:34.700 --> 00:55:38.166 my account set account table with the ID of a bunch of fives.
00:55:38.166 --> 00:55:41.408 It doesn't exist and so it doesn't allow you to make that
00:55:41.408 --> 00:55:43.421 change because it would be invalid.
00:55:44.131 --> 00:55:47.688 Umm, so the way that we configure that foreign key
00:55:47.688 --> 00:55:51.943 relationship in code first is with these two right here. The
00:55:51.943 --> 00:55:55.361 first one is saying foreign key name of account.
00:55:56.181 --> 00:55:59.051 Uh, which is pointing at uh. This guy right here.
00:55:59.911 --> 00:56:04.775 And the inverse property is the name of the key to which we're
00:56:04.775 --> 00:56:09.640 pointing, and I know that's kind of a confusing thing, but you
00:56:09.640 --> 00:56:14.350 can pretty much assume that it's always gonna be name of ID,
00:56:14.350 --> 00:56:17.671 because pretty much every table and stuff.
00:56:18.671 --> 00:56:22.756 It's it's primary key is called ID and so generally speaking
00:56:22.756 --> 00:56:26.507 you'll just copy if you're making a new related object,
00:56:26.507 --> 00:56:29.521 you'll just copy these attributes like this.
00:56:30.771 --> 00:56:32.982 And you'll just rename. Obviously it's not gonna be
00:56:32.982 --> 00:56:35.534 called account. It's gonna be called. Whatever you whatever
00:56:35.534 --> 00:56:38.171 your foreign keys called. In this case, it's account because.
00:56:38.881 --> 00:56:40.631 It's account because that's what it is.
00:56:42.891 --> 00:56:46.577 But that would be. That's what these two properties do is it's
00:56:46.577 --> 00:56:50.029 basically configuring that foreign key relationship in the
00:56:50.029 --> 00:56:52.311 database that imposes that constraint.
00:56:54.231 --> 00:56:58.248 A quick note on foreign key relationships and entity
00:56:58.248 --> 00:57:02.569 framework. This kind of specifically relates to nullable
00:57:02.569 --> 00:57:05.601 reference types and nullity in general.
00:57:06.881 --> 00:57:09.581 This is an optional foreign key.
00:57:10.241 --> 00:57:14.691 Meaning that it is allowed to be null and that's specified by the
00:57:14.691 --> 00:57:18.872 fact that this ID column, this ID property is nullable in and
00:57:18.872 --> 00:57:22.311 of itself. If I were to remove this question mark.
00:57:22.951 --> 00:57:26.915 That would actually require me to make a schema change because
00:57:26.915 --> 00:57:30.691 this is no longer an optional foreign key. By making this a
00:57:30.691 --> 00:57:34.718 non nullable integer, I'm saying that the account ID absolutely
00:57:34.718 --> 00:57:38.745 has to be specified and it can't be specified to anything other
00:57:38.745 --> 00:57:42.521 than a valid account because of the foreign key constraint.
00:57:43.291 --> 00:57:47.234 Umm, so that's really important if you're setting up a
00:57:47.234 --> 00:57:51.248 relationship between 2 tables where the relationship is
00:57:51.248 --> 00:57:55.550 required, the the connection between 2 tables is always. It
00:57:55.550 --> 00:58:00.066 always has to be specified and a record that doesn't have that
00:58:00.066 --> 00:58:04.654 specified isn't valid. Then that needs to be a required foreign
00:58:04.654 --> 00:58:04.941 key.
00:58:05.611 --> 00:58:09.576 Umm, so uh, that's how you do that. The only thing you do now
00:58:09.576 --> 00:58:13.733 you may be wondering then, does that mean I need to go make this
00:58:13.733 --> 00:58:17.954 also not null? The answer is no. This needs to stay nullable. The
00:58:17.954 --> 00:58:19.681 reason for that is because.
00:58:20.911 --> 00:58:24.833 Stuff is complicated in life, is pain basically. UM in newer
00:58:24.833 --> 00:58:28.885 versions of C# you actually have a better way to do this where
00:58:28.885 --> 00:58:32.679 you can say public virtual required account like that. But
00:58:32.679 --> 00:58:36.601 unfortunately in NET Framework we don't have support for the
00:58:36.601 --> 00:58:40.331 required keyword. So we just have to mark it as nullable.
00:58:41.871 --> 00:58:45.814 And you can write code that assumes that this won't be null
00:58:45.814 --> 00:58:48.311 because the relationship is required.
00:58:49.881 --> 00:58:53.101 So I'm going to put that back before I forget.
00:58:55.201 --> 00:58:58.321 Umm. So any questions on that stuff?
00:59:03.901 --> 00:59:06.368 And I'm I'm hoping that I'm not. I'm hoping I'm not losing
00:59:06.368 --> 00:59:06.661 people.
00:59:08.201 --> 00:59:08.611 But.
00:59:09.771 --> 00:59:11.581 I think this is all good stuff to cover so.
00:59:10.461 --> 00:59:15.035 Yeah. Yeah, I I kind of have the question. So when you're setting
00:59:13.381 --> 00:59:14.011 Yeah, yeah, sure.
00:59:15.035 --> 00:59:19.332 these up, it seems like, correct me if I'm wrong, I really do
00:59:19.332 --> 00:59:23.560 wanna be corrected if this is wrong. It seems like the thing
00:59:23.560 --> 00:59:25.431 to do is to find a similar.
00:59:28.551 --> 00:59:32.899 Model that's already existing and kind of use that to get some
00:59:32.899 --> 00:59:34.141 of the properties.
00:59:34.601 --> 00:59:37.630 Absolutely correct. Yes, generally speaking, and I'll,
00:59:35.491 --> 00:59:35.841 OK.
00:59:37.630 --> 00:59:40.549 I'll, I'll you know, I won't even. I won't even say.
00:59:40.549 --> 00:59:44.075 Generally speaking, I'm gonna. I'm gonna generalize and say any
00:59:44.075 --> 00:59:47.324 relationship that you need to define in SQL and example of
00:59:47.324 --> 00:59:50.850 that exists in stuff already. I can pretty much guarantee that.
00:59:50.850 --> 00:59:54.154 So rather than reinventing the wheel trying to you know dig
00:59:54.154 --> 00:59:57.514 through old entity framework documentation try to figure out
00:59:57.514 --> 01:00:01.094 how to do it yourself. If you're not sure of an example just ask
01:00:01.094 --> 01:00:04.454 and say hey I need to have this sort of relationship between
01:00:04.454 --> 01:00:05.391 these two tables.
01:00:05.831 --> 01:00:09.948 Can anybody point me to an example of that and and there
01:00:08.381 --> 01:00:08.651 OK.
01:00:09.948 --> 01:00:14.354 will be some example of that somewhere in the CEF data model
01:00:14.354 --> 01:00:15.221 I'm sure of.
01:00:15.841 --> 01:00:19.117 Umm, the table that I like to use as a guide if I'm doing a
01:00:19.117 --> 01:00:22.611 schema change is the categories dot category table because it's
01:00:22.611 --> 01:00:26.105 got a little bit of everything on it. It's got related objects,
01:00:26.105 --> 01:00:29.436 associated objects. It's got tons of its own flat properties
01:00:29.436 --> 01:00:32.493 with their own attributes on them. It's got some of the
01:00:31.511 --> 01:00:31.781 Yeah.
01:00:32.493 --> 01:00:35.988 interfaces like I have a type or I'm filterable by whatever. So
01:00:35.988 --> 01:00:39.100 it's a really good starting point if you're building new
01:00:39.100 --> 01:00:42.594 schema and you're like, oh, how do I need for related object or
01:00:42.594 --> 01:00:45.816 an associated object which I'll talk about those in just a
01:00:45.816 --> 01:00:46.471 minute. But.
01:00:47.021 --> 01:00:50.283 This is a table that sort of has all the stuff on it. Uh, this
01:00:50.283 --> 01:00:53.339 one and product. But products a little bit bigger and more
01:00:53.339 --> 01:00:55.721 unwieldy. So it's kind of hard to get around.
01:00:56.341 --> 01:01:01.221 Umm, but uh yeah, you can by all means. Uh. Not only is it.
01:01:02.381 --> 01:01:05.826 Not only is that sort of the a good way to do it, that's the
01:01:05.826 --> 01:01:09.498 heavily recommended way to do it is to find a working example of
01:01:09.498 --> 01:01:13.112 that relationship in some other class and just copy paste it to
01:01:13.112 --> 01:01:16.671 yours and do whatever renaming you need to do to make it work.
01:01:17.461 --> 01:01:20.461 Umm so that saves you tons of time.
01:01:17.691 --> 01:01:18.041 OK.
01:01:22.091 --> 01:01:25.837 I think it might be there might be value at some point in the
01:01:25.837 --> 01:01:26.441 future to.
01:01:28.091 --> 01:01:32.278 Maybe sort of template vizing some of this so that you know we
01:01:32.278 --> 01:01:36.531 have a a document that has some copy paste table samples of. If
01:01:36.531 --> 01:01:40.851 you need to related foreign key to another table then copy paste
01:01:40.851 --> 01:01:45.171 this into your class and rename. If you need a many to many then
01:01:45.171 --> 01:01:48.361 copy paste this into your solution or whatever.
01:01:49.951 --> 01:01:53.178 Something like that may be valuable at some point, but it
01:01:53.178 --> 01:01:56.294 would. It would be a decent amount of stuff to generate
01:01:56.294 --> 01:01:57.351 documentation wise.
01:01:58.191 --> 01:02:01.111 Umm, so uh but yeah.
01:02:02.291 --> 01:02:05.871 That's a great question. And for anybody that didn't hear, I'm
01:02:05.871 --> 01:02:09.565 going to repeat it for like the third time. Uh, by all means, if
01:02:09.565 --> 01:02:13.203 you are making a schema change and you need to create a foreign
01:02:13.203 --> 01:02:16.499 key or anything else, find an example of that in the code
01:02:16.499 --> 01:02:18.261 already and just copy paste it.
01:02:19.621 --> 01:02:24.151 And again repeating it, I like to use the category table.
01:02:25.311 --> 01:02:29.146 The category dot CS file as a guide for that because it's got
01:02:29.146 --> 01:02:32.610 pretty much every kind of relationship kind of the most
01:02:32.610 --> 01:02:36.384 common ones defined, and you can use that as a guide or even
01:02:36.384 --> 01:02:38.611 better, you can just copy paste so.
01:02:41.141 --> 01:02:44.233 Just making sure that I triple down on that so everybody hears
01:02:44.233 --> 01:02:44.381 it.
01:02:45.101 --> 01:02:45.641 Umm.
01:02:47.651 --> 01:02:48.621 Copy paste is.
01:02:49.741 --> 01:02:53.103 Is recommended in this in these scenarios. Like I said, the CEF
01:02:53.103 --> 01:02:56.203 data model does pretty much everything that you need it to
01:02:56.203 --> 01:02:59.093 do already somewhere. If you're not sure where to look
01:02:59.093 --> 01:03:02.193 absolutely feel free to ask. Somebody can point you in the
01:03:02.193 --> 01:03:05.293 right direction, but yeah, that's a good way to save a lot
01:03:05.293 --> 01:03:06.291 of time is to just.
01:03:07.401 --> 01:03:08.511 Find it and copy it.
01:03:09.661 --> 01:03:10.141 Umm.
01:03:11.541 --> 01:03:13.471 So yeah, that is a. That is a really good question.
01:03:14.951 --> 01:03:18.110 So the last the last relationship type I'll cover
01:03:18.110 --> 01:03:20.511 really quickly is associated objects.
01:03:21.891 --> 01:03:25.847 That's unfortunate, doesn't really help illustrate. Let me
01:03:25.847 --> 01:03:27.591 find one that is actually.
01:03:28.591 --> 01:03:31.121 Good product categories is probably good.
01:03:33.241 --> 01:03:34.191 If they're in here.
01:03:35.201 --> 01:03:39.608 Ah, even better product associations. UM, this type of
01:03:39.608 --> 01:03:41.291 relationship is when.
01:03:42.521 --> 01:03:47.570 If you want to think about it like this, if user points to one
01:03:47.570 --> 01:03:48.211 account.
01:03:49.501 --> 01:03:53.499 Then in theory, there could be 20 user records that all point
01:03:53.499 --> 01:03:57.627 to the same account, right? So that account can be said to have
01:03:57.627 --> 01:04:01.238 20 users. If you want to think about it like that, it's
01:04:01.238 --> 01:04:05.366 basically looking at a foreign key relationship in the opposite
01:04:05.366 --> 01:04:06.011 direction.
01:04:06.761 --> 01:04:11.825 Umm. And So what that ends up meaning pretty much is that
01:04:11.825 --> 01:04:16.803 there could be potentially multiple. Excuse me, multiple
01:04:16.803 --> 01:04:20.121 records that match that relationship.
01:04:22.101 --> 01:04:26.075 Entity framework specifies these with these icollection of the
01:04:26.075 --> 01:04:30.050 type right. So in fact, we can even go look at just to keep it
01:04:30.050 --> 01:04:33.835 relevant, we can go look at accounts and find think it's in
01:04:33.835 --> 01:04:34.151 here.
01:04:36.981 --> 01:04:40.324 It might be under the don't map these out. No, it's not.
01:04:40.324 --> 01:04:44.077 Probably under. Yeah. There we go. Look at that. Users accounts
01:04:44.077 --> 01:04:45.661 have a collection of users.
01:04:47.681 --> 01:04:50.236 This collection, and I'll talk about these mapping ones you
01:04:50.236 --> 01:04:52.875 asked about earlier, Michael here in just a second and then I
01:04:52.875 --> 01:04:55.132 still need to get to Jeremy's question from the very
01:04:55.132 --> 01:04:55.771 beginning, but.
01:04:57.551 --> 01:05:01.036 This is sort of the inverse of that same thing we were looking
01:05:01.036 --> 01:05:04.245 at over here with the account ID, so a user points at one
01:05:04.245 --> 01:05:07.786 account, but nothing specifies necessarily that an account only
01:05:07.786 --> 01:05:11.271 has one user. And obviously we know in CEF that that's not the
01:05:11.271 --> 01:05:14.701 case. An account can have many users and so in the data model
01:05:14.701 --> 01:05:18.186 we actually have this property to query against. Now something
01:05:18.186 --> 01:05:21.838 that you guys might have noticed a moment ago. Actually I'm going
01:05:21.838 --> 01:05:25.213 to slow down before I go any further. Make sure does anybody
01:05:25.213 --> 01:05:27.481 have any questions about that does that.
01:05:27.571 --> 01:05:28.631 That makes sense, everybody.
01:05:32.071 --> 01:05:35.161 Let it sink in for a minute before I, before I keep going.
01:05:35.681 --> 01:05:38.631 Uh, I know I kind of move it like 100 miles an hour. Yeah,
01:05:38.631 --> 01:05:39.381 it's up, David.
01:05:41.901 --> 01:05:45.559 Sorry, I just I I missed the react thumbs up and I clicked
01:05:45.559 --> 01:05:46.861 raise instead my bed.
01:05:46.781 --> 01:05:49.781 OK, now you're good. OK, so.
01:05:51.921 --> 01:05:54.804 So we've kind of talked about the three relationships of the
01:05:54.804 --> 01:05:57.781 three types of properties in any framework. We've talked about
01:05:57.781 --> 01:06:00.522 the flat properties that are just a column on the record.
01:06:00.522 --> 01:06:03.263 We've talked about related objects that are a foreign key
01:06:03.263 --> 01:06:06.099 relationship. And now I've talked about associated objects,
01:06:06.099 --> 01:06:08.840 which are sort of the opposite direction of a foreign key
01:06:08.840 --> 01:06:11.864 relationship or a many or one to many type of deal or a many to
01:06:11.864 --> 01:06:12.101 many.
01:06:13.601 --> 01:06:14.131 So.
01:06:15.001 --> 01:06:18.175 In Indy framework and specifically in the C# code side
01:06:18.175 --> 01:06:21.061 of entity framework, when you're writing queries.
01:06:22.831 --> 01:06:25.922 Entity framework allows us to specify something called a
01:06:25.922 --> 01:06:29.393 navigation property that makes writing these queries easier and
01:06:29.393 --> 01:06:32.755 those of us that work on the back end that have written these
01:06:32.755 --> 01:06:35.901 that have written like database query with any framework.
01:06:36.601 --> 01:06:38.917 You've probably used these and you didn't even realize that's
01:06:38.917 --> 01:06:40.411 what they were or what they were doing.
01:06:41.511 --> 01:06:44.830 And So what that looks like is on this user table we have
01:06:44.830 --> 01:06:47.921 account ID and if we go look at the user table again.
01:06:49.561 --> 01:06:50.031 Hold on.
01:06:52.221 --> 01:06:55.151 We can actually go look at that account ID column right here.
01:06:56.031 --> 01:06:59.630 There's a count ID well in the class back over here in the code
01:06:59.630 --> 01:07:03.061 we also have account. Well, there's no column in here called
01:07:03.061 --> 01:07:03.511 account.
01:07:04.171 --> 01:07:07.533 And I mean, how could there be? It couldn't be the entire
01:07:07.533 --> 01:07:10.895 account flattened onto this record. That doesn't make any
01:07:10.895 --> 01:07:14.374 sense, right? This property account and entity framework is
01:07:14.374 --> 01:07:17.910 called a navigation property. It's entire purpose is to make
01:07:17.910 --> 01:07:21.040 your queries easier to write when you're using entity
01:07:21.040 --> 01:07:24.345 framework. When you're using your database context, it's
01:07:24.345 --> 01:07:28.055 basically like I like to think of it like a window to the other
01:07:28.055 --> 01:07:28.461 record.
01:07:29.681 --> 01:07:33.909 And so it allows you to basically query properties of
01:07:33.909 --> 01:07:38.998 the account while you're looking at a user. So I can say context
01:07:38.998 --> 01:07:40.251 dot users where.
01:07:40.341 --> 01:07:43.861 Uh, where user dot account dot.
01:07:45.101 --> 01:07:49.405 Name equals something, right? And that would translate into
01:07:49.405 --> 01:07:53.924 SQL. It automatically knows that since I read a property off a
01:07:53.924 --> 01:07:58.372 navigation property that that's gonna generate a join for me,
01:07:58.372 --> 01:08:02.820 it'll generate SQL that says select whatever from context dot
01:08:02.820 --> 01:08:07.267 user, inner join accounts, dot account on user dot account ID
01:08:07.267 --> 01:08:11.715 equals account dot ID, where account dot name equals whatever
01:08:11.715 --> 01:08:14.011 it'll generate that SQL as if I.
01:08:14.101 --> 01:08:18.203 Had written this crazy, you know this crazy complex SQL, when in
01:08:18.203 --> 01:08:21.926 reality I wrote a very simple and easily readable bit of C
01:08:21.926 --> 01:08:25.523 that I can at a glance I can understand exactly what the
01:08:25.523 --> 01:08:29.561 intent of this query is supposed to be much easier and at least
01:08:29.561 --> 01:08:31.581 in my opinion, than reading SQL.
01:08:32.021 --> 01:08:33.751 Umm so.
01:08:33.891 --> 01:08:37.551 Umm, that's what these properties exist for. They don't
01:08:37.551 --> 01:08:41.669 map to an actual column in the database, they're just a helper
01:08:41.669 --> 01:08:45.461 property that goes along with a foreign key relationship.
01:08:47.711 --> 01:08:48.611 And uh.
01:08:49.561 --> 01:08:51.721 So that's that's what these exist for.
01:08:53.021 --> 01:08:56.947 And then looking at the other half of it, this functions in
01:08:56.491 --> 01:08:59.701 Sorry, can I can I interrupt there for a second?
01:08:56.947 --> 01:08:57.471 exactly.
01:08:58.421 --> 01:08:58.861 Yeah, yeah.
01:08:59.531 --> 01:09:00.111 Absolutely.
01:09:00.651 --> 01:09:03.838 Is it the virtual keyword on that that's making it a
01:09:03.838 --> 01:09:05.041 navigation property?
01:09:05.981 --> 01:09:08.935 No, it's the type. It's the actual type. Now, I'm glad you
01:09:06.821 --> 01:09:07.911 It isn't OK.
01:09:08.861 --> 01:09:09.431 Just the type.
01:09:08.935 --> 01:09:12.090 brought up the virtual keyword. I'll talk about that in just a
01:09:12.090 --> 01:09:12.441 second.
01:09:13.761 --> 01:09:15.694 Real quick, I'll. I'll kind of finish up what I'm talking about
01:09:15.694 --> 01:09:17.385 over here and then I'll jump back to that. But that's a
01:09:17.385 --> 01:09:18.291 really good thing to bring up.
01:09:19.441 --> 01:09:23.144 So like I was saying this, this also there's no property on the
01:09:23.144 --> 01:09:25.691 account table in the database called users.
01:09:26.371 --> 01:09:30.347 This is another navigation property, but it points to all
01:09:30.347 --> 01:09:34.528 of the users whose account ID matches the ID of this record.
01:09:34.528 --> 01:09:39.052 This account, right? So I can do context dot accounts dot where X
01:09:39.052 --> 01:09:43.302 dot users dot any or something like that and that will return
01:09:43.302 --> 01:09:47.690 to me all of the accounts that have any users assigned to them.
01:09:47.690 --> 01:09:51.940 Or I could even delve into those users specifically and query
01:09:51.940 --> 01:09:56.464 against those to return accounts with any of the users match some
01:09:56.464 --> 01:09:57.081 specific.
01:09:57.381 --> 01:10:02.157 Subquery if you will and again entity framework will generate
01:10:02.157 --> 01:10:07.087 all the SQL around that. It may not be the prettiest SQL you've
01:10:07.087 --> 01:10:11.941 ever seen. It's not certainly not going to be as performant as
01:10:11.941 --> 01:10:16.409 if you were to manually hand roll the SQL, but the actual
01:10:16.409 --> 01:10:21.262 query itself is. Again, it's all subjective, but in my opinion
01:10:21.262 --> 01:10:26.038 the Lync query is much easier to read and quickly into it and
01:10:26.038 --> 01:10:27.271 understand than.
01:10:27.471 --> 01:10:30.011 A big ball of of sequel.
01:10:31.121 --> 01:10:34.402 So any questions on that and then I will cover that virtual
01:10:34.402 --> 01:10:37.081 keyword because that's really important to know.
01:10:38.051 --> 01:10:41.376 Brendan, I guess just to confirm one more time. So that's
01:10:41.376 --> 01:10:44.701 occurring because there is a type of eye collection user.
01:10:46.061 --> 01:10:50.207 Correct. So what this is doing here is and and again I'll talk
01:10:47.181 --> 01:10:47.441 That.
01:10:50.207 --> 01:10:54.287 I I there's a bunch of stuff I keep saying I'll cover and I'm
01:10:54.287 --> 01:10:58.039 I'm way running out of time here so but the type of i.e.
01:10:58.039 --> 01:11:01.988 Collection of some database entity. So user represents that
01:11:01.941 --> 01:11:02.401 Yep.
01:11:01.988 --> 01:11:06.134 database entity that's telling entity framework that this is a
01:11:06.134 --> 01:11:10.017 navigation property to users that have some foreign key to
01:11:10.017 --> 01:11:10.741 this table.
01:11:11.451 --> 01:11:11.861 OK.
01:11:12.221 --> 01:11:15.362 There is some complexity to this. If you have, let's say
01:11:15.362 --> 01:11:18.724 that there were two different columns on the user table that
01:11:18.724 --> 01:11:22.085 related to account for some reason, then this would actually
01:11:22.085 --> 01:11:25.392 be ambiguous because entity framework wouldn't know. Do you
01:11:25.392 --> 01:11:28.754 want this to be users that are pointing to account from this
01:11:28.754 --> 01:11:32.281 property or from this property and you have to manually specify
01:11:32.281 --> 01:11:35.752 that elsewhere? I'm not gonna cover that right now because 90%
01:11:35.752 --> 01:11:37.461 of the time it doesn't come up.
01:11:38.561 --> 01:11:41.929 And it's, you know, it's kind of power user type stuff that is
01:11:41.929 --> 01:11:45.031 not really in the scope of what we're talking about here.
01:11:46.431 --> 01:11:49.904 But yes, effectively because it's type is icollection of some
01:11:49.904 --> 01:11:53.265 other database type. That's what's telling entity framework
01:11:53.265 --> 01:11:56.738 this. This represents all the users that are pointing to this
01:11:56.738 --> 01:11:59.931 account, or all the categories that are pointing to this
01:11:59.931 --> 01:12:03.237 product or whatever it is, right? So does that answer your
01:12:03.237 --> 01:12:03.741 question?
01:12:04.271 --> 01:12:06.748 That does. Yeah. Nope, that's that's awesome. That's good to
01:12:06.748 --> 01:12:06.951 know.
01:12:06.761 --> 01:12:10.622 Perfect. OK. So real quick. I'm gonna cover this virtual
01:12:07.781 --> 01:12:08.091 Cool.
01:12:10.622 --> 01:12:14.482 keyword. There's very little to no here, but it is still
01:12:14.482 --> 01:12:18.817 critically important. Basically just put virtual and everything
01:12:18.817 --> 01:12:20.511 in a an entity framework.
01:12:23.011 --> 01:12:26.739 Entity class. The reason for that without getting too into
01:12:26.739 --> 01:12:27.561 the weeds is.
01:12:28.361 --> 01:12:32.205 Entity framework returns a proxy of your class and if the
01:12:32.205 --> 01:12:35.651 properties aren't virtual, it doesn't work as well.
01:12:36.681 --> 01:12:41.285 I don't have a full breadth of understanding on all the magic
01:12:41.285 --> 01:12:45.591 that goes on inside of that, so I can't really explain it
01:12:45.591 --> 01:12:47.151 anymore I guess, but.
01:12:46.701 --> 01:12:49.051 Part of it is also because.
01:12:48.171 --> 01:12:50.791 I think it's something to do with lazy loading.
01:12:51.531 --> 01:12:54.578 That's part of it. Yeah. That that's part of it. And then part
01:12:51.731 --> 01:12:52.291 Go ahead.
01:12:51.891 --> 01:12:52.311 Yeah.
01:12:54.578 --> 01:12:57.432 of it is also the the property change tracking that entity
01:12:57.432 --> 01:13:00.431 framework is doing internally where whenever you assign a new
01:13:00.431 --> 01:13:01.641 value to like custom key.
01:13:02.861 --> 01:13:06.113 The proxy knows that it needs to go tell the database context.
01:13:06.113 --> 01:13:09.210 Hey, this property just got changed. So whenever the person
01:13:09.210 --> 01:13:12.308 you know, whenever the user calls save changes or save unit
01:13:12.308 --> 01:13:12.721 of work.
01:13:13.431 --> 01:13:16.708 You need to go update the custom key in the database, right? All
01:13:16.708 --> 01:13:19.582 the magic that is involved within a framework doing that
01:13:19.582 --> 01:13:21.901 and then sorry Jonathan, think I cut you off.
01:13:23.081 --> 01:13:25.211 No. I was about to say the same thing about these loading so.
01:13:25.301 --> 01:13:28.547 Yeah. Perfect. Yeah. So, but yeah, suffice to say there's
01:13:28.547 --> 01:13:31.793 there's technical reasons with entity framework that that
01:13:31.793 --> 01:13:35.375 necessitated, but all you really need to know is just put it on
01:13:35.375 --> 01:13:35.711 there.
01:13:35.871 --> 01:13:40.448 Umm. Especially for navigation properties, but really just for
01:13:40.448 --> 01:13:44.953 everything. Just put virtual and stuff. It's a grand total of
01:13:44.953 --> 01:13:48.441 like 8 extra letters. If you include the space.
01:13:48.881 --> 01:13:53.360 Uh, so it it takes no extra time and it avoids some edge Casey
01:13:53.360 --> 01:13:57.555 issues later. So all you really need to know is just don't
01:13:57.555 --> 01:13:59.191 forget to put it there.
01:14:00.301 --> 01:14:03.912 It is very important, especially for the related and associated
01:14:03.912 --> 01:14:04.871 collection stuff.
01:14:05.901 --> 01:14:07.031 Umm OK.
01:14:09.071 --> 01:14:12.504 I am I am running really long time and I've got one relatively
01:14:12.504 --> 01:14:15.937 simple question to answer that's still floating around and one
01:14:15.937 --> 01:14:19.097 really hard one. So I'm gonna start with the easy one and
01:14:19.097 --> 01:14:22.421 that's these mapping questions. So you guys have been seeing
01:14:22.421 --> 01:14:25.745 these as I've been scrolling through, there's this don't map
01:14:25.745 --> 01:14:29.124 out with listing or don't map in ever. Don't map out ever. Or
01:14:29.124 --> 01:14:32.611 there's the really complicated ones you can find perfect. Allow
01:14:32.611 --> 01:14:35.826 map in with relate workflows but don't auto generate these
01:14:35.826 --> 01:14:38.878 attributes. Control the code that gets generated in the
01:14:38.878 --> 01:14:39.641 mapping layer.
01:14:39.851 --> 01:14:43.311 So all these ones that are like the only one that has the word
01:14:43.311 --> 01:14:46.497 map in it, that's actually related to entity framework is
01:14:46.497 --> 01:14:49.793 the not mapped property. We talked about a little while ago
01:14:49.793 --> 01:14:51.881 and the user class up here, this one.
01:14:53.001 --> 01:14:57.111 All the rest of these like don't map out ever. Don't map out with
01:14:57.111 --> 01:15:00.909 listing whatever it is, those are only CEF specific and they
01:15:00.909 --> 01:15:04.770 relate specifically to how the mapping layer works. So if you
01:15:04.770 --> 01:15:08.631 guys are familiar with like the list light and full mappings.
01:15:09.671 --> 01:15:12.101 Sev's default behavior is.
01:15:13.351 --> 01:15:17.192 At a list mapping and above and a light mapping and above, by
01:15:17.192 --> 01:15:18.741 default they're the same.
01:15:19.281 --> 01:15:22.956 Uh, all of the properties that are flat properties will map
01:15:22.956 --> 01:15:23.201 out.
01:15:24.001 --> 01:15:27.621 Umm. So anything that isn't a related or associated object is
01:15:27.621 --> 01:15:30.191 gonna map out at the light and list levels.
01:15:31.141 --> 01:15:35.370 A full mapping will also by default include related objects
01:15:35.370 --> 01:15:36.991 and associated objects.
01:15:38.271 --> 01:15:41.361 Now, there are obviously gonna be scenarios where.
01:15:42.211 --> 01:15:45.620 You want to include additional information at a lower level. So
01:15:45.620 --> 01:15:47.591 let's say that in the light mapping.
01:15:48.341 --> 01:15:51.696 This is a. This is one that we actually do use, I believe, and
01:15:51.696 --> 01:15:54.892 the light mapping we want the users contact to map out what
01:15:54.892 --> 01:15:57.875 the user where it normally wouldn't, because that would
01:15:57.875 --> 01:16:01.177 only map out to related objects. It would only map out on the
01:16:01.177 --> 01:16:04.266 full mapping. But if we're listing out a handful of users
01:16:04.266 --> 01:16:07.568 for like the admin editor or something, it helps to have that
01:16:07.568 --> 01:16:10.657 contact already on there. So we have a force map out with
01:16:10.657 --> 01:16:14.013 listing or with light. Sorry. And that makes it so that at the
01:16:14.013 --> 01:16:16.995 listing level the contact doesn't come out but at light
01:16:16.995 --> 01:16:17.901 and full it does.
01:16:19.151 --> 01:16:22.256 So that's that allows us to force things to map out at
01:16:22.256 --> 01:16:25.643 layers they wouldn't normally map out. And then we have the
01:16:25.643 --> 01:16:29.030 inverse of these. These don't map out ones that allow us to
01:16:29.030 --> 01:16:32.361 say we don't want this to map out with listing even though
01:16:32.361 --> 01:16:35.636 normally would and don't map out with listing is you know
01:16:35.636 --> 01:16:38.910 basically saying that at the light or the full level this
01:16:38.910 --> 01:16:42.241 property can map out. But at the listing level, it cannot.
01:16:44.211 --> 01:16:47.053 And then you can also do don't map out with light, which will
01:16:47.053 --> 01:16:49.895 say that it doesn't map out at listing or light, but does map
01:16:49.895 --> 01:16:52.371 out at full and then the last is. Don't map out ever.
01:16:53.831 --> 01:16:56.849 Don't map out ever is exactly what it sounds like you. It's
01:16:56.849 --> 01:16:59.767 just not gonna unless you manually query for it. It's not
01:16:59.767 --> 01:17:02.031 gonna come out through the mapping layer so.
01:17:02.981 --> 01:17:07.256 And then the last ones that are really complicated is these
01:17:07.256 --> 01:17:10.818 allow map in with relate workflows but don't auto
01:17:10.818 --> 01:17:15.450 generate by default the map and behavior of a related object is.
01:17:15.450 --> 01:17:19.725 So let's say that I map in a user like I call contacts user
01:17:19.725 --> 01:17:24.071 update or whatever that endpoint is and it has the preferred
01:17:24.071 --> 01:17:25.211 store set on it.
01:17:25.611 --> 01:17:29.427 Umm by default, assuming this attribute wasn't here. If that
01:17:29.427 --> 01:17:32.993 store that I'm mapping in doesn't exist, it would go try
01:17:32.993 --> 01:17:36.621 to generate it based on the information that I mapped, it
01:17:36.621 --> 01:17:40.250 would go try to generate a new store. This attribute says
01:17:40.250 --> 01:17:44.066 you're allowed to map in the store that this user associates
01:17:44.066 --> 01:17:46.881 to like. You can set that store ID property.
01:17:47.531 --> 01:17:50.736 But if that store ID or that store like object that you're
01:17:50.736 --> 01:17:54.105 mapping in doesn't correspond to an existing record, it's not
01:17:54.105 --> 01:17:57.202 gonna try to generate one. With that information, it you
01:17:57.202 --> 01:18:00.570 basically can only assign it to a record that already exists.
01:18:00.570 --> 01:18:02.961 It's not gonna try to generate one for you.
01:18:04.891 --> 01:18:05.361 So.
01:18:06.751 --> 01:18:09.760 I hope that that made sense and I know that these ones like
01:18:09.760 --> 01:18:12.971 these allow map in with relate but don't auto generate. There's
01:18:12.971 --> 01:18:16.181 an allow map in with associate but don't auto generate as well.
01:18:17.071 --> 01:18:19.495 Again, don't really need to worry about those, it's it's
01:18:19.495 --> 01:18:21.111 kind of edge case that that comes up.
01:18:23.261 --> 01:18:24.011 And.
01:18:25.361 --> 01:18:28.152 If, if, if we excuse me, if we do catch that it's something
01:18:28.152 --> 01:18:30.943 that we might catch in a code review, and if not, you know,
01:18:30.943 --> 01:18:33.641 we'll cross that bridge when we come to it kind of thing.
01:18:35.411 --> 01:18:39.143 Important note is that changing those mapping attributes does
01:18:39.143 --> 01:18:42.695 not require creating a new migration or anything else. All
01:18:42.695 --> 01:18:46.247 that it requires is running the mapping T4 and more recent
01:18:46.247 --> 01:18:49.979 versions of stuff that's just running the Big Daddy T4 that's
01:18:49.979 --> 01:18:50.401 in the.
01:18:51.271 --> 01:18:54.579 This one right here. Data model dot T But in 2022.3 and older.
01:18:54.579 --> 01:18:57.940 If you're just changing these, you know force map outs or don't
01:18:57.940 --> 01:19:01.143 map outs or whatever in the in this layer the only thing you
01:19:01.143 --> 01:19:04.241 need to do is rebuild your solution and run the mapping T4
01:19:04.241 --> 01:19:07.235 and that's it, it doesn't. It doesn't actually alter the
01:19:07.235 --> 01:19:10.333 schema according to entity framework so there doesn't need
01:19:10.333 --> 01:19:12.381 to be migration or anything like that.
01:19:13.951 --> 01:19:14.281 So.
01:19:15.021 --> 01:19:16.111 Any questions on those?
01:19:20.251 --> 01:19:22.891 And if not, I will cover the final question which was
01:19:22.891 --> 01:19:26.021 actually the first question that I was asked like an hour and a
01:19:26.021 --> 01:19:26.461 half ago.
01:19:26.531 --> 01:19:26.881 Ohh.
01:19:27.531 --> 01:19:31.427 Uh, and apologies for it taking this long to get around to that
01:19:31.427 --> 01:19:35.080 question, but it it's gonna involve digging into the T4, so
01:19:35.080 --> 01:19:38.611 I wanted to make sure that I didn't let anyone eyes glaze
01:19:38.611 --> 01:19:40.681 over before we got to that point.
01:19:41.901 --> 01:19:45.319 So I wanted to try to keep people engaged in the stuff that
01:19:45.319 --> 01:19:46.971 was more broadly relevant so.
01:19:49.361 --> 01:19:53.425 If anybody, if anybody is interested in the way that these
01:19:53.425 --> 01:19:57.834 T fours work and all that stuff, then now is your time to learn
01:19:57.834 --> 01:19:58.661 some things.
01:20:00.001 --> 01:20:03.839 So first important note, and I think everybody's aware of this
01:20:03.839 --> 01:20:07.251 now, but I'm just gonna say it out loud to to do my due
01:20:07.251 --> 01:20:07.861 diligence.
01:20:08.621 --> 01:20:12.570 The T4 is do not read your code, they don't read a dot CS file,
01:20:12.570 --> 01:20:16.395 they don't read anything. You've actually physically manually
01:20:16.395 --> 01:20:19.851 written. They look at the compiled output of the build.
01:20:20.651 --> 01:20:24.653 What that actually means is if you change the code and you
01:20:24.653 --> 01:20:28.519 don't build and you run the T4, your changes will not be
01:20:28.519 --> 01:20:32.928 reflected by that T4 run. So if I go and I make an entire 20 new
01:20:32.928 --> 01:20:37.065 classes of schema and the data model layer and I don't build
01:20:37.065 --> 01:20:40.321 and I run the T4, it's going to change nothing.
01:20:40.961 --> 01:20:44.376 Umm, so that's something you absolutely have to keep in mind
01:20:44.376 --> 01:20:47.511 is before any T4 runs you need to rebuild the solution.
01:20:49.781 --> 01:20:50.201 So.
01:20:51.091 --> 01:20:54.342 Saying that for a second time out loud before you run any T
01:20:54.342 --> 01:20:57.486 fours, you need to rebuild the solution. So I I hope that
01:20:57.486 --> 01:21:00.737 everybody heard that at least one of those two times that I
01:21:00.737 --> 01:21:01.171 said it.
01:21:01.851 --> 01:21:05.536 Umm, that's most of the time. If you're having issues with T4's
01:21:05.536 --> 01:21:08.588 not having the output that they're supposed to, it's
01:21:08.588 --> 01:21:10.201 because you need to rebuild.
01:21:11.601 --> 01:21:11.971 So.
01:21:12.821 --> 01:21:16.262 And if you're still having issues after that, it's because
01:21:16.262 --> 01:21:19.587 you probably need to close Visual Studio, reopen it, and
01:21:19.587 --> 01:21:23.145 then rebuild. So that's your. That's your T4 troubleshooting
01:21:23.145 --> 01:21:26.878 steps. One and two, rebuild and run it again. If it's still not
01:21:26.878 --> 01:21:30.261 working, restart Visual Studio, rebuild and run it again.
01:21:31.041 --> 01:21:34.421 Then if it's not working, you've got some more weird problem.
01:21:35.581 --> 01:21:40.091 So that's just kind of a T fours 101. Yeah. What's up, nick?
01:21:41.531 --> 01:21:45.216 Uh. When you say T fours aren't working, do they ever actually
01:21:45.216 --> 01:21:48.843 throw an error or by not working you just mean you run it and
01:21:48.843 --> 01:21:50.481 there are no modified files?
01:21:51.031 --> 01:21:54.792 Either no modified files or a bunch of unexpected modified
01:21:54.792 --> 01:21:58.171 files. They do occasionally throw errors. Yes, it's.
01:21:59.541 --> 01:22:03.026 I I I can't think of a way to trigger one so I can show you
01:22:03.026 --> 01:22:06.743 what they look like, but in your error list you'll get a really
01:22:06.743 --> 01:22:08.951 big giant BLOB of angry looking text.
01:22:10.221 --> 01:22:12.975 And really, it's not worth reading the angry text. You
01:22:12.975 --> 01:22:16.079 should just know that when you see, when you run at 4 and you
01:22:16.079 --> 01:22:17.031 see the angry text.
01:22:17.681 --> 01:22:21.151 You should probably just restart Visual Studio, build it and try
01:22:21.151 --> 01:22:24.353 to run it again and then if it doesn't work and you get the
01:22:24.353 --> 01:22:27.663 angry text again or your outputs weird, then you can probably
01:22:27.663 --> 01:22:30.812 like send a message in the Ask anything chat or get office
01:22:30.812 --> 01:22:32.681 hours or something like that. But.
01:22:33.761 --> 01:22:36.551 Yeah, they do occasionally error.
01:22:36.711 --> 01:22:38.051 Umm so.
01:22:41.081 --> 01:22:46.026 Let's see. So like I said, the T4 is read the compiled code and
01:22:46.026 --> 01:22:50.971 they do that with a C# feature called reflection. I'm not gonna
01:22:50.971 --> 01:22:55.298 dig into the ends and outs of reflection because it's a
01:22:55.298 --> 01:22:59.934 gigantic topic, but suffice to say it's basically a process
01:22:59.934 --> 01:23:02.561 through which C code can analyze.
01:23:03.231 --> 01:23:06.021 Other code or compiled code?
01:23:07.531 --> 01:23:11.261 And use. Basically look at that code through data structures
01:23:11.261 --> 01:23:15.113 that you can work with in your code. So reflection is a really
01:23:15.113 --> 01:23:18.354 cool, powerful tool. I highly recommend learning and
01:23:18.354 --> 01:23:22.145 understanding it, but I'm not gonna go over it right now. The
01:23:22.145 --> 01:23:24.591 specific question that you were asking.
01:23:25.811 --> 01:23:29.211 Jeremy was related to scenarios where.
01:23:29.291 --> 01:23:32.583 Uh, perfect example right here, category user. This is even. I'm
01:23:32.583 --> 01:23:35.521 pretty sure the table you were asking about specifically.
01:23:35.651 --> 01:23:36.981 Yes, yes, exactly.
01:23:37.261 --> 01:23:37.921 Uh.
01:23:39.181 --> 01:23:43.482 When Jeremy created this table originally, he called it user
01:23:43.482 --> 01:23:47.924 category and when he ran the T fours it wanted to generate his
01:23:47.924 --> 01:23:52.366 models as being called category user model even though the the
01:23:52.366 --> 01:23:54.481 table class was user category.
01:23:56.061 --> 01:24:00.132 I don't know for sure if This is why, but I suspect that it's
01:24:00.132 --> 01:24:04.071 because of these guys right here. I am pretty sure that the
01:24:04.071 --> 01:24:08.076 name of the class at the time was user category, but I think
01:24:08.076 --> 01:24:11.819 it had these attributes specified in this order where it
01:24:11.819 --> 01:24:15.824 was saying user is the slave category is the master and when
01:24:15.824 --> 01:24:19.632 that's the case the naming convention by the way, for any
01:24:19.632 --> 01:24:23.637 association table like this, the naming convention is always
01:24:23.637 --> 01:24:27.511 master then slave, so category then user in this scenario.
01:24:28.011 --> 01:24:28.491 Umm.
01:24:29.371 --> 01:24:33.550 So something to keep in mind when you're when you're making
01:24:33.550 --> 01:24:37.381 new schema is the the order that you have those names.
01:24:38.181 --> 01:24:41.418 It doesn't affect the functionality of the table, but
01:24:41.418 --> 01:24:45.074 it does affect other developer's ability to intuit about the
01:24:45.074 --> 01:24:49.030 structure of that table. So when I read one of these table names,
01:24:49.030 --> 01:24:52.687 I should be able to read OK category. That's the first name.
01:24:52.687 --> 01:24:56.583 So it's probably if I'm querying against master ID, I'm querying
01:24:56.583 --> 01:25:00.060 against the category and then user is the second-half, so
01:25:00.060 --> 01:25:03.716 that's gonna be the slave ID. That kind of thing. So this is
01:25:03.716 --> 01:25:07.013 the first place you want to check if your T4 output is
01:25:07.013 --> 01:25:09.111 inverse related to your other one.
01:25:09.411 --> 01:25:13.475 Is to make sure that the ordering of the the name in the
01:25:13.475 --> 01:25:17.325 class matches the way that you've specified it in the
01:25:17.325 --> 01:25:19.821 interfaces that you're using here.
01:25:21.891 --> 01:25:22.391 So.
01:25:23.161 --> 01:25:27.147 Uh. Specifically, the way that it's handling all of that is
01:25:27.147 --> 01:25:31.133 buried in one of these many T fours over here. I was hoping
01:25:31.133 --> 01:25:35.185 I'd have more time to find it and look through the code, but
01:25:35.185 --> 01:25:36.381 we're at time now.
01:25:37.441 --> 01:25:40.889 But ultimately, that's the main thing to check is to look at the
01:25:40.889 --> 01:25:43.914 look at the order that your class is defined. So in this
01:25:43.914 --> 01:25:47.415 case it's category user and that makes sense because we're saying
01:25:47.415 --> 01:25:47.681 that.
01:25:48.461 --> 01:25:51.820 Category. If it would stop giving me popups that cover the
01:25:51.820 --> 01:25:55.122 text I'm trying to show, category is the master users the
01:25:55.122 --> 01:25:58.311 slave. So category comes first, then user comes second.
01:25:59.711 --> 01:26:02.121 And again, that's that's a.
01:26:03.341 --> 01:26:07.306 That's a practice that we follow for all of CEF, for any table
01:26:07.306 --> 01:26:11.333 that's a relationship table or a many to many relationship join
01:26:11.333 --> 01:26:11.711 table.
01:26:13.511 --> 01:26:17.577 The first name in the table name is going to be the master, the
01:26:17.577 --> 01:26:21.643 second is gonna be the slave. So I would guess that that's what
01:26:21.643 --> 01:26:25.773 the issue was. I don't remember exactly Jeremy from from the PR.
01:26:25.773 --> 01:26:29.267 That was a few weeks ago and obviously this is like 27
01:26:29.267 --> 01:26:33.334 character long interface that I don't. I don't remember exactly
01:26:32.781 --> 01:26:33.191 Yeah.
01:26:33.334 --> 01:26:37.209 what it said in the original PR but I would suspect now that
01:26:37.209 --> 01:26:41.275 with the benefit of hindsight I would suspect that if we looked
01:26:41.275 --> 01:26:42.991 there that might have been.
01:26:44.241 --> 01:26:47.745 That might have been what was causing it. Now if you ever run
01:26:47.745 --> 01:26:51.418 into this problem again and I'm wrong, which that would be cool,
01:26:51.418 --> 01:26:54.922 I'd love to. I'd love to see what the actual problem was. You
01:26:54.922 --> 01:26:56.561 know, beyond just conjecture.
01:26:57.531 --> 01:27:00.094 But if you ever run into this again, let me know, because if
01:27:00.094 --> 01:27:02.656 there is a problem with the T4 is generating names backwards
01:27:02.656 --> 01:27:04.001 relative to what they should be.
01:27:04.681 --> 01:27:07.431 We're probably going to want to fix that so.
01:27:08.041 --> 01:27:08.951 Alright, we'll do.
01:27:09.581 --> 01:27:10.571 Yeah. So.
01:27:11.691 --> 01:27:13.991 But I guess that's that's all I got.
01:27:15.431 --> 01:27:20.235 And we were right. I I said 15 to 20 minutes and I I covered
01:27:20.235 --> 01:27:21.731 the whole thing so.
00:00:10.890 --> 00:00:13.993 You're not, you're not. Uh, mandated to, to sit here and
00:00:13.993 --> 00:00:16.170 listen to me explain the mapping layer.
00:00:17.700 --> 00:00:21.688 But so the mapping layer has three layers of mapping. The
00:00:21.688 --> 00:00:25.882 purpose of of the three layers are defined as the full layer
00:00:25.882 --> 00:00:30.145 being. I call it the everything in the kitchen sink approach.
00:00:30.145 --> 00:00:34.270 It's just every piece of data that's potentially related to
00:00:34.270 --> 00:00:38.257 what you're looking at. So you're querying a user, you're
00:00:38.257 --> 00:00:42.451 going to get their account and their contact and their this,
00:00:42.451 --> 00:00:46.577 and they're that and they're everything else that's related
00:00:46.577 --> 00:00:47.470 to that user.
00:00:47.570 --> 00:00:50.300 It's just a it's all the information about that user.
00:00:51.900 --> 00:00:55.128 That is really useful for things like the admin editing page,
00:00:55.128 --> 00:00:58.564 where you're gonna wanna see all that information so you can edit
00:00:58.564 --> 00:00:58.720 it.
00:01:00.240 --> 00:01:03.876 And then in the case of like the product, a full mapping is good
00:01:03.876 --> 00:01:07.343 for like the product details page. You're gonna, you're gonna
00:01:07.343 --> 00:01:10.755 want to show everything about a product you want to get it's
00:01:10.755 --> 00:01:13.831 associated products, the categories that it's in, it's
00:01:13.831 --> 00:01:17.467 images, it's type, it's status, it's everything, all that stuff.
00:01:17.467 --> 00:01:20.934 The downside to a full mapping is obviously it's crap load of
00:01:20.934 --> 00:01:24.458 data. So it's a slow query. It's a lot of data to load and map
00:01:24.458 --> 00:01:27.702 and there's some churn with querying the database for all
00:01:27.702 --> 00:01:30.610 that stuff and storing it in memory and everything.
00:01:30.850 --> 00:01:33.720 That takes time, takes memory, so it's slower.
00:01:35.240 --> 00:01:38.721 So ultimately, what that boils down to is full map, lots of
00:01:38.721 --> 00:01:42.202 information, good for detail pages. Not great if you need a
00:01:42.202 --> 00:01:45.683 lot of a lot of individual records that you're just showing
00:01:45.683 --> 00:01:49.454 a little bit of information for. So then we move down one to the
00:01:49.454 --> 00:01:52.180 lightmapping the intent for the light mapping.
00:01:53.090 --> 00:01:57.070 Of of any given record is, it's sort of the next step down. It
00:01:57.070 --> 00:02:00.860 doesn't have quite as much stuff as the full mapping layer.
00:02:02.110 --> 00:02:03.990 And it's good for if you're wanting to show.
00:02:04.690 --> 00:02:08.471 Uh, you know, maybe 567 of some record and you want a good a
00:02:08.471 --> 00:02:12.252 good chunk of the information, but you don't need absolutely
00:02:12.252 --> 00:02:16.033 everything. You know you're showing a handful of little bits
00:02:16.033 --> 00:02:20.000 of information about this thing on maybe like a card or like a.
00:02:21.260 --> 00:02:23.952 You know page where you're showing like some relations to
00:02:23.952 --> 00:02:26.829 something and you've got like five or six or seven of them or
00:02:26.829 --> 00:02:29.800 whatever. It's a decent number of things, but it's not a ton of
00:02:29.800 --> 00:02:32.631 them and it's not a singular one of them. That's kind of the
00:02:32.631 --> 00:02:33.280 middle ground.
00:02:34.520 --> 00:02:38.845 And then the last mapping size, so to speak, is list. The list
00:02:38.845 --> 00:02:43.239 layer is the minimal amount of information that's useful if you
00:02:43.239 --> 00:02:47.632 will, and so I like to think of it as like, it's almost like if
00:02:47.632 --> 00:02:51.820 you were to take like the digest that connect gets, which is
00:02:51.820 --> 00:02:55.870 literally just like ID and custom key. If you were to take
00:02:55.870 --> 00:03:00.127 that and attach like name and maybe like short description to
00:03:00.127 --> 00:03:03.490 it, it's just a very tiny amount of information.
00:03:03.890 --> 00:03:06.802 The list mapping is great when you need to show 50 of some
00:03:06.802 --> 00:03:10.060 record and you just need them to be in like a drop down where you
00:03:10.060 --> 00:03:13.219 can pick like the name like you know the drop down just renders
00:03:13.219 --> 00:03:16.230 the name and you can pick it. It's for that sort of scenario
00:03:16.230 --> 00:03:19.339 so it's lots and lots of that record and you're showing a tiny
00:03:19.339 --> 00:03:22.350 bit of information off of each one. Then you're going to use
00:03:22.350 --> 00:03:23.090 the list layer.
00:03:23.950 --> 00:03:28.189 Umm, so generally speaking, UM, it's it's sort of handled
00:03:28.189 --> 00:03:32.867 automatically for you if you are hitting like a singular buy ID
00:03:32.867 --> 00:03:35.790 endpoint, it's gonna be a full mapping.
00:03:36.640 --> 00:03:39.874 And this is more relevant to front Enders, but if you're if
00:03:39.874 --> 00:03:43.270 you're hitting like one of the buy aids endpoints on the front
00:03:43.270 --> 00:03:46.666 end, it's going to give you back a full mapping. And if you're
00:03:46.666 --> 00:03:49.953 using the like the bulk git endpoints that are T4 generated,
00:03:49.953 --> 00:03:53.295 then they'll actually accept a parameter that you can pass in
00:03:53.295 --> 00:03:56.583 for as listing. If you pass false, then you'll get them back
00:03:56.583 --> 00:04:00.086 as a light mapping. If you pass through, you'll get them back as
00:04:00.086 --> 00:04:02.889 a list mapping. So really the only time you need to
00:04:02.889 --> 00:04:06.069 differentiate manually is in that scenario where if you're
00:04:06.069 --> 00:04:09.195 like, I don't need all this extra information and I could
00:04:09.195 --> 00:04:09.680 probably.
00:04:09.760 --> 00:04:12.993 You know, load this page half a second faster if I don't get all
00:04:12.993 --> 00:04:15.729 the extra stuff, then you can you can pass true for as
00:04:15.729 --> 00:04:18.365 listing. Just know that you're not gonna get as much
00:04:18.365 --> 00:04:21.598 information and if you need that information then you'll have to
00:04:21.598 --> 00:04:23.090 pass false for that parameter.
00:04:25.040 --> 00:04:26.910 Does that answer the question, Nick?
00:04:27.840 --> 00:04:29.480 Yes, it does. Thank you very much.
00:04:29.900 --> 00:04:30.670 No problem.
00:04:32.020 --> 00:04:35.350 Well, cool, assuming nobody else has any questions or anything.
00:04:36.580 --> 00:04:39.260 I think we're probably probably good to drop and.
00:04:40.540 --> 00:04:42.290 Now I can have a fantastic weekend.
00:04:44.750 --> 00:04:46.820 Thank you very much, Brendan. That was awesome.
00:04:47.720 --> 00:04:48.130 Ohh.
00:04:47.910 --> 00:04:48.960 Yep. Thank you, Brian.
00:04:50.030 --> 00:04:51.690 Amazing. Thank you for all the details.
00:04:51.600 --> 00:04:52.910 Yeah, very useful.