Project

Profile

Help

Story #2672

As a user, I can associate content with repositories using the content API

Added by semyers over 2 years ago. Updated 6 months ago.

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

0%

Platform Release:
Blocks Release:
Backwards Incompatible:
No
Groomed:
No
Sprint Candidate:
No
Tags:
QA Contact:
Complexity:
Smash Test:
Verified:
No
Verification Required:
No
Sprint:

Description

Now that we've got a plugin with "real" content types (pending completion of #2454), we're able to do some tinkering around in the API to see what works and what doesn't.

So far, the only thing I've found that doesn't work via the API is attempting to associate a content unit with repositories when creating content units. The "repositories" field is current exposed and writable, but attempting to create a unit with references to repositories results in an error like this:

AttributeError at /api/v3/content/file/

Cannot set values on a ManyToManyField which specifies an intermediary model. Use pulp.RepositoryContent's Manager instead.

This is true, the addition of the "updated" timestamp field to the explicitly defined RepositoryContent model means that we lose the ability to use the 'add' and 'remove' method on the related manager:
https://docs.djangoproject.com/en/1.8/topics/db/models/#intermediary-manytomany

It would be pretty nice to be able to handle this association right on the content unit, and not have to expose RepositoryContent in the API directly, since that's an unfriendly workflow (create repo, create content, associate content with repo vs. create repo, create content associate with repo, and similar usability benefits for adding a repo to a content unit's list of repos).


Related issues

Related to Pulp - Story #2873: As an authenticated user, I can associate a Content unit with a Repository CLOSED - CURRENTRELEASE Actions

History

#1 Updated by semyers over 2 years ago

There are a few options for fixing this, which I'll outline.

  1. Stop using the RepositoryContent through model, allowing Django to automatically create it. Associate extra data on the repo/content associate through a separate model whose values are able to be determined any time a repo/content associate is made, and saved to this separate model's table via signals.
  2. Modify the 'add' and 'remove' remove methods directly on the ManyRelatedManager/ReverseManyRelatedManager to disable the check for our use of a through model with extra data, and ensure the correct values for any extra data are set on the model prior to saving.
  3. Modify the Content serializer's save operations to correctly create/delete RepositoryContent records, rendering the implementation detail of extra data that we store on this relationship invisible to API users.
  4. Something I've missed here.

Of these, I think Option 2 looks like it's the best, but might not be. Implementing it would mean that both the API and Django's own model API available to application developers will "just work", and we can all but ignore the existence of the extra data (currently just the "updated" timestamp") stored on the RepositoryContent relationship, except when we explicitly need it during publishing. However, as far as I can tell, Django 1.8 does not make it easy to customize the behaviors of its ManyRelatedManagers, so modifying the behaviors of .add and .remove might be prohibitively risky and unmaintainable.

Option 1 is very simple, but comes at the potential cost of an additional join done when looking up the extra data, as well as the very real cost of keeping the "extra data" table up to date with Repo/Content associations, including the cost of getting it wrong and ending up with inconsistent data.

Option 3 is less friendly to developers, since you no longer add units to a repository using the django-provided interface. It should be very straightforward, and assuming we provide our own interface for managing the addition/removal of content from a repository that correctly sets any related timestamps, it should also be the easiest and least risky one to implement.

Throughout this entire storywriting process, I've referred to the timestamp on the RepositoryContent model as "updated", but actually it's "created". Please pardon the confusion there.

#2 Updated by bmbouter over 2 years ago

  • Tags Pulp 3 added

#3 Updated by bizhang over 2 years ago

  • Tags Pulp 3 Plugin Writer Alpha added

#4 Updated by amacdona@redhat.com over 2 years ago

  • Duplicated by Story #2873: As an authenticated user, I can associate a Content unit with a Repository added

#5 Updated by amacdona@redhat.com over 2 years ago

  • Duplicated by deleted (Story #2873: As an authenticated user, I can associate a Content unit with a Repository)

#6 Updated by amacdona@redhat.com over 2 years ago

  • Related to Story #2873: As an authenticated user, I can associate a Content unit with a Repository added

#7 Updated by bmbouter almost 2 years ago

  • Tags deleted (Pulp 3 Plugin Writer Alpha)

#8 Updated by amacdona@redhat.com 11 months ago

  • Status changed from NEW to CLOSED - WONTFIX

This all changed with repository versions. Content is associated by a POST request to create a new RepositoryVersion.

#9 Updated by daviddavis 6 months ago

  • Sprint/Milestone set to 3.0

#10 Updated by bmbouter 6 months ago

  • Tags deleted (Pulp 3)

Please register to edit this issue

Also available in: Atom PDF