# Record Layer \`Field\` proto message

**URL:** <https://forums.foundationdb.org/t/record-layer-field-proto-message/3091>\
**Category:** FoundationDB Layers\
**Created:** [December 25, 2021, 4:32am UTC](https://forums.foundationdb.org/t/record-layer-field-proto-message/3091 "2021-12-25T04:32:20Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![rajivr](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/rajivr/32/1100_2.png) [@rajivr](https://forums.foundationdb.org/u/rajivr)\
**Post date:** [December 25, 2021, 4:32am UTC](https://forums.foundationdb.org/t/record-layer-field-proto-message/3091/1 "2021-12-25T04:32:20Z")

</div>

When studying record layer code, I noticed that in [`record_metadata.proto`](https://github.com/FoundationDB/fdb-record-layer/blob/3.1.224.0/fdb-record-layer-core/src/main/proto/record_metadata.proto#L110-L124), the proto message `Field` is defined as follows.

```auto
message Field {
  required string field_name = 1;

  // [...]
  }
}

```

In protobuf, the way to uniquely identify a field/column is by using field number. I tried to understand the implications of using field name, and found the following comment in [`SchemaEvolution.md`](https://github.com/FoundationDB/fdb-record-layer/blob/3.1.224.0/docs/SchemaEvolution.md#rename-a-field-in-a-record-type).

> However, index and primary key definitions in the meta-data itself are based on field names, so these will also need to be updated in exactly the same way. At present, to avoid this appearing to be a change requiring an index rebuild, the index’s subspace key and version need to be copied from the old definition.

I was wondering what was the motivation for using field name instead of field number? I am trying to understand the pros and cons.

For my implementation, I am considering something as follows instead.

```auto
message Field {
  required uint32 field_number = 1;

  // [...]
  }
}

```

Happy Holidays! 🙂

---

<div class="post-metadata">

**Author:** ![alloc](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/alloc/32/9_2.png) [@alloc](https://forums.foundationdb.org/u/alloc)\
**Post date:** [January 4, 2022, 9:50pm UTC](https://forums.foundationdb.org/t/record-layer-field-proto-message/3091/2 "2022-01-04T21:50:33Z")

</div>

One reason to use name instead of number is that you can have an index definition (or common primary key) that spans across types as long as all types have that field defined on them. So, for example, you could have `ChildType1` and `ChildType2` that both had a `parent_id` field that pointed to some `ParentType` by its primary key (say), and then you could define a multi-type index on `ChildType1` and `ChildType2` on the `parent_id` field that would let you query for all children (of both types) for a given parent.

Now, you could do the same thing with field numbers instead of field names, but I think there are more cases where the same field name gets used across types to represent the same information rather than number (or, perhaps, it’s easier to retroactively change a protobuf definition so that the same names are used for the same data across messages are the same rather than numbers, which can’t be changed after the fact).

But that is a bit niche and for single-type indexes, it doesn’t really buy you too much (other than maybe being slightly easier for humans to look at and understand, though that can be fixed by having whatever user interface the human is looking through look up the field name by number), and using the field number instead would be fine for most purposes, I think.

---

<div class="post-metadata">

**Author:** ![rajivr](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/rajivr/32/1100_2.png) [@rajivr](https://forums.foundationdb.org/u/rajivr)\
**Post date:** [January 5, 2022, 12:28am UTC](https://forums.foundationdb.org/t/record-layer-field-proto-message/3091/3 "2022-01-05T00:28:08Z")

</div>

Thanks @alloc for the reply!