Updated to retain support for automatic distribution to multiple distributions (base paths).

1) Are we in agreement that a distribution's url is `api/v2/distributions/<name>/` making Distrubition.name unique (no longer unique together with repositories)?

2) We should rename the `publisher_id` field to be more descriptive. Does "subscribed_to" seems right to me. Google's definition of subscribe: "arrange to receive something regularly, typically a publication"

amacdona@redhat.com wrote:

1) Are we in agreement that a distribution's url is `api/v2/distributions/<name>/` making Distrubition.name unique (no longer unique together with repositories)?

Since Distribution would be a top level resource that represents a system-wide unique distribution base path (URL), I think it's appropriate for the name to also be universally unique.

2) We should rename the `publisher_id` field to be more descriptive. Does "subscribed_to" seems right to me. Google's definition of subscribe: "arrange to receive something regularly, typically a publication"

I think publisher_id is more descriptive and appropriate.

+1 to moving this to be a top-level resource.

Is 'name' mutable? If so we can't use it in the url based on some recent discussions. I can elaborate more if need be.

Instead of 'publisher_id' it probably should be 'publisher' since the representation of that relationship won't be an ID but an actual publisher link. A field named id I would expect to contain an identifier not a full url.

I think it makes more sense to make "name" immutable than to use id. Whether by CLI or by REST API, users will want to use a name.

I agree that keys that are a part of urls should be immutable, but I don't think that needs to be a part of this work. Name is currently mutable, and part of the url. Instead, I'd prefer to include Distributions (and other applicable objects) in https://pulp.plan.io/issues/3101.

I took away a different conclusion from the irc discussion about natural keys in urls. I took away that we should not strive to use natural keys in urls because they are mutable and that we shouldn't strive to have readable urls since they are really for machines anyway. Readable urls are important for SEO and those situations, but not as much for APIs (I think). Making an attribute read only to make the url prettier I don't think is a win.

Either way, we can separate these two discussions. For the purposes of this I'm +1 to making it top level resource with whatever urls you want because ultimately we're going to have to revisit our natural key usage in urls anyway.

bmbouter wrote:

+1 to moving this to be a top-level resource.

Is 'name' mutable? If so we can't use it in the url based on some recent discussions. I can elaborate more if need be.

My position on this is the same as repository name. Distribution.name should be mutable and not used in URLs.

Instead of 'publisher_id' it probably should be 'publisher' since the representation of that relationship won't be an ID but an actual publisher link. A field named id I would expect to contain an identifier not a full url.

Understood. I was talking in ER diagramming terms not django modeling. The Distribution.publisher attribute will result in a DB column named "publisher_id". I updated the description for clarity.

The DRF mixin classes maintained by pulp do not seem to support references to a nested master-detail resource outside the nested hierarchy. Austin is investigating.

I tracked the problem down to drf-nested-routers. It has been fixed upstream, but has not been released yet.

Depending on their release schedule, we have a couple options (1) override this function with corrected code (2) carry the dep until they release.

https://github.com/alanjds/drf-nested-routers/commit/6185da2c2e81bd452a87e87c3781b61964513873#diff-8a5d58427acdc6881c2096ebbefc0cefR79