Visibility leaves dangling types
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 25/100
- issue の種類
- 機能追加
- 明瞭さ
- 説明が足りない
- 活発さ
- 停滞
- 技術スタック
- graphql, ruby
調査の方向性
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.
索引モデルが issue の本文から書いたものです。
説明
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?
- 主要言語
- Ruby
- スター
- 5.4k
- フォーク
- 1.4k
- 平均マージ
- 1日 8時間
- マージ済み PR（30日）
- 74
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
rmosolgo/graphql-ruby のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
rmosolgo/graphql-ruby#5843 ·
メンテナーはふだん 1 日以内に返信
-
難易度 3/5 1〜2日 初心者へのやさしさ 55/100
rmosolgo/graphql-ruby#5763 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 45/100
rmosolgo/graphql-ruby#5761 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 52/100
rmosolgo/graphql-ruby#5707 · コメント 10 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 3/5 1〜2日 初心者へのやさしさ 30/100
rmosolgo/graphql-ruby#5655 · コメント 4 件 ·
メンテナーはふだん 1 日以内に返信
rmosolgo/graphql-ruby の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
heartcombo/simple_form#1874 ·
-
Category: OneSwap Status: Accepted
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
OpenNebula/one#8237 ·
-
enhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
AllYourBot/hostedgpt#882 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
greenelab/lab-website-template#357 · コメント 1 件 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
open-feature/ruby-sdk-contrib#283 ·
メンテナーはふだん 1 日以内に返信