Timeline for Migration pattern for logic too complex to cover it with SQL
Current License: CC BY-SA 4.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 27 at 14:44 | comment | added | greenoldman | Ok, thank you. It would help a bit indeed -- the amount of code would increase but the code would be separated, so I could be sure that by mistake I would not affect any migration (when changing current code). | |
| Aug 27 at 14:07 | history | edited | Ewan | CC BY-SA 4.0 |
added 690 characters in body
|
| Aug 27 at 13:55 | comment | added | Ewan | OK, so that's the step you are missing. rather than just running the new exe you should have an upgrade process | |
| Aug 27 at 13:41 | comment | added | greenoldman | (1) I am building binary and executing it locally (2) I am creating docker image and then executing newer image. You can say it is desktop app, no patches, only full versions, after v1, there is v2, after that v3, and so on. | |
| Aug 27 at 13:26 | comment | added | Ewan | No i mean, forget about the DB, how are you upgrading/deploying this software? is it on your site, do you use a CD pipeline, or send out a patch? what? | |
| Aug 27 at 12:50 | comment | added | greenoldman | I think it would be a problem for any ORM. You can evolve you code however you like, but what is within the scope of migration has to be fixed/frozen. Thus on one hand my Rebuild function would use "current" models (for daily use), and "2024-08-27/frozen" models for migration use. It is not hard too achieve, but it leaves a lot of dead code behind, thus I am looking for some other approach, lighter, more fit/streamlined. | |
| Aug 27 at 12:46 | comment | added | Ewan | OK, but why is that hard? surely as part of your deploy you can run whatever you like? | |
| Aug 27 at 12:16 | comment | added | greenoldman | I indeed intend to have something like "Rebuild data" and this will update affected record(s) (the one user edited or added for example). But there is one special case -- migration. Right after migration there will be no such data so I would like to call "Rebuild data" on all records. | |
| Aug 27 at 10:48 | comment | added | Ewan | Im still a bit unclear on how you got into this thing with migrations | |
| Aug 27 at 10:47 | comment | added | Ewan | OK, so say you have this intensive computation, so you want to store the result, I would add this in code, so you have a "Rebuild Data" function in the code, which you run after the migration handles adding the new cols to the DB. eg. load all the nodes with a null cliqueid, computer it and save them again | |
| Aug 27 at 10:43 | comment | added | greenoldman | My question is in general sense, what to do on such occasions. In this particular case (i.e. currently) I store node records, then pairs (which node is connected to which other one). And now I am changing it to have also information (per node) -- clique id. Having it to recompute each time it would be too time consuming, IMHO it is best to keep it in DB, the only problem is initial computation :-). | |
| Aug 27 at 10:31 | comment | added | Ewan | hmm yeah that seems like it goes beyond "EF migrations", they are just supposed to be dealing with the database schema. If you have calculated fields, its unclear why you would do those on the DB, you could add them as calculated columns in the DB, or as properties on your objects? | |
| Aug 27 at 10:19 | comment | added | greenoldman | I am not sure if this helps, but part of the migration is altering tables (adding new columns, etc) -- this will be covered by SQL of course. The second part is computing the values for those new fields. Writing computation on C# side is trivial, but doing so is somewhat breaking the limits of EF Core migration concepts. On the other hand writing computation on SQL side is convoluted. I am looking (outside this post) how to simplify the second approach (SQL-only), here I am looking how to minimize the impact of the first approach. Later, when I have more information I will decide what to pick. | |
| Aug 27 at 8:22 | history | edited | Ewan | CC BY-SA 4.0 |
added 318 characters in body
|
| Aug 27 at 8:17 | comment | added | Ewan | You don't go into a lot of detail on what you can't achieve with migrations specifically, so I'm answering on the basis that there is some impossible transformation and my answer is to avoid it by using versioning and updates rather than migrations. ie you have some special upgrade v4 -> v5 which you handle outside of migrations and then you make all spanning upgrades other than 4->5, ie 1-> 6 error out instead of trying to cope with the bigger transformation | |
| Aug 27 at 5:33 | comment | added | greenoldman | Your recommendation is of course true, and I support it, but it is too general to apply. I am asking how to achieve this goal if you have to support migration with actual C# code. The approach I described looks like the best for me, but maybe I am missing something (maybe someone was already in such situation, etc). | |
| Aug 26 at 23:34 | history | answered | Ewan | CC BY-SA 4.0 |