Don't force translation of request attribute names

[amw]

This attribute key translation was advertised to be "off by default", but was in fact forced in parser. This commit makes it so that request attributes and relations are only translated back to snake_case format if JSON_API_FORMAT_KEYS setting is set.

I'm not mad – I don't have my model/serializer attributes named someField or SomeField. My use case is quite simple: I have a JSONField where I accept some black-box content for storage. I need to be able to return the data as it was submitted to me by users of the API.

[codecov-io]

Codecov Report

Merging #284 into develop will decrease coverage by <.01%.
The diff coverage is 100%.

@@             Coverage Diff             @@
##           develop     #284      +/-   ##
===========================================
- Coverage    76.35%   76.34%   -0.01%     
===========================================
  Files           50       50              
  Lines         6014     6021       +7     
===========================================
+ Hits          4592     4597       +5     
- Misses        1422     1424       +2

Impacted Files	Coverage Δ
rest_framework_json_api/parsers.py	54.04% <100%> (ø)	⬆️
example/api/serializers/identity.py	85.71% <0%> (-14.29%)	⬇️
example/models.py	67.52% <0%> (+0.17%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cdb8a52...2c8f50d. Read the comment docs.

[jerel]

This change looks good to me. However I suppose it should go in the next major release since it changes default behavior.

[amw]

@jerel Is there a timeline for this?

[jerel]

@amw not really, would it help you out if it was merged soon or are you working from your fork? I'm guessing there's other things that we should include in a v2.2 but don't have to

[amw]

I am working from a fork, but it would comfort me if you had a current-release branch and next-release branch. Having this merged into next-release branch would:
– prevent the PR from diverging and getting conflicts
– make me worry less that this will accidentally be omitted
– allow me to point my package install to your next-release branch and get other fixes that you apply in between now and next major release (which as you said doesn't even have the timeline)

[mblayman]

Hi all, since this PR is quite old now and seems to have stalled, I'd like to consider closing this PR unless it finds a champion who can bring it to closure.

What needs to be done to bring this to a conclusion?

[amw]

I'm not sure what's the reason this has stalled. I thought it was scheduled for 2.2, but that has come and gone. I think we should just merge it.

[mblayman]

After looking at this a bit more closely, it appears that this fixes a behavior that wasn't working as expected so I'm happy to merge it. Before I merge this, may I make a couple of requests?

• Could you start a section in the CHANGELOG for v2.3.0 and put an appropriate line for this fix?
• Could you add yourself to the AUTHORS file? This project has moved to be more community maintained and I'd like to see each contributor recorded there for their efforts. I don't care if you include your email or not, but I thinking adding your name would be a nice addition.

[amw]

I had to revise my PR. My initial version used the same conversion that was specified by JSON_API_FORMAT_KEYS, but that didn't make any sense. If you have attribute author_name and you set conversion to camelize then you generate authorName in API responses. In the other direction you want to read requests that contain authorName and translate it back to Django's author_name.

So I've left original author's underscore as the only possible request translation format, but I only use it when JSON_API_FORMAT_KEYS is set (default is off).

I've added changelog and authors entry. I don't want to give my email in plain text so I've used what is common in Django's AUTHORS file – website address. There is info that people can use to contact me.

[mblayman]

Thanks. I totally understand not wanting to put your email address. I don't like doing that either for the same reason you described. Thanks for adding your name.

[mblayman]

Could you move this import line above the rest_framework lines without a newline between them? This project groups third party libraries together alphabetically.

[amw]

I've actually copied the style applied here from utils.py file:
https://github.com/django-json-api/django-rest-framework-json-api/blob/develop/rest_framework_json_api/utils.py

[mblayman]

Yeah, the style is a bit of a mess because it's not consistent. Don't worry about it. I created issue #344 after I left this comment above so it can be cleaned up in the future. I'll get this line later.

[amw]

I recommend using isort for this kind of churn. Give it a try.

[mblayman]

👍 This looks good to me. Thanks for being patient with this and for your contribution. Once the import is moved as commented, I'll merge the PR.