Project

Profile

Help

Refactor #8274

closed

Move fields from abstract Distribution models to BaseDistribution

Added by dalley about 3 years ago. Updated almost 3 years ago.

Status:
CLOSED - WONTFIX
Priority:
Normal
Assignee:
-
Category:
-
Sprint/Milestone:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Platform Release:
Groomed:
No
Sprint Candidate:
No
Tags:
Wishlist
Sprint:
Quarter:

Description

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 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 requires a major deprecation policy-breaking release where core and all plugins can be upgraded simultaneously.

Moving the data across apps is 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)

The problem is you fundamentally can't separate step 3 from step 4, and one is in pulpcore and the other 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 would need to be upgraded at the same time.

The "runs_before" Django functionality can be used to make sure the 2nd core migration happens last.

Also available in: Atom PDF