# Models with Domains

Here is a list of all the models in pulpcore and if I decided to add a domain relation. For uniqueness constraint, fields in parenthesis () are unique_together constrained, else it is unique=True

## Objects to not have a domain

| Model(base) | Uniqueness constraint | Notes |
| -------- | -------- | -------- |
|BaseModel| None | this is abstract
|MasterModel(BaseModel)| None| also abstract
|Group(django.Group)|name | individual groups per domain not possible, could always domain-prefix on the name
|django.User| username | |
|BaseDistribution(MasterModel)| name, base_path | deprecated object that can't be removed...
|AccessPolicy(basemodel) | viewset_name| should this get a domain?
|Role(basemodel) | name | User defined roles per domain seem inpractical though with the name constraint and using system wide roles requires trust for them not be modified
| ContentAppStatus(basemodel) | name | don't think it makes sense for this to have a domain
|Worker(basemodel) | name | ^^^
|TaskSchedule(basemodel)| name | only admins can modify TaskSchedules, doesn't make sense to have a domain
|SystemID(django.LifecycleModel) | None | singleton object
|SigningService(basemodel)| name | How do storing scripts work with domains? Still keep them on base machine? Actually not sure about this one since you need to be an admin to create this object |
|AsciiArmoredDetachedSigning Service(SigningService) | name | |

## Objects to have a domain

| Model(base) | Uniqueness constraint | Notes |
| -------- | -------- | -------- |
|Artifact(basemodel)| sha256, sha384, sha512| |
|PulpTemporaryFile(basemodel)| None | |
|Content(MasterModel)| unique_together = ()| Has to be declared on each plugin subclass since field for unique_together needs to be in the child table
|RemoteArtifact(basemodel)| (remote, content_artifact) | need domain for content-app on-demand and pull-through features to find the right RA, still questionable if needed
|AlternateContentSource(mastermodel) | name| |
|Exporter(MasterModel) | name | These require settings for valid directories, what to do for domains|
|Importer(MasterModel) | name |^^^ |
|Publication(MasterModel) | None | has required RepositoryVersion relation, techincally could get through two lookups |->repository_version->repository->domain, but that seems extra complicated for an object that can be listed in API
|PublishedMetadata(Content) | (*publication, relative_path) | a unique piece of content (need to think about this one)|
|ContentGuard(MasterModel) | name | |
|Distribution(MasterModel) | name, base_path | has optional ContentGuard, Publication, Remote, Repository, RepositoryVersion relations
|Repository(MasterModel) | name | has many Content relations and optional Remote relation
|Remote(MasterModel) | name | |
|Task(basemodel) | None | needed so objects w/ domains created by tasks know which domain to use, has relation to Worker and optional relations to parent Task and TaskGroup
|TaskGroup(basemodel) | None | needed for easy grouping of TaskGroups by domain, actually what if you want to have a TaskGruop of tasks across domains? Should Tasks be allowed to work across domains?
|UserRole(basemodel) | (user, role, content_type, object_id) | generic relation content_object formed from content_type and object_id can be an object with a domain |
|GroupRole(basemodel) | (group, role, content_type, object_id) | ^^^ |
|Upload(basemodel) | None | needed to know which domain the created Artifact should go to

## Objects that get domain through relations:

The * before a field represents the model that this object is getting its domain relation through.

| Model(base) | Uniqueness constraint | Notes |
| -------- | -------- | -------- |
|ContentArtifact(basemodel) | (*content, relative_path) | Also, has an optional artifact relation|
|AlternateContentSourcePath (basemodel) | (*alternate_content_source, path) | Also has a repository relation |
|GenericRelationModel (basemodel) | None | is abstract and has a required object relation. domain requires potentially looking though multiple object relations and could still be None |
|Export(basemodel) | None | has required *Exporter relation and optional Task relation |
|Import(basemodel) | None | has required *Importer relation and Task relation|
|PulpImporterRepository (basemodel) | None | has required *PulpImporter and reposistory relation|
|ProgressReport(basemodel) | None | has required *Task relation|
|GroupProgressReport (basemodel) | (code, *task_group) | has required *TaskGroup relation |
|PublishedArtifact(basemodel) | (*publication, relative_path) | also has a ContentArtifact relation |
|RepositoryContent(basemodel) | (*repository, *content, version_added), (*repository, *content, version_removed) | this a many-to-many through object, allowing cross domain relations seems unwise |
|RepositoryVersion(basemodel) | (*repository, number) | also has an optional relation to a base RepositoryVersion |
|RepositoryVersionContentDetails (django.Models)| None | has a relation to Repositoryversion, would require a double look up |
|UploadChunk(basemodel) | None | has *Upload relation, also has a FileField needs to use the Upload's domain for storage location |

## Objects that get domain through inheritance

| Model(base) | Uniqueness constraint | Notes |
| -------- | -------- | -------- |
|ExportedResource(GenericRelationModel) | None | has required Export relation |can also be used for domain
|FilesystemExporter(Exporter) | name | |
|PulpExport(Export) | None | |
|PulpExporter(Exporter) | name | has many repository relations and optional relation to last PulpExport|
|PulpImport(Import) | None | |
|PulpImporter(Importer) | name | |
|RBACContentGuard(ContentGuard) | name | |
|ContentRedirectGuard(ContentGuard) | name | |
|CreatedReource(GenericRelationModel) | None | has relation to *Task