Das ist die so genannte Feld ID, eine 32-Bit-Ganzzahl. Abgesehen von den Daten selbst ist dies das einzige, was über die Leitung geht, um der anderen Seite die korrekte Identifizierung des Feldes zu erlauben, zu dem die Daten gehören.
In früheren Zeiten hat das System intern automatisch diese IDs zur Verfügung gestellt, was zu Inkompatibilitäten führte: Wenn jemand die Reihenfolge der Felder änderte, fügte ein Feld zwischen anderen oder entfernten Feldern hinzu. Aus Kompatibilitätsgründen können Sie immer noch die Zahlen weglassen und haben das System zuweisen negative IDs automatisch 1):
struct yeolde {
i32 foo
string bar
}
aber jetzt erhalten Sie eine nette Warnung darüber:
$ thrift -gen csharp test.thrift
[WARNING:test.thrift:3] No field key specified for foo, resulting protocol may have conflicts or not be backwards compatible!
[WARNING:test.thrift:4] No field key specified for bar, resulting protocol may have conflicts or not be backwards compatible!
Warum springt es von 5 auf 16?
Man könnte das für eine gute Idee entschieden haben. Es gibt nicht so viele Einschränkungen, dass die Nummer ein positiver 32-Bit-Wert > 0
sein muss.
Oder es wurden Felder in der Zwischenzeit entfernt. Insbesondere für den letzten Fall empfiehlt es sich, veraltete Felder zu kommentieren, sie aber im IDL zu belassen, um Kompatibilitätsunfälle zu vermeiden, da jemand eine bereits benutzte und veraltete alte Feldnummer für neue Zwecke "wieder verwendet".
1) Das ist der Grund, warum negative ID-Nummern sind nicht erlaubt.