[Feature Request] Support validation of extension fields
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Ambito
- backend-api-design
Direzione di ricerca
Inizia tracciando come vengono creati e memorizzati nella cache gli evaluator nelle implementazioni Go, Java, Python e C++, quindi esamina come vengono forniti i FieldDescriptors delle estensioni e i tipi di messaggio noti. Il lavoro è completato quando le estensioni presenti vengono validate ricorsivamente, inclusi i valori di messaggio annidati, e le API supportano il caso non lazy; l’issue non indica file o test.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Currently, all four implementations (Go, Java, Python, and C++) ignore extension fields.
Ideally, when building the evaluator for a message, if a message is extendable (its descriptor defines at least one extension range), an additional message-level evaluator would be instantiated whose implementation loops through all present extensions and recursively validates them. Not only should this apply field constraints to the extension fields, but it should also recursively validate nested messages, for extensions whose type is a message (or a list of messages or a map with message values).
Currently, evaluators are created and cached on a per-message basis. Computing an evaluator for a message constructs sub-evaluators for all fields and oneofs. We will need to either augment this to support to creating/caching evaluators keyed by an extension FieldDescriptor or the message evaluator needs to be mutable (at least when "lazy-loading" of evaluators is enabled), so that add'l extension field evaluators can be added as new extensions are encountered when validating message instances.
In order to properly support non-lazy validators, where all constraints must be defined up front, the APIs should be updated to accept extension FieldDescriptors up-front, in addition to accepting the set of known message types up-front. That way, rules can be built ahead-of-time for these extension fields and applied to the relevant messages.
- Lingua principale
- Go
- Stelle
- 1.6k
- Fork
- 66
- Merge medio
- 10h 49m
- PR unite (30g)
- 4
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di bufbuild/protovalidate
-
[BUG] Hostname rule rejects a 253-character name with a trailing dot, which the docs say is valid Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 58/100
bufbuild/protovalidate#512 · 2 commenti ·
-
Feature
Difficoltà 5/5 Più di una settimana Idoneità per principianti 45/100
bufbuild/protovalidate#490 · 1 commento ·
-
Feature
Difficoltà 5/5 Più di una settimana Idoneità per principianti 30/100
bufbuild/protovalidate#486 · 10 commenti ·
-
Feature
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
bufbuild/protovalidate#485 ·
-
Feature
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
bufbuild/protovalidate#483 · 1 reazione ·
Tutte le issue di bufbuild/protovalidate
Issue simili
-
bug github_actions
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
registrystack/registry-stack#1393 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
JakeChampion/lang#10213 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
oasisprotocol/oasis-sdk#2523 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100