OpenAPI Schema Generation

[dhaval-mehta]

Hi @auvipy,

This fixes: #219, #237

You requested to wait for 3.12 Release. I will write code in such a way that it will be compatible will 3.12 Release.

This will close: #186 and #219

[auvipy]

OK

[dhaval-mehta]

Hi, @auvipy Whenever you are free time, please review code quality.
Now, I will work on Testcases and Documentation.

I do not know how to generate schema for models.GeometryField & models.GeometryCollectionField. Please provide guidance for the schema generation for these fields.

[auvipy]

@sir-sigurd would you mind sharing your insight on this? I saw you contribute a lot on geodjango front :)

[compacq]

#````````

_{Sent with GitHawk}

[dhaval-mehta]

why?

These commits are no longer required. #248 fixes PostgreSQL integration problem.

[dhaval-mehta]

@auvipy Gentle reminder. I have merged the latest master.

[nemesifier]

Great progress @dhaval-mehta!

I left some comments below.

Anyone else here using/testing this who would like to leave feedback? @jayvdb @auvipy

[nemesifier]

I guess the only way to get feedback on this feature is to publish it and see what happens, @dhaval-mehta will you stick around to help us maintain it?

[dhaval-mehta]

I guess the only way to get feedback on this feature is to publish it and see what happens, @dhaval-mehta will you stick around to help us maintain it?

Sure. It will be my pleasure to maintain this project.

[nemesifier]

@dhaval-mehta your work is now released! I expect feedback from users of this library in the coming months.
I sent you an invite to have write access to this repository in the hope that you can help us maintain this feature as feedback from users comes in.

Pushes to master are restricted to admins, but pushes to other branches are allowed 👍.

[dhaval-mehta]

I will ask my network to test this as well. It will help us to improve the schema generation quickly.

[dhaval-mehta]

@dhaval-mehta your work is now released! I expect feedback from users of this library in the coming months.
I sent you an invite to have write access to this repository in the hope that you can help us maintain this feature as feedback from users comes in.

Pushes to master are restricted to admins, but pushes to other branches are allowed 👍.

Thank you so much for providing me this opportunity. It would be my pleasure to contribute to this repo.

[christiaan-dockbite]

Requiring users to set REST_FRAMEWORK.DEFAULT_SCHEMA_CLASS to a custom GIS specific class will limit the utility of this. The default DRF schema generator is rarely used for serious projects because there are so many unsolved problems in it. Most medium to large projects will use drf-yasg, or similar (including drf-spectacular which is new but quite good), and they use their own mechanism, either requiring that DEFAULT_SCHEMA_CLASS is set to their own class, or they ignore DEFAULT_SCHEMA_CLASS altogether. And many projects need to sub-class DRF's AutoSchema to add their own behaviour. I've tried to do a WIP for drf-spectacular to use the standard AutoSchema inheritance at tfranzel/drf-spectacular#46 , but it has has some curly problems.

Keeping GeoFeatureAutoSchema is ok, but it would be better as a thin wrapper only, using functionality that exists outside of the class.

i.e. the schemas and functions that are embedded here inside this class should be in the module namespace, so they can be used with other generators. The code in this custom AutoSchema only uses self. to reference the new code below -- it doesnt rely on any of the inner workings of DRF AutoSchema.

@dhaval-mehta Is there any way now that the schema generation is compatible with other schema generators, such as drf-spectacular? If not, is there a way we can make it compatible?

[dhaval-mehta]

Requiring users to set REST_FRAMEWORK.DEFAULT_SCHEMA_CLASS to a custom GIS specific class will limit the utility of this. The default DRF schema generator is rarely used for serious projects because there are so many unsolved problems in it. Most medium to large projects will use drf-yasg, or similar (including drf-spectacular which is new but quite good), and they use their own mechanism, either requiring that DEFAULT_SCHEMA_CLASS is set to their own class, or they ignore DEFAULT_SCHEMA_CLASS altogether. And many projects need to sub-class DRF's AutoSchema to add their own behaviour. I've tried to do a WIP for drf-spectacular to use the standard AutoSchema inheritance at tfranzel/drf-spectacular#46 , but it has has some curly problems.
Keeping GeoFeatureAutoSchema is ok, but it would be better as a thin wrapper only, using functionality that exists outside of the class.
i.e. the schemas and functions that are embedded here inside this class should be in the module namespace, so they can be used with other generators. The code in this custom AutoSchema only uses self. to reference the new code below -- it doesnt rely on any of the inner workings of DRF AutoSchema.

@dhaval-mehta Is there any way now that the schema generation is compatible with other schema generators, such as drf-spectacular? If not, is there a way we can make it compatible?

This implementation is compatible with all libraries which are compatible with DRF schema generation.
As per my knowledge, implementation of drf-spectacular is not compatible with DRF's schema generation. Hence I think, there is no way to make it compatible with drf-spectacular.

tfranzel/drf-spectacular#38 This PR is open. This can bring support for open API schema generation for drf-spectacular.

[auvipy]

drf-specticular need to upgrade its code to drf openAPI 3.0+

[stefangeorg]

This needs to return the params. It is throwing an error in drf spectacular

[auvipy]

this implementation is not based on DRF spectacular btw

[stefangeorg]

@auvipy yes but check all implementations of get_schema_operation_parameters, they all return data. This is the only one that does not. Settings params inside of get_schema_operation_parameters and then not returning it also does not make sense since no one can access these parameters, since they are not set on self or returned. It is a get function, which should return something. In this case the params.

[auvipy]

are you up for making a contribution? I will review it