feat(Spanner): Add support for Protobuf Enums by efevans · Pull Request #15699 · googleapis/google-cloud-dotnet

efevans · 2026-06-22T22:52:00Z

b/522532048

gemini-code-assist

Code Review

This pull request introduces support for Spanner Enum types by adding a ProtobufEnumName property, a constructor, and helper methods to SpannerDbType, as well as supporting conversion of protobuf values to CLR enum types. The review feedback suggests correcting the string representation of the enum type from PROTO to ENUM, handling nullable enum types correctly during conversion, and fixing a typo in a parameter name.

robertvoinescu-work · 2026-06-25T16:35:48Z

@@ -110,6 +110,11 @@ internal object ConvertToClrType(Value protobufValue, System.Type targetClrType,
                return Guid.Parse(ConvertToClrTypeImpl<string>(protobufValue, options));
            }

+            if (targetClrType.IsEnum)
+            {
+                return System.Enum.ToObject(targetClrType, ConvertToClrTypeImpl<long>(protobufValue, options));


In the case of a string are we sure it cannot be the enum member name (e.g. "Colors.Red") rather than the enum member value that is used? docs.

You will need to add some logic in SpannerDbType.StringParsing to handle enum member names.

In the case of a string are we sure it cannot be the enum member name (e.g. "Colors.Red") rather than the enum member value that is used?

I understood this as being a conversion method for reading the response from Spanner from a SELECT query and from the type.proto definition it should come formatted as a string containing the decimal Enums representation:

// Encoded as `string`, in decimal format. ENUM = 14;

Are there other uses for this?

You will need to add some logic in SpannerDbType.StringParsing to handle enum member names.

Good callout, will address this part after a discussion about Enums FQNs

robertvoinescu-work · 2026-06-25T16:56:14Z

@@ -41,7 +41,8 @@ public void CreateKeyFromParameterCollection()
                    { "", SpannerDbType.PgOid, 2 },
                    { "", SpannerDbType.String, "test" },
                    { "", SpannerDbType.Timestamp, new DateTime(2021, 9, 10, 9, 37, 10, DateTimeKind.Utc) },
-                    { "", SpannerDbType.Uuid, Guid.Parse("8f8c4746-17b1-4d9f-a634-58e11942095f") }


Let's add some integration tests to validate against a real spanner instance

robertvoinescu-work · 2026-06-25T16:59:28Z

@@ -315,6 +320,10 @@ internal static SpannerDbType FromProtobufType(V1.Type type)
                    return new SpannerDbType(type.StructType.Fields.Select(f => new StructField(f.Name, FromProtobufType(f.Type))).ToList());
                case TypeCode.Proto:
                    return new SpannerDbType(type.ProtoTypeFqn);
+                case TypeCode.Enum:
+                    // This is handled here because equality logic prevent enum type working in s_simpleTypes,


I don't think this is true, Spanner will need the fully qualified name to figure out what type to cast to on it's end.

In my testing so far I haven't had a FQN to easily grab from unless I hardcoded it. Unlike Proto messages that expose the FQN as part of the C# compiled proto, Enums do not have this and as you point out our Spanner will need the FQN if we send a parameter as type Enum.

In my testing, if the FQN isn't hard coded then there's no trivial way to get it so I've been adding parameters as Int64:

cmdInsert.Parameters.Add("class", SpannerDbType.Int64, character.CharacterClass);

Will address this more after a discussion on how we will handle Enum FQNs

robertvoinescu-work · 2026-06-25T17:06:51Z

We should add some logic here to get the clr type given the enum typecode.

If the CLR type is an Enum then I think we'd have to rely on reflection to find the real Enum type, the SpannerDbType object will need the FQN which is seemingly unreliable. If we go a route where we handle cases where TypeCode is Enum differently based on whether or not we have the FQN, we could do reflection for the FQN case and defer to the default typeof(Value); otherwise.

robertvoinescu-work · 2026-06-25T17:12:12Z

We will need to update this method to convert to the enum type.

Can add this after addressing the issue with the FQN

robertvoinescu-work · 2026-06-25T17:20:39Z

Looking good, I think writing the integration tests should help clear up how spanner is actually handling the enums. You've got the logic to handle enums coming from Spanner almost there, but we will also need to support the other direction of enum types flowing to spanner from the client.

efevans · 2026-06-25T19:15:11Z

@robertvoinescu-work answered most of our comments but there's some discussion still worth having. I'll be going over with Amanda the issues I'm seeing with FQNs later today and should be able to respond again with more afterwards.

feat(Spanner): Add support for Protobuf Enums

954c623

product-auto-label Bot added the api: spanner Issues related to the Spanner API. label Jun 22, 2026

gemini-code-assist Bot reviewed Jun 22, 2026

View reviewed changes

efevans added 8 commits June 22, 2026 23:03

Fix spacing

53468c5

Fix typo

0da2a91

Add convenience method GetEnum to DataReader

f752fd3

Remove references to enum as a spannerdbtype

fb83b37

Remove unused enum references

49965ac

Re-add Enum case for ProtobufType conversion

5cbc2b0

Add test for keys with enums

0a073d6

Move test protos to CommonTesting

032daff

robertvoinescu-work reviewed Jun 25, 2026

View reviewed changes

efevans added 7 commits June 25, 2026 20:59

Update test Fantast proto to use an embeded enum

9aa64e7

Add enum types to database test fixure

eea30a4

Add integration tests for just embedded enums

33e399f

.

f15f936

More work on integration testing

3b4817b

Remove references to old proto enums

0a306b3

Fix failing tests

80c2488

Uh oh!

Conversation

efevans commented Jun 22, 2026

Uh oh!

gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

robertvoinescu-work commented Jun 25, 2026

Uh oh!

efevans commented Jun 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants