[Django] CompositePrimaryKey isn't supported

[rachel-mack]

Pull Request Info

PR Reviewing Guidelines

JIRA - https://jira.mongodb.org/browse/DOCSP-49585

Staging Links

limitations-upcoming

Self-Review Checklist

• Is this free of any warnings or errors in the RST?
• Did you run a spell-check?
• Did you run a grammar-check?
• Are all the links working?
• Are the facets and meta keywords accurate?

[netlify]

✅ Deploy Preview for docs-django ready!

Name	Link
🔨 Latest commit	b02ce33
🔍 Latest deploy log	https://app.netlify.com/sites/docs-django/deploys/681badb18d89a50008c1bce4
😎 Deploy Preview	https://deploy-preview-31--docs-django.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[norareidy]

LGTM - this page is reformatted by #27 so I'll add this change to that PR as well

[timgraham]

This should be part of a larger commit to update the docs for Django 5.2.

(Incidentally, does the commit message need a [Django] prefix? This is, after all, docs-django!)

[rachel-mack]

@timgraham we often do smaller changes as they come up, and then everything gets release the next time we publish.
And the [Django] prefix is for the docs team to sort things - you'll notice the associated Jira ticket is part of the DOCSP project, which includes all of our work.

But per Nora's comment, we'll be closing this in favour of #27 because she's done some extensive reformatting.

[timgraham]

My suggestion is that with multiple versions of the documentation, making all the updates for a given version of Django will make it less likely to forget something (and easier for me to review in one go) and to inadvertently backport something to an older version of the docs where it doesn't apply. Putting this change in the documentation for Django 5.1 doesn't make sense because this feature doesn't exist there.

[norareidy]

My suggestion is that with multiple versions of the documentation, making all the updates for a given version of Django will make it less likely to forget something (and easier for me to review in one go) and to inadvertently backport something to an older version of the docs where it doesn't apply. Putting this change in the documentation for Django 5.1 doesn't make sense because this feature doesn't exist there.

For some context: The "master" branch of this repository corresponds to the "upcoming" docs version. So this PR would only add the 5.2 changes to upcoming, not to 5.1. The "v5.1" branch stores the 5.1 docs. For version releases, out usual process would be to merge everything for 5.2 into master; then, once the version is released, we cut a new branch (v5.2) from master and that becomes the new "current".

[timgraham]

To my thinking, documentation corrections and enhancements may also be backported to v5.1 and/or v.5.0 as appropriate, so that's why I'd keep changes for 5.2 separate from other changes that could be backported, like reformatting the limitations table (#27).