Project

Profile

Help

Task #2238

Task #1873: Plan REST API for 3.0

Make DRF tools that can represent our generic models via the API

Added by semyers about 3 years ago. Updated 6 months ago.

Status:
CLOSED - CURRENTRELEASE
Priority:
Normal
Assignee:
Category:
API
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

In putting all this API stuff together, I just now realized that I've completely ignored things like the GenericKeyValueMutableMapping that's related to models as the Config/Notes/etc fields. This should be a simple custom field, based on the DRF docs that detail a few different methods of handling generic relations in the api:
http://www.django-rest-framework.org/api-guide/relations/#generic-relationships

History

#1 Updated by semyers about 3 years ago

  • Parent task set to #1873

#2 Updated by semyers about 3 years ago

This should be a simple custom field, based on the DRF docs that detail a few different methods of handling generic relations in the api

Well...sorta?

Since the generic fields we're using right now are exposed as a key/value mapping, I'd really like to see them be exposed that way in the API, as well. DRF support this pretty easily: Make a DictField on your serializers, and then set it's "source" to 'fieldname.mapping', and it then reads is value from the custom mapping field. On the read side, this works perfectly. However, when writing to these fields, things get a little trickier. Somewhat understandably, DRF has no idea how to correctly write values to this field. It santity-checks the "source" value, sees that it's a dotted attribute, and bails out before doing something potentially dangerous.

So, to start, I have created a "GenericKeyValueRelatedField" (or something like that) for us to use when relating to these things. It works well enough in a read_only fashion now, but we'll also need a Serializer base class to eventually support writing to these fields. I'll capture all of this in a task with more detail and some suggestions for resolution, but in terms of "Plan REST API for 3.0", we've got enough to build a plan on so this is probably done depending whether or not the reviewers agree. :)

#3 Updated by semyers about 3 years ago

Admitting default and settling for leaving the field read-only bugged the crap out of me, so after letting it simmer for a few days I had an idea for making read-write in a DRF-friendly and sane way. This is now implemented, with the only issue being that the DRF browser-based API views don't support DictField, so the only way to update this field is by using the API with some other content type (i.e. JSON and XML work perfectly). I was also able to cut down on "trickeration" and instead implement the GenericKeyValueRelatedField as a more "normal" DRF field subclass according to their documented extension methods.

tl;dr woot

#4 Updated by semyers about 3 years ago

semyers wrote:

the DRF browser-based API views don't support DictField

On this topic, I haven't yet checked to see if there are any upstream issues to deal with this. It's a minor thing, since most API users should be using JSON, but if we could add this to DRF I'm sure they'd appreciate it. I plan to look into this later and see how we can either help DRF out or get help from DRF for this.

#5 Updated by semyers about 3 years ago

semyers wrote:

semyers wrote:

the DRF browser-based API views don't support DictField

On this topic, I haven't yet checked to see if there are any upstream issues to deal with this. It's a minor thing, since most API users should be using JSON, but if we could add this to DRF I'm sure they'd appreciate it. I plan to look into this later and see how we can either help DRF out or get help from DRF for this.

And, of course, it's a known issue: https://github.com/tomchristie/django-rest-framework/issues/2485

#6 Updated by semyers about 3 years ago

  • Status changed from ASSIGNED to CLOSED - CURRENTRELEASE

This work is up in a PR in this issue's parent task, #1873.

#7 Updated by daviddavis 6 months ago

  • Sprint/Milestone set to 3.0

#8 Updated by bmbouter 6 months ago

  • Tags deleted (Pulp 3)

Please register to edit this issue

Also available in: Atom PDF