Hacktoberfest 2026:維護者為十月標記出來的 issue,仍然開放、適合新手。 瀏覽 Hacktoberfest issue

orderby enum should not contain complex types OR should project sub-properties that are not complex types

未關閉
#613 0 則留言 1 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

還沒有人認領這個 Issue。

評估

難度
5/5
預估耗時
一週以上
新手友好度
35/100
Issue 類型
功能
描述清晰度
基本清楚
活躍度
停滯
技術堆疊
csharp
領域
api

研究方向

首先追蹤 GET /me/calendar/events 的中繼資料如何產生 orderby enum,以及 complex 或 entity 屬性在哪裡分類。比較這兩種提議的行為,包括巢狀深度和產生常數時對斜線的處理。完成的標準是專案已有一項確定且經過測試的規則,可避免建議服務無法使用的 orderby 值。

由索引模型根據 Issue 內容生成。

描述

priority:p1 type:bug

for GET /me/calendar/events we currently project an enum value of start and start desc.
This ends up failing on the service because the start property is a complex type and cannot be used for ordering.
The conversion library should either:

  1. not project properties that are complex/entity types
  2. project sub properties of the complex/entity types which are themselves scalar types (e.g. start/dateTime desc )

If we go with 2, this brings a couple of questions:

  1. how many levels of depths should this support?
  2. what's going to happen for consumers using that metadata to project enums / union types of constants which all of a sudden will see a / character appear, which is reserved in most programing languages?

This also impacts graph explorer as we're suggesting customers things that cannot work.

Image

主要語言
C#
星號
240
分支
70
平均合併
2 小時 8 分鐘
30 天內合併 PR
9

環境準備

  • 沒有 Dockerfile 或 Docker Compose 檔案
  • 沒有 Pull Request 範本
  • 閱讀貢獻指南

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

microsoft/OpenAPI.NET.OData 的其他 Issue

查看 microsoft/OpenAPI.NET.OData 的全部 Issue

相似的 Issue

更多 C# Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。