| Topic | Presenter | Summary | Duration | Tags | Quiz | Captions |
| --------------------- | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---- | -------- |
| CEF Migrations Errors | James Gray | This Dev Training session from 07/31/2020 includes James giving a detailed explanation of CEF migration errors and how to go about handling them. | 43:49 | #FridayTrainings, #ClarityTraining, #DevTraining, #CEF, #CEFMigrationErrors, #WeeklyDevTrainings, #TrainingVideos, #DeveloperTrainingVideos | N/A | |00:00:02.530 --> 00:00:06.014 - So a lot of what that mean. Thatbook and everything is going 00:00:06.014 --> 00:00:08.962 - over F core, which is going to function differently than F. 00:00:11.440 --> 00:00:14.828 - In the in a lot of respects as far as like like the exact 00:00:14.828 --> 00:00:17.248 - attributes that you might put or exactly how the migration 00:00:17.248 --> 00:00:17.974 - supposed to go. 00:00:19.490 --> 00:00:23.507 - But the some of the specifics around things are going to be a 00:00:23.507 --> 00:00:26.906 - little bit different. Also in theft because we do have things 00:00:26.906 --> 00:00:30.614 - that where we are doing through extra custom work in order to 00:00:30.614 --> 00:00:34.013 - handle certain scenarios and prep for use with our view for 00:00:34.013 --> 00:00:38.234 - throughout the system. As well as, uh, you know, knew stuff 00:00:38.234 --> 00:00:41.750 - that we found as we were trying to create the Oracle integration 00:00:41.750 --> 00:00:45.266 - so that we could have a database that's running at that Oracle. 00:00:45.266 --> 00:00:48.782 - We had to change a bunch of stuff around and separate some 00:00:48.782 --> 00:00:53.198 - stuff so that. You're cool stuff could run, which was fun. 00:00:54.630 --> 00:00:58.470 - And but that's a lot of sarcasm, right there, um. 00:01:00.180 --> 00:01:06.270 - So I'm going to go over with some of those things are and how 00:01:06.270 --> 00:01:11.925 - some of the stuff is is happened in some of the things that 00:01:11.925 --> 00:01:15.840 - problems that we had overtime with entity framework. We 00:01:15.840 --> 00:01:19.755 - started using entity framework database first in 2013 2014. 00:01:21.370 --> 00:01:25.036 - At that point, uh, it was still pretty still pretty new. I think 00:01:25.036 --> 00:01:28.984 - we were. It was entity framework for uhm, so it was, you know, it 00:01:28.984 --> 00:01:32.368 - was clear enough that it had a lot of their major issues 00:01:32.368 --> 00:01:34.906 - thought, but there were still like, you know, individual 00:01:34.906 --> 00:01:38.290 - problems going on and the code first wasn't super great at that 00:01:38.290 --> 00:01:41.392 - time. In fact, we actually had to wait through several versions 00:01:41.392 --> 00:01:44.212 - of entity framework to solve certain issues. We could really 00:01:44.212 --> 00:01:45.340 - go to code first. 00:01:46.820 --> 00:01:49.984 - And use it the way that we needed to be able to use it 00:01:49.984 --> 00:01:50.436 - with stuff. 00:01:51.650 --> 00:01:56.083 - But if I expand this data model project here, it's F. We have 00:01:56.083 --> 00:01:59.493 - migrations here when we were building energy or we were 00:01:59.493 --> 00:02:02.903 - building this entity framework with code. First we were in. 00:02:04.220 --> 00:02:09.530 - US F version 4.0 and 4.1 kind of the stuff that I want. Uhm, you 00:02:09.530 --> 00:02:13.070 - know all the stuff that was going on back then. 00:02:14.600 --> 00:02:18.065 - And we created a set of migrations and we were doing 00:02:18.065 --> 00:02:22.475 - things for about a year and then we got through a stack of stuff 00:02:22.475 --> 00:02:25.310 - when I get to the end of 4.6 and 00:02:25.310 --> 00:02:30.597 - said OK. At the end of 4.6 here, we're kind of identifying some 00:02:30.597 --> 00:02:34.067 - issues that are becoming more systemic with how the databases 00:02:34.067 --> 00:02:37.884 - in the migrations that we have migrating data up from older 00:02:37.884 --> 00:02:41.701 - versions to newer versions of the schema set that we had. 00:02:42.890 --> 00:02:45.260 - Some issues that we were having with different people doing 00:02:45.260 --> 00:02:47.393 - different stuff. You know trying to create their own 00:02:47.393 --> 00:02:49.763 - migrations and then like having to quote Unquote zipper them 00:02:49.763 --> 00:02:50.000 - together. 00:02:51.660 --> 00:02:53.900 - You know, by having different people making migrations at the 00:02:53.900 --> 00:02:56.140 - same time and then having them basically play well together. 00:02:57.740 --> 00:03:01.480 - And somebody had to do with like datetime precisions and decimal 00:03:01.480 --> 00:03:04.540 - precisions. Things like that where the data was just 00:03:04.540 --> 00:03:08.960 - inconsistent and it would cause data loss if we do it that way. 00:03:08.960 --> 00:03:13.720 - So at some point we decided as part of 4.7. Let's cut it off. 00:03:13.720 --> 00:03:17.800 - Let's create a new initial one that has all the correct columns 00:03:17.800 --> 00:03:19.840 - with the correct stuff on it. 00:03:20.700 --> 00:03:23.638 - So that and then will use Redgate to push data over if the 00:03:23.638 --> 00:03:26.350 - client has something older to that point, and then we can let 00:03:26.350 --> 00:03:27.480 - them migrate up normally from 00:03:27.480 --> 00:03:29.678 - there. Um and since then? 00:03:30.310 --> 00:03:35.254 - You see, this was in December of 2016 that we created this 00:03:35.254 --> 00:03:39.374 - initial create a 4.7 and so we've been creating migrations 00:03:39.374 --> 00:03:44.318 - all the way down. Even current stuff, you know, June of this 00:03:44.318 --> 00:03:48.850 - year was the last couple of major migrations there on this. 00:03:49.480 --> 00:03:53.419 - Uh, that had stuff in it and you can see here like you 00:03:53.419 --> 00:03:55.540 - know, there's there's sometimes here. We've got 00:03:55.540 --> 00:03:58.570 - several things back to back like this overhaul, you know, 00:03:58.570 --> 00:04:01.297 - keep one BCD here where significant levels of effort 00:04:01.297 --> 00:04:04.327 - went into cleaning up issues that were happening in the 00:04:04.327 --> 00:04:06.448 - database isn't making things consistent. Dropping stuff 00:04:06.448 --> 00:04:10.084 - that didn't need to be there anymore because it was just no 00:04:10.084 --> 00:04:12.811 - longer relevant. Never got used. That kind of thing. 00:04:14.190 --> 00:04:17.270 - You know, going from master from the individual types to to 00:04:17.270 --> 00:04:20.630 - common names like like Master and slave ID so that we had 00:04:20.630 --> 00:04:23.710 - more interfaces that we could use for stuff and reduce the 00:04:23.710 --> 00:04:26.790 - amount of code in the system. Things like that were happening 00:04:26.790 --> 00:04:30.150 - and generally speaking we have a lot of stuff in here that's 00:04:30.150 --> 00:04:32.950 - like here's a migration where it's absolutely going in and 00:04:32.950 --> 00:04:35.750 - dropping cables that have a deprecated for a long time 00:04:35.750 --> 00:04:39.390 - because no one was using them anymore. We had to do her ways 00:04:39.390 --> 00:04:42.470 - of doing this. Stuff like these are all these attribute tables. 00:04:42.470 --> 00:04:43.870 - Well we had Jason attributes. 00:04:45.480 --> 00:04:48.301 - But in so we no longer needed these other tables and we can 00:04:48.301 --> 00:04:51.122 - get rid of them. So that was dropping a lot of stuff like 00:04:51.122 --> 00:04:52.207 - that out of the schema. 00:04:54.090 --> 00:04:57.250 - Um, as far as actually creating the migrations and running 00:04:57.250 --> 00:05:01.674 - through stuff we do still have a lot of the same things. Here we 00:05:01.674 --> 00:05:05.782 - have, like an account cable and let me minimize this. Be more of 00:05:05.782 --> 00:05:09.258 - this stuff. First we have an interface, but I'll skip over 00:05:09.258 --> 00:05:11.470 - that for the moment and look at 00:05:11.470 --> 00:05:13.378 - the. The class itself. 00:05:14.550 --> 00:05:18.510 - The account table here, instead of using the table tag, one of 00:05:18.510 --> 00:05:22.800 - the issues that we run into with the Oracle stuff is the Oracle 00:05:22.800 --> 00:05:27.750 - needs all the schemas to be the same and it has to be the name 00:05:27.750 --> 00:05:31.710 - of the user that's accessing it, which was annoying and to get 00:05:31.710 --> 00:05:35.010 - around that I created a separate attribute called SQL Schema. 00:05:35.620 --> 00:05:39.316 - And it basically takes in the sequel table table and then like 00:05:39.316 --> 00:05:42.396 - I have a both here that basically just join them 00:05:42.396 --> 00:05:46.400 - together with a dot in the middle and then I have a handler 00:05:46.400 --> 00:05:47.940 - in the clarity covers entities. 00:05:48.740 --> 00:05:49.769 - That help it. 00:05:50.570 --> 00:05:55.106 - To use the SQL schema, it actually might be in the T4. 00:06:01.880 --> 00:06:04.010 - And then what straight that way? 00:06:08.090 --> 00:06:09.170 - Try. 00:06:12.020 --> 00:06:13.260 - Nope, not that one. 00:06:14.690 --> 00:06:18.416 - On model creating Gates, Nope. There's the dates handling. 00:06:19.510 --> 00:06:26.580 - Creating schemas. OK here it is So what this does is it's 00:06:26.580 --> 00:06:29.035 - using that SQL SQL schema 00:06:29.035 --> 00:06:33.727 - attribute. Uh, to physically populated T4 here in this T4 00:06:33.727 --> 00:06:38.706 - goes in itself it to use this class to use through that table 00:06:38.706 --> 00:06:42.153 - with this thing, whereas Alternatively in the one that's 00:06:42.153 --> 00:06:45.813 - for Oracle. Where it's going in and doing the same thing. 00:06:46.420 --> 00:06:50.050 - Uh, it's creating it with the Oracle username as the schema. 00:06:50.860 --> 00:06:54.501 - Instead, that way we can have the two different things going 00:06:54.501 --> 00:06:58.804 - on at the same time in A T4 is just handling the differences 00:06:58.804 --> 00:07:02.445 - for us that we don't have to worry about actually running 00:07:02.445 --> 00:07:06.086 - those differences ourselves, and I had to take the physical table 00:07:06.086 --> 00:07:10.389 - tag off because with the tag on there was no way to overwrite 00:07:10.389 --> 00:07:12.044 - what it was doing directly. 00:07:13.640 --> 00:07:16.400 - Because the attribute was basically being considered as 00:07:16.400 --> 00:07:20.195 - the source of truth, and it wouldn't allow the Oracle stuff 00:07:20.195 --> 00:07:23.990 - to behave differently once they took it off. Similarly, we had 00:07:23.990 --> 00:07:27.095 - we had issues with things like date, time, precisions. 00:07:28.460 --> 00:07:33.150 - On that stuff, so I had to write in code that would check for 00:07:33.150 --> 00:07:37.505 - every date, time and go in an manually assign all of the all 00:07:37.505 --> 00:07:41.525 - of the provisions in the two different ways that they need to 00:07:41.525 --> 00:07:42.865 - do be done for. 00:07:43.480 --> 00:07:48.496 - Um, Oracle versus a Microsoft SQL Server which worked out that 00:07:48.496 --> 00:07:54.424 - that way. Do we have a test Oracle database that we can see 00:07:54.424 --> 00:07:59.253 - this in? The only one I know I'm aware of is the one for 80 00:07:59.253 --> 00:08:01.794 - and I'd have to connect to the VPN and everything, or 00:08:01.794 --> 00:08:04.335 - actually know the vegans site to site now. I'd have to 00:08:04.335 --> 00:08:05.490 - connect you all that stuff. 00:08:07.740 --> 00:08:10.262 - I did someone up initially, but I don't think in EEG or you 00:08:10.262 --> 00:08:11.620 - might be able to speak to this. 00:08:12.720 --> 00:08:16.452 - It's the developer version and I want to say that that version 00:08:16.452 --> 00:08:19.873 - doesn't have the rights to do everything we need. Is that 00:08:19.873 --> 00:08:21.428 - sound right to you though? 00:08:22.540 --> 00:08:27.640 - Stick with the yeah development, know it. What's it called a SQL 00:08:27.640 --> 00:08:33.165 - Express is, uh, in Oracle? Um, what's the name of it? Uh, so 00:08:33.165 --> 00:08:38.690 - the database that we have is the free database, uh, what would be 00:08:38.690 --> 00:08:44.215 - sick with 18 or whatever? Yeah, I'm not sure what the name is. 00:08:44.215 --> 00:08:48.890 - We have that installed, but that one doesn't have identity field 00:08:48.890 --> 00:08:50.590 - working automatically, so yeah. 00:08:52.500 --> 00:08:55.790 - And it would break. So now is the short answer. 00:08:55.790 --> 00:08:56.448 - Unfortunately, Brandon. 00:08:57.990 --> 00:09:02.384 - Let's see some how how some of that works. Yeah, I would too. 00:09:02.384 --> 00:09:04.074 - Um, I suppose we could. 00:09:04.770 --> 00:09:08.166 - I I would be really interested in seeing and this doesn't need 00:09:08.166 --> 00:09:11.279 - to be right now James, just whenever it makes sense here, 00:09:11.279 --> 00:09:14.392 - I'd be interested in seeing some of the migration errors that 00:09:14.392 --> 00:09:17.222 - typically are going to occur for someone that's pulling down 00:09:17.222 --> 00:09:20.052 - code, and you know they're running into little issues with 00:09:20.052 --> 00:09:23.165 - that. That's probably one of the more common things. It's helpful 00:09:23.165 --> 00:09:26.844 - to kind of get behind the scenes here too. Just pointing out I'm 00:09:26.844 --> 00:09:30.806 - going to get into the area where that were able to tell you what 00:09:30.806 --> 00:09:31.938 - their migration errors are. 00:09:32.820 --> 00:09:34.884 - Um and why and why they're 00:09:34.884 --> 00:09:38.860 - happening? OK, so this is, you know, the stuff that builds. 00:09:38.860 --> 00:09:42.193 - Scheming typically runs it and then whenever it goes and push 00:09:42.193 --> 00:09:45.526 - the database and it creates the migration history table with my 00:09:45.526 --> 00:09:49.162 - Christian values in it. Now the cable he showed earlier with net 00:09:49.162 --> 00:09:52.798 - core has two columns and it's got the version number and it's 00:09:52.798 --> 00:09:54.010 - got the migration name. 00:09:54.580 --> 00:09:59.380 - The. One for dot NET Framework however has three columns, the 00:09:59.380 --> 00:10:05.370 - third column. Is basically it's like a base 64 ash of them 00:10:05.370 --> 00:10:11.156 - bottle DMX that it would be equivalent to a database first. 00:10:11.940 --> 00:10:14.855 - All of the database running running so that it could provide 00:10:14.855 --> 00:10:18.035 - a hash value to make sure that the values are actually matching 00:10:18.035 --> 00:10:20.950 - and that the things can be migrated up and down correctly. 00:10:21.550 --> 00:10:22.310 - Um? 00:10:23.440 --> 00:10:27.892 - And in that it kind of. It's a little weird in what it's doing 00:10:27.892 --> 00:10:29.164 - with some stuff, but. 00:10:30.810 --> 00:10:34.370 - It's part of how it recognizes whether something is has 00:10:34.370 --> 00:10:37.930 - actually changed or not is. It's actually comparing that what 00:10:37.930 --> 00:10:42.914 - that content is, where it's one of our model DMX which is an XML 00:10:42.914 --> 00:10:45.762 - file that contains all the properties of relationships. 00:10:45.762 --> 00:10:48.966 - Everything that it would eventually build out for stuff. 00:10:50.360 --> 00:10:53.298 - And I don't know what they did differently in.net Core 2 to get 00:10:53.298 --> 00:10:56.236 - around the need for that, but that is what it here. Or maybe 00:10:56.236 --> 00:10:59.174 - they just they just need to do it with the code files. They 00:10:59.174 --> 00:11:02.112 - don't need to do it by starting at the database. I don't know. 00:11:03.740 --> 00:11:06.932 - But going back to the class here. So that's the class. You 00:11:06.932 --> 00:11:10.124 - know. This is the thing that tells it what does females we 00:11:10.124 --> 00:11:13.050 - have it telling it to do two different things. Whether you're 00:11:13.050 --> 00:11:15.976 - working with Microsoft SQL or Oracle, in order to create your 00:11:15.976 --> 00:11:19.350 - database. Uhm, you have these private collections here. For 00:11:19.350 --> 00:11:22.500 - anything that's an associate list, that's that's a one to 00:11:22.500 --> 00:11:25.020 - many or many to many relationships are all 00:11:25.020 --> 00:11:28.485 - collections you initialize the mall with a hash set up. That 00:11:28.485 --> 00:11:31.635 - would be the collection in the constructor, and then whenever 00:11:31.635 --> 00:11:35.730 - you go to run your properties on the things here and I will 00:11:35.730 --> 00:11:39.195 - spread this out a little bit so you can feel better. 00:11:39.810 --> 00:11:47.262 - Uhm, you forget that and then like to, uh, Chris Cyruses Uhm. 00:11:48.130 --> 00:11:50.913 - Uh, point earlier with the I could put referencing a private 00:11:50.913 --> 00:11:53.696 - field. This is what that looks like when you do that. 00:11:54.840 --> 00:11:57.469 - Or the individual thing and you like if you needed to 00:11:57.469 --> 00:11:58.664 - add more logic into your. 00:12:00.170 --> 00:12:03.158 - Statement here. It's like I said he's sleeping body, but I could 00:12:03.158 --> 00:12:04.403 - say like do custom code. 00:12:07.650 --> 00:12:11.836 - And I could have stuff before and after do more stuff. So this 00:12:11.836 --> 00:12:15.700 - is to what series was talking about earlier, where you have a. 00:12:16.900 --> 00:12:19.859 - After that, with the private property that you can access and 00:12:19.859 --> 00:12:22.549 - do all those things and not doing this, basically just 00:12:22.549 --> 00:12:25.239 - syntactic sugar around around you know how it goes straight 00:12:25.239 --> 00:12:28.948 - up. Guitar Center. On their uhm? 00:12:29.720 --> 00:12:32.270 - And I will undo those map. 00:12:33.760 --> 00:12:37.555 - So this is the stuff here. Now the default value null. 00:12:38.560 --> 00:12:42.575 - And the JSON ignore are for serialization things, so that if 00:12:42.575 --> 00:12:46.225 - this object is serialized into like logging or other records 00:12:46.225 --> 00:12:50.240 - that are or into your UI, Azure like running a debugging 00:12:50.240 --> 00:12:53.890 - session, it knows to not put those properties into those 00:12:53.890 --> 00:12:57.540 - serializers so that it's easier to physically mess with them. 00:12:59.130 --> 00:13:02.520 - Door is on associations prevent some things that would cause, 00:13:02.520 --> 00:13:05.232 - like loopbacks inside Georgetown, and causes the Jason 00:13:05.232 --> 00:13:09.639 - just spin deal for forever. So these are more like these Q with 00:13:09.639 --> 00:13:13.707 - a null on the collection and the JSON ignore is more about 00:13:13.707 --> 00:13:17.097 - serializing for debugging while you're looking at it with the 00:13:17.097 --> 00:13:19.809 - debugger open attached than it is anything else. 00:13:21.240 --> 00:13:25.368 - Um, additional stuff that's on here. This has to do with this. 00:13:25.368 --> 00:13:28.464 - Allow map in with associate workflows, but don't auto 00:13:28.464 --> 00:13:32.592 - generate is 44 in the mapping and the workflows layers so that 00:13:32.592 --> 00:13:36.376 - when you are coming in and you're trying to save this 00:13:36.376 --> 00:13:40.504 - account record like from the admin UI and there's a list of 00:13:40.504 --> 00:13:43.944 - current currencies on it. The expectation here is that you 00:13:43.944 --> 00:13:47.728 - would be able to save it with existing currencies, but it 00:13:47.728 --> 00:13:50.824 - would not know how to automatically generate a new 00:13:50.824 --> 00:13:54.868 - currency. If if it was trying to assign a currency that was not 00:13:54.868 --> 00:13:57.717 - found, so let's say that, uh, you know the Canadian dollar 00:13:57.717 --> 00:14:00.825 - wasn't in the currencies table, but you were trying to save it 00:14:00.825 --> 00:14:03.674 - with the Canadian dollar because it came in. However, wet method 00:14:03.674 --> 00:14:07.300 - you were doing that by doing a post band with test, or you had 00:14:07.300 --> 00:14:09.890 - something coming in from Munich from connect. It would basically 00:14:09.890 --> 00:14:13.257 - say that it can't do that and throw an exception or return an 00:14:13.257 --> 00:14:15.847 - error basically so that they connect or whatever. The thing 00:14:15.847 --> 00:14:19.473 - is that you would get the job would say that it could do this 00:14:19.473 --> 00:14:22.063 - with an account because it couldn't find the currency that 00:14:22.063 --> 00:14:26.690 - was there. There and 1st you would basically be told to go 00:14:26.690 --> 00:14:28.675 - right there right this data. 00:14:31.110 --> 00:14:33.827 - At the Canadian dollar there and then you would be allowed 00:14:33.827 --> 00:14:36.791 - to go in and save an account with that value. Same thing 00:14:36.791 --> 00:14:39.014 - with price points and an Association. They won't be 00:14:39.014 --> 00:14:41.731 - able to just auto generated this other stuff and we do 00:14:41.731 --> 00:14:44.695 - that in a lot of cases here because we don't want people 00:14:44.695 --> 00:14:45.930 - to just send over massive. 00:14:47.480 --> 00:14:51.568 - Object craft, uh, we had a lot of issues with that in the past 00:14:51.568 --> 00:14:55.072 - where people would sit there and go like, well, I'm going to 00:14:55.072 --> 00:14:58.576 - send, you know, 80 objects on this one record call. In order 00:14:58.576 --> 00:15:01.788 - to do all this different stuff and things, but that was 00:15:01.788 --> 00:15:04.416 - incredibly underperformance and caused a lot of like duplicate 00:15:04.416 --> 00:15:07.044 - records and things to get generated overtime because we 00:15:07.044 --> 00:15:09.964 - didn't have the greatest checks for making sure that stuff 00:15:09.964 --> 00:15:12.884 - wasn't already being generated by something else at the same 00:15:12.884 --> 00:15:14.636 - time, especially with with concurrent call. 00:15:15.810 --> 00:15:19.310 - So we wanted to prevent that kind of stuff and just say in a 00:15:19.310 --> 00:15:22.060 - lot of these cases make sure that the secondary data exists 00:15:22.060 --> 00:15:25.060 - 1st and then you can reference that data rather than trying to 00:15:25.060 --> 00:15:26.310 - have it created every time. 00:15:26.950 --> 00:15:30.922 - Cases where we don't do that might be like the products were 00:15:30.922 --> 00:15:33.239 - able automatically. It's allowed to automatically create 00:15:33.239 --> 00:15:36.218 - category. You know almost everything is allowed to create 00:15:36.218 --> 00:15:40.190 - an attribute type on it. Saying that it's an attribute for a 00:15:40.190 --> 00:15:43.831 - product for a, for a sales order. For the color attribute 00:15:43.831 --> 00:15:48.134 - it's allowed to do that because we did add some of the extra 00:15:48.134 --> 00:15:51.113 - Texan specializations into those workflows to make sure that 00:15:51.113 --> 00:15:54.423 - those things were much less likely to cause duplicate on 00:15:54.423 --> 00:15:56.409 - things. So we're able to do 00:15:56.409 --> 00:16:00.258 - those. This attribute here is different than those and then. 00:16:00.258 --> 00:16:03.690 - Basically it says don't don't map this in with the Associate 00:16:03.690 --> 00:16:06.498 - Workflow at all, because it's expected that some other 00:16:06.498 --> 00:16:09.306 - workflow will handle. You know, taking care of it, 00:16:09.306 --> 00:16:11.490 - namely the account associations, is. I'm excited 00:16:11.490 --> 00:16:14.298 - to this other accounts and accounts associated with some 00:16:14.298 --> 00:16:18.354 - other account is with me, so I don't want to control it from 00:16:18.354 --> 00:16:21.474 - that direction. I only want to control it from this 00:16:21.474 --> 00:16:21.786 - direction. 00:16:23.420 --> 00:16:24.608 - As opposed to, you know, going 00:16:24.608 --> 00:16:28.570 - to. And we have some other things that we basically just 00:16:28.570 --> 00:16:32.206 - say don't ever map out or in. UM, basically don't don't deal 00:16:32.206 --> 00:16:35.539 - with this. Associations at all is some other workflow is going 00:16:35.539 --> 00:16:39.175 - to take care of these entirely. Don't don't try to provide this 00:16:39.175 --> 00:16:42.205 - information that way, 'cause it performance reasons or like with 00:16:42.205 --> 00:16:43.417 - user role security thing. 00:16:45.110 --> 00:16:48.134 - Or it's just not relevant for you to have every purchase order 00:16:48.134 --> 00:16:50.906 - that's going to tide to the account ever, always coming out 00:16:50.906 --> 00:16:53.930 - with the account model. So we just skip that stuff. We require 00:16:53.930 --> 00:16:55.442 - you to go pull that data 00:16:55.442 --> 00:16:59.540 - separately. Sorry, you might have already said this for those 00:16:59.540 --> 00:17:02.780 - attributes part of entity framework where those part of 00:17:02.780 --> 00:17:06.020 - that before generation. No, these these are all custom 00:17:06.020 --> 00:17:10.340 - attributes that we create that are created here and we are used 00:17:10.340 --> 00:17:13.580 - for the cheaper generation. Could find all the custom 00:17:13.580 --> 00:17:16.820 - attributes in this one attributes folder here. So all 00:17:16.820 --> 00:17:21.140 - of these are stuff that we had created, the decimal and the 00:17:21.140 --> 00:17:24.020 - string is Unicorn attributes specifically affect the entity 00:17:24.020 --> 00:17:26.540 - framework but everything else and that one. 00:17:26.650 --> 00:17:29.242 - Those three affect the entity framework. Everything else will 00:17:29.242 --> 00:17:32.122 - have to do with RT four generation, an creating mapping 00:17:32.122 --> 00:17:34.426 - or creating workflows and associations and things like 00:17:34.426 --> 00:17:37.594 - that. So that means all of these in all of these. 00:17:38.640 --> 00:17:41.196 - Are the ones that are 4 hour to your internal use only 00:17:41.196 --> 00:17:42.474 - and don't effect EFF at all? 00:17:44.230 --> 00:17:46.310 - Does it mean that, uhm? 00:17:46.910 --> 00:17:49.730 - Entity framework will automatically generate a 00:17:49.730 --> 00:17:54.430 - role in the foreign key if it doesn't have it. 00:17:56.510 --> 00:18:01.760 - No, no no. It has to do with the the the associations of the 00:18:01.760 --> 00:18:05.885 - mapping that are happening down here. So when you create when 00:18:05.885 --> 00:18:07.760 - you run the Associations T4. 00:18:09.050 --> 00:18:10.688 - Uh, like if I'm looking at the 00:18:10.688 --> 00:18:12.900 - account here. Uh, like you know? 00:18:13.650 --> 00:18:18.690 - It doesn't. It's not allowed to do to associate children on it. 00:18:18.690 --> 00:18:23.310 - It's not allowed to minimize stuff here. Uhm, so we manually 00:18:23.310 --> 00:18:27.930 - would if the attribute wasn't on the Association of field, we 00:18:27.930 --> 00:18:31.710 - would manually probably create first the child record parent 00:18:31.710 --> 00:18:35.070 - record and then insert the child record, right? 00:18:37.130 --> 00:18:40.730 - Mini adventure, which property in what you're doing with it? 00:18:40.730 --> 00:18:45.050 - But yes, um, like the account user role here. When it got 00:18:45.050 --> 00:18:49.010 - that attribute that says don't map in ever don't map out 00:18:49.010 --> 00:18:52.250 - ever. It basically didn't even create an Association workflow 00:18:52.250 --> 00:18:56.210 - forward at all. And then the thing that's calling this in 00:18:56.210 --> 00:18:58.010 - the workflows T4 which is. 00:19:00.080 --> 00:19:03.750 - Run, the default Association were close disc. Pauls all the 00:19:03.750 --> 00:19:07.053 - Association workflows. In order to do those different things. 00:19:07.890 --> 00:19:12.026 - So here's the account currency. It got it created. An is 00:19:12.026 --> 00:19:17.290 - physically able to cook, to call into it. But if you look at the 00:19:17.290 --> 00:19:19.546 - Association, the account Currency Association Workflow. 00:19:21.250 --> 00:19:24.026 - Uh, which should be back in this file. 00:19:30.050 --> 00:19:33.566 - It real quick it should be right here. Yeah, so it has 00:19:33.566 --> 00:19:37.082 - it here and then. It says like model to new objects in 00:19:37.082 --> 00:19:38.254 - modern object. Anything um? 00:19:39.510 --> 00:19:46.266 - And then, uh, we create the manual part of this over here. 00:19:46.266 --> 00:19:50.328 - Count currencies. Where it's allowed to resolve to ID. 00:19:50.970 --> 00:19:53.742 - And so we do that there. And so we were allowed to resolve the 00:19:53.742 --> 00:19:56.316 - idea, but we don't go in and visit Lee like auto generate a 00:19:56.316 --> 00:19:58.296 - new currency and then you know inside this Association workflow 00:19:58.296 --> 00:19:59.484 - we also have the extra things 00:19:59.484 --> 00:20:02.547 - that you have. Watching like a verifying that the you know what 00:20:02.547 --> 00:20:05.966 - the other currency side is. You know if it changed. If there's a 00:20:05.966 --> 00:20:09.385 - custom that was a sign of the currency like we create a custom 00:20:09.385 --> 00:20:11.226 - names for currencies for redemption because different 00:20:11.226 --> 00:20:13.856 - customers were going to, or different clients were going to 00:20:13.856 --> 00:20:17.538 - have like one was going to get tickets when I was going to call 00:20:17.538 --> 00:20:20.431 - him points, was going to call him, you know, favors or 00:20:20.431 --> 00:20:23.324 - something else. I don't know who knows what or experience. Who 00:20:23.324 --> 00:20:26.480 - knows that way they could go specify even though this was the 00:20:26.480 --> 00:20:29.899 - ticket currency that we had in the system that it was going to 00:20:29.899 --> 00:20:32.003 - be used on the back end is the 00:20:32.003 --> 00:20:34.600 - ticket everywhere. Inside their custom portal, whenever that 00:20:34.600 --> 00:20:37.550 - client login, they would be experience or points or tickets 00:20:37.550 --> 00:20:41.680 - or whatever they want to specify on it, and then this is just a 00:20:41.680 --> 00:20:44.630 - check to make sure that that value is quote, Unquote, 00:20:44.630 --> 00:20:47.875 - different, and to pull it in and do all that stuff. 00:20:48.550 --> 00:20:53.005 - OK, so getting back down. I need to move this along 00:20:53.005 --> 00:20:54.625 - away from this point. 00:20:56.220 --> 00:20:58.800 - This is getting into that stuff. I want to make sure I 00:20:58.800 --> 00:21:00.520 - get into some of the actual migration stuff. 00:21:01.980 --> 00:21:06.696 - Let's see if clothes that that that. So once you've made your 00:21:06.696 --> 00:21:11.805 - class and you got it doing all the different things we do have 00:21:11.805 --> 00:21:13.770 - these base projects on here. 00:21:14.640 --> 00:21:17.290 - That they are inheriting at least root concrete. So like 00:21:17.290 --> 00:21:20.735 - here's the base itself. I did manage to fix so that we can 00:21:20.735 --> 00:21:23.650 - have these things in her, it properly and it won't just 00:21:23.650 --> 00:21:25.770 - put 'em all in the same table anymore. 00:21:27.370 --> 00:21:31.673 - Uh, which was good? Uh, but we could do things like here's the 00:21:31.673 --> 00:21:35.645 - things you saw before like here's the key. It means that it 00:21:35.645 --> 00:21:38.955 - must be there. This says that its database generator with 00:21:38.955 --> 00:21:43.258 - identity. It has an index on it. There are tables in here that 00:21:43.258 --> 00:21:47.230 - have like a multicolumn index like the cart table does. So I 00:21:47.230 --> 00:21:49.216 - go to like the shopping table 00:21:49.216 --> 00:21:54.390 - cart. I can specify I have to override the active variables 00:21:54.390 --> 00:21:58.938 - that can provide its own index and then you could have this 00:21:58.938 --> 00:22:00.454 - unique by session ID. 00:22:02.010 --> 00:22:05.718 - So it actually go through the file. There you can see there's 00:22:05.718 --> 00:22:09.735 - 1234 spots in this table that have to do with this one index, 00:22:09.735 --> 00:22:13.134 - and you specify that it is unique. It's not a clustered 00:22:13.134 --> 00:22:16.224 - index, and then the order in which these properties are 00:22:16.224 --> 00:22:19.932 - assigned in. Then it goes and creates an index that is multi 00:22:19.932 --> 00:22:23.640 - column that says that it must meet all of these values in 00:22:23.640 --> 00:22:27.348 - order to stay unique on the stuff that's in order to prevent 00:22:27.348 --> 00:22:30.129 - duplicate cart from getting created in their user shopping 00:22:30.129 --> 00:22:33.837 - sessions and making it so that like they log into one box. 00:22:33.970 --> 00:22:38.000 - You know it shows it up and it does it incorrectly and then 00:22:38.000 --> 00:22:41.410 - just generates more and more carts overtime by after then we 00:22:41.410 --> 00:22:44.820 - have had many years worth of issues with that. Before we 00:22:44.820 --> 00:22:48.850 - finally settled on a value that kind of 90% of the time it 00:22:48.850 --> 00:22:51.950 - works. I want to say probably more than that, but. 00:22:52.720 --> 00:22:56.087 - At this point we have a lot of problems with that. We had 00:22:56.087 --> 00:22:58.936 - this multi clustered index in order to make sure that the 00:22:58.936 --> 00:23:01.267 - database said no, you're trying to create a duplicate. 00:23:01.267 --> 00:23:03.857 - Stop that with the same session ID, the same whether 00:23:03.857 --> 00:23:07.224 - it's active or not on the same user of the same type, etc. 00:23:09.470 --> 00:23:12.451 - So that's kind of those attributes that are in there and 00:23:12.451 --> 00:23:15.974 - then you have these base columns in here that you all this stuff, 00:23:15.974 --> 00:23:19.226 - and then these ones that are commented out here with the date 00:23:19.226 --> 00:23:22.478 - time precision that has to do with that Oracle change where I 00:23:22.478 --> 00:23:25.459 - have to auto generate all that stuff because having the column 00:23:25.459 --> 00:23:28.169 - attributes here and the daytime to precision attribute here it 00:23:28.169 --> 00:23:30.879 - was preventing me from having the difference occur between the 00:23:30.879 --> 00:23:33.860 - Microsoft SQL version of the Oracle SQL. Once you have all 00:23:33.860 --> 00:23:37.112 - that stuff done you go in and you create your migration. The 00:23:37.112 --> 00:23:40.093 - creating of your migration. You do that with the package manager 00:23:40.093 --> 00:23:42.868 - console. Um, so other windows. 00:23:43.560 --> 00:23:48.756 - And package manager console help in this open I make sure that 00:23:48.756 --> 00:23:54.818 - this is bold and then I make sure that this is an data model. 00:23:54.818 --> 00:24:00.014 - I clear that off and then I could say entity framework fix 00:24:00.014 --> 00:24:03.290 - Flash. Uh, add migration and then you say whatever your 00:24:03.290 --> 00:24:05.790 - migration name, it needs to be. You don't include the 00:24:05.790 --> 00:24:08.040 - date, time or anything. All that stuff is happening 00:24:08.040 --> 00:24:10.290 - automatically. You just need the migration stuff. I'm going 00:24:10.290 --> 00:24:12.290 - to name it so I'm gonna say unknown. 00:24:13.600 --> 00:24:16.072 - I know I've done actually made any changes here, so when it 00:24:16.072 --> 00:24:18.132 - goes and creates, this migration is basically going to create 00:24:18.132 --> 00:24:20.192 - with info and something that there's nothing in the upper 00:24:20.192 --> 00:24:23.763 - down. Uh, which is fine and I specifically called entity 00:24:23.763 --> 00:24:26.436 - framework fix flash, because both of those things are 00:24:26.436 --> 00:24:30.000 - installed and I want to make sure that I'm using the dot 00:24:30.000 --> 00:24:32.376 - NET Framework version not that night core version. 00:24:35.030 --> 00:24:37.670 - And you can see here that it's actually telling me how 00:24:37.670 --> 00:24:40.550 - to do it with with with.net core instead if I wanted. If 00:24:40.550 --> 00:24:43.190 - I had intended to call that instead, which I did not. 00:24:44.330 --> 00:24:46.778 - And it usually takes about 30 seconds to a minute before it 00:24:46.778 --> 00:24:47.390 - physically runs it. 00:24:52.500 --> 00:24:55.536 - OK, tell me something about the migration snapshot and then a 00:24:55.536 --> 00:24:58.848 - moment here. It's going to give you a new migration files that. 00:25:00.010 --> 00:25:00.890 - Down here. 00:25:03.540 --> 00:25:06.360 - Here it is and then here because I didn't change 00:25:06.360 --> 00:25:09.462 - anything, it has nothing in the upper down. I hit save 00:25:09.462 --> 00:25:12.000 - and it automatically removed unused using and covered the 00:25:12.000 --> 00:25:14.820 - white space with lines. But if I had changed something 00:25:14.820 --> 00:25:17.922 - here it would automatically create it. Now if I were to 00:25:17.922 --> 00:25:21.588 - go in and say that I wanted to make it change these field 00:25:21.588 --> 00:25:23.844 - order juice that can physically force a change 00:25:23.844 --> 00:25:26.946 - going to add another column. Here I'm going to call it. 00:25:28.990 --> 00:25:30.698 - I tested ship date. 00:25:31.640 --> 00:25:36.022 - Now I've created a created a change and I need to go for. I 00:25:36.022 --> 00:25:39.778 - need to change this migration so that it knows to handle that 00:25:39.778 --> 00:25:41.656 - extra column that I just added. 00:25:43.350 --> 00:25:46.122 - Seven it again it takes about the same amount of time. 00:25:48.440 --> 00:25:50.912 - And then my up and down will both have values of it. 00:25:53.410 --> 00:25:56.420 - Now sometimes when I'm going through and I'm, I'm making 00:25:56.420 --> 00:25:58.828 - multiple schema changes overtime like I'm trying to 00:25:58.828 --> 00:26:03.042 - add a like a whole new feature of which is going to involve a 00:26:03.042 --> 00:26:06.052 - bunch of table at it like something that's going to 00:26:06.052 --> 00:26:08.460 - affect the entire process. So that's orders, invoices, 00:26:08.460 --> 00:26:11.169 - quotes, returns, carts, sample requests. I think that's also 00:26:11.169 --> 00:26:12.072 - having them AM. 00:26:13.170 --> 00:26:16.635 - All those things will end up needing that stuff added into 00:26:16.635 --> 00:26:20.730 - that thing, and doing that stuff and Drop it in there now this 00:26:20.730 --> 00:26:24.510 - time it added it, but it says nothing changed even though I 00:26:24.510 --> 00:26:25.770 - know I changed that. 00:26:26.390 --> 00:26:27.710 - As I just added that. 00:26:29.830 --> 00:26:30.960 - So. 00:26:33.310 --> 00:26:36.082 - Why didn't that make a change? Maybe I need to do 00:26:36.082 --> 00:26:38.602 - my force option like it said, let's add the force. 00:26:39.960 --> 00:26:42.907 - Is can you name it unknown twice? 00:26:44.310 --> 00:26:46.358 - But when you when the migration hasn't been 00:26:46.358 --> 00:26:48.662 - applied to the database because it does need to 00:26:48.662 --> 00:26:51.734 - actually look at the data in order to sign it, it will 00:26:51.734 --> 00:26:54.038 - and using the same name it just automatically supposed 00:26:54.038 --> 00:26:56.342 - to automatically just replace the one that you got 00:26:56.342 --> 00:26:59.158 - so that you can do Chapman quick run without having to 00:26:59.158 --> 00:27:00.438 - delete it and start over. 00:27:12.290 --> 00:27:15.073 - OK, so the force made it regenerate correctly and we can 00:27:15.073 --> 00:27:18.615 - see that we have the ad column and we have the drop column in 00:27:18.615 --> 00:27:21.904 - our down. That's what it is now since I didn't do anything else 00:27:21.904 --> 00:27:25.446 - at the time, this is not going to have a precision on it. what 00:27:25.446 --> 00:27:29.494 - I would need to do to fix that is I would do a quick build of 00:27:29.494 --> 00:27:33.810 - this project. And then I would come into my data model context 00:27:33.810 --> 00:27:38.174 - when that's done. And physically run that so that it will replace 00:27:38.174 --> 00:27:40.316 - it. So if I say ship dates. 00:27:41.470 --> 00:27:43.862 - Um, so like here's the ship date like the actual ship, these are 00:27:43.862 --> 00:27:45.150 - the ones that were next to it. 00:27:45.850 --> 00:27:48.316 - I'm going to physically, you know now that that 00:27:48.316 --> 00:27:51.330 - project is built. I'm going to run this custom tool and 00:27:51.330 --> 00:27:54.344 - it should have another line here for my test ship date. 00:27:55.370 --> 00:27:56.310 - Automatically. 00:28:01.820 --> 00:28:03.420 - That way I can get my daytime precision. 00:28:05.160 --> 00:28:09.185 - There it is. Uhm, and then now I need to go in an I need to 00:28:09.185 --> 00:28:11.235 - rebuild migration again. I'm going to leave the force option 00:28:11.235 --> 00:28:14.766 - on. And we should see the change so that the time goes 00:28:14.766 --> 00:28:17.472 - in with a precision. Now at any point during this stuff, 00:28:17.472 --> 00:28:20.424 - like if I had added a column but had not created a 00:28:20.424 --> 00:28:23.376 - migration yet and I did a build and I looked at the 00:28:23.376 --> 00:28:25.098 - website, the website would tell me that. 00:28:26.360 --> 00:28:29.260 - All the API service calls are failing because the migrations 00:28:29.260 --> 00:28:32.740 - are different or the migrations don't match, and then one of the 00:28:32.740 --> 00:28:36.220 - errors that part of the error catching that I have. I designed 00:28:36.220 --> 00:28:39.990 - a thing that goes in uses a raw ado connection to the database 00:28:39.990 --> 00:28:42.890 - and ask the migration history table with the differences are. 00:28:43.540 --> 00:28:47.335 - Um, and you can see here. Here it is with the. You know it says 00:28:47.335 --> 00:28:50.371 - that the daytime two has the precision of Seven. So now we 00:28:50.371 --> 00:28:53.407 - know that that has gone in correctly, and we know that this 00:28:53.407 --> 00:28:56.696 - is the migration that I would want to keep. So I would go 00:28:56.696 --> 00:28:59.732 - ahead and run my little automata or thing that generates the XML 00:28:59.732 --> 00:29:03.274 - thing at the top and then I would say, you know now that I 00:29:03.274 --> 00:29:04.792 - have run this, I would say 00:29:04.792 --> 00:29:08.730 - update database. But if I just run, it's like this, it's going 00:29:08.730 --> 00:29:11.290 - to have a problem because the default printer framework or 00:29:11.290 --> 00:29:14.106 - something to make sure that I put entity framework stick than 00:29:14.106 --> 00:29:16.922 - the front, and I'm physically not going to run this real 00:29:16.922 --> 00:29:18.458 - quick, so I'm going to build. 00:29:19.550 --> 00:29:21.699 - So I could see my DFO2 failing. 00:29:23.080 --> 00:29:27.232 - A man I'll Anne well that's building. I'm going to go over 00:29:27.232 --> 00:29:30.346 - to my services API in my storefront. Show you. 00:29:31.080 --> 00:29:33.846 - It should be either here or 00:29:33.846 --> 00:29:37.058 - here. That's going to physically check my. 00:29:39.300 --> 00:29:41.428 - My greater so you can see here. 00:29:42.260 --> 00:29:44.730 - The storefront is physically told not to look. We have 00:29:44.730 --> 00:29:47.694 - commented out 'cause we want the admin want to do that instead. 00:29:47.694 --> 00:29:50.658 - That way there's no chance that there's two are going to be 00:29:50.658 --> 00:29:52.140 - doing it at the same time. 00:29:54.150 --> 00:29:58.168 - If I look at that, um, looks like the air handling is not in 00:29:58.168 --> 00:30:00.177 - this file. It must be over here. 00:30:00.250 --> 00:30:00.570 - Here. 00:30:01.790 --> 00:30:05.346 - I'm gonna check this one for Migration. 00:30:06.510 --> 00:30:07.998 - Nope, that's not it. 00:30:09.480 --> 00:30:13.896 - Uh, maybe it's inherited from this service project. 00:30:22.050 --> 00:30:25.426 - Yes, OK, so we have code in here. 00:30:26.580 --> 00:30:30.636 - And looks like a a Taylor had recently added some stuff for 00:30:30.636 --> 00:30:34.354 - specifically for talking to Oracle, but this is the code for 00:30:34.354 --> 00:30:38.072 - talking to the SQL Server. What it basically does is it. 00:30:39.720 --> 00:30:42.954 - It looks to see if there are any pending migrations and 00:30:42.954 --> 00:30:46.188 - physically runs them. If you. If this was the admin app. 00:30:46.188 --> 00:30:49.716 - Uhm, and then uh runs them now. If I hadn't created the 00:30:49.716 --> 00:30:52.656 - migration, but I had just created the column that we 00:30:52.656 --> 00:30:55.008 - then our migrations wouldn't match. It wouldn't work. 00:30:55.008 --> 00:30:57.360 - There's an exception handling that needs to happen. 00:30:58.930 --> 00:31:01.230 - Let me find the exception handler that is doing that. 00:31:03.770 --> 00:31:06.170 - And I apologize because we all how many times is 00:31:06.170 --> 00:31:08.090 - getting replicated out. It's harder to find this. 00:31:16.120 --> 00:31:20.080 - Find some people somewhere in here. OK, let's try 00:31:20.080 --> 00:31:20.960 - migration history. 00:31:22.660 --> 00:31:24.400 - Ale should be entire solution. 00:31:25.620 --> 00:31:27.279 - And it would be a seastar file. 00:31:47.330 --> 00:31:48.338 - And it should be. 00:31:53.330 --> 00:31:55.778 - We did it just fine. Here we go. 00:31:57.010 --> 00:32:01.378 - OK, so this uhm here it is get less migration. OK so this does 00:32:01.378 --> 00:32:04.810 - this goes and creates a sequence action using your SQL connection 00:32:04.810 --> 00:32:08.242 - string and talk to the migration history table goes through it 00:32:08.242 --> 00:32:11.674 - finds the migration there and then replies with that to get 00:32:11.674 --> 00:32:15.730 - life migration. So if I follow this back it's got the one that 00:32:15.730 --> 00:32:20.098 - from legal and then it looks the one is in code and says I 00:32:20.098 --> 00:32:23.218 - migration has occurred. Last migration is blah and what the 00:32:23.218 --> 00:32:26.650 - value that is inside the database and it comes back with. 00:32:26.920 --> 00:32:30.110 - Information that saying so that your UI and break correctly and 00:32:30.110 --> 00:32:33.010 - tell you what's wrong. Otherwise you would just get migration 00:32:33.010 --> 00:32:35.910 - errors occur, but it wouldn't tell you what's actually wrong. 00:32:37.490 --> 00:32:39.856 - So in theory, if I open this. 00:32:43.980 --> 00:32:45.908 - The API should fail. 00:32:46.620 --> 00:32:47.838 - In Tacular Lee. 00:32:55.760 --> 00:32:57.280 - Well, let this thing fail. 00:33:00.730 --> 00:33:01.849 - Did you OK? 00:33:03.780 --> 00:33:05.400 - So that one got through. 00:33:07.000 --> 00:33:09.720 - Came back with this so a migration here error has 00:33:09.720 --> 00:33:12.984 - occurred last migration. The DB is by brand 2 lost one of 00:33:12.984 --> 00:33:15.976 - the code is unknown. What that would basically tells you is 00:33:15.976 --> 00:33:19.240 - there's a newer timestamp on one that's in the code so you 00:33:19.240 --> 00:33:22.776 - need to run an update database or you need to run the admin 00:33:22.776 --> 00:33:25.496 - app so that it can run the migrator automatically for 00:33:25.496 --> 00:33:25.768 - you. 00:33:27.230 --> 00:33:30.610 - Another error like if it says the suit, the two are the same, 00:33:30.610 --> 00:33:33.730 - then it would give you a message that says something is probably 00:33:33.730 --> 00:33:36.330 - changed, the date or the database and are something is 00:33:36.330 --> 00:33:39.190 - probably changed with the code first and you probably need to 00:33:39.190 --> 00:33:42.570 - make a migration and then run it or the one that's in databases 00:33:42.570 --> 00:33:45.170 - newer than what you thought, which means that someone else 00:33:45.170 --> 00:33:48.030 - probably updated the database that you are talking to. So you 00:33:48.030 --> 00:33:51.410 - need to go find out what their code isn't. Pull their code into 00:33:51.410 --> 00:33:54.530 - your code so that you have the migration that they have and 00:33:54.530 --> 00:33:55.570 - then run it yourself. 00:33:56.900 --> 00:33:59.684 - And that's the majority of what those things are, and this is 00:33:59.684 --> 00:34:02.236 - extra verbs that I had created with this extra function so 00:34:02.236 --> 00:34:05.252 - that it would go through and do this. Otherwise you just get a 00:34:05.252 --> 00:34:07.340 - generic migration, doesn't match error and you have no 00:34:07.340 --> 00:34:08.500 - idea what's actually going on. 00:34:10.330 --> 00:34:14.158 - So how come the the code actually breaks with the generic 00:34:14.158 --> 00:34:19.378 - error if we are not? Uh, trying to read the value of the of the 00:34:19.378 --> 00:34:23.902 - field or anything if we just created a field in the class and 00:34:23.902 --> 00:34:28.426 - we're not trying to read it or set the value or do anything 00:34:28.426 --> 00:34:30.514 - with it, how come it's breaking? 00:34:31.320 --> 00:34:34.719 - Because entity framework as it starts up, it looks at the 00:34:34.719 --> 00:34:38.118 - classes that are being assigned for things like tables and looks 00:34:38.118 --> 00:34:42.135 - and create that hash of a model DMX and compares it with what's 00:34:42.135 --> 00:34:45.225 - in there and finds out that there's something different and 00:34:45.225 --> 00:34:49.242 - says something is wrong. I'm not going to allow any kind of data 00:34:49.242 --> 00:34:52.950 - loss or anything, so I don't want to do anything unless I'm 00:34:52.950 --> 00:34:56.040 - specifically told how to handle this by creating a migration 00:34:56.040 --> 00:34:59.748 - that says what to do. And the other question, would we also 00:34:59.748 --> 00:35:01.602 - get an error if we manually? 00:35:01.700 --> 00:35:04.660 - Went to the table, edit the new column. 00:35:05.770 --> 00:35:06.850 - And you do not. 00:35:09.120 --> 00:35:13.293 - You do not, uh, if you working physically added a column or a 00:35:13.293 --> 00:35:17.145 - table to the database, it does not have the same problem, it 00:35:17.145 --> 00:35:20.676 - just doesn't know that column is there for you to interface 00:35:20.676 --> 00:35:24.528 - with. You have to write your own manual SQL like like this 00:35:24.528 --> 00:35:27.417 - in order to interface with that column directly, which 00:35:27.417 --> 00:35:30.306 - you should not be doing like ever in here. 00:35:31.850 --> 00:35:37.810 - See, uh? The other outside of like if you were going to go in. 00:35:38.400 --> 00:35:42.338 - And you were to physically remove a column like. Let's say 00:35:42.338 --> 00:35:44.844 - that this this test data was on. 00:35:46.340 --> 00:35:50.019 - Um, I'm sorry if I had run this migration. It added that column 00:35:50.019 --> 00:35:53.981 - to the sales order table. Then if I were to go to the database 00:35:53.981 --> 00:35:57.094 - and physically remove that column but not remove it from my 00:35:57.094 --> 00:35:59.924 - entity framework code first, then I would get an error 00:35:59.924 --> 00:36:03.037 - whenever I try to access the sales order table from entity 00:36:03.037 --> 00:36:06.150 - framework. But I would not get migration errors, it would get 00:36:06.150 --> 00:36:09.263 - it would say that there's a column that's invalid and it 00:36:09.263 --> 00:36:12.376 - doesn't know what to do, so it won't allow interfacing with 00:36:12.376 --> 00:36:15.489 - that particular table. and I don't really want to break the 00:36:15.489 --> 00:36:16.621 - database at the moment. 00:36:17.360 --> 00:36:21.221 - Get to the first. We try that. I might do that on my 00:36:21.221 --> 00:36:24.191 - local another chance and just like that into a video 00:36:24.191 --> 00:36:25.973 - for you but that stuff but. 00:36:28.490 --> 00:36:32.452 - So that's kind of the basis of what that would do, and you know 00:36:32.452 --> 00:36:35.848 - scenario back and forth will get this over to the intern. They'll 00:36:35.848 --> 00:36:39.244 - be able to translate all this stuff into a wiki article about 00:36:39.244 --> 00:36:40.376 - it for those things. 00:36:41.730 --> 00:36:43.764 - This is another area with specifically wanted me to 00:36:43.764 --> 00:36:44.442 - try and cover. 00:36:45.570 --> 00:36:49.722 - Just one more question, how would we go back to the previous 00:36:49.722 --> 00:36:50.760 - version of migration? 00:36:52.890 --> 00:36:56.270 - Um, if you need to downgrade what you can do with the update 00:36:56.270 --> 00:36:59.390 - database command by itself will always do an update, but you can 00:36:59.390 --> 00:37:00.430 - also specify a target. 00:37:00.990 --> 00:37:02.652 - And with that target you can 00:37:02.652 --> 00:37:07.078 - grab. The name of a migration like. Let's say I want to go 00:37:07.078 --> 00:37:09.136 - back to uh, like just by brand. 00:37:10.650 --> 00:37:13.471 - Read by brand. To do that, you could do either the short name 00:37:13.471 --> 00:37:16.075 - or the full name that actually includes the date. Either one of 00:37:16.075 --> 00:37:19.268 - them works. So you don't have to have typing all those 00:37:19.268 --> 00:37:21.692 - numbers, you can just do the short name, but when you do 00:37:21.692 --> 00:37:23.510 - this it will physically downgrade the database to that 00:37:23.510 --> 00:37:23.712 - target. 00:37:25.190 --> 00:37:27.590 - There's also an option that you can do. 00:37:29.250 --> 00:37:32.890 - Uh, with exact syntax for it, but it's, uh, there is a way to 00:37:32.890 --> 00:37:36.010 - actually have it create a SQL script instead to make what it 00:37:36.010 --> 00:37:39.390 - would do, so that you could easily have the SQL script to go 00:37:39.390 --> 00:37:42.250 - to another environment where you don't have access to it. Like 00:37:42.250 --> 00:37:45.110 - for instance, the client is doing the work themselves and we 00:37:45.110 --> 00:37:47.710 - don't have like a Visual Studio anywhere in their environment. 00:37:47.710 --> 00:37:49.530 - We can do a creating a SQL 00:37:49.530 --> 00:37:53.022 - script. Um? I think it's like 00:37:53.022 --> 00:37:56.310 - that. Um, to do it, let me try that real quick. 00:37:58.480 --> 00:38:01.585 - Yes, he doesn't know that one. Uhm, I script. 00:38:06.670 --> 00:38:08.140 - Looks like it's scratch. There we go. 00:38:12.270 --> 00:38:14.454 - So what description be is basically what the 00:38:14.454 --> 00:38:17.184 - difference is to go down function from this one so 00:38:17.184 --> 00:38:19.095 - that you end up at this one. 00:38:20.460 --> 00:38:25.361 - In this script that it creates an would we also have to delete 00:38:25.361 --> 00:38:28.377 - those columns fields in the class in the.net? 00:38:30.400 --> 00:38:33.590 - Well, if you're yeah, if you're going to revert, you basically 00:38:33.590 --> 00:38:36.780 - need to remove your migration. You need to undo anything you've 00:38:36.780 --> 00:38:39.970 - changed, like using your commit history and go back to revert 00:38:39.970 --> 00:38:43.450 - tables. So here it opened the SQL file and basically this is 00:38:43.450 --> 00:38:46.350 - everything that's inside the down function of this by brand 00:38:46.350 --> 00:38:50.300 - 2. So everything that's going on here, all these drop index 00:38:50.300 --> 00:38:52.739 - dropped columns are all being converted into SQL here. 00:38:53.580 --> 00:38:56.219 - And that's what it's doing with all this stuff. And so I now 00:38:56.219 --> 00:38:58.858 - have a SQL script that I could handle the client say this is 00:38:58.858 --> 00:39:00.076 - how to downgrade from by brand 00:39:00.076 --> 00:39:02.190 - two to buy brand. I think. 00:39:04.400 --> 00:39:08.041 - With it, um, Alternatively, you might say, like, uhm, you know 00:39:08.041 --> 00:39:13.006 - if you had. If you were to a point it at a blank database in 00:39:13.006 --> 00:39:16.647 - SQL, you could say update database script with no value on 00:39:16.647 --> 00:39:20.950 - it and you would have a full migration that went all the way 00:39:20.950 --> 00:39:24.260 - up and that migration script that creates would be item 00:39:24.260 --> 00:39:27.570 - potent, which means that no matter what database you pointed 00:39:27.570 --> 00:39:31.542 - it at, any databases on an older migration up to where the 00:39:31.542 --> 00:39:34.852 - migration script runs, which I'm going to try this unknown. 00:39:35.490 --> 00:39:40.194 - So if I wanted to go all the way to buy brand 2, then any number 00:39:40.194 --> 00:39:43.428 - of databases that could be on any one of these integrations 00:39:43.428 --> 00:39:46.956 - would be automatically upgraded to all the way to buy grand two 00:39:46.956 --> 00:39:50.190 - and it would know how to step them up automatically throughout 00:39:50.190 --> 00:39:53.424 - the whole process. Thanks good question, and I think I think 00:39:53.424 --> 00:39:56.070 - the main thing for folks is understanding when they're 00:39:56.070 --> 00:39:58.716 - working with Steven, they're dealing with the local usually 00:39:58.716 --> 00:40:00.186 - when they make a pool. 00:40:00.340 --> 00:40:03.882 - So if there's a difference in the database from what they're 00:40:03.882 --> 00:40:07.424 - using and what they pulled in, there can be migration errors, 00:40:07.424 --> 00:40:11.288 - and I've commonly seen it where someone is working on a local 00:40:11.288 --> 00:40:14.186 - but attached to a database that everyone is using. 00:40:15.350 --> 00:40:19.860 - And whenever they make a change, it breaks. Everyone else is 00:40:19.860 --> 00:40:21.910 - ability to use that shared 00:40:21.910 --> 00:40:25.813 - database. Hum, which is one of the reasons we wouldn't 00:40:25.813 --> 00:40:28.983 - encourage doing that. Sharing the database in that case, but 00:40:28.983 --> 00:40:32.787 - but that does happen, and when it does happen, being able to 00:40:32.787 --> 00:40:36.274 - kind of deal with that, and I think what you covered. 00:40:37.000 --> 00:40:40.852 - Especially at the end, there, um, after you kind of laid the 00:40:40.852 --> 00:40:44.383 - foundation for how it's set up. I think that covers those 00:40:44.383 --> 00:40:48.235 - scenarios, but feel free if you guys are thinking of some, but 00:40:48.235 --> 00:40:52.408 - the James didn't hit on already, and if not then one question is00:40:52.408 --> 00:40:56.260 - there away. Let's say somebody made a change. A new column has 00:40:56.260 --> 00:40:58.186 - been created and I do pull. 00:40:59.010 --> 00:41:04.236 - Uh. How do I know that something would I have to like get an 00:41:04.236 --> 00:41:08.324 - error to know that I have to run migrations? Or is there a way 00:41:08.324 --> 00:41:10.368 - for me to get together and air? 00:41:11.650 --> 00:41:14.515 - You would get to the point where you had to get an error and then 00:41:14.515 --> 00:41:16.425 - troubleshooting it. You would basically just go in and run. 00:41:17.780 --> 00:41:21.102 - Do an ad migration, I I literally call add migration and 00:41:21.102 --> 00:41:25.028 - call it unknown just to see what the changes are. Because if that 00:41:25.028 --> 00:41:28.954 - column is there an it would pop up inside this thing tell me 00:41:28.954 --> 00:41:32.276 - something different and they never go look at the history on 00:41:32.276 --> 00:41:36.202 - the on the table that the class that was modified and who broke 00:41:36.202 --> 00:41:39.826 - it in, why they didn't fix it correctly when they were sending 00:41:39.826 --> 00:41:43.752 - stuff to the repo. And you know how this got missed on really 00:41:43.752 --> 00:41:47.678 - gotta break every website trying to use it. I want to make sure 00:41:47.678 --> 00:41:50.098 - that. You know whoever did that initially get educated 00:41:50.098 --> 00:41:52.458 - on making sure that we go through and actually create 00:41:52.458 --> 00:41:54.346 - the migration correctly? That gets tested by running 00:41:54.346 --> 00:41:56.470 - against an actual website and all that stuff. 'cause 00:41:56.470 --> 00:41:58.358 - sometimes you created migration and it turns out 00:41:58.358 --> 00:42:00.718 - that what you're creating is going to create like a 00:42:00.718 --> 00:42:03.078 - cyclical dependency, and so it has extra work that you 00:42:03.078 --> 00:42:05.910 - have to do in order to make sure that it works correctly. 00:42:07.490 --> 00:42:11.606 - That more as the more advanced scenario and it usually has to 00:42:11.606 --> 00:42:15.722 - do with like 1 table. Trying to reference another table twice or 00:42:15.722 --> 00:42:19.152 - more times like a like the account table referencing. I'm 00:42:19.152 --> 00:42:23.954 - sorry that was a good one. They are all listening here so I will 00:42:23.954 --> 00:42:28.580 - know them. Like the a note table referencing the user table three 00:42:28.580 --> 00:42:32.850 - times, you have to physically tell it how to do it and how to 00:42:32.850 --> 00:42:35.595 - deal with Cascade delete correctly because one of them 00:42:35.595 --> 00:42:38.950 - will will confuse it when you're creating the schema. When you're 00:42:38.950 --> 00:42:42.305 - creating the migration, it will physically do it, but it will 00:42:42.305 --> 00:42:45.965 - tell you warnings, or it might error out saying that there's a 00:42:45.965 --> 00:42:49.625 - cyclical dependency and that you need to do this manually and how 00:42:49.625 --> 00:42:53.590 - to deal with that, and basically what it boils down to is you 00:42:53.590 --> 00:42:55.725 - have to come in here and do 00:42:55.725 --> 00:43:00.732 - this. Um, in order to tell how to handle talking to the same 00:43:00.732 --> 00:43:03.540 - record, the same alternate record twice with two 00:43:03.540 --> 00:43:06.699 - different lists and what their foreign keys are specifically, 00:43:06.699 --> 00:43:09.507 - and that it needs to Cascades, undelete false. 00:43:11.350 --> 00:43:14.194 - On that stuff, in which case you have to go in and 00:43:14.194 --> 00:43:16.327 - manually delete the other record first before you can 00:43:16.327 --> 00:43:17.038 - delete this record. 00:43:18.720 --> 00:43:21.558 - To deal with that properly, otherwise it doesn't know how to 00:43:21.558 --> 00:43:23.880 - handle deleting the data properly because it might go 00:43:23.880 --> 00:43:26.460 - through and try to delete stuff it wasn't supposed to. 00:43:29.570 --> 00:43:32.639 - Then like so you're unknown migration like if I had just 00:43:32.639 --> 00:43:35.987 - had that column there, it would have that column show up inside 00:43:35.987 --> 00:43:39.614 - this thing and I would know that it was on the sales order 00:43:39.614 --> 00:43:42.962 - table and have to go check the history on the sales order 00:43:42.962 --> 00:43:46.310 - table code file and figure out what's wrong and go fix it.