<div dir="ltr"><div>I've been working on supporting tags in Pulp 3[0] and have gotten some feedback from various other developers. I'd like to open up the discussion though to a broader audience and see if anyone has any feedback.</div><div><br></div><div>Background:</div><div><br></div><div>Currently in Pulp 2, there are two types of task tags: action and resource. Action tags indicate the action being performed (sync, publish, etc), while resource tags indicate the resource type (repository, publisher, etc) and the resource id of the resource being acted upon.</div><div><br></div><div>Proposal:</div><div><br></div><div>In Pulp 3, we ought to get rid of tags. For action tags, we'll simply add a field named "name" to the task table. This will store information about which action the tag is performing (sync, publish, etc).</div><div><br></div><div>For resource tags, these will be replaced with Task Resources. Like resource tags, these will be a one-to-many relationship to tasks (ie a task will have many task resources). These Task Resources then have a one-to-one generic relation[1] to any object in Pulp that a task can act on.</div><div><br></div><div>Database Tables:</div><div><br></div><div>Task</div><div>---</div><div>...</div><div>name - varchar</div><div><br></div><div>TaskResource</div><div>---</div><div>id - uuid</div><div>task_id - uuid (foreign key to a task)</div><div>content_type - varchar (e.g. "Repository")</div><div>object_id - uuid (generic foreign key to a repo/publisher/etc)</div><div><br></div><div>Rest API:</div><div><br></div><div>For task names, this field will be returned when querying tasks and can also be filtered, etc when searching tasks. Pretty straightforward.</div><div><br></div><div>For Task Resources, I'm imagining that there won't be a separate API for Task Resources. Instead, task resource information will be returned along with tasks in a list field such as "resources." This presents a bit of a problem though: each resource will have different data depending on the type of resource (repo, publisher, etc)[2]. Alternatively, we could return a homogeneous list of hashes with fields like type (Publisher/Repository, etc), id, and href. However, I think this is less useful to users.</div><div><br></div><div>For filtering, I think it would be possible to filter on content_type and object_id in Task Resource but I think this would be inconvenient for users. I think it would be easier if we define some shortcuts (e.g. repository_id, publisher_id, etc) that users can use to filter on. I'm imagining one such id filter for every possible content_type.</div><div><br></div><div><br></div><div>Thoughts on this design?</div><div><br></div><div>[0] <a href="https://pulp.plan.io/issues/2482">https://pulp.plan.io/issues/2482</a></div><div>[1] <a href="https://docs.djangoproject.com/en/1.11/ref/contrib/contenttypes/#generic-relations">https://docs.djangoproject.com/en/1.11/ref/contrib/contenttypes/#generic-relations</a></div><div>[2] <a href="http://www.django-rest-framework.org/api-guide/relations/#generic-relationships">http://www.django-rest-framework.org/api-guide/relations/#generic-relationships</a></div><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br></div><div>David<br></div></div></div></div></div></div></div></div>
</div>