I don't think we can run with this.
If you want to go outside the interop and use the API docs with that, then yes, you need to customize the schema generation. (I don't think having string by default for BigAutoField is going to be acceptable as the default tho.)

Addressing #5007 would at least error loudly when you hit this case. We could also put a "max_value" on the schema field, which, if we validated it in the interaction form would prevent the request from being made in the first place.

@tomchristie The question is: why is AutoField so special that it needs special treatment in documentation API? Serializers make great work there and validation should rely on them and not on hardcoded magic. And the worst thing that it is the "magic" which cannot be easily adjusted.

Maybe I don't see all the reasons behind this design , but this change has only impact on documentation API and event removing the hardwired mapping between AutoField and integer would be better then restricting valid values of BigAutoField (I think there were some reasons why this type was created). IMO this is a bug not a feature.

Sorry for my English.

There's nothing "special" about autofield/bigautofield, it's just that they are integers, and our API schemas should represent them as such.

(With the edge-case exception of folks who need to operate outside the tremendously large interop range, that JSON cannot handle.)