Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: Add drf-gis fields #38

Closed
wants to merge 2 commits into from
Closed

WIP: Add drf-gis fields #38

wants to merge 2 commits into from

Conversation

jayvdb
Copy link
Contributor

@jayvdb jayvdb commented Apr 25, 2020

Closes #31

@jayvdb jayvdb mentioned this pull request Apr 25, 2020
Copy link
Owner

@tfranzel tfranzel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jayvdb thank you very much for contributing this. have a look at the comments. lets try to reevaluate after those changes but it looks already very promising i think.

assert schema['components']['schemas']['X']['properties']['hash']['format'] == 'byte'


def test_serializer_field_extension_geo(no_warnings):
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please move contib tests to tests/contib/PACKAGE_NAME

also would like to see a full schema test for that. have a look at test_oauth_toolkit for reference. makes it easier to inspect that the generated schema look reasonable.

target_class = 'rest_framework_gis.fields.GeometryField'

def map_serializer_field(self, auto_schema):
return {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use component as discussed here: #31 (comment)


def map_serializer_field(self, auto_schema):
return {
'oneOf': [
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here i guess

'type': {
'description': 'The type of the geos instance',
'type': 'string',
'enum': ['Feature'],
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should be 'FeatureCollection'

@jayvdb jayvdb force-pushed the geo branch 4 times, most recently from 323020f to 3a7823c Compare May 3, 2020 03:47
@codecov
Copy link

codecov bot commented May 3, 2020

Codecov Report

Merging #38 into master will increase coverage by 0.05%.
The diff coverage is 100.00%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master      #38      +/-   ##
==========================================
+ Coverage   96.79%   96.85%   +0.05%     
==========================================
  Files          38       39       +1     
  Lines        2496     2541      +45     
==========================================
+ Hits         2416     2461      +45     
  Misses         80       80              
Impacted Files Coverage Δ
drf_spectacular/contrib/fields.py 100.00% <100.00%> (ø)
drf_spectacular/openapi.py 92.50% <100.00%> (+0.01%) ⬆️
tests/test_extensions.py 100.00% <100.00%> (ø)

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 749dfb6...2ba7de7. Read the comment docs.

@jayvdb jayvdb force-pushed the geo branch 2 times, most recently from 1f611b3 to 2a42819 Compare May 7, 2020 22:35
@tfranzel
Copy link
Owner

tfranzel commented May 8, 2020

hey @jayvdb i can't really tell the difference between the last force pushes. what changed? could you do the remaining change requests so we can wrap this up? thanks

jayvdb added 2 commits May 22, 2020 11:10
Xenial results in
libgdal.so: undefined symbol: OGR_F_GetFieldAsInteger64

Related to tfranzel#31
@jayvdb
Copy link
Contributor Author

jayvdb commented Jun 6, 2020

The pushes are me rebasing my WIP to stay on top of changes to master.
We've had some more testing occur on our side. Still a bit more to do re correctness; then the technical fixes needed.

@jayvdb
Copy link
Contributor Author

jayvdb commented Jul 21, 2020

This is blocked by #130 , as it uses anyOf.

@jayvdb
Copy link
Contributor Author

jayvdb commented Oct 15, 2020

Note that openwisp/django-rest-framework-gis#223 is now progressing, and provides the appropriate basis for this PR.

Please close #67 and let me finish my own PR, rather than merging incomplete PRs like you did with #125. That is basic respect for people contributing to your project.

@tfranzel
Copy link
Owner

that is good to hear! as a matter of fact i have updated (but not yet pushed) my adaptation in #67 a few days ago. I will happily close it if your/their new approach is better, which i believe it will be. in the meantime i will not continue working on #67

regarding #125: i took the liberty of completing your PR because it was stale for months with pending change requests. you indicated that you were too out-of-sync, lacking time, and basically moved on. i decided it was better for the project to finish it myself instead of not having it at all. imho waiting 3 months for a follow-up is hardly disrespecting your contribution.

@jayvdb
Copy link
Contributor Author

jayvdb commented Oct 16, 2020

Out of sync is regarding ability to test your patches against my real systems. It has nothing to do with my ability to complete PRs.

regarding #125: it was stale because it was waiting for you to finish a solution to #101 - you already cookie licked that one. You never gave a reply to #125 (comment) , which was the last exchange there. So who was "waiting 3 months for a follow-up" ?

@tfranzel
Copy link
Owner

fair enough. i'm sorry that the open question fell off my radar. i invested more time in doing a detailed review of #125 (as requested) than actually completing the PR, which seems like quite an inefficient cookie licking tactic. you are of course entitled to your opinion, but i will no longer respond to accusational or passive aggressive comments.

@nemesifier
Copy link

openwisp/django-rest-framework-gis#223 merged and released.

@AndrewGuenther
Copy link

What else needs to happen to get this landed? I'd really like to see support for this.

@jayvdb
Copy link
Contributor Author

jayvdb commented Jul 11, 2021

I think there were a few things in that PR which were deferred to later, and I havent been tracking this closely.
c.f. openwisp/django-rest-framework-gis#223 (comment)

I'll get this rebased next week, and work out the current status of bits outstanding.

@tfranzel
Copy link
Owner

it looks to me that they went with the official recommendation of patching AutoSchema, which is in conflict with our AutoSchema. @jayvdb made the very good point there that this solution simply does not scale well. I frankly do not understand how this recommendation was ever supposed to work for non-trivial cases. If someone is to use 2 different libs (e.g. drf-gis and something else) that each patch AutoSchema, you are already in a deadlock, because they cannot be easily reconciliated.

The core question is whether we can extract their spec from their AutoSchema in a reasonable way without bending backwards too much. @jayvdb suggested a thin wrapper on their side to make their implementation also usable without the AutoSchema. I do not currently know if that was considered or not. It would make things a lot easier.

if we were able to use their implementation, the code in this PR is pretty much obsolete. The likely outcome would be to use Serializer(Field)Extension that extract schema info from their AutoSchema/codebase. @AndrewGuenther i hope that clears things up.

@jayvdb thanks for picking this up again.

@jayvdb
Copy link
Contributor Author

jayvdb commented Jul 11, 2021

I'm going to take a quick look this week, to get a plan in place, but I'll be more focused on Django in a few weeks when I can devote some serious time to it, and likely get some patches into drf-gis building on top of what they have done.

@AndrewGuenther
Copy link

@tfranzel Yeah, that recommendation is quite silly. I had tried to make a change where drf-gis would inherit from DefaultSchema instead, but that leads to circular dependency problems if their generator is the default. There's really just not a great way to go about it that I can see. Maybe if DefaultSchema was smart enough to check that the current class is the default and just turns itself into a no-op? That would take a change both in drf as well as drf-gis to make work, but then wouldn't require any effort here.

Copy link

@auvipy auvipy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would be really a great addition! can the review comments be adressed?

@tfranzel
Copy link
Owner

this PR got superseded by #746. discussion&feedback continues there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

django-rest-framework-gis
5 participants