Refactor #8274
Updated by dalley about 3 years ago
Relevant to that last point, there's one additional change I would like to make that isn't committed yet, that I want to put up for debate. It's actually relevant to performance and metadata mirroring also, bridging a lot of gaps at once. I already have it working. I want to move all of the data present on the PublicationDistribution and RepositoryVersionDistribution models to the BaseDistribution model. This would solve the following problems: * It would eliminate the aforementioned blocker to listing distributions from the repository field (can't do it without knowing the type of distribution) * It would get rid of a few lazy queries in the content app by allowing us to prefetch the data we need with .select_related(), and simultaneously clean up the content app code which already does weird stuff to get around this split in the data model * It would help us implement auto-distribution (on new publish, without any repository version change) * If you point a distribution at e.g. a File repository version instead of specifying a publication, the distribution could ask for the most recent publication of the repository version. This The downside: Migrating this properly requires that *every* plugin would need set a major deprecation policy-breaking release where core hard floor of 3.11 in the next release, and all old plugins can would also be upgraded simultaneously. Moving the incompatible with new Pulpcore. And there's no way around that because we're moving data across apps is apps. It's basically a 4 step process. Create a new field on the core models (core) Move the data from the plugin models to the new the new field on core (plugin) Then the old field needs to be deleted on the plugin model (plugin) Then the core field needs to be renamed to the original name (core) hard break but without any actual user-facing changes at all. The problem thing is you fundamentally can't separate step 3 from step 4, and one though... this is in pulpcore and already basically true with all of the other changes going on in plugin(s). You have to say "this plugin migration needs to happen before this pulpcore migration but after this other pulpcore migration" which you can only do if the 2nd core migration hasn't been applied yet. So migrations 3 and 4 need to run at the same time, which means core and all the plugins 3.11. Now would need to be upgraded at the same time. The "runs_before" Django functionality can be used a really good time to make sure the 2nd core migration happens last. do it.
.