graphql-core coerce_string used instead of graphene.String
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 35/100
Hướng nghiên cứu
Bắt đầu bằng cách theo dõi việc xử lý scalar qua graphene/types/schema.py và so sánh graphene/types/scalars.py với graphql/type/scalars.py. Tái hiện trường hợp HttpUrl bằng graphene.test.Client.execute, sau đó xác định liệu bản sửa dự kiến là giữ nguyên cơ chế cưỡng chế kiểu của graphene.String hay căn chỉnh nó theo graphql-core. Công việc được xem là hoàn tất khi hành vi và cơ chế cưỡng chế kiểu dự kiến được bao phủ bởi một regression test.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Note: for support questions, please use stackoverflow. This repository's issues are reserved for feature requests and bug reports.
- What is the current behavior?
Not 100% sure this is a bug, but it seems not quite right.
graphene.String has the following coerce_string method:
https://github.com/graphql-python/graphene/blob/master/graphene/types/scalars.py#L144
This should mean that any value that is resolved via a graphene.String field gets cast to str
In contrast, graphql-core has this coerce_string method:
https://github.com/graphql-python/graphql-core/blob/a2d52df815f81a62649ee637999fc241af1e67a3/src/graphql/type/scalars.py#L176
...note that in graphql-core any value which passes an isinstance(val, str) check will not get cast to str.
I noticed this because I am using pydantic HttpUrl type in my parent object, the value is an HttpUrl instance (which passes an isinstance(val, str) check).
I noticed in my test cases that the HttpUrl value passes untouched through the graphene.test.Client.execute flow.
Looking at the graphene src this was puzzling because it seemed like it should get cast down to a plain string.
Stepping through with ipdb, I could see in complete_value method:
ipdb> pp result
HttpUrl('https://example.com/test-url, scheme='https', host='example.com', tld='com', host_type='domain', path='test-url')
ipdb> return_type
<graphql.type.definition.GraphQLScalarType object at 0x1059876a0>
ipdb> import inspect
ipdb> inspect.getsource(return_type.serialize)
'def coerce_string(value):\n # type: (Any) -> str\n if isinstance(value, string_types):\n return value\n\n if isinstance(value, bool):\n return u"true" if value else u"false"\n\n return text_type(value)\n'
ipdb> inspect.getsourcefile(return_type.serialize)
'/lib/python3.8/site-packages/graphql/type/scalars.py'
...so we have a graphql-core field rather than a graphene one, which explains why the cast to str didn't happen.
I am guessing it may be due to this code:
https://github.com/graphql-python/graphene/blob/f039af2810806ab42521426777b3a0d061b02802/graphene/types/schema.py#L148
Which raises the question... are the methods on graphene.String and friends just dead code?
Or if they're still used in some other circumstance, should they maybe delegate to corresponding graphql-core methods for sake of consistency, rather than having their own subtly different implementation?
If I change my type def to:
import graphene
class HttpUrl(graphene.String):
pass
class MyParent(graphene.ObjectType):
some_url = HttpUrl(required=True)
...then I get the graphene casting behaviour, again I think because we fall thru this check https://github.com/graphql-python/graphene/blob/f039af2810806ab42521426777b3a0d061b02802/graphene/types/schema.py#L148 and don't substitute a graphql-core type.
In the end this behaviour didn't break anything for me, but it's probably possible to imagine a scenario where it would.
- Ngôn ngữ chính
- Python
- Star
- 8.2k
- Fork
- 822
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của graphql-python/graphene
-
Tutorial mistakesĐang mở🐛 bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
graphql-python/graphene#1389 · 5 bình luận · 2 reaction ·
-
Support OneOf input object typesĐang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 68/100
graphql-python/graphene#1606 ·
-
Python 3.14 supportĐang mở✨ enhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 38/100
graphql-python/graphene#1601 · 2 bình luận ·
-
✨ enhancement
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 42/100
graphql-python/graphene#1600 ·
-
Inaccurate Float-to-Decimal Conversion in `parse_value` of `Decimal` `Scalar`Có thể đã có người làm @mak626 đã nhận 606 ngày trước. Đang mở🐛 bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 55/100
graphql-python/graphene#1593 ·
Tất cả issue của graphql-python/graphene
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
aicell-lab/bioengine#232 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
modelscope/evalscope#1836 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
-
bug
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
jbaruch/speaker-toolkit#480 ·
Maintainer thường phản hồi trong vòng 1 ngày