Good questions.  Here was my thinking when modeling them.  In pulp2, we 
associate a distributor with either a
repository or a repository group.  Because of this, modeling as:

                       Distributor
                            |
            -----------------------------------
            |                                 |
  RepositoryDistributor              GroupDistributor

made sense to me.

I don't know of any use cases whereby we'd need/want a distributor that is not 
associated with a repository or
repository group.  Unless, we get rid of repository groups as they exist in 
pulp2.  If we did we /could/
collapse the model down to just a Distributor.

As for the importer, I mainly modeled as:

                   Importer
                      |
          ------------------------
          |
  RepositoryImporter

for symmetry with distributors.  In pulp2, we do not have a use case for an 
importer that is not associated
with a repository that I'm aware of.  But, I still feel that there is value in 
having the symmetry with
distributors.  There has been discussion of revising Alternate-Content-Sources 
to leverage theDeferred
Downloading (Lazy) catalog and machinery.  Preliminary thinking was that an 
alternate content source /could/
be an importer that was associated with the deferred downloading catalog but 
not associated with a repository.
 However, this idea has not gone beyond high-level brainstorming.

We may want to consider how well django migrations would handle a significant 
change in this model.  I have
seen the generated migrations deal with significant structure changes poorly 
but I assume we can write a
custom migration as needed.


On 09/06/2016 03:35 PM, Brian Bouterse wrote:
> The current Django modeled Importer [0] and Distributor [1] allow for these 
> objects to be associated or
> unassociated with a repository. I'm familiar with the use cases that motivate 
> associating a
> importer/distributor with a repository, but what are the use cases around an 
> Importer/Distributor to exist
> without being associated with a repo? Is there something that we already do 
> which would require this?
> 
> [0]:
> https://github.com/pulp/pulp/blob/28029cdc59fb5b8aef3975464df498a6496f9138/platform/pulp/platform/models/repository.py#L221
> 
> [1]:
> https://github.com/pulp/pulp/blob/28029cdc59fb5b8aef3975464df498a6496f9138/platform/pulp/platform/models/repository.py#L271
> 
> 
> -Brian
> 
> _______________________________________________
> Pulp-dev mailing list
> [email protected]
> https://www.redhat.com/mailman/listinfo/pulp-dev

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Pulp-dev mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/pulp-dev

Reply via email to