Django-rest-framework: Camel-case model field names

[jacobg]

The convention for Django model field names is to underscore them, while the convention for Javascript variables is camel-case. It would be great for DRF to automatically convert between the two.

More on this issue in this thread:
https://groups.google.com/forum/#!searchin/django-rest-framework/camelcase/django-rest-framework/jpb2NNpAMto/tFOt5dD_9NEJ

Tom suggested the following solution in that thread:

_Something along the lines of a 'get_field_name' on the serializer class that can be overridden, and a setting that defines the default function and allows secs to switch to a different default style._

[johtso]

I wanted to do exactly the same thing. I ended up implementing it as a custom JSON(Parser/Renderer).

This is what I came up with: https://gist.github.com/johtso/5881137

[vbabiy]

I also did that same thing, and it works perfectly: https://gist.github.com/vbabiy/5842073

[Salmatron]

+1 a setting for this would be great!

[tomchristie]

Given that @vbabiy's approach works without needing to make any further changes to REST framework, I'm currently pretty tempted to close this off and suggest that if anyone needs this, then package that approach up nicely and we'll link to it from the docs.

[carltongibson]

I finally looked at @vbabiy's gist — it looks spot on.

Aside: Part of me thinks a whole package might be overkill for just a simple class — I like to write _some_ code. I'm tempted to say we need some board to act as a repo for good ideas like this BUT between searching here, the Google Group and Stack Overflow we already have it. (I wonder if there's an easy way of unifying that search...)

I'm going to push the boat out and close this one.

[tomchristie]

@carltongibson I reckon we could recommend the 'django snippets' site for things like this, and link to them from the main docs. (Unless/until anyone wants to take on a cookbook site as has been mentioned a few times)

[vbabiy]

I don't hate the idea of creating a package to make it easy for people to add it to their setup. And linking to the package docs from the docs.

[tomchristie]

@vbabiy Wither way is fine from my POV. Packages preferable, but also ok if someone would rather just post a snippet.

[vbabiy]

I create a new package: https://github.com/vbabiy/djangorestframework-camel-case

[tomchristie]

Aces! Nice work @vbabiy :). Wanna PR adding links to it from the renderer/parser third party packages docs?

[vbabiy]

@tomchristie added #1310

[hwkns]

FWIW, this seems like a common enough use case (I'd guess that JS, Java, and Swift are probably the most popular consumers of DRF endpoints), and the code to implement it is small enough, that it merits being part of the DRF project, rather than a separate dependency (which forces end users to keep up with version matching between dependencies and vetting whether or not the camel case project still works).

Apologies for the comment on a dead issue, but I didn't want to create a new one.

[yhuanghamu]

I am surprised that it has been 5 years, and django rest still doesn't support this feature.

[xordoquy]

@yhuanghamu what are you referring to ? It seems there's already a package to support it.

[dakotahawkins]

@xordoquy It looks like it's infrequently updated and even so contains fixes not published to the package.

In fact it has more than one fork, all made at some point to attempt to resurrect it, and some of those even have forks themselves made for the same apparent reason. Based on the issues/PRs spread across all of them it doesn't seem like there's a package I'd be willing to trust enough to use :(

[xordoquy]

Thanks @dakotahawkins for the clarification.
I still don't think there's enough traction (as the package seems unsupported) to add it to DRF core as opposed to the work it adds.
In my opinion, the solution is simple enough and can be adapted if the existing package doesn't exactly match a project's requirements.

[dakotahawkins]

@xordoquy I think the feature probably fits best in DRF core, but not by simply adding one of the (old) existing solutions. It would take some work to address concerns raised in the various packages, but at least I think the result would be trustworthy in the longer term.

The main reason I think it'd be good for DRF is to prevent mistakes with other DRF features. I think having to explicitly re-declare serializer fields just to change field names from "pythonic" to "jsonic" invites a lot of mistakes in the construction of the fields that might otherwise get the intended behavior by default.

In particular, I think the following is true and also non-obvious:

# account_name is read-only
class AccountSerializer(serializers.ModelSerializer):
    class Meta:
        model = Account
        fields = ('id', 'account_name', 'users', 'created')
        read_only_fields = ('account_name',)

# accountName is NOT read-only
class AccountSerializer(serializers.ModelSerializer):
    accountName = CharField(source='account_name')
    class Meta:
        model = Account
        fields = ('id', 'account_name', 'users', 'created')
        read_only_fields = ('account_name',)

I might be wrong, I haven't been doing this that long, but I experienced something very like that, found a closed issue about it, and then remembered to be careful. In my case I didn't change any of the field names, but had to construct a few for other reasons and tried to use something like read_only_fields = fields, which didn't work for the explicitly constructed fields.

I'm not saying the lack of this feature is a deal-breaker or super-critical, since there are workarounds. I'm just saying it would make the most sense to me if the option were maintained as a part of DRF. Feel free to disagree or correct me if the example above isn't correct!

[carltongibson]

I don't see why this keeps coming up. _"Use a custom renderer"_ (and parser too) is the advice. Sure enough that's exactly what the package contains. If it's unmaintained, fork it, merge the PR yourself. (Welcome to Open Source.) There's no enough code there that you can't just pull it into your project wholesale.

[dakotahawkins]

@carltongibson

I'd suggest it comes up because it seems like it would be in the wheelhouse of this project. For my part, I've been working with all of this for a very short time, and in my estimation doing it myself isn't worth the added risk (though I'm no stranger to Open Source, I'm just not really a web developer).

If an available package was maintained/used enough for me to trust them, I'd probably be trying it.

Don't get me wrong, I don't want to sound like I'm making demands or anything. I'm just chiming in to say I _wish_ it were either built-in to DRF or better maintained elsewhere.

[xordoquy]

@dakotahawkins it's been a pleasure for me reading your thoughts and discuss with you.
I agree it would be a nice to have feature included with core and I'm sorry to notice that the package for that feature needs more love/work.
However adding more features to DRF core means more overall work and increase the risk of burnout for the maintainers. One of the reason we try to keep the core as lean as possible and resist so much to add things to core itself.

[dakotahawkins]

@xordoquy Thank you, and I certainly understand that. At the very least I feel this discussion is helpful to others who (like me) wonder for the first time if anybody else has had the same issue they've had!

It was reassuring and helpful to me to find recent comments on this issue, even if it remains closed forever, so thank you and @carltongibson for checking back in here again :)