Visibility leaves dangling types
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 25/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Cần làm rõ
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- graphql, ruby
- Lĩnh vực
- api, backend-api-design
Hướng nghiên cứu
No files, tests, or entry points are named. Start by comparing how Visibility and Warden resolve interface and object fields, then examine how dangling objects, interfaces, fields, and implementations are retained. Done requires a decided middle ground that preserves Visibility's advantages while enforcing the stated schema guarantees.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Not sure if this is a bug or not... it looks like Visibility and Warden put different priority on fields belonging to objects and interfaces. Consider:
interface Sprocket {
size: Int # Interface implements field as public
}
type Widget implements Sprocket {
size: Int # Object implements field as private
}
It looks like Warden would resolve Widget.size as public, because the interface would have the final say on its fields. With Visibility it seems the object field has final say and goes private.
In some ways the Visibility implementation makes sense because the more specific implementation wins, EXCEPT – we're allowing the object to renege on its interface. This turns into a footgun that allows developers to compose invalid schemas; best case scenario the more restrictive override should probably error.
I'm seeing echoes of this in other places with dangling objects and interfaces left in the schema without fields or implementations. On one hand this is a feature of faster visibility, on the other hand it's an open door for sloppy mistakes. I'm curious if there's a middle ground here that capitalizes on Visibility advantages while also enforcing strong schema guarantees, even if only in certain circumstances?
- Ngôn ngữ chính
- Ruby
- Star
- 5.4k
- Fork
- 1.4k
- Merge trung bình
- 1 ngày 8 giờ
- Pull request đã merge (30 ngày)
- 74
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
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 rmosolgo/graphql-ruby
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
rmosolgo/graphql-ruby#5843 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 55/100
rmosolgo/graphql-ruby#5763 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 45/100
rmosolgo/graphql-ruby#5761 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 52/100
rmosolgo/graphql-ruby#5707 · 10 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 30/100
rmosolgo/graphql-ruby#5655 · 4 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của rmosolgo/graphql-ruby
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
heartcombo/simple_form#1874 ·
-
Category: OneSwap Status: Accepted
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
OpenNebula/one#8237 ·
-
Reconfigure Settings sidebarĐang mởenhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
AllYourBot/hostedgpt#882 ·
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 65/100
greenelab/lab-website-template#357 · 1 bình luận ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
open-feature/ruby-sdk-contrib#283 ·
Maintainer thường phản hồi trong vòng 1 ngày