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

Offen

#613 erstellt am 03.12.2024 0 Kommentare 1 Reaktion 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit: 5/5
Geschätzter Aufwand: Über eine Woche
Anfängerfreundlichkeit: 35/100

Issue-Typ: Feature
Klarheit: Größtenteils klar
Aktivitätsstatus: Veraltet
Tech-Stack: csharp
Bereich: api

Rechercherichtung

Beginne damit nachzuverfolgen, wie Metadaten für GET /me/calendar/events das orderby-Enum erzeugen und wo komplexe oder Entitätseigenschaften klassifiziert werden. Vergleiche die beiden vorgeschlagenen Verhaltensweisen, einschließlich der Verschachtelungstiefe und des Umgangs mit Schrägstrichen bei generierten Konstanten. Erledigt ist dies, wenn das Projekt eine festgelegte, getestete Regel hat, die verhindert, dass orderby-Werte vorgeschlagen werden, die der Dienst nicht verwenden kann.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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:

not project properties that are complex/entity types
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:

how many levels of depths should this support?
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.