Pulp

This task cannot be started until the documentation written in #1873 is merged to 3.0-dev.

This task should be considered complete when all serializers for a given models module are defined in a corresponding serializers module.

The serializers defined should expose fields "native" (defined directly on a model or in its superclasses) to the model being represented, including Generic Key/Value types (Config/Notes/Scratchpad). Relations to other models should be included where possible, but the available serializer base classes and fields may be insufficient, so only the "native" fields should be required.

This task is among several similar tasks to stub out serializers for our existing models. Please spread the work around so we gain more team-wide knowledge around these serializers. If you have any questions, ask me. Common issues and their resolutions will be added to the pulp 3.0 rest-api development guide.

Is the following correct?

• We do not need serializer for ContentAdaptor model because its fields will be serialized in Importer/Publisher serializers.
• We do not need serializer for RepositoryContent model because we won't access this model directly, it is a through model. We are going to set relations specified in it via ContentViewset and read this info via RepositoryViewset or ContentViewset.

ttereshc wrote:

Is the following correct?

• We do not need serializer for ContentAdaptor model because its fields will be serialized in Importer/Publisher serializers.

Maybe true! If it's useful to create an abstract ContentAdaptor to define the fields that should be included on all Model subclasses, though, then it makes sense to create a similar serializer that only gets used abstractly by all ContentAdaptorSerializer subclasses. Since all ContentAdaptors have at least a name and 0 or more related repositories, I think it may be worthwhile to have a ContentAdaptorSerializer.

• We do not need serializer for RepositoryContent model because we won't access this model directly, it is a through model. We are going to set relations specified in it via ContentViewset and read this info via RepositoryViewset or ContentViewset.

I'm not really sure how best to handle this. I have some ideas, I think Austin has some other ideas, but I think the best thing right now might be to leave it out, and figure out how to work in the timestamp stored on this through model later. From an API standpoint, I think we definitely want to be able to filter repository content by this timestamp, and we'll definitely want to include it in some view, somewhere. I'm just not sure about the specifics, and think this is an easy enough one to do that we can avoid having to do it right now.

Since all ContentAdaptors have at least a name and 0 or more related repositories, I think it may be worthwhile to have a ContentAdaptorSerializer.

I agreed initially but now I am thinking that maybe it makes sense to have those common fields specified in each ContentAdaptor, this way we will be able to be more specific in the `help_text`: "name of the importer" or "name of the publisher" rather than just "name of the content adaptor". So I will leave this one as well. It should be very easy to create it and refactor importer/publisher later if needed.