From aea271185eb06c046cd5b7431fd431c0c97671e6 Mon Sep 17 00:00:00 2001
From: G8XSU <3442979+G8XSU@users.noreply.github.com>
Date: Fri, 13 Dec 2024 12:59:21 -0800
Subject: [PATCH] Upgrade protobuf to v3.25.5.

Earlier versions are impacted by `CVE-2024-7254`. Even though
we don't use groups or nested fields and mostly are not impacted directly.
We upgrade nonetheless to ensure safe use in case on unknown fields.
---
 java/app/build.gradle                         |   2 +-
 .../proto/org/vss/DeleteObjectRequest.java    | 168 +++++--
 .../org/vss/DeleteObjectRequestOrBuilder.java |  16 +
 .../proto/org/vss/DeleteObjectResponse.java   |   7 +-
 .../vss/DeleteObjectResponseOrBuilder.java    |   1 +
 .../proto/org/vss/EncryptionMetadata.java     |  60 ++-
 .../org/vss/EncryptionMetadataOrBuilder.java  |   1 +
 .../generated/proto/org/vss/ErrorCode.java    |   1 +
 .../proto/org/vss/ErrorResponse.java          |  55 ++-
 .../proto/org/vss/ErrorResponseOrBuilder.java |   1 +
 .../proto/org/vss/GetObjectRequest.java       |  72 ++-
 .../org/vss/GetObjectRequestOrBuilder.java    |   7 +
 .../proto/org/vss/GetObjectResponse.java      |  91 ++--
 .../org/vss/GetObjectResponseOrBuilder.java   |   1 +
 .../generated/proto/org/vss/KeyValue.java     |  59 ++-
 .../proto/org/vss/KeyValueOrBuilder.java      |   1 +
 .../proto/org/vss/ListKeyVersionsRequest.java | 127 +++--
 .../vss/ListKeyVersionsRequestOrBuilder.java  |  13 +
 .../org/vss/ListKeyVersionsResponse.java      |  88 +++-
 .../vss/ListKeyVersionsResponseOrBuilder.java |  14 +
 .../proto/org/vss/PlaintextBlob.java          |  42 +-
 .../proto/org/vss/PlaintextBlobOrBuilder.java |   1 +
 .../proto/org/vss/PutObjectRequest.java       | 441 ++++++++++++++++--
 .../org/vss/PutObjectRequestOrBuilder.java    |  77 +++
 .../proto/org/vss/PutObjectResponse.java      |   7 +-
 .../org/vss/PutObjectResponseOrBuilder.java   |   1 +
 .../generated/proto/org/vss/Storable.java     | 104 +++--
 .../proto/org/vss/StorableOrBuilder.java      |   1 +
 .../src/main/generated/proto/org/vss/Vss.java |   7 +-
 29 files changed, 1107 insertions(+), 359 deletions(-)

diff --git a/java/app/build.gradle b/java/app/build.gradle
index 8f66fbe..9f9c86d 100644
--- a/java/app/build.gradle
+++ b/java/app/build.gradle
@@ -1,6 +1,6 @@
 buildscript {
   ext.protobufPlugInVersion = '0.9.4'
-  ext.protobufVersion = '3.21.7'
+  ext.protobufVersion = '3.25.5'
   ext.jerseyVersion = '3.1.0'
   ext.junitVersion = '5.9.0'
   ext.mockitoVersion = '5.2.0'
diff --git a/java/app/src/main/generated/proto/org/vss/DeleteObjectRequest.java b/java/app/src/main/generated/proto/org/vss/DeleteObjectRequest.java
index 48a68dc..f4e35b1 100644
--- a/java/app/src/main/generated/proto/org/vss/DeleteObjectRequest.java
+++ b/java/app/src/main/generated/proto/org/vss/DeleteObjectRequest.java
@@ -1,6 +1,7 @@
 // Generated by the protocol buffer compiler.  DO NOT EDIT!
 // source: vss.proto
 
+// Protobuf Java Version: 3.25.5
 package org.vss;
 
 /**
@@ -32,12 +33,6 @@ protected java.lang.Object newInstance(
 		return new DeleteObjectRequest();
 	}
 
-	@java.lang.Override
-	public final com.google.protobuf.UnknownFieldSet
-	getUnknownFields() {
-		return this.unknownFields;
-	}
-
 	public static final com.google.protobuf.Descriptors.Descriptor
 	getDescriptor() {
 		return org.vss.Vss.internal_static_vss_DeleteObjectRequest_descriptor;
@@ -51,8 +46,10 @@ protected java.lang.Object newInstance(
 						org.vss.DeleteObjectRequest.class, org.vss.DeleteObjectRequest.Builder.class);
 	}
 
+	private int bitField0_;
 	public static final int STORE_ID_FIELD_NUMBER = 1;
-	private volatile java.lang.Object storeId_;
+	@SuppressWarnings("serial")
+	private volatile java.lang.Object storeId_ = "";
 
 	/**
 	 * <pre>
@@ -117,14 +114,19 @@ public java.lang.String getStoreId() {
 	/**
 	 * <pre>
 	 * Item to be deleted as a result of this `DeleteObjectRequest`.
+	 *
 	 * An item consists of a `key` and its corresponding `version`.
+	 *
 	 * Key-level Versioning (Conditional Delete):
 	 *   The item is only deleted if the current database version against the `key` is the same as
 	 *   the `version` specified in the request.
+	 *
 	 * Skipping key-level versioning (Non-conditional Delete):
 	 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 	 *   This will perform a non-conditional delete query.
+	 *
 	 * This operation is idempotent, that is, multiple delete calls for the same item will not fail.
+	 *
 	 * If the requested item does not exist, this operation will not fail.
 	 * If you wish to perform stricter checks while deleting an item, consider using `PutObject` API.
 	 * </pre>
@@ -135,20 +137,25 @@ public java.lang.String getStoreId() {
 	 */
 	@java.lang.Override
 	public boolean hasKeyValue() {
-		return keyValue_ != null;
+		return ((bitField0_ & 0x00000001) != 0);
 	}
 
 	/**
 	 * <pre>
 	 * Item to be deleted as a result of this `DeleteObjectRequest`.
+	 *
 	 * An item consists of a `key` and its corresponding `version`.
+	 *
 	 * Key-level Versioning (Conditional Delete):
 	 *   The item is only deleted if the current database version against the `key` is the same as
 	 *   the `version` specified in the request.
+	 *
 	 * Skipping key-level versioning (Non-conditional Delete):
 	 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 	 *   This will perform a non-conditional delete query.
+	 *
 	 * This operation is idempotent, that is, multiple delete calls for the same item will not fail.
+	 *
 	 * If the requested item does not exist, this operation will not fail.
 	 * If you wish to perform stricter checks while deleting an item, consider using `PutObject` API.
 	 * </pre>
@@ -165,14 +172,19 @@ public org.vss.KeyValue getKeyValue() {
 	/**
 	 * <pre>
 	 * Item to be deleted as a result of this `DeleteObjectRequest`.
+	 *
 	 * An item consists of a `key` and its corresponding `version`.
+	 *
 	 * Key-level Versioning (Conditional Delete):
 	 *   The item is only deleted if the current database version against the `key` is the same as
 	 *   the `version` specified in the request.
+	 *
 	 * Skipping key-level versioning (Non-conditional Delete):
 	 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 	 *   This will perform a non-conditional delete query.
+	 *
 	 * This operation is idempotent, that is, multiple delete calls for the same item will not fail.
+	 *
 	 * If the requested item does not exist, this operation will not fail.
 	 * If you wish to perform stricter checks while deleting an item, consider using `PutObject` API.
 	 * </pre>
@@ -181,7 +193,7 @@ public org.vss.KeyValue getKeyValue() {
 	 */
 	@java.lang.Override
 	public org.vss.KeyValueOrBuilder getKeyValueOrBuilder() {
-		return getKeyValue();
+		return keyValue_ == null ? org.vss.KeyValue.getDefaultInstance() : keyValue_;
 	}
 
 	private byte memoizedIsInitialized = -1;
@@ -202,7 +214,7 @@ public void writeTo(com.google.protobuf.CodedOutputStream output)
 		if (!com.google.protobuf.GeneratedMessageV3.isStringEmpty(storeId_)) {
 			com.google.protobuf.GeneratedMessageV3.writeString(output, 1, storeId_);
 		}
-		if (keyValue_ != null) {
+		if (((bitField0_ & 0x00000001) != 0)) {
 			output.writeMessage(2, getKeyValue());
 		}
 		getUnknownFields().writeTo(output);
@@ -217,7 +229,7 @@ public int getSerializedSize() {
 		if (!com.google.protobuf.GeneratedMessageV3.isStringEmpty(storeId_)) {
 			size += com.google.protobuf.GeneratedMessageV3.computeStringSize(1, storeId_);
 		}
-		if (keyValue_ != null) {
+		if (((bitField0_ & 0x00000001) != 0)) {
 			size += com.google.protobuf.CodedOutputStream
 					.computeMessageSize(2, getKeyValue());
 		}
@@ -398,24 +410,30 @@ public static final class Builder extends
 
 		// Construct using org.vss.DeleteObjectRequest.newBuilder()
 		private Builder() {
-
+			maybeForceBuilderInitialization();
 		}
 
 		private Builder(
 				com.google.protobuf.GeneratedMessageV3.BuilderParent parent) {
 			super(parent);
+			maybeForceBuilderInitialization();
+		}
 
+		private void maybeForceBuilderInitialization() {
+			if (com.google.protobuf.GeneratedMessageV3
+					.alwaysUseFieldBuilders) {
+				getKeyValueFieldBuilder();
+			}
 		}
 
 		@java.lang.Override
 		public Builder clear() {
 			super.clear();
+			bitField0_ = 0;
 			storeId_ = "";
-
-			if (keyValueBuilder_ == null) {
-				keyValue_ = null;
-			} else {
-				keyValue_ = null;
+			keyValue_ = null;
+			if (keyValueBuilder_ != null) {
+				keyValueBuilder_.dispose();
 				keyValueBuilder_ = null;
 			}
 			return this;
@@ -444,16 +462,28 @@ public org.vss.DeleteObjectRequest build() {
 		@java.lang.Override
 		public org.vss.DeleteObjectRequest buildPartial() {
 			org.vss.DeleteObjectRequest result = new org.vss.DeleteObjectRequest(this);
-			result.storeId_ = storeId_;
-			if (keyValueBuilder_ == null) {
-				result.keyValue_ = keyValue_;
-			} else {
-				result.keyValue_ = keyValueBuilder_.build();
+			if (bitField0_ != 0) {
+				buildPartial0(result);
 			}
 			onBuilt();
 			return result;
 		}
 
+		private void buildPartial0(org.vss.DeleteObjectRequest result) {
+			int from_bitField0_ = bitField0_;
+			if (((from_bitField0_ & 0x00000001) != 0)) {
+				result.storeId_ = storeId_;
+			}
+			int to_bitField0_ = 0;
+			if (((from_bitField0_ & 0x00000002) != 0)) {
+				result.keyValue_ = keyValueBuilder_ == null
+						? keyValue_
+						: keyValueBuilder_.build();
+				to_bitField0_ |= 0x00000001;
+			}
+			result.bitField0_ |= to_bitField0_;
+		}
+
 		@java.lang.Override
 		public Builder clone() {
 			return super.clone();
@@ -506,6 +536,7 @@ public Builder mergeFrom(org.vss.DeleteObjectRequest other) {
 			if (other == org.vss.DeleteObjectRequest.getDefaultInstance()) return this;
 			if (!other.getStoreId().isEmpty()) {
 				storeId_ = other.storeId_;
+				bitField0_ |= 0x00000001;
 				onChanged();
 			}
 			if (other.hasKeyValue()) {
@@ -539,14 +570,14 @@ public Builder mergeFrom(
 							break;
 						case 10: {
 							storeId_ = input.readStringRequireUtf8();
-
+							bitField0_ |= 0x00000001;
 							break;
 						} // case 10
 						case 18: {
 							input.readMessage(
 									getKeyValueFieldBuilder().getBuilder(),
 									extensionRegistry);
-
+							bitField0_ |= 0x00000002;
 							break;
 						} // case 18
 						default: {
@@ -565,6 +596,8 @@ public Builder mergeFrom(
 			return this;
 		}
 
+		private int bitField0_;
+
 		private java.lang.Object storeId_ = "";
 
 		/**
@@ -642,8 +675,8 @@ public Builder setStoreId(
 			if (value == null) {
 				throw new NullPointerException();
 			}
-
 			storeId_ = value;
+			bitField0_ |= 0x00000001;
 			onChanged();
 			return this;
 		}
@@ -663,8 +696,8 @@ public Builder setStoreId(
 		 * @return This builder for chaining.
 		 */
 		public Builder clearStoreId() {
-
 			storeId_ = getDefaultInstance().getStoreId();
+			bitField0_ = (bitField0_ & ~0x00000001);
 			onChanged();
 			return this;
 		}
@@ -690,8 +723,8 @@ public Builder setStoreIdBytes(
 				throw new NullPointerException();
 			}
 			checkByteStringIsUtf8(value);
-
 			storeId_ = value;
+			bitField0_ |= 0x00000001;
 			onChanged();
 			return this;
 		}
@@ -703,14 +736,19 @@ public Builder setStoreIdBytes(
 		/**
 		 * <pre>
 		 * Item to be deleted as a result of this `DeleteObjectRequest`.
+		 *
 		 * An item consists of a `key` and its corresponding `version`.
+		 *
 		 * Key-level Versioning (Conditional Delete):
 		 *   The item is only deleted if the current database version against the `key` is the same as
 		 *   the `version` specified in the request.
+		 *
 		 * Skipping key-level versioning (Non-conditional Delete):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional delete query.
+		 *
 		 * This operation is idempotent, that is, multiple delete calls for the same item will not fail.
+		 *
 		 * If the requested item does not exist, this operation will not fail.
 		 * If you wish to perform stricter checks while deleting an item, consider using `PutObject` API.
 		 * </pre>
@@ -720,20 +758,25 @@ public Builder setStoreIdBytes(
 		 * @return Whether the keyValue field is set.
 		 */
 		public boolean hasKeyValue() {
-			return keyValueBuilder_ != null || keyValue_ != null;
+			return ((bitField0_ & 0x00000002) != 0);
 		}
 
 		/**
 		 * <pre>
 		 * Item to be deleted as a result of this `DeleteObjectRequest`.
+		 *
 		 * An item consists of a `key` and its corresponding `version`.
+		 *
 		 * Key-level Versioning (Conditional Delete):
 		 *   The item is only deleted if the current database version against the `key` is the same as
 		 *   the `version` specified in the request.
+		 *
 		 * Skipping key-level versioning (Non-conditional Delete):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional delete query.
+		 *
 		 * This operation is idempotent, that is, multiple delete calls for the same item will not fail.
+		 *
 		 * If the requested item does not exist, this operation will not fail.
 		 * If you wish to perform stricter checks while deleting an item, consider using `PutObject` API.
 		 * </pre>
@@ -753,14 +796,19 @@ public org.vss.KeyValue getKeyValue() {
 		/**
 		 * <pre>
 		 * Item to be deleted as a result of this `DeleteObjectRequest`.
+		 *
 		 * An item consists of a `key` and its corresponding `version`.
+		 *
 		 * Key-level Versioning (Conditional Delete):
 		 *   The item is only deleted if the current database version against the `key` is the same as
 		 *   the `version` specified in the request.
+		 *
 		 * Skipping key-level versioning (Non-conditional Delete):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional delete query.
+		 *
 		 * This operation is idempotent, that is, multiple delete calls for the same item will not fail.
+		 *
 		 * If the requested item does not exist, this operation will not fail.
 		 * If you wish to perform stricter checks while deleting an item, consider using `PutObject` API.
 		 * </pre>
@@ -773,25 +821,30 @@ public Builder setKeyValue(org.vss.KeyValue value) {
 					throw new NullPointerException();
 				}
 				keyValue_ = value;
-				onChanged();
 			} else {
 				keyValueBuilder_.setMessage(value);
 			}
-
+			bitField0_ |= 0x00000002;
+			onChanged();
 			return this;
 		}
 
 		/**
 		 * <pre>
 		 * Item to be deleted as a result of this `DeleteObjectRequest`.
+		 *
 		 * An item consists of a `key` and its corresponding `version`.
+		 *
 		 * Key-level Versioning (Conditional Delete):
 		 *   The item is only deleted if the current database version against the `key` is the same as
 		 *   the `version` specified in the request.
+		 *
 		 * Skipping key-level versioning (Non-conditional Delete):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional delete query.
+		 *
 		 * This operation is idempotent, that is, multiple delete calls for the same item will not fail.
+		 *
 		 * If the requested item does not exist, this operation will not fail.
 		 * If you wish to perform stricter checks while deleting an item, consider using `PutObject` API.
 		 * </pre>
@@ -802,25 +855,30 @@ public Builder setKeyValue(
 				org.vss.KeyValue.Builder builderForValue) {
 			if (keyValueBuilder_ == null) {
 				keyValue_ = builderForValue.build();
-				onChanged();
 			} else {
 				keyValueBuilder_.setMessage(builderForValue.build());
 			}
-
+			bitField0_ |= 0x00000002;
+			onChanged();
 			return this;
 		}
 
 		/**
 		 * <pre>
 		 * Item to be deleted as a result of this `DeleteObjectRequest`.
+		 *
 		 * An item consists of a `key` and its corresponding `version`.
+		 *
 		 * Key-level Versioning (Conditional Delete):
 		 *   The item is only deleted if the current database version against the `key` is the same as
 		 *   the `version` specified in the request.
+		 *
 		 * Skipping key-level versioning (Non-conditional Delete):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional delete query.
+		 *
 		 * This operation is idempotent, that is, multiple delete calls for the same item will not fail.
+		 *
 		 * If the requested item does not exist, this operation will not fail.
 		 * If you wish to perform stricter checks while deleting an item, consider using `PutObject` API.
 		 * </pre>
@@ -829,31 +887,39 @@ public Builder setKeyValue(
 		 */
 		public Builder mergeKeyValue(org.vss.KeyValue value) {
 			if (keyValueBuilder_ == null) {
-				if (keyValue_ != null) {
-					keyValue_ =
-							org.vss.KeyValue.newBuilder(keyValue_).mergeFrom(value).buildPartial();
+				if (((bitField0_ & 0x00000002) != 0) &&
+						keyValue_ != null &&
+						keyValue_ != org.vss.KeyValue.getDefaultInstance()) {
+					getKeyValueBuilder().mergeFrom(value);
 				} else {
 					keyValue_ = value;
 				}
-				onChanged();
 			} else {
 				keyValueBuilder_.mergeFrom(value);
 			}
-
+			if (keyValue_ != null) {
+				bitField0_ |= 0x00000002;
+				onChanged();
+			}
 			return this;
 		}
 
 		/**
 		 * <pre>
 		 * Item to be deleted as a result of this `DeleteObjectRequest`.
+		 *
 		 * An item consists of a `key` and its corresponding `version`.
+		 *
 		 * Key-level Versioning (Conditional Delete):
 		 *   The item is only deleted if the current database version against the `key` is the same as
 		 *   the `version` specified in the request.
+		 *
 		 * Skipping key-level versioning (Non-conditional Delete):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional delete query.
+		 *
 		 * This operation is idempotent, that is, multiple delete calls for the same item will not fail.
+		 *
 		 * If the requested item does not exist, this operation will not fail.
 		 * If you wish to perform stricter checks while deleting an item, consider using `PutObject` API.
 		 * </pre>
@@ -861,28 +927,32 @@ public Builder mergeKeyValue(org.vss.KeyValue value) {
 		 * <code>.vss.KeyValue key_value = 2;</code>
 		 */
 		public Builder clearKeyValue() {
-			if (keyValueBuilder_ == null) {
-				keyValue_ = null;
-				onChanged();
-			} else {
-				keyValue_ = null;
+			bitField0_ = (bitField0_ & ~0x00000002);
+			keyValue_ = null;
+			if (keyValueBuilder_ != null) {
+				keyValueBuilder_.dispose();
 				keyValueBuilder_ = null;
 			}
-
+			onChanged();
 			return this;
 		}
 
 		/**
 		 * <pre>
 		 * Item to be deleted as a result of this `DeleteObjectRequest`.
+		 *
 		 * An item consists of a `key` and its corresponding `version`.
+		 *
 		 * Key-level Versioning (Conditional Delete):
 		 *   The item is only deleted if the current database version against the `key` is the same as
 		 *   the `version` specified in the request.
+		 *
 		 * Skipping key-level versioning (Non-conditional Delete):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional delete query.
+		 *
 		 * This operation is idempotent, that is, multiple delete calls for the same item will not fail.
+		 *
 		 * If the requested item does not exist, this operation will not fail.
 		 * If you wish to perform stricter checks while deleting an item, consider using `PutObject` API.
 		 * </pre>
@@ -890,7 +960,7 @@ public Builder clearKeyValue() {
 		 * <code>.vss.KeyValue key_value = 2;</code>
 		 */
 		public org.vss.KeyValue.Builder getKeyValueBuilder() {
-
+			bitField0_ |= 0x00000002;
 			onChanged();
 			return getKeyValueFieldBuilder().getBuilder();
 		}
@@ -898,14 +968,19 @@ public org.vss.KeyValue.Builder getKeyValueBuilder() {
 		/**
 		 * <pre>
 		 * Item to be deleted as a result of this `DeleteObjectRequest`.
+		 *
 		 * An item consists of a `key` and its corresponding `version`.
+		 *
 		 * Key-level Versioning (Conditional Delete):
 		 *   The item is only deleted if the current database version against the `key` is the same as
 		 *   the `version` specified in the request.
+		 *
 		 * Skipping key-level versioning (Non-conditional Delete):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional delete query.
+		 *
 		 * This operation is idempotent, that is, multiple delete calls for the same item will not fail.
+		 *
 		 * If the requested item does not exist, this operation will not fail.
 		 * If you wish to perform stricter checks while deleting an item, consider using `PutObject` API.
 		 * </pre>
@@ -924,14 +999,19 @@ public org.vss.KeyValueOrBuilder getKeyValueOrBuilder() {
 		/**
 		 * <pre>
 		 * Item to be deleted as a result of this `DeleteObjectRequest`.
+		 *
 		 * An item consists of a `key` and its corresponding `version`.
+		 *
 		 * Key-level Versioning (Conditional Delete):
 		 *   The item is only deleted if the current database version against the `key` is the same as
 		 *   the `version` specified in the request.
+		 *
 		 * Skipping key-level versioning (Non-conditional Delete):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional delete query.
+		 *
 		 * This operation is idempotent, that is, multiple delete calls for the same item will not fail.
+		 *
 		 * If the requested item does not exist, this operation will not fail.
 		 * If you wish to perform stricter checks while deleting an item, consider using `PutObject` API.
 		 * </pre>
diff --git a/java/app/src/main/generated/proto/org/vss/DeleteObjectRequestOrBuilder.java b/java/app/src/main/generated/proto/org/vss/DeleteObjectRequestOrBuilder.java
index fb5fef4..6c150e6 100644
--- a/java/app/src/main/generated/proto/org/vss/DeleteObjectRequestOrBuilder.java
+++ b/java/app/src/main/generated/proto/org/vss/DeleteObjectRequestOrBuilder.java
@@ -1,6 +1,7 @@
 // Generated by the protocol buffer compiler.  DO NOT EDIT!
 // source: vss.proto
 
+// Protobuf Java Version: 3.25.5
 package org.vss;
 
 public interface DeleteObjectRequestOrBuilder extends
@@ -43,14 +44,19 @@ public interface DeleteObjectRequestOrBuilder extends
 	/**
 	 * <pre>
 	 * Item to be deleted as a result of this `DeleteObjectRequest`.
+	 *
 	 * An item consists of a `key` and its corresponding `version`.
+	 *
 	 * Key-level Versioning (Conditional Delete):
 	 *   The item is only deleted if the current database version against the `key` is the same as
 	 *   the `version` specified in the request.
+	 *
 	 * Skipping key-level versioning (Non-conditional Delete):
 	 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 	 *   This will perform a non-conditional delete query.
+	 *
 	 * This operation is idempotent, that is, multiple delete calls for the same item will not fail.
+	 *
 	 * If the requested item does not exist, this operation will not fail.
 	 * If you wish to perform stricter checks while deleting an item, consider using `PutObject` API.
 	 * </pre>
@@ -64,14 +70,19 @@ public interface DeleteObjectRequestOrBuilder extends
 	/**
 	 * <pre>
 	 * Item to be deleted as a result of this `DeleteObjectRequest`.
+	 *
 	 * An item consists of a `key` and its corresponding `version`.
+	 *
 	 * Key-level Versioning (Conditional Delete):
 	 *   The item is only deleted if the current database version against the `key` is the same as
 	 *   the `version` specified in the request.
+	 *
 	 * Skipping key-level versioning (Non-conditional Delete):
 	 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 	 *   This will perform a non-conditional delete query.
+	 *
 	 * This operation is idempotent, that is, multiple delete calls for the same item will not fail.
+	 *
 	 * If the requested item does not exist, this operation will not fail.
 	 * If you wish to perform stricter checks while deleting an item, consider using `PutObject` API.
 	 * </pre>
@@ -85,14 +96,19 @@ public interface DeleteObjectRequestOrBuilder extends
 	/**
 	 * <pre>
 	 * Item to be deleted as a result of this `DeleteObjectRequest`.
+	 *
 	 * An item consists of a `key` and its corresponding `version`.
+	 *
 	 * Key-level Versioning (Conditional Delete):
 	 *   The item is only deleted if the current database version against the `key` is the same as
 	 *   the `version` specified in the request.
+	 *
 	 * Skipping key-level versioning (Non-conditional Delete):
 	 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 	 *   This will perform a non-conditional delete query.
+	 *
 	 * This operation is idempotent, that is, multiple delete calls for the same item will not fail.
+	 *
 	 * If the requested item does not exist, this operation will not fail.
 	 * If you wish to perform stricter checks while deleting an item, consider using `PutObject` API.
 	 * </pre>
diff --git a/java/app/src/main/generated/proto/org/vss/DeleteObjectResponse.java b/java/app/src/main/generated/proto/org/vss/DeleteObjectResponse.java
index dcf3603..20d0ab8 100644
--- a/java/app/src/main/generated/proto/org/vss/DeleteObjectResponse.java
+++ b/java/app/src/main/generated/proto/org/vss/DeleteObjectResponse.java
@@ -1,6 +1,7 @@
 // Generated by the protocol buffer compiler.  DO NOT EDIT!
 // source: vss.proto
 
+// Protobuf Java Version: 3.25.5
 package org.vss;
 
 /**
@@ -31,12 +32,6 @@ protected java.lang.Object newInstance(
 		return new DeleteObjectResponse();
 	}
 
-	@java.lang.Override
-	public final com.google.protobuf.UnknownFieldSet
-	getUnknownFields() {
-		return this.unknownFields;
-	}
-
 	public static final com.google.protobuf.Descriptors.Descriptor
 	getDescriptor() {
 		return org.vss.Vss.internal_static_vss_DeleteObjectResponse_descriptor;
diff --git a/java/app/src/main/generated/proto/org/vss/DeleteObjectResponseOrBuilder.java b/java/app/src/main/generated/proto/org/vss/DeleteObjectResponseOrBuilder.java
index 42442e9..a2c3edb 100644
--- a/java/app/src/main/generated/proto/org/vss/DeleteObjectResponseOrBuilder.java
+++ b/java/app/src/main/generated/proto/org/vss/DeleteObjectResponseOrBuilder.java
@@ -1,6 +1,7 @@
 // Generated by the protocol buffer compiler.  DO NOT EDIT!
 // source: vss.proto
 
+// Protobuf Java Version: 3.25.5
 package org.vss;
 
 public interface DeleteObjectResponseOrBuilder extends
diff --git a/java/app/src/main/generated/proto/org/vss/EncryptionMetadata.java b/java/app/src/main/generated/proto/org/vss/EncryptionMetadata.java
index 9d2b698..4d689f0 100644
--- a/java/app/src/main/generated/proto/org/vss/EncryptionMetadata.java
+++ b/java/app/src/main/generated/proto/org/vss/EncryptionMetadata.java
@@ -1,6 +1,7 @@
 // Generated by the protocol buffer compiler.  DO NOT EDIT!
 // source: vss.proto
 
+// Protobuf Java Version: 3.25.5
 package org.vss;
 
 /**
@@ -34,12 +35,6 @@ protected java.lang.Object newInstance(
 		return new EncryptionMetadata();
 	}
 
-	@java.lang.Override
-	public final com.google.protobuf.UnknownFieldSet
-	getUnknownFields() {
-		return this.unknownFields;
-	}
-
 	public static final com.google.protobuf.Descriptors.Descriptor
 	getDescriptor() {
 		return org.vss.Vss.internal_static_vss_EncryptionMetadata_descriptor;
@@ -54,7 +49,8 @@ protected java.lang.Object newInstance(
 	}
 
 	public static final int CIPHER_FORMAT_FIELD_NUMBER = 1;
-	private volatile java.lang.Object cipherFormat_;
+	@SuppressWarnings("serial")
+	private volatile java.lang.Object cipherFormat_ = "";
 
 	/**
 	 * <pre>
@@ -104,7 +100,7 @@ public java.lang.String getCipherFormat() {
 	}
 
 	public static final int NONCE_FIELD_NUMBER = 2;
-	private com.google.protobuf.ByteString nonce_;
+	private com.google.protobuf.ByteString nonce_ = com.google.protobuf.ByteString.EMPTY;
 
 	/**
 	 * <pre>
@@ -122,7 +118,7 @@ public com.google.protobuf.ByteString getNonce() {
 	}
 
 	public static final int TAG_FIELD_NUMBER = 3;
-	private com.google.protobuf.ByteString tag_;
+	private com.google.protobuf.ByteString tag_ = com.google.protobuf.ByteString.EMPTY;
 
 	/**
 	 * <pre>
@@ -371,12 +367,10 @@ private Builder(
 		@java.lang.Override
 		public Builder clear() {
 			super.clear();
+			bitField0_ = 0;
 			cipherFormat_ = "";
-
 			nonce_ = com.google.protobuf.ByteString.EMPTY;
-
 			tag_ = com.google.protobuf.ByteString.EMPTY;
-
 			return this;
 		}
 
@@ -403,13 +397,26 @@ public org.vss.EncryptionMetadata build() {
 		@java.lang.Override
 		public org.vss.EncryptionMetadata buildPartial() {
 			org.vss.EncryptionMetadata result = new org.vss.EncryptionMetadata(this);
-			result.cipherFormat_ = cipherFormat_;
-			result.nonce_ = nonce_;
-			result.tag_ = tag_;
+			if (bitField0_ != 0) {
+				buildPartial0(result);
+			}
 			onBuilt();
 			return result;
 		}
 
+		private void buildPartial0(org.vss.EncryptionMetadata result) {
+			int from_bitField0_ = bitField0_;
+			if (((from_bitField0_ & 0x00000001) != 0)) {
+				result.cipherFormat_ = cipherFormat_;
+			}
+			if (((from_bitField0_ & 0x00000002) != 0)) {
+				result.nonce_ = nonce_;
+			}
+			if (((from_bitField0_ & 0x00000004) != 0)) {
+				result.tag_ = tag_;
+			}
+		}
+
 		@java.lang.Override
 		public Builder clone() {
 			return super.clone();
@@ -462,6 +469,7 @@ public Builder mergeFrom(org.vss.EncryptionMetadata other) {
 			if (other == org.vss.EncryptionMetadata.getDefaultInstance()) return this;
 			if (!other.getCipherFormat().isEmpty()) {
 				cipherFormat_ = other.cipherFormat_;
+				bitField0_ |= 0x00000001;
 				onChanged();
 			}
 			if (other.getNonce() != com.google.protobuf.ByteString.EMPTY) {
@@ -498,17 +506,17 @@ public Builder mergeFrom(
 							break;
 						case 10: {
 							cipherFormat_ = input.readStringRequireUtf8();
-
+							bitField0_ |= 0x00000001;
 							break;
 						} // case 10
 						case 18: {
 							nonce_ = input.readBytes();
-
+							bitField0_ |= 0x00000002;
 							break;
 						} // case 18
 						case 26: {
 							tag_ = input.readBytes();
-
+							bitField0_ |= 0x00000004;
 							break;
 						} // case 26
 						default: {
@@ -527,6 +535,8 @@ public Builder mergeFrom(
 			return this;
 		}
 
+		private int bitField0_;
+
 		private java.lang.Object cipherFormat_ = "";
 
 		/**
@@ -589,8 +599,8 @@ public Builder setCipherFormat(
 			if (value == null) {
 				throw new NullPointerException();
 			}
-
 			cipherFormat_ = value;
+			bitField0_ |= 0x00000001;
 			onChanged();
 			return this;
 		}
@@ -605,8 +615,8 @@ public Builder setCipherFormat(
 		 * @return This builder for chaining.
 		 */
 		public Builder clearCipherFormat() {
-
 			cipherFormat_ = getDefaultInstance().getCipherFormat();
+			bitField0_ = (bitField0_ & ~0x00000001);
 			onChanged();
 			return this;
 		}
@@ -627,8 +637,8 @@ public Builder setCipherFormatBytes(
 				throw new NullPointerException();
 			}
 			checkByteStringIsUtf8(value);
-
 			cipherFormat_ = value;
+			bitField0_ |= 0x00000001;
 			onChanged();
 			return this;
 		}
@@ -665,8 +675,8 @@ public Builder setNonce(com.google.protobuf.ByteString value) {
 			if (value == null) {
 				throw new NullPointerException();
 			}
-
 			nonce_ = value;
+			bitField0_ |= 0x00000002;
 			onChanged();
 			return this;
 		}
@@ -682,7 +692,7 @@ public Builder setNonce(com.google.protobuf.ByteString value) {
 		 * @return This builder for chaining.
 		 */
 		public Builder clearNonce() {
-
+			bitField0_ = (bitField0_ & ~0x00000002);
 			nonce_ = getDefaultInstance().getNonce();
 			onChanged();
 			return this;
@@ -720,8 +730,8 @@ public Builder setTag(com.google.protobuf.ByteString value) {
 			if (value == null) {
 				throw new NullPointerException();
 			}
-
 			tag_ = value;
+			bitField0_ |= 0x00000004;
 			onChanged();
 			return this;
 		}
@@ -737,7 +747,7 @@ public Builder setTag(com.google.protobuf.ByteString value) {
 		 * @return This builder for chaining.
 		 */
 		public Builder clearTag() {
-
+			bitField0_ = (bitField0_ & ~0x00000004);
 			tag_ = getDefaultInstance().getTag();
 			onChanged();
 			return this;
diff --git a/java/app/src/main/generated/proto/org/vss/EncryptionMetadataOrBuilder.java b/java/app/src/main/generated/proto/org/vss/EncryptionMetadataOrBuilder.java
index 2d51ad5..6d6fcd9 100644
--- a/java/app/src/main/generated/proto/org/vss/EncryptionMetadataOrBuilder.java
+++ b/java/app/src/main/generated/proto/org/vss/EncryptionMetadataOrBuilder.java
@@ -1,6 +1,7 @@
 // Generated by the protocol buffer compiler.  DO NOT EDIT!
 // source: vss.proto
 
+// Protobuf Java Version: 3.25.5
 package org.vss;
 
 public interface EncryptionMetadataOrBuilder extends
diff --git a/java/app/src/main/generated/proto/org/vss/ErrorCode.java b/java/app/src/main/generated/proto/org/vss/ErrorCode.java
index 2775e69..aa99ede 100644
--- a/java/app/src/main/generated/proto/org/vss/ErrorCode.java
+++ b/java/app/src/main/generated/proto/org/vss/ErrorCode.java
@@ -1,6 +1,7 @@
 // Generated by the protocol buffer compiler.  DO NOT EDIT!
 // source: vss.proto
 
+// Protobuf Java Version: 3.25.5
 package org.vss;
 
 /**
diff --git a/java/app/src/main/generated/proto/org/vss/ErrorResponse.java b/java/app/src/main/generated/proto/org/vss/ErrorResponse.java
index 8fb7f69..1088646 100644
--- a/java/app/src/main/generated/proto/org/vss/ErrorResponse.java
+++ b/java/app/src/main/generated/proto/org/vss/ErrorResponse.java
@@ -1,6 +1,7 @@
 // Generated by the protocol buffer compiler.  DO NOT EDIT!
 // source: vss.proto
 
+// Protobuf Java Version: 3.25.5
 package org.vss;
 
 /**
@@ -34,12 +35,6 @@ protected java.lang.Object newInstance(
 		return new ErrorResponse();
 	}
 
-	@java.lang.Override
-	public final com.google.protobuf.UnknownFieldSet
-	getUnknownFields() {
-		return this.unknownFields;
-	}
-
 	public static final com.google.protobuf.Descriptors.Descriptor
 	getDescriptor() {
 		return org.vss.Vss.internal_static_vss_ErrorResponse_descriptor;
@@ -54,7 +49,7 @@ protected java.lang.Object newInstance(
 	}
 
 	public static final int ERROR_CODE_FIELD_NUMBER = 1;
-	private int errorCode_;
+	private int errorCode_ = 0;
 
 	/**
 	 * <pre>
@@ -85,13 +80,13 @@ public int getErrorCodeValue() {
 	 */
 	@java.lang.Override
 	public org.vss.ErrorCode getErrorCode() {
-		@SuppressWarnings("deprecation")
-		org.vss.ErrorCode result = org.vss.ErrorCode.valueOf(errorCode_);
+		org.vss.ErrorCode result = org.vss.ErrorCode.forNumber(errorCode_);
 		return result == null ? org.vss.ErrorCode.UNRECOGNIZED : result;
 	}
 
 	public static final int MESSAGE_FIELD_NUMBER = 2;
-	private volatile java.lang.Object message_;
+	@SuppressWarnings("serial")
+	private volatile java.lang.Object message_ = "";
 
 	/**
 	 * <pre>
@@ -365,10 +360,9 @@ private Builder(
 		@java.lang.Override
 		public Builder clear() {
 			super.clear();
+			bitField0_ = 0;
 			errorCode_ = 0;
-
 			message_ = "";
-
 			return this;
 		}
 
@@ -395,12 +389,23 @@ public org.vss.ErrorResponse build() {
 		@java.lang.Override
 		public org.vss.ErrorResponse buildPartial() {
 			org.vss.ErrorResponse result = new org.vss.ErrorResponse(this);
-			result.errorCode_ = errorCode_;
-			result.message_ = message_;
+			if (bitField0_ != 0) {
+				buildPartial0(result);
+			}
 			onBuilt();
 			return result;
 		}
 
+		private void buildPartial0(org.vss.ErrorResponse result) {
+			int from_bitField0_ = bitField0_;
+			if (((from_bitField0_ & 0x00000001) != 0)) {
+				result.errorCode_ = errorCode_;
+			}
+			if (((from_bitField0_ & 0x00000002) != 0)) {
+				result.message_ = message_;
+			}
+		}
+
 		@java.lang.Override
 		public Builder clone() {
 			return super.clone();
@@ -456,6 +461,7 @@ public Builder mergeFrom(org.vss.ErrorResponse other) {
 			}
 			if (!other.getMessage().isEmpty()) {
 				message_ = other.message_;
+				bitField0_ |= 0x00000002;
 				onChanged();
 			}
 			this.mergeUnknownFields(other.getUnknownFields());
@@ -486,12 +492,12 @@ public Builder mergeFrom(
 							break;
 						case 8: {
 							errorCode_ = input.readEnum();
-
+							bitField0_ |= 0x00000001;
 							break;
 						} // case 8
 						case 18: {
 							message_ = input.readStringRequireUtf8();
-
+							bitField0_ |= 0x00000002;
 							break;
 						} // case 18
 						default: {
@@ -510,6 +516,8 @@ public Builder mergeFrom(
 			return this;
 		}
 
+		private int bitField0_;
+
 		private int errorCode_ = 0;
 
 		/**
@@ -541,8 +549,8 @@ public int getErrorCodeValue() {
 		 * @return This builder for chaining.
 		 */
 		public Builder setErrorCodeValue(int value) {
-
 			errorCode_ = value;
+			bitField0_ |= 0x00000001;
 			onChanged();
 			return this;
 		}
@@ -560,8 +568,7 @@ public Builder setErrorCodeValue(int value) {
 		 */
 		@java.lang.Override
 		public org.vss.ErrorCode getErrorCode() {
-			@SuppressWarnings("deprecation")
-			org.vss.ErrorCode result = org.vss.ErrorCode.valueOf(errorCode_);
+			org.vss.ErrorCode result = org.vss.ErrorCode.forNumber(errorCode_);
 			return result == null ? org.vss.ErrorCode.UNRECOGNIZED : result;
 		}
 
@@ -581,7 +588,7 @@ public Builder setErrorCode(org.vss.ErrorCode value) {
 			if (value == null) {
 				throw new NullPointerException();
 			}
-
+			bitField0_ |= 0x00000001;
 			errorCode_ = value.getNumber();
 			onChanged();
 			return this;
@@ -599,7 +606,7 @@ public Builder setErrorCode(org.vss.ErrorCode value) {
 		 * @return This builder for chaining.
 		 */
 		public Builder clearErrorCode() {
-
+			bitField0_ = (bitField0_ & ~0x00000001);
 			errorCode_ = 0;
 			onChanged();
 			return this;
@@ -673,8 +680,8 @@ public Builder setMessage(
 			if (value == null) {
 				throw new NullPointerException();
 			}
-
 			message_ = value;
+			bitField0_ |= 0x00000002;
 			onChanged();
 			return this;
 		}
@@ -691,8 +698,8 @@ public Builder setMessage(
 		 * @return This builder for chaining.
 		 */
 		public Builder clearMessage() {
-
 			message_ = getDefaultInstance().getMessage();
+			bitField0_ = (bitField0_ & ~0x00000002);
 			onChanged();
 			return this;
 		}
@@ -715,8 +722,8 @@ public Builder setMessageBytes(
 				throw new NullPointerException();
 			}
 			checkByteStringIsUtf8(value);
-
 			message_ = value;
+			bitField0_ |= 0x00000002;
 			onChanged();
 			return this;
 		}
diff --git a/java/app/src/main/generated/proto/org/vss/ErrorResponseOrBuilder.java b/java/app/src/main/generated/proto/org/vss/ErrorResponseOrBuilder.java
index 3dd0a08..a1ea738 100644
--- a/java/app/src/main/generated/proto/org/vss/ErrorResponseOrBuilder.java
+++ b/java/app/src/main/generated/proto/org/vss/ErrorResponseOrBuilder.java
@@ -1,6 +1,7 @@
 // Generated by the protocol buffer compiler.  DO NOT EDIT!
 // source: vss.proto
 
+// Protobuf Java Version: 3.25.5
 package org.vss;
 
 public interface ErrorResponseOrBuilder extends
diff --git a/java/app/src/main/generated/proto/org/vss/GetObjectRequest.java b/java/app/src/main/generated/proto/org/vss/GetObjectRequest.java
index eb8e69b..89b1e51 100644
--- a/java/app/src/main/generated/proto/org/vss/GetObjectRequest.java
+++ b/java/app/src/main/generated/proto/org/vss/GetObjectRequest.java
@@ -1,6 +1,7 @@
 // Generated by the protocol buffer compiler.  DO NOT EDIT!
 // source: vss.proto
 
+// Protobuf Java Version: 3.25.5
 package org.vss;
 
 /**
@@ -33,12 +34,6 @@ protected java.lang.Object newInstance(
 		return new GetObjectRequest();
 	}
 
-	@java.lang.Override
-	public final com.google.protobuf.UnknownFieldSet
-	getUnknownFields() {
-		return this.unknownFields;
-	}
-
 	public static final com.google.protobuf.Descriptors.Descriptor
 	getDescriptor() {
 		return org.vss.Vss.internal_static_vss_GetObjectRequest_descriptor;
@@ -53,7 +48,8 @@ protected java.lang.Object newInstance(
 	}
 
 	public static final int STORE_ID_FIELD_NUMBER = 1;
-	private volatile java.lang.Object storeId_;
+	@SuppressWarnings("serial")
+	private volatile java.lang.Object storeId_ = "";
 
 	/**
 	 * <pre>
@@ -113,16 +109,20 @@ public java.lang.String getStoreId() {
 	}
 
 	public static final int KEY_FIELD_NUMBER = 2;
-	private volatile java.lang.Object key_;
+	@SuppressWarnings("serial")
+	private volatile java.lang.Object key_ = "";
 
 	/**
 	 * <pre>
 	 * The key of the value to be fetched.
+	 *
 	 * If the specified `key` does not exist, returns `ErrorCode.NO_SUCH_KEY_EXCEPTION` in the
 	 * the `ErrorResponse`.
+	 *
 	 * Consistency Guarantee:
 	 * Get(read) operations against a `key` are consistent reads and will reflect all previous writes,
 	 * since Put/Write provides read-after-write and read-after-update consistency guarantees.
+	 *
 	 * Read Isolation:
 	 * Get/Read operations against a `key` are ensured to have read-committed isolation.
 	 * Ref: https://en.wikipedia.org/wiki/Isolation_(database_systems)#Read_committed
@@ -149,11 +149,14 @@ public java.lang.String getKey() {
 	/**
 	 * <pre>
 	 * The key of the value to be fetched.
+	 *
 	 * If the specified `key` does not exist, returns `ErrorCode.NO_SUCH_KEY_EXCEPTION` in the
 	 * the `ErrorResponse`.
+	 *
 	 * Consistency Guarantee:
 	 * Get(read) operations against a `key` are consistent reads and will reflect all previous writes,
 	 * since Put/Write provides read-after-write and read-after-update consistency guarantees.
+	 *
 	 * Read Isolation:
 	 * Get/Read operations against a `key` are ensured to have read-committed isolation.
 	 * Ref: https://en.wikipedia.org/wiki/Isolation_(database_systems)#Read_committed
@@ -398,10 +401,9 @@ private Builder(
 		@java.lang.Override
 		public Builder clear() {
 			super.clear();
+			bitField0_ = 0;
 			storeId_ = "";
-
 			key_ = "";
-
 			return this;
 		}
 
@@ -428,12 +430,23 @@ public org.vss.GetObjectRequest build() {
 		@java.lang.Override
 		public org.vss.GetObjectRequest buildPartial() {
 			org.vss.GetObjectRequest result = new org.vss.GetObjectRequest(this);
-			result.storeId_ = storeId_;
-			result.key_ = key_;
+			if (bitField0_ != 0) {
+				buildPartial0(result);
+			}
 			onBuilt();
 			return result;
 		}
 
+		private void buildPartial0(org.vss.GetObjectRequest result) {
+			int from_bitField0_ = bitField0_;
+			if (((from_bitField0_ & 0x00000001) != 0)) {
+				result.storeId_ = storeId_;
+			}
+			if (((from_bitField0_ & 0x00000002) != 0)) {
+				result.key_ = key_;
+			}
+		}
+
 		@java.lang.Override
 		public Builder clone() {
 			return super.clone();
@@ -486,10 +499,12 @@ public Builder mergeFrom(org.vss.GetObjectRequest other) {
 			if (other == org.vss.GetObjectRequest.getDefaultInstance()) return this;
 			if (!other.getStoreId().isEmpty()) {
 				storeId_ = other.storeId_;
+				bitField0_ |= 0x00000001;
 				onChanged();
 			}
 			if (!other.getKey().isEmpty()) {
 				key_ = other.key_;
+				bitField0_ |= 0x00000002;
 				onChanged();
 			}
 			this.mergeUnknownFields(other.getUnknownFields());
@@ -520,12 +535,12 @@ public Builder mergeFrom(
 							break;
 						case 10: {
 							storeId_ = input.readStringRequireUtf8();
-
+							bitField0_ |= 0x00000001;
 							break;
 						} // case 10
 						case 18: {
 							key_ = input.readStringRequireUtf8();
-
+							bitField0_ |= 0x00000002;
 							break;
 						} // case 18
 						default: {
@@ -544,6 +559,8 @@ public Builder mergeFrom(
 			return this;
 		}
 
+		private int bitField0_;
+
 		private java.lang.Object storeId_ = "";
 
 		/**
@@ -621,8 +638,8 @@ public Builder setStoreId(
 			if (value == null) {
 				throw new NullPointerException();
 			}
-
 			storeId_ = value;
+			bitField0_ |= 0x00000001;
 			onChanged();
 			return this;
 		}
@@ -642,8 +659,8 @@ public Builder setStoreId(
 		 * @return This builder for chaining.
 		 */
 		public Builder clearStoreId() {
-
 			storeId_ = getDefaultInstance().getStoreId();
+			bitField0_ = (bitField0_ & ~0x00000001);
 			onChanged();
 			return this;
 		}
@@ -669,8 +686,8 @@ public Builder setStoreIdBytes(
 				throw new NullPointerException();
 			}
 			checkByteStringIsUtf8(value);
-
 			storeId_ = value;
+			bitField0_ |= 0x00000001;
 			onChanged();
 			return this;
 		}
@@ -680,11 +697,14 @@ public Builder setStoreIdBytes(
 		/**
 		 * <pre>
 		 * The key of the value to be fetched.
+		 *
 		 * If the specified `key` does not exist, returns `ErrorCode.NO_SUCH_KEY_EXCEPTION` in the
 		 * the `ErrorResponse`.
+		 *
 		 * Consistency Guarantee:
 		 * Get(read) operations against a `key` are consistent reads and will reflect all previous writes,
 		 * since Put/Write provides read-after-write and read-after-update consistency guarantees.
+		 *
 		 * Read Isolation:
 		 * Get/Read operations against a `key` are ensured to have read-committed isolation.
 		 * Ref: https://en.wikipedia.org/wiki/Isolation_(database_systems)#Read_committed
@@ -710,11 +730,14 @@ public java.lang.String getKey() {
 		/**
 		 * <pre>
 		 * The key of the value to be fetched.
+		 *
 		 * If the specified `key` does not exist, returns `ErrorCode.NO_SUCH_KEY_EXCEPTION` in the
 		 * the `ErrorResponse`.
+		 *
 		 * Consistency Guarantee:
 		 * Get(read) operations against a `key` are consistent reads and will reflect all previous writes,
 		 * since Put/Write provides read-after-write and read-after-update consistency guarantees.
+		 *
 		 * Read Isolation:
 		 * Get/Read operations against a `key` are ensured to have read-committed isolation.
 		 * Ref: https://en.wikipedia.org/wiki/Isolation_(database_systems)#Read_committed
@@ -741,11 +764,14 @@ public java.lang.String getKey() {
 		/**
 		 * <pre>
 		 * The key of the value to be fetched.
+		 *
 		 * If the specified `key` does not exist, returns `ErrorCode.NO_SUCH_KEY_EXCEPTION` in the
 		 * the `ErrorResponse`.
+		 *
 		 * Consistency Guarantee:
 		 * Get(read) operations against a `key` are consistent reads and will reflect all previous writes,
 		 * since Put/Write provides read-after-write and read-after-update consistency guarantees.
+		 *
 		 * Read Isolation:
 		 * Get/Read operations against a `key` are ensured to have read-committed isolation.
 		 * Ref: https://en.wikipedia.org/wiki/Isolation_(database_systems)#Read_committed
@@ -761,8 +787,8 @@ public Builder setKey(
 			if (value == null) {
 				throw new NullPointerException();
 			}
-
 			key_ = value;
+			bitField0_ |= 0x00000002;
 			onChanged();
 			return this;
 		}
@@ -770,11 +796,14 @@ public Builder setKey(
 		/**
 		 * <pre>
 		 * The key of the value to be fetched.
+		 *
 		 * If the specified `key` does not exist, returns `ErrorCode.NO_SUCH_KEY_EXCEPTION` in the
 		 * the `ErrorResponse`.
+		 *
 		 * Consistency Guarantee:
 		 * Get(read) operations against a `key` are consistent reads and will reflect all previous writes,
 		 * since Put/Write provides read-after-write and read-after-update consistency guarantees.
+		 *
 		 * Read Isolation:
 		 * Get/Read operations against a `key` are ensured to have read-committed isolation.
 		 * Ref: https://en.wikipedia.org/wiki/Isolation_(database_systems)#Read_committed
@@ -785,8 +814,8 @@ public Builder setKey(
 		 * @return This builder for chaining.
 		 */
 		public Builder clearKey() {
-
 			key_ = getDefaultInstance().getKey();
+			bitField0_ = (bitField0_ & ~0x00000002);
 			onChanged();
 			return this;
 		}
@@ -794,11 +823,14 @@ public Builder clearKey() {
 		/**
 		 * <pre>
 		 * The key of the value to be fetched.
+		 *
 		 * If the specified `key` does not exist, returns `ErrorCode.NO_SUCH_KEY_EXCEPTION` in the
 		 * the `ErrorResponse`.
+		 *
 		 * Consistency Guarantee:
 		 * Get(read) operations against a `key` are consistent reads and will reflect all previous writes,
 		 * since Put/Write provides read-after-write and read-after-update consistency guarantees.
+		 *
 		 * Read Isolation:
 		 * Get/Read operations against a `key` are ensured to have read-committed isolation.
 		 * Ref: https://en.wikipedia.org/wiki/Isolation_(database_systems)#Read_committed
@@ -815,8 +847,8 @@ public Builder setKeyBytes(
 				throw new NullPointerException();
 			}
 			checkByteStringIsUtf8(value);
-
 			key_ = value;
+			bitField0_ |= 0x00000002;
 			onChanged();
 			return this;
 		}
diff --git a/java/app/src/main/generated/proto/org/vss/GetObjectRequestOrBuilder.java b/java/app/src/main/generated/proto/org/vss/GetObjectRequestOrBuilder.java
index e57542d..3150f62 100644
--- a/java/app/src/main/generated/proto/org/vss/GetObjectRequestOrBuilder.java
+++ b/java/app/src/main/generated/proto/org/vss/GetObjectRequestOrBuilder.java
@@ -1,6 +1,7 @@
 // Generated by the protocol buffer compiler.  DO NOT EDIT!
 // source: vss.proto
 
+// Protobuf Java Version: 3.25.5
 package org.vss;
 
 public interface GetObjectRequestOrBuilder extends
@@ -43,11 +44,14 @@ public interface GetObjectRequestOrBuilder extends
 	/**
 	 * <pre>
 	 * The key of the value to be fetched.
+	 *
 	 * If the specified `key` does not exist, returns `ErrorCode.NO_SUCH_KEY_EXCEPTION` in the
 	 * the `ErrorResponse`.
+	 *
 	 * Consistency Guarantee:
 	 * Get(read) operations against a `key` are consistent reads and will reflect all previous writes,
 	 * since Put/Write provides read-after-write and read-after-update consistency guarantees.
+	 *
 	 * Read Isolation:
 	 * Get/Read operations against a `key` are ensured to have read-committed isolation.
 	 * Ref: https://en.wikipedia.org/wiki/Isolation_(database_systems)#Read_committed
@@ -62,11 +66,14 @@ public interface GetObjectRequestOrBuilder extends
 	/**
 	 * <pre>
 	 * The key of the value to be fetched.
+	 *
 	 * If the specified `key` does not exist, returns `ErrorCode.NO_SUCH_KEY_EXCEPTION` in the
 	 * the `ErrorResponse`.
+	 *
 	 * Consistency Guarantee:
 	 * Get(read) operations against a `key` are consistent reads and will reflect all previous writes,
 	 * since Put/Write provides read-after-write and read-after-update consistency guarantees.
+	 *
 	 * Read Isolation:
 	 * Get/Read operations against a `key` are ensured to have read-committed isolation.
 	 * Ref: https://en.wikipedia.org/wiki/Isolation_(database_systems)#Read_committed
diff --git a/java/app/src/main/generated/proto/org/vss/GetObjectResponse.java b/java/app/src/main/generated/proto/org/vss/GetObjectResponse.java
index e4bf9dd..686e48a 100644
--- a/java/app/src/main/generated/proto/org/vss/GetObjectResponse.java
+++ b/java/app/src/main/generated/proto/org/vss/GetObjectResponse.java
@@ -1,6 +1,7 @@
 // Generated by the protocol buffer compiler.  DO NOT EDIT!
 // source: vss.proto
 
+// Protobuf Java Version: 3.25.5
 package org.vss;
 
 /**
@@ -31,12 +32,6 @@ protected java.lang.Object newInstance(
 		return new GetObjectResponse();
 	}
 
-	@java.lang.Override
-	public final com.google.protobuf.UnknownFieldSet
-	getUnknownFields() {
-		return this.unknownFields;
-	}
-
 	public static final com.google.protobuf.Descriptors.Descriptor
 	getDescriptor() {
 		return org.vss.Vss.internal_static_vss_GetObjectResponse_descriptor;
@@ -50,6 +45,7 @@ protected java.lang.Object newInstance(
 						org.vss.GetObjectResponse.class, org.vss.GetObjectResponse.Builder.class);
 	}
 
+	private int bitField0_;
 	public static final int VALUE_FIELD_NUMBER = 2;
 	private org.vss.KeyValue value_;
 
@@ -64,7 +60,7 @@ protected java.lang.Object newInstance(
 	 */
 	@java.lang.Override
 	public boolean hasValue() {
-		return value_ != null;
+		return ((bitField0_ & 0x00000001) != 0);
 	}
 
 	/**
@@ -90,7 +86,7 @@ public org.vss.KeyValue getValue() {
 	 */
 	@java.lang.Override
 	public org.vss.KeyValueOrBuilder getValueOrBuilder() {
-		return getValue();
+		return value_ == null ? org.vss.KeyValue.getDefaultInstance() : value_;
 	}
 
 	private byte memoizedIsInitialized = -1;
@@ -108,7 +104,7 @@ public final boolean isInitialized() {
 	@java.lang.Override
 	public void writeTo(com.google.protobuf.CodedOutputStream output)
 			throws java.io.IOException {
-		if (value_ != null) {
+		if (((bitField0_ & 0x00000001) != 0)) {
 			output.writeMessage(2, getValue());
 		}
 		getUnknownFields().writeTo(output);
@@ -120,7 +116,7 @@ public int getSerializedSize() {
 		if (size != -1) return size;
 
 		size = 0;
-		if (value_ != null) {
+		if (((bitField0_ & 0x00000001) != 0)) {
 			size += com.google.protobuf.CodedOutputStream
 					.computeMessageSize(2, getValue());
 		}
@@ -297,22 +293,29 @@ public static final class Builder extends
 
 		// Construct using org.vss.GetObjectResponse.newBuilder()
 		private Builder() {
-
+			maybeForceBuilderInitialization();
 		}
 
 		private Builder(
 				com.google.protobuf.GeneratedMessageV3.BuilderParent parent) {
 			super(parent);
+			maybeForceBuilderInitialization();
+		}
 
+		private void maybeForceBuilderInitialization() {
+			if (com.google.protobuf.GeneratedMessageV3
+					.alwaysUseFieldBuilders) {
+				getValueFieldBuilder();
+			}
 		}
 
 		@java.lang.Override
 		public Builder clear() {
 			super.clear();
-			if (valueBuilder_ == null) {
-				value_ = null;
-			} else {
-				value_ = null;
+			bitField0_ = 0;
+			value_ = null;
+			if (valueBuilder_ != null) {
+				valueBuilder_.dispose();
 				valueBuilder_ = null;
 			}
 			return this;
@@ -341,15 +344,25 @@ public org.vss.GetObjectResponse build() {
 		@java.lang.Override
 		public org.vss.GetObjectResponse buildPartial() {
 			org.vss.GetObjectResponse result = new org.vss.GetObjectResponse(this);
-			if (valueBuilder_ == null) {
-				result.value_ = value_;
-			} else {
-				result.value_ = valueBuilder_.build();
+			if (bitField0_ != 0) {
+				buildPartial0(result);
 			}
 			onBuilt();
 			return result;
 		}
 
+		private void buildPartial0(org.vss.GetObjectResponse result) {
+			int from_bitField0_ = bitField0_;
+			int to_bitField0_ = 0;
+			if (((from_bitField0_ & 0x00000001) != 0)) {
+				result.value_ = valueBuilder_ == null
+						? value_
+						: valueBuilder_.build();
+				to_bitField0_ |= 0x00000001;
+			}
+			result.bitField0_ |= to_bitField0_;
+		}
+
 		@java.lang.Override
 		public Builder clone() {
 			return super.clone();
@@ -433,7 +446,7 @@ public Builder mergeFrom(
 							input.readMessage(
 									getValueFieldBuilder().getBuilder(),
 									extensionRegistry);
-
+							bitField0_ |= 0x00000001;
 							break;
 						} // case 18
 						default: {
@@ -452,6 +465,8 @@ public Builder mergeFrom(
 			return this;
 		}
 
+		private int bitField0_;
+
 		private org.vss.KeyValue value_;
 		private com.google.protobuf.SingleFieldBuilderV3<
 				org.vss.KeyValue, org.vss.KeyValue.Builder, org.vss.KeyValueOrBuilder> valueBuilder_;
@@ -466,7 +481,7 @@ public Builder mergeFrom(
 		 * @return Whether the value field is set.
 		 */
 		public boolean hasValue() {
-			return valueBuilder_ != null || value_ != null;
+			return ((bitField0_ & 0x00000001) != 0);
 		}
 
 		/**
@@ -499,11 +514,11 @@ public Builder setValue(org.vss.KeyValue value) {
 					throw new NullPointerException();
 				}
 				value_ = value;
-				onChanged();
 			} else {
 				valueBuilder_.setMessage(value);
 			}
-
+			bitField0_ |= 0x00000001;
+			onChanged();
 			return this;
 		}
 
@@ -518,11 +533,11 @@ public Builder setValue(
 				org.vss.KeyValue.Builder builderForValue) {
 			if (valueBuilder_ == null) {
 				value_ = builderForValue.build();
-				onChanged();
 			} else {
 				valueBuilder_.setMessage(builderForValue.build());
 			}
-
+			bitField0_ |= 0x00000001;
+			onChanged();
 			return this;
 		}
 
@@ -535,17 +550,20 @@ public Builder setValue(
 		 */
 		public Builder mergeValue(org.vss.KeyValue value) {
 			if (valueBuilder_ == null) {
-				if (value_ != null) {
-					value_ =
-							org.vss.KeyValue.newBuilder(value_).mergeFrom(value).buildPartial();
+				if (((bitField0_ & 0x00000001) != 0) &&
+						value_ != null &&
+						value_ != org.vss.KeyValue.getDefaultInstance()) {
+					getValueBuilder().mergeFrom(value);
 				} else {
 					value_ = value;
 				}
-				onChanged();
 			} else {
 				valueBuilder_.mergeFrom(value);
 			}
-
+			if (value_ != null) {
+				bitField0_ |= 0x00000001;
+				onChanged();
+			}
 			return this;
 		}
 
@@ -557,14 +575,13 @@ public Builder mergeValue(org.vss.KeyValue value) {
 		 * <code>.vss.KeyValue value = 2;</code>
 		 */
 		public Builder clearValue() {
-			if (valueBuilder_ == null) {
-				value_ = null;
-				onChanged();
-			} else {
-				value_ = null;
+			bitField0_ = (bitField0_ & ~0x00000001);
+			value_ = null;
+			if (valueBuilder_ != null) {
+				valueBuilder_.dispose();
 				valueBuilder_ = null;
 			}
-
+			onChanged();
 			return this;
 		}
 
@@ -576,7 +593,7 @@ public Builder clearValue() {
 		 * <code>.vss.KeyValue value = 2;</code>
 		 */
 		public org.vss.KeyValue.Builder getValueBuilder() {
-
+			bitField0_ |= 0x00000001;
 			onChanged();
 			return getValueFieldBuilder().getBuilder();
 		}
diff --git a/java/app/src/main/generated/proto/org/vss/GetObjectResponseOrBuilder.java b/java/app/src/main/generated/proto/org/vss/GetObjectResponseOrBuilder.java
index 19be268..4903be2 100644
--- a/java/app/src/main/generated/proto/org/vss/GetObjectResponseOrBuilder.java
+++ b/java/app/src/main/generated/proto/org/vss/GetObjectResponseOrBuilder.java
@@ -1,6 +1,7 @@
 // Generated by the protocol buffer compiler.  DO NOT EDIT!
 // source: vss.proto
 
+// Protobuf Java Version: 3.25.5
 package org.vss;
 
 public interface GetObjectResponseOrBuilder extends
diff --git a/java/app/src/main/generated/proto/org/vss/KeyValue.java b/java/app/src/main/generated/proto/org/vss/KeyValue.java
index 1ef1fa8..76d3fc0 100644
--- a/java/app/src/main/generated/proto/org/vss/KeyValue.java
+++ b/java/app/src/main/generated/proto/org/vss/KeyValue.java
@@ -1,6 +1,7 @@
 // Generated by the protocol buffer compiler.  DO NOT EDIT!
 // source: vss.proto
 
+// Protobuf Java Version: 3.25.5
 package org.vss;
 
 /**
@@ -33,12 +34,6 @@ protected java.lang.Object newInstance(
 		return new KeyValue();
 	}
 
-	@java.lang.Override
-	public final com.google.protobuf.UnknownFieldSet
-	getUnknownFields() {
-		return this.unknownFields;
-	}
-
 	public static final com.google.protobuf.Descriptors.Descriptor
 	getDescriptor() {
 		return org.vss.Vss.internal_static_vss_KeyValue_descriptor;
@@ -53,7 +48,8 @@ protected java.lang.Object newInstance(
 	}
 
 	public static final int KEY_FIELD_NUMBER = 1;
-	private volatile java.lang.Object key_;
+	@SuppressWarnings("serial")
+	private volatile java.lang.Object key_ = "";
 
 	/**
 	 * <pre>
@@ -103,7 +99,7 @@ public java.lang.String getKey() {
 	}
 
 	public static final int VERSION_FIELD_NUMBER = 2;
-	private long version_;
+	private long version_ = 0L;
 
 	/**
 	 * <pre>
@@ -125,7 +121,7 @@ public long getVersion() {
 	}
 
 	public static final int VALUE_FIELD_NUMBER = 3;
-	private com.google.protobuf.ByteString value_;
+	private com.google.protobuf.ByteString value_ = com.google.protobuf.ByteString.EMPTY;
 
 	/**
 	 * <pre>
@@ -377,12 +373,10 @@ private Builder(
 		@java.lang.Override
 		public Builder clear() {
 			super.clear();
+			bitField0_ = 0;
 			key_ = "";
-
 			version_ = 0L;
-
 			value_ = com.google.protobuf.ByteString.EMPTY;
-
 			return this;
 		}
 
@@ -409,13 +403,26 @@ public org.vss.KeyValue build() {
 		@java.lang.Override
 		public org.vss.KeyValue buildPartial() {
 			org.vss.KeyValue result = new org.vss.KeyValue(this);
-			result.key_ = key_;
-			result.version_ = version_;
-			result.value_ = value_;
+			if (bitField0_ != 0) {
+				buildPartial0(result);
+			}
 			onBuilt();
 			return result;
 		}
 
+		private void buildPartial0(org.vss.KeyValue result) {
+			int from_bitField0_ = bitField0_;
+			if (((from_bitField0_ & 0x00000001) != 0)) {
+				result.key_ = key_;
+			}
+			if (((from_bitField0_ & 0x00000002) != 0)) {
+				result.version_ = version_;
+			}
+			if (((from_bitField0_ & 0x00000004) != 0)) {
+				result.value_ = value_;
+			}
+		}
+
 		@java.lang.Override
 		public Builder clone() {
 			return super.clone();
@@ -468,6 +475,7 @@ public Builder mergeFrom(org.vss.KeyValue other) {
 			if (other == org.vss.KeyValue.getDefaultInstance()) return this;
 			if (!other.getKey().isEmpty()) {
 				key_ = other.key_;
+				bitField0_ |= 0x00000001;
 				onChanged();
 			}
 			if (other.getVersion() != 0L) {
@@ -504,17 +512,17 @@ public Builder mergeFrom(
 							break;
 						case 10: {
 							key_ = input.readStringRequireUtf8();
-
+							bitField0_ |= 0x00000001;
 							break;
 						} // case 10
 						case 16: {
 							version_ = input.readInt64();
-
+							bitField0_ |= 0x00000002;
 							break;
 						} // case 16
 						case 26: {
 							value_ = input.readBytes();
-
+							bitField0_ |= 0x00000004;
 							break;
 						} // case 26
 						default: {
@@ -533,6 +541,8 @@ public Builder mergeFrom(
 			return this;
 		}
 
+		private int bitField0_;
+
 		private java.lang.Object key_ = "";
 
 		/**
@@ -595,8 +605,8 @@ public Builder setKey(
 			if (value == null) {
 				throw new NullPointerException();
 			}
-
 			key_ = value;
+			bitField0_ |= 0x00000001;
 			onChanged();
 			return this;
 		}
@@ -611,8 +621,8 @@ public Builder setKey(
 		 * @return This builder for chaining.
 		 */
 		public Builder clearKey() {
-
 			key_ = getDefaultInstance().getKey();
+			bitField0_ = (bitField0_ & ~0x00000001);
 			onChanged();
 			return this;
 		}
@@ -633,8 +643,8 @@ public Builder setKeyBytes(
 				throw new NullPointerException();
 			}
 			checkByteStringIsUtf8(value);
-
 			key_ = value;
+			bitField0_ |= 0x00000001;
 			onChanged();
 			return this;
 		}
@@ -678,6 +688,7 @@ public long getVersion() {
 		public Builder setVersion(long value) {
 
 			version_ = value;
+			bitField0_ |= 0x00000002;
 			onChanged();
 			return this;
 		}
@@ -697,7 +708,7 @@ public Builder setVersion(long value) {
 		 * @return This builder for chaining.
 		 */
 		public Builder clearVersion() {
-
+			bitField0_ = (bitField0_ & ~0x00000002);
 			version_ = 0L;
 			onChanged();
 			return this;
@@ -739,8 +750,8 @@ public Builder setValue(com.google.protobuf.ByteString value) {
 			if (value == null) {
 				throw new NullPointerException();
 			}
-
 			value_ = value;
+			bitField0_ |= 0x00000004;
 			onChanged();
 			return this;
 		}
@@ -758,7 +769,7 @@ public Builder setValue(com.google.protobuf.ByteString value) {
 		 * @return This builder for chaining.
 		 */
 		public Builder clearValue() {
-
+			bitField0_ = (bitField0_ & ~0x00000004);
 			value_ = getDefaultInstance().getValue();
 			onChanged();
 			return this;
diff --git a/java/app/src/main/generated/proto/org/vss/KeyValueOrBuilder.java b/java/app/src/main/generated/proto/org/vss/KeyValueOrBuilder.java
index 1728e8d..3c92503 100644
--- a/java/app/src/main/generated/proto/org/vss/KeyValueOrBuilder.java
+++ b/java/app/src/main/generated/proto/org/vss/KeyValueOrBuilder.java
@@ -1,6 +1,7 @@
 // Generated by the protocol buffer compiler.  DO NOT EDIT!
 // source: vss.proto
 
+// Protobuf Java Version: 3.25.5
 package org.vss;
 
 public interface KeyValueOrBuilder extends
diff --git a/java/app/src/main/generated/proto/org/vss/ListKeyVersionsRequest.java b/java/app/src/main/generated/proto/org/vss/ListKeyVersionsRequest.java
index af516f8..ea35ff9 100644
--- a/java/app/src/main/generated/proto/org/vss/ListKeyVersionsRequest.java
+++ b/java/app/src/main/generated/proto/org/vss/ListKeyVersionsRequest.java
@@ -1,6 +1,7 @@
 // Generated by the protocol buffer compiler.  DO NOT EDIT!
 // source: vss.proto
 
+// Protobuf Java Version: 3.25.5
 package org.vss;
 
 /**
@@ -34,12 +35,6 @@ protected java.lang.Object newInstance(
 		return new ListKeyVersionsRequest();
 	}
 
-	@java.lang.Override
-	public final com.google.protobuf.UnknownFieldSet
-	getUnknownFields() {
-		return this.unknownFields;
-	}
-
 	public static final com.google.protobuf.Descriptors.Descriptor
 	getDescriptor() {
 		return org.vss.Vss.internal_static_vss_ListKeyVersionsRequest_descriptor;
@@ -55,7 +50,8 @@ protected java.lang.Object newInstance(
 
 	private int bitField0_;
 	public static final int STORE_ID_FIELD_NUMBER = 1;
-	private volatile java.lang.Object storeId_;
+	@SuppressWarnings("serial")
+	private volatile java.lang.Object storeId_ = "";
 
 	/**
 	 * <pre>
@@ -115,14 +111,17 @@ public java.lang.String getStoreId() {
 	}
 
 	public static final int KEY_PREFIX_FIELD_NUMBER = 2;
-	private volatile java.lang.Object keyPrefix_;
+	@SuppressWarnings("serial")
+	private volatile java.lang.Object keyPrefix_ = "";
 
 	/**
 	 * <pre>
 	 * A `key_prefix` is a string of characters at the beginning of the key. Prefixes can be used as
 	 * a way to organize key-values in a similar way to directories.
+	 *
 	 * If `key_prefix` is specified, the response results will be limited to those keys that begin with
 	 * the specified prefix.
+	 *
 	 * If no `key_prefix` is specified or it is empty (""), all the keys are eligible to be returned in
 	 * the response.
 	 * </pre>
@@ -140,8 +139,10 @@ public boolean hasKeyPrefix() {
 	 * <pre>
 	 * A `key_prefix` is a string of characters at the beginning of the key. Prefixes can be used as
 	 * a way to organize key-values in a similar way to directories.
+	 *
 	 * If `key_prefix` is specified, the response results will be limited to those keys that begin with
 	 * the specified prefix.
+	 *
 	 * If no `key_prefix` is specified or it is empty (""), all the keys are eligible to be returned in
 	 * the response.
 	 * </pre>
@@ -168,8 +169,10 @@ public java.lang.String getKeyPrefix() {
 	 * <pre>
 	 * A `key_prefix` is a string of characters at the beginning of the key. Prefixes can be used as
 	 * a way to organize key-values in a similar way to directories.
+	 *
 	 * If `key_prefix` is specified, the response results will be limited to those keys that begin with
 	 * the specified prefix.
+	 *
 	 * If no `key_prefix` is specified or it is empty (""), all the keys are eligible to be returned in
 	 * the response.
 	 * </pre>
@@ -194,7 +197,7 @@ public java.lang.String getKeyPrefix() {
 	}
 
 	public static final int PAGE_SIZE_FIELD_NUMBER = 3;
-	private int pageSize_;
+	private int pageSize_ = 0;
 
 	/**
 	 * <pre>
@@ -231,12 +234,15 @@ public int getPageSize() {
 	}
 
 	public static final int PAGE_TOKEN_FIELD_NUMBER = 4;
-	private volatile java.lang.Object pageToken_;
+	@SuppressWarnings("serial")
+	private volatile java.lang.Object pageToken_ = "";
 
 	/**
 	 * <pre>
 	 * `page_token` is a pagination token.
+	 *
 	 * To query for the first page of `ListKeyVersions`, `page_token` must not be specified.
+	 *
 	 * For subsequent pages, use the value that was returned as `next_page_token` in the previous
 	 * page's `ListKeyVersionsResponse`.
 	 * </pre>
@@ -253,7 +259,9 @@ public boolean hasPageToken() {
 	/**
 	 * <pre>
 	 * `page_token` is a pagination token.
+	 *
 	 * To query for the first page of `ListKeyVersions`, `page_token` must not be specified.
+	 *
 	 * For subsequent pages, use the value that was returned as `next_page_token` in the previous
 	 * page's `ListKeyVersionsResponse`.
 	 * </pre>
@@ -279,7 +287,9 @@ public java.lang.String getPageToken() {
 	/**
 	 * <pre>
 	 * `page_token` is a pagination token.
+	 *
 	 * To query for the first page of `ListKeyVersions`, `page_token` must not be specified.
+	 *
 	 * For subsequent pages, use the value that was returned as `next_page_token` in the previous
 	 * page's `ListKeyVersionsResponse`.
 	 * </pre>
@@ -559,14 +569,11 @@ private Builder(
 		@java.lang.Override
 		public Builder clear() {
 			super.clear();
+			bitField0_ = 0;
 			storeId_ = "";
-
 			keyPrefix_ = "";
-			bitField0_ = (bitField0_ & ~0x00000001);
 			pageSize_ = 0;
-			bitField0_ = (bitField0_ & ~0x00000002);
 			pageToken_ = "";
-			bitField0_ = (bitField0_ & ~0x00000004);
 			return this;
 		}
 
@@ -593,24 +600,32 @@ public org.vss.ListKeyVersionsRequest build() {
 		@java.lang.Override
 		public org.vss.ListKeyVersionsRequest buildPartial() {
 			org.vss.ListKeyVersionsRequest result = new org.vss.ListKeyVersionsRequest(this);
+			if (bitField0_ != 0) {
+				buildPartial0(result);
+			}
+			onBuilt();
+			return result;
+		}
+
+		private void buildPartial0(org.vss.ListKeyVersionsRequest result) {
 			int from_bitField0_ = bitField0_;
-			int to_bitField0_ = 0;
-			result.storeId_ = storeId_;
 			if (((from_bitField0_ & 0x00000001) != 0)) {
-				to_bitField0_ |= 0x00000001;
+				result.storeId_ = storeId_;
 			}
-			result.keyPrefix_ = keyPrefix_;
+			int to_bitField0_ = 0;
 			if (((from_bitField0_ & 0x00000002) != 0)) {
+				result.keyPrefix_ = keyPrefix_;
+				to_bitField0_ |= 0x00000001;
+			}
+			if (((from_bitField0_ & 0x00000004) != 0)) {
 				result.pageSize_ = pageSize_;
 				to_bitField0_ |= 0x00000002;
 			}
-			if (((from_bitField0_ & 0x00000004) != 0)) {
+			if (((from_bitField0_ & 0x00000008) != 0)) {
+				result.pageToken_ = pageToken_;
 				to_bitField0_ |= 0x00000004;
 			}
-			result.pageToken_ = pageToken_;
-			result.bitField0_ = to_bitField0_;
-			onBuilt();
-			return result;
+			result.bitField0_ |= to_bitField0_;
 		}
 
 		@java.lang.Override
@@ -665,19 +680,20 @@ public Builder mergeFrom(org.vss.ListKeyVersionsRequest other) {
 			if (other == org.vss.ListKeyVersionsRequest.getDefaultInstance()) return this;
 			if (!other.getStoreId().isEmpty()) {
 				storeId_ = other.storeId_;
+				bitField0_ |= 0x00000001;
 				onChanged();
 			}
 			if (other.hasKeyPrefix()) {
-				bitField0_ |= 0x00000001;
 				keyPrefix_ = other.keyPrefix_;
+				bitField0_ |= 0x00000002;
 				onChanged();
 			}
 			if (other.hasPageSize()) {
 				setPageSize(other.getPageSize());
 			}
 			if (other.hasPageToken()) {
-				bitField0_ |= 0x00000004;
 				pageToken_ = other.pageToken_;
+				bitField0_ |= 0x00000008;
 				onChanged();
 			}
 			this.mergeUnknownFields(other.getUnknownFields());
@@ -708,22 +724,22 @@ public Builder mergeFrom(
 							break;
 						case 10: {
 							storeId_ = input.readStringRequireUtf8();
-
+							bitField0_ |= 0x00000001;
 							break;
 						} // case 10
 						case 18: {
 							keyPrefix_ = input.readStringRequireUtf8();
-							bitField0_ |= 0x00000001;
+							bitField0_ |= 0x00000002;
 							break;
 						} // case 18
 						case 24: {
 							pageSize_ = input.readInt32();
-							bitField0_ |= 0x00000002;
+							bitField0_ |= 0x00000004;
 							break;
 						} // case 24
 						case 34: {
 							pageToken_ = input.readStringRequireUtf8();
-							bitField0_ |= 0x00000004;
+							bitField0_ |= 0x00000008;
 							break;
 						} // case 34
 						default: {
@@ -821,8 +837,8 @@ public Builder setStoreId(
 			if (value == null) {
 				throw new NullPointerException();
 			}
-
 			storeId_ = value;
+			bitField0_ |= 0x00000001;
 			onChanged();
 			return this;
 		}
@@ -842,8 +858,8 @@ public Builder setStoreId(
 		 * @return This builder for chaining.
 		 */
 		public Builder clearStoreId() {
-
 			storeId_ = getDefaultInstance().getStoreId();
+			bitField0_ = (bitField0_ & ~0x00000001);
 			onChanged();
 			return this;
 		}
@@ -869,8 +885,8 @@ public Builder setStoreIdBytes(
 				throw new NullPointerException();
 			}
 			checkByteStringIsUtf8(value);
-
 			storeId_ = value;
+			bitField0_ |= 0x00000001;
 			onChanged();
 			return this;
 		}
@@ -881,8 +897,10 @@ public Builder setStoreIdBytes(
 		 * <pre>
 		 * A `key_prefix` is a string of characters at the beginning of the key. Prefixes can be used as
 		 * a way to organize key-values in a similar way to directories.
+		 *
 		 * If `key_prefix` is specified, the response results will be limited to those keys that begin with
 		 * the specified prefix.
+		 *
 		 * If no `key_prefix` is specified or it is empty (""), all the keys are eligible to be returned in
 		 * the response.
 		 * </pre>
@@ -892,15 +910,17 @@ public Builder setStoreIdBytes(
 		 * @return Whether the keyPrefix field is set.
 		 */
 		public boolean hasKeyPrefix() {
-			return ((bitField0_ & 0x00000001) != 0);
+			return ((bitField0_ & 0x00000002) != 0);
 		}
 
 		/**
 		 * <pre>
 		 * A `key_prefix` is a string of characters at the beginning of the key. Prefixes can be used as
 		 * a way to organize key-values in a similar way to directories.
+		 *
 		 * If `key_prefix` is specified, the response results will be limited to those keys that begin with
 		 * the specified prefix.
+		 *
 		 * If no `key_prefix` is specified or it is empty (""), all the keys are eligible to be returned in
 		 * the response.
 		 * </pre>
@@ -926,8 +946,10 @@ public java.lang.String getKeyPrefix() {
 		 * <pre>
 		 * A `key_prefix` is a string of characters at the beginning of the key. Prefixes can be used as
 		 * a way to organize key-values in a similar way to directories.
+		 *
 		 * If `key_prefix` is specified, the response results will be limited to those keys that begin with
 		 * the specified prefix.
+		 *
 		 * If no `key_prefix` is specified or it is empty (""), all the keys are eligible to be returned in
 		 * the response.
 		 * </pre>
@@ -954,8 +976,10 @@ public java.lang.String getKeyPrefix() {
 		 * <pre>
 		 * A `key_prefix` is a string of characters at the beginning of the key. Prefixes can be used as
 		 * a way to organize key-values in a similar way to directories.
+		 *
 		 * If `key_prefix` is specified, the response results will be limited to those keys that begin with
 		 * the specified prefix.
+		 *
 		 * If no `key_prefix` is specified or it is empty (""), all the keys are eligible to be returned in
 		 * the response.
 		 * </pre>
@@ -970,8 +994,8 @@ public Builder setKeyPrefix(
 			if (value == null) {
 				throw new NullPointerException();
 			}
-			bitField0_ |= 0x00000001;
 			keyPrefix_ = value;
+			bitField0_ |= 0x00000002;
 			onChanged();
 			return this;
 		}
@@ -980,8 +1004,10 @@ public Builder setKeyPrefix(
 		 * <pre>
 		 * A `key_prefix` is a string of characters at the beginning of the key. Prefixes can be used as
 		 * a way to organize key-values in a similar way to directories.
+		 *
 		 * If `key_prefix` is specified, the response results will be limited to those keys that begin with
 		 * the specified prefix.
+		 *
 		 * If no `key_prefix` is specified or it is empty (""), all the keys are eligible to be returned in
 		 * the response.
 		 * </pre>
@@ -991,8 +1017,8 @@ public Builder setKeyPrefix(
 		 * @return This builder for chaining.
 		 */
 		public Builder clearKeyPrefix() {
-			bitField0_ = (bitField0_ & ~0x00000001);
 			keyPrefix_ = getDefaultInstance().getKeyPrefix();
+			bitField0_ = (bitField0_ & ~0x00000002);
 			onChanged();
 			return this;
 		}
@@ -1001,8 +1027,10 @@ public Builder clearKeyPrefix() {
 		 * <pre>
 		 * A `key_prefix` is a string of characters at the beginning of the key. Prefixes can be used as
 		 * a way to organize key-values in a similar way to directories.
+		 *
 		 * If `key_prefix` is specified, the response results will be limited to those keys that begin with
 		 * the specified prefix.
+		 *
 		 * If no `key_prefix` is specified or it is empty (""), all the keys are eligible to be returned in
 		 * the response.
 		 * </pre>
@@ -1018,8 +1046,8 @@ public Builder setKeyPrefixBytes(
 				throw new NullPointerException();
 			}
 			checkByteStringIsUtf8(value);
-			bitField0_ |= 0x00000001;
 			keyPrefix_ = value;
+			bitField0_ |= 0x00000002;
 			onChanged();
 			return this;
 		}
@@ -1040,7 +1068,7 @@ public Builder setKeyPrefixBytes(
 		 */
 		@java.lang.Override
 		public boolean hasPageSize() {
-			return ((bitField0_ & 0x00000002) != 0);
+			return ((bitField0_ & 0x00000004) != 0);
 		}
 
 		/**
@@ -1074,8 +1102,9 @@ public int getPageSize() {
 		 * @return This builder for chaining.
 		 */
 		public Builder setPageSize(int value) {
-			bitField0_ |= 0x00000002;
+
 			pageSize_ = value;
+			bitField0_ |= 0x00000004;
 			onChanged();
 			return this;
 		}
@@ -1093,7 +1122,7 @@ public Builder setPageSize(int value) {
 		 * @return This builder for chaining.
 		 */
 		public Builder clearPageSize() {
-			bitField0_ = (bitField0_ & ~0x00000002);
+			bitField0_ = (bitField0_ & ~0x00000004);
 			pageSize_ = 0;
 			onChanged();
 			return this;
@@ -1104,7 +1133,9 @@ public Builder clearPageSize() {
 		/**
 		 * <pre>
 		 * `page_token` is a pagination token.
+		 *
 		 * To query for the first page of `ListKeyVersions`, `page_token` must not be specified.
+		 *
 		 * For subsequent pages, use the value that was returned as `next_page_token` in the previous
 		 * page's `ListKeyVersionsResponse`.
 		 * </pre>
@@ -1114,13 +1145,15 @@ public Builder clearPageSize() {
 		 * @return Whether the pageToken field is set.
 		 */
 		public boolean hasPageToken() {
-			return ((bitField0_ & 0x00000004) != 0);
+			return ((bitField0_ & 0x00000008) != 0);
 		}
 
 		/**
 		 * <pre>
 		 * `page_token` is a pagination token.
+		 *
 		 * To query for the first page of `ListKeyVersions`, `page_token` must not be specified.
+		 *
 		 * For subsequent pages, use the value that was returned as `next_page_token` in the previous
 		 * page's `ListKeyVersionsResponse`.
 		 * </pre>
@@ -1145,7 +1178,9 @@ public java.lang.String getPageToken() {
 		/**
 		 * <pre>
 		 * `page_token` is a pagination token.
+		 *
 		 * To query for the first page of `ListKeyVersions`, `page_token` must not be specified.
+		 *
 		 * For subsequent pages, use the value that was returned as `next_page_token` in the previous
 		 * page's `ListKeyVersionsResponse`.
 		 * </pre>
@@ -1171,7 +1206,9 @@ public java.lang.String getPageToken() {
 		/**
 		 * <pre>
 		 * `page_token` is a pagination token.
+		 *
 		 * To query for the first page of `ListKeyVersions`, `page_token` must not be specified.
+		 *
 		 * For subsequent pages, use the value that was returned as `next_page_token` in the previous
 		 * page's `ListKeyVersionsResponse`.
 		 * </pre>
@@ -1186,8 +1223,8 @@ public Builder setPageToken(
 			if (value == null) {
 				throw new NullPointerException();
 			}
-			bitField0_ |= 0x00000004;
 			pageToken_ = value;
+			bitField0_ |= 0x00000008;
 			onChanged();
 			return this;
 		}
@@ -1195,7 +1232,9 @@ public Builder setPageToken(
 		/**
 		 * <pre>
 		 * `page_token` is a pagination token.
+		 *
 		 * To query for the first page of `ListKeyVersions`, `page_token` must not be specified.
+		 *
 		 * For subsequent pages, use the value that was returned as `next_page_token` in the previous
 		 * page's `ListKeyVersionsResponse`.
 		 * </pre>
@@ -1205,8 +1244,8 @@ public Builder setPageToken(
 		 * @return This builder for chaining.
 		 */
 		public Builder clearPageToken() {
-			bitField0_ = (bitField0_ & ~0x00000004);
 			pageToken_ = getDefaultInstance().getPageToken();
+			bitField0_ = (bitField0_ & ~0x00000008);
 			onChanged();
 			return this;
 		}
@@ -1214,7 +1253,9 @@ public Builder clearPageToken() {
 		/**
 		 * <pre>
 		 * `page_token` is a pagination token.
+		 *
 		 * To query for the first page of `ListKeyVersions`, `page_token` must not be specified.
+		 *
 		 * For subsequent pages, use the value that was returned as `next_page_token` in the previous
 		 * page's `ListKeyVersionsResponse`.
 		 * </pre>
@@ -1230,8 +1271,8 @@ public Builder setPageTokenBytes(
 				throw new NullPointerException();
 			}
 			checkByteStringIsUtf8(value);
-			bitField0_ |= 0x00000004;
 			pageToken_ = value;
+			bitField0_ |= 0x00000008;
 			onChanged();
 			return this;
 		}
diff --git a/java/app/src/main/generated/proto/org/vss/ListKeyVersionsRequestOrBuilder.java b/java/app/src/main/generated/proto/org/vss/ListKeyVersionsRequestOrBuilder.java
index c453685..003e74b 100644
--- a/java/app/src/main/generated/proto/org/vss/ListKeyVersionsRequestOrBuilder.java
+++ b/java/app/src/main/generated/proto/org/vss/ListKeyVersionsRequestOrBuilder.java
@@ -1,6 +1,7 @@
 // Generated by the protocol buffer compiler.  DO NOT EDIT!
 // source: vss.proto
 
+// Protobuf Java Version: 3.25.5
 package org.vss;
 
 public interface ListKeyVersionsRequestOrBuilder extends
@@ -44,8 +45,10 @@ public interface ListKeyVersionsRequestOrBuilder extends
 	 * <pre>
 	 * A `key_prefix` is a string of characters at the beginning of the key. Prefixes can be used as
 	 * a way to organize key-values in a similar way to directories.
+	 *
 	 * If `key_prefix` is specified, the response results will be limited to those keys that begin with
 	 * the specified prefix.
+	 *
 	 * If no `key_prefix` is specified or it is empty (""), all the keys are eligible to be returned in
 	 * the response.
 	 * </pre>
@@ -60,8 +63,10 @@ public interface ListKeyVersionsRequestOrBuilder extends
 	 * <pre>
 	 * A `key_prefix` is a string of characters at the beginning of the key. Prefixes can be used as
 	 * a way to organize key-values in a similar way to directories.
+	 *
 	 * If `key_prefix` is specified, the response results will be limited to those keys that begin with
 	 * the specified prefix.
+	 *
 	 * If no `key_prefix` is specified or it is empty (""), all the keys are eligible to be returned in
 	 * the response.
 	 * </pre>
@@ -76,8 +81,10 @@ public interface ListKeyVersionsRequestOrBuilder extends
 	 * <pre>
 	 * A `key_prefix` is a string of characters at the beginning of the key. Prefixes can be used as
 	 * a way to organize key-values in a similar way to directories.
+	 *
 	 * If `key_prefix` is specified, the response results will be limited to those keys that begin with
 	 * the specified prefix.
+	 *
 	 * If no `key_prefix` is specified or it is empty (""), all the keys are eligible to be returned in
 	 * the response.
 	 * </pre>
@@ -120,7 +127,9 @@ public interface ListKeyVersionsRequestOrBuilder extends
 	/**
 	 * <pre>
 	 * `page_token` is a pagination token.
+	 *
 	 * To query for the first page of `ListKeyVersions`, `page_token` must not be specified.
+	 *
 	 * For subsequent pages, use the value that was returned as `next_page_token` in the previous
 	 * page's `ListKeyVersionsResponse`.
 	 * </pre>
@@ -134,7 +143,9 @@ public interface ListKeyVersionsRequestOrBuilder extends
 	/**
 	 * <pre>
 	 * `page_token` is a pagination token.
+	 *
 	 * To query for the first page of `ListKeyVersions`, `page_token` must not be specified.
+	 *
 	 * For subsequent pages, use the value that was returned as `next_page_token` in the previous
 	 * page's `ListKeyVersionsResponse`.
 	 * </pre>
@@ -148,7 +159,9 @@ public interface ListKeyVersionsRequestOrBuilder extends
 	/**
 	 * <pre>
 	 * `page_token` is a pagination token.
+	 *
 	 * To query for the first page of `ListKeyVersions`, `page_token` must not be specified.
+	 *
 	 * For subsequent pages, use the value that was returned as `next_page_token` in the previous
 	 * page's `ListKeyVersionsResponse`.
 	 * </pre>
diff --git a/java/app/src/main/generated/proto/org/vss/ListKeyVersionsResponse.java b/java/app/src/main/generated/proto/org/vss/ListKeyVersionsResponse.java
index 7079dd5..50491dd 100644
--- a/java/app/src/main/generated/proto/org/vss/ListKeyVersionsResponse.java
+++ b/java/app/src/main/generated/proto/org/vss/ListKeyVersionsResponse.java
@@ -1,6 +1,7 @@
 // Generated by the protocol buffer compiler.  DO NOT EDIT!
 // source: vss.proto
 
+// Protobuf Java Version: 3.25.5
 package org.vss;
 
 /**
@@ -33,12 +34,6 @@ protected java.lang.Object newInstance(
 		return new ListKeyVersionsResponse();
 	}
 
-	@java.lang.Override
-	public final com.google.protobuf.UnknownFieldSet
-	getUnknownFields() {
-		return this.unknownFields;
-	}
-
 	public static final com.google.protobuf.Descriptors.Descriptor
 	getDescriptor() {
 		return org.vss.Vss.internal_static_vss_ListKeyVersionsResponse_descriptor;
@@ -54,6 +49,7 @@ protected java.lang.Object newInstance(
 
 	private int bitField0_;
 	public static final int KEY_VERSIONS_FIELD_NUMBER = 1;
+	@SuppressWarnings("serial")
 	private java.util.List<org.vss.KeyValue> keyVersions_;
 
 	/**
@@ -124,18 +120,22 @@ public org.vss.KeyValueOrBuilder getKeyVersionsOrBuilder(
 	}
 
 	public static final int NEXT_PAGE_TOKEN_FIELD_NUMBER = 2;
-	private volatile java.lang.Object nextPageToken_;
+	@SuppressWarnings("serial")
+	private volatile java.lang.Object nextPageToken_ = "";
 
 	/**
 	 * <pre>
 	 * `next_page_token` is a pagination token, used to retrieve the next page of results.
 	 * Use this value to query for next-page of paginated `ListKeyVersions` operation, by specifying
 	 * this value as the `page_token` in the next request.
+	 *
 	 * If `next_page_token` is empty (""), then the "last page" of results has been processed and
 	 * there is no more data to be retrieved.
+	 *
 	 * If `next_page_token` is not empty, it does not necessarily mean that there is more data in the
 	 * result set. The only way to know when you have reached the end of the result set is when
 	 * `next_page_token` is empty.
+	 *
 	 * Caution: Clients must not assume a specific number of key_versions to be present in a page for
 	 * paginated response.
 	 * </pre>
@@ -154,11 +154,14 @@ public boolean hasNextPageToken() {
 	 * `next_page_token` is a pagination token, used to retrieve the next page of results.
 	 * Use this value to query for next-page of paginated `ListKeyVersions` operation, by specifying
 	 * this value as the `page_token` in the next request.
+	 *
 	 * If `next_page_token` is empty (""), then the "last page" of results has been processed and
 	 * there is no more data to be retrieved.
+	 *
 	 * If `next_page_token` is not empty, it does not necessarily mean that there is more data in the
 	 * result set. The only way to know when you have reached the end of the result set is when
 	 * `next_page_token` is empty.
+	 *
 	 * Caution: Clients must not assume a specific number of key_versions to be present in a page for
 	 * paginated response.
 	 * </pre>
@@ -186,11 +189,14 @@ public java.lang.String getNextPageToken() {
 	 * `next_page_token` is a pagination token, used to retrieve the next page of results.
 	 * Use this value to query for next-page of paginated `ListKeyVersions` operation, by specifying
 	 * this value as the `page_token` in the next request.
+	 *
 	 * If `next_page_token` is empty (""), then the "last page" of results has been processed and
 	 * there is no more data to be retrieved.
+	 *
 	 * If `next_page_token` is not empty, it does not necessarily mean that there is more data in the
 	 * result set. The only way to know when you have reached the end of the result set is when
 	 * `next_page_token` is empty.
+	 *
 	 * Caution: Clients must not assume a specific number of key_versions to be present in a page for
 	 * paginated response.
 	 * </pre>
@@ -215,13 +221,15 @@ public java.lang.String getNextPageToken() {
 	}
 
 	public static final int GLOBAL_VERSION_FIELD_NUMBER = 3;
-	private long globalVersion_;
+	private long globalVersion_ = 0L;
 
 	/**
 	 * <pre>
 	 * `global_version` is a sequence-number/version of the whole store.
+	 *
 	 * `global_version` is only returned in response for the first page of the `ListKeyVersionsResponse`
 	 * and is guaranteed to be read before reading any key-versions.
+	 *
 	 * In case of refreshing the complete key-version view on the client-side, correct usage for
 	 * the returned `global_version` is as following:
 	 *   1. Read `global_version` from the first page of paginated response and save it as local variable.
@@ -244,8 +252,10 @@ public boolean hasGlobalVersion() {
 	/**
 	 * <pre>
 	 * `global_version` is a sequence-number/version of the whole store.
+	 *
 	 * `global_version` is only returned in response for the first page of the `ListKeyVersionsResponse`
 	 * and is guaranteed to be read before reading any key-versions.
+	 *
 	 * In case of refreshing the complete key-version view on the client-side, correct usage for
 	 * the returned `global_version` is as following:
 	 *   1. Read `global_version` from the first page of paginated response and save it as local variable.
@@ -510,6 +520,7 @@ private Builder(
 		@java.lang.Override
 		public Builder clear() {
 			super.clear();
+			bitField0_ = 0;
 			if (keyVersionsBuilder_ == null) {
 				keyVersions_ = java.util.Collections.emptyList();
 			} else {
@@ -518,9 +529,7 @@ public Builder clear() {
 			}
 			bitField0_ = (bitField0_ & ~0x00000001);
 			nextPageToken_ = "";
-			bitField0_ = (bitField0_ & ~0x00000002);
 			globalVersion_ = 0L;
-			bitField0_ = (bitField0_ & ~0x00000004);
 			return this;
 		}
 
@@ -547,8 +556,15 @@ public org.vss.ListKeyVersionsResponse build() {
 		@java.lang.Override
 		public org.vss.ListKeyVersionsResponse buildPartial() {
 			org.vss.ListKeyVersionsResponse result = new org.vss.ListKeyVersionsResponse(this);
-			int from_bitField0_ = bitField0_;
-			int to_bitField0_ = 0;
+			buildPartialRepeatedFields(result);
+			if (bitField0_ != 0) {
+				buildPartial0(result);
+			}
+			onBuilt();
+			return result;
+		}
+
+		private void buildPartialRepeatedFields(org.vss.ListKeyVersionsResponse result) {
 			if (keyVersionsBuilder_ == null) {
 				if (((bitField0_ & 0x00000001) != 0)) {
 					keyVersions_ = java.util.Collections.unmodifiableList(keyVersions_);
@@ -558,17 +574,20 @@ public org.vss.ListKeyVersionsResponse buildPartial() {
 			} else {
 				result.keyVersions_ = keyVersionsBuilder_.build();
 			}
+		}
+
+		private void buildPartial0(org.vss.ListKeyVersionsResponse result) {
+			int from_bitField0_ = bitField0_;
+			int to_bitField0_ = 0;
 			if (((from_bitField0_ & 0x00000002) != 0)) {
+				result.nextPageToken_ = nextPageToken_;
 				to_bitField0_ |= 0x00000001;
 			}
-			result.nextPageToken_ = nextPageToken_;
 			if (((from_bitField0_ & 0x00000004) != 0)) {
 				result.globalVersion_ = globalVersion_;
 				to_bitField0_ |= 0x00000002;
 			}
-			result.bitField0_ = to_bitField0_;
-			onBuilt();
-			return result;
+			result.bitField0_ |= to_bitField0_;
 		}
 
 		@java.lang.Override
@@ -648,8 +667,8 @@ public Builder mergeFrom(org.vss.ListKeyVersionsResponse other) {
 				}
 			}
 			if (other.hasNextPageToken()) {
-				bitField0_ |= 0x00000002;
 				nextPageToken_ = other.nextPageToken_;
+				bitField0_ |= 0x00000002;
 				onChanged();
 			}
 			if (other.hasGlobalVersion()) {
@@ -1079,11 +1098,14 @@ public org.vss.KeyValue.Builder addKeyVersionsBuilder(
 		 * `next_page_token` is a pagination token, used to retrieve the next page of results.
 		 * Use this value to query for next-page of paginated `ListKeyVersions` operation, by specifying
 		 * this value as the `page_token` in the next request.
+		 *
 		 * If `next_page_token` is empty (""), then the "last page" of results has been processed and
 		 * there is no more data to be retrieved.
+		 *
 		 * If `next_page_token` is not empty, it does not necessarily mean that there is more data in the
 		 * result set. The only way to know when you have reached the end of the result set is when
 		 * `next_page_token` is empty.
+		 *
 		 * Caution: Clients must not assume a specific number of key_versions to be present in a page for
 		 * paginated response.
 		 * </pre>
@@ -1101,11 +1123,14 @@ public boolean hasNextPageToken() {
 		 * `next_page_token` is a pagination token, used to retrieve the next page of results.
 		 * Use this value to query for next-page of paginated `ListKeyVersions` operation, by specifying
 		 * this value as the `page_token` in the next request.
+		 *
 		 * If `next_page_token` is empty (""), then the "last page" of results has been processed and
 		 * there is no more data to be retrieved.
+		 *
 		 * If `next_page_token` is not empty, it does not necessarily mean that there is more data in the
 		 * result set. The only way to know when you have reached the end of the result set is when
 		 * `next_page_token` is empty.
+		 *
 		 * Caution: Clients must not assume a specific number of key_versions to be present in a page for
 		 * paginated response.
 		 * </pre>
@@ -1132,11 +1157,14 @@ public java.lang.String getNextPageToken() {
 		 * `next_page_token` is a pagination token, used to retrieve the next page of results.
 		 * Use this value to query for next-page of paginated `ListKeyVersions` operation, by specifying
 		 * this value as the `page_token` in the next request.
+		 *
 		 * If `next_page_token` is empty (""), then the "last page" of results has been processed and
 		 * there is no more data to be retrieved.
+		 *
 		 * If `next_page_token` is not empty, it does not necessarily mean that there is more data in the
 		 * result set. The only way to know when you have reached the end of the result set is when
 		 * `next_page_token` is empty.
+		 *
 		 * Caution: Clients must not assume a specific number of key_versions to be present in a page for
 		 * paginated response.
 		 * </pre>
@@ -1164,11 +1192,14 @@ public java.lang.String getNextPageToken() {
 		 * `next_page_token` is a pagination token, used to retrieve the next page of results.
 		 * Use this value to query for next-page of paginated `ListKeyVersions` operation, by specifying
 		 * this value as the `page_token` in the next request.
+		 *
 		 * If `next_page_token` is empty (""), then the "last page" of results has been processed and
 		 * there is no more data to be retrieved.
+		 *
 		 * If `next_page_token` is not empty, it does not necessarily mean that there is more data in the
 		 * result set. The only way to know when you have reached the end of the result set is when
 		 * `next_page_token` is empty.
+		 *
 		 * Caution: Clients must not assume a specific number of key_versions to be present in a page for
 		 * paginated response.
 		 * </pre>
@@ -1183,8 +1214,8 @@ public Builder setNextPageToken(
 			if (value == null) {
 				throw new NullPointerException();
 			}
-			bitField0_ |= 0x00000002;
 			nextPageToken_ = value;
+			bitField0_ |= 0x00000002;
 			onChanged();
 			return this;
 		}
@@ -1194,11 +1225,14 @@ public Builder setNextPageToken(
 		 * `next_page_token` is a pagination token, used to retrieve the next page of results.
 		 * Use this value to query for next-page of paginated `ListKeyVersions` operation, by specifying
 		 * this value as the `page_token` in the next request.
+		 *
 		 * If `next_page_token` is empty (""), then the "last page" of results has been processed and
 		 * there is no more data to be retrieved.
+		 *
 		 * If `next_page_token` is not empty, it does not necessarily mean that there is more data in the
 		 * result set. The only way to know when you have reached the end of the result set is when
 		 * `next_page_token` is empty.
+		 *
 		 * Caution: Clients must not assume a specific number of key_versions to be present in a page for
 		 * paginated response.
 		 * </pre>
@@ -1208,8 +1242,8 @@ public Builder setNextPageToken(
 		 * @return This builder for chaining.
 		 */
 		public Builder clearNextPageToken() {
-			bitField0_ = (bitField0_ & ~0x00000002);
 			nextPageToken_ = getDefaultInstance().getNextPageToken();
+			bitField0_ = (bitField0_ & ~0x00000002);
 			onChanged();
 			return this;
 		}
@@ -1219,11 +1253,14 @@ public Builder clearNextPageToken() {
 		 * `next_page_token` is a pagination token, used to retrieve the next page of results.
 		 * Use this value to query for next-page of paginated `ListKeyVersions` operation, by specifying
 		 * this value as the `page_token` in the next request.
+		 *
 		 * If `next_page_token` is empty (""), then the "last page" of results has been processed and
 		 * there is no more data to be retrieved.
+		 *
 		 * If `next_page_token` is not empty, it does not necessarily mean that there is more data in the
 		 * result set. The only way to know when you have reached the end of the result set is when
 		 * `next_page_token` is empty.
+		 *
 		 * Caution: Clients must not assume a specific number of key_versions to be present in a page for
 		 * paginated response.
 		 * </pre>
@@ -1239,8 +1276,8 @@ public Builder setNextPageTokenBytes(
 				throw new NullPointerException();
 			}
 			checkByteStringIsUtf8(value);
-			bitField0_ |= 0x00000002;
 			nextPageToken_ = value;
+			bitField0_ |= 0x00000002;
 			onChanged();
 			return this;
 		}
@@ -1250,8 +1287,10 @@ public Builder setNextPageTokenBytes(
 		/**
 		 * <pre>
 		 * `global_version` is a sequence-number/version of the whole store.
+		 *
 		 * `global_version` is only returned in response for the first page of the `ListKeyVersionsResponse`
 		 * and is guaranteed to be read before reading any key-versions.
+		 *
 		 * In case of refreshing the complete key-version view on the client-side, correct usage for
 		 * the returned `global_version` is as following:
 		 *   1. Read `global_version` from the first page of paginated response and save it as local variable.
@@ -1274,8 +1313,10 @@ public boolean hasGlobalVersion() {
 		/**
 		 * <pre>
 		 * `global_version` is a sequence-number/version of the whole store.
+		 *
 		 * `global_version` is only returned in response for the first page of the `ListKeyVersionsResponse`
 		 * and is guaranteed to be read before reading any key-versions.
+		 *
 		 * In case of refreshing the complete key-version view on the client-side, correct usage for
 		 * the returned `global_version` is as following:
 		 *   1. Read `global_version` from the first page of paginated response and save it as local variable.
@@ -1298,8 +1339,10 @@ public long getGlobalVersion() {
 		/**
 		 * <pre>
 		 * `global_version` is a sequence-number/version of the whole store.
+		 *
 		 * `global_version` is only returned in response for the first page of the `ListKeyVersionsResponse`
 		 * and is guaranteed to be read before reading any key-versions.
+		 *
 		 * In case of refreshing the complete key-version view on the client-side, correct usage for
 		 * the returned `global_version` is as following:
 		 *   1. Read `global_version` from the first page of paginated response and save it as local variable.
@@ -1316,8 +1359,9 @@ public long getGlobalVersion() {
 		 * @return This builder for chaining.
 		 */
 		public Builder setGlobalVersion(long value) {
-			bitField0_ |= 0x00000004;
+
 			globalVersion_ = value;
+			bitField0_ |= 0x00000004;
 			onChanged();
 			return this;
 		}
@@ -1325,8 +1369,10 @@ public Builder setGlobalVersion(long value) {
 		/**
 		 * <pre>
 		 * `global_version` is a sequence-number/version of the whole store.
+		 *
 		 * `global_version` is only returned in response for the first page of the `ListKeyVersionsResponse`
 		 * and is guaranteed to be read before reading any key-versions.
+		 *
 		 * In case of refreshing the complete key-version view on the client-side, correct usage for
 		 * the returned `global_version` is as following:
 		 *   1. Read `global_version` from the first page of paginated response and save it as local variable.
diff --git a/java/app/src/main/generated/proto/org/vss/ListKeyVersionsResponseOrBuilder.java b/java/app/src/main/generated/proto/org/vss/ListKeyVersionsResponseOrBuilder.java
index 04a3589..802a948 100644
--- a/java/app/src/main/generated/proto/org/vss/ListKeyVersionsResponseOrBuilder.java
+++ b/java/app/src/main/generated/proto/org/vss/ListKeyVersionsResponseOrBuilder.java
@@ -1,6 +1,7 @@
 // Generated by the protocol buffer compiler.  DO NOT EDIT!
 // source: vss.proto
 
+// Protobuf Java Version: 3.25.5
 package org.vss;
 
 public interface ListKeyVersionsResponseOrBuilder extends
@@ -65,11 +66,14 @@ org.vss.KeyValueOrBuilder getKeyVersionsOrBuilder(
 	 * `next_page_token` is a pagination token, used to retrieve the next page of results.
 	 * Use this value to query for next-page of paginated `ListKeyVersions` operation, by specifying
 	 * this value as the `page_token` in the next request.
+	 *
 	 * If `next_page_token` is empty (""), then the "last page" of results has been processed and
 	 * there is no more data to be retrieved.
+	 *
 	 * If `next_page_token` is not empty, it does not necessarily mean that there is more data in the
 	 * result set. The only way to know when you have reached the end of the result set is when
 	 * `next_page_token` is empty.
+	 *
 	 * Caution: Clients must not assume a specific number of key_versions to be present in a page for
 	 * paginated response.
 	 * </pre>
@@ -85,11 +89,14 @@ org.vss.KeyValueOrBuilder getKeyVersionsOrBuilder(
 	 * `next_page_token` is a pagination token, used to retrieve the next page of results.
 	 * Use this value to query for next-page of paginated `ListKeyVersions` operation, by specifying
 	 * this value as the `page_token` in the next request.
+	 *
 	 * If `next_page_token` is empty (""), then the "last page" of results has been processed and
 	 * there is no more data to be retrieved.
+	 *
 	 * If `next_page_token` is not empty, it does not necessarily mean that there is more data in the
 	 * result set. The only way to know when you have reached the end of the result set is when
 	 * `next_page_token` is empty.
+	 *
 	 * Caution: Clients must not assume a specific number of key_versions to be present in a page for
 	 * paginated response.
 	 * </pre>
@@ -105,11 +112,14 @@ org.vss.KeyValueOrBuilder getKeyVersionsOrBuilder(
 	 * `next_page_token` is a pagination token, used to retrieve the next page of results.
 	 * Use this value to query for next-page of paginated `ListKeyVersions` operation, by specifying
 	 * this value as the `page_token` in the next request.
+	 *
 	 * If `next_page_token` is empty (""), then the "last page" of results has been processed and
 	 * there is no more data to be retrieved.
+	 *
 	 * If `next_page_token` is not empty, it does not necessarily mean that there is more data in the
 	 * result set. The only way to know when you have reached the end of the result set is when
 	 * `next_page_token` is empty.
+	 *
 	 * Caution: Clients must not assume a specific number of key_versions to be present in a page for
 	 * paginated response.
 	 * </pre>
@@ -124,8 +134,10 @@ org.vss.KeyValueOrBuilder getKeyVersionsOrBuilder(
 	/**
 	 * <pre>
 	 * `global_version` is a sequence-number/version of the whole store.
+	 *
 	 * `global_version` is only returned in response for the first page of the `ListKeyVersionsResponse`
 	 * and is guaranteed to be read before reading any key-versions.
+	 *
 	 * In case of refreshing the complete key-version view on the client-side, correct usage for
 	 * the returned `global_version` is as following:
 	 *   1. Read `global_version` from the first page of paginated response and save it as local variable.
@@ -145,8 +157,10 @@ org.vss.KeyValueOrBuilder getKeyVersionsOrBuilder(
 	/**
 	 * <pre>
 	 * `global_version` is a sequence-number/version of the whole store.
+	 *
 	 * `global_version` is only returned in response for the first page of the `ListKeyVersionsResponse`
 	 * and is guaranteed to be read before reading any key-versions.
+	 *
 	 * In case of refreshing the complete key-version view on the client-side, correct usage for
 	 * the returned `global_version` is as following:
 	 *   1. Read `global_version` from the first page of paginated response and save it as local variable.
diff --git a/java/app/src/main/generated/proto/org/vss/PlaintextBlob.java b/java/app/src/main/generated/proto/org/vss/PlaintextBlob.java
index 3be5959..e247a64 100644
--- a/java/app/src/main/generated/proto/org/vss/PlaintextBlob.java
+++ b/java/app/src/main/generated/proto/org/vss/PlaintextBlob.java
@@ -1,6 +1,7 @@
 // Generated by the protocol buffer compiler.  DO NOT EDIT!
 // source: vss.proto
 
+// Protobuf Java Version: 3.25.5
 package org.vss;
 
 /**
@@ -33,12 +34,6 @@ protected java.lang.Object newInstance(
 		return new PlaintextBlob();
 	}
 
-	@java.lang.Override
-	public final com.google.protobuf.UnknownFieldSet
-	getUnknownFields() {
-		return this.unknownFields;
-	}
-
 	public static final com.google.protobuf.Descriptors.Descriptor
 	getDescriptor() {
 		return org.vss.Vss.internal_static_vss_PlaintextBlob_descriptor;
@@ -53,7 +48,7 @@ protected java.lang.Object newInstance(
 	}
 
 	public static final int VALUE_FIELD_NUMBER = 1;
-	private com.google.protobuf.ByteString value_;
+	private com.google.protobuf.ByteString value_ = com.google.protobuf.ByteString.EMPTY;
 
 	/**
 	 * <pre>
@@ -70,7 +65,7 @@ public com.google.protobuf.ByteString getValue() {
 	}
 
 	public static final int VERSION_FIELD_NUMBER = 2;
-	private long version_;
+	private long version_ = 0L;
 
 	/**
 	 * <pre>
@@ -310,10 +305,9 @@ private Builder(
 		@java.lang.Override
 		public Builder clear() {
 			super.clear();
+			bitField0_ = 0;
 			value_ = com.google.protobuf.ByteString.EMPTY;
-
 			version_ = 0L;
-
 			return this;
 		}
 
@@ -340,12 +334,23 @@ public org.vss.PlaintextBlob build() {
 		@java.lang.Override
 		public org.vss.PlaintextBlob buildPartial() {
 			org.vss.PlaintextBlob result = new org.vss.PlaintextBlob(this);
-			result.value_ = value_;
-			result.version_ = version_;
+			if (bitField0_ != 0) {
+				buildPartial0(result);
+			}
 			onBuilt();
 			return result;
 		}
 
+		private void buildPartial0(org.vss.PlaintextBlob result) {
+			int from_bitField0_ = bitField0_;
+			if (((from_bitField0_ & 0x00000001) != 0)) {
+				result.value_ = value_;
+			}
+			if (((from_bitField0_ & 0x00000002) != 0)) {
+				result.version_ = version_;
+			}
+		}
+
 		@java.lang.Override
 		public Builder clone() {
 			return super.clone();
@@ -430,12 +435,12 @@ public Builder mergeFrom(
 							break;
 						case 10: {
 							value_ = input.readBytes();
-
+							bitField0_ |= 0x00000001;
 							break;
 						} // case 10
 						case 16: {
 							version_ = input.readInt64();
-
+							bitField0_ |= 0x00000002;
 							break;
 						} // case 16
 						default: {
@@ -454,6 +459,8 @@ public Builder mergeFrom(
 			return this;
 		}
 
+		private int bitField0_;
+
 		private com.google.protobuf.ByteString value_ = com.google.protobuf.ByteString.EMPTY;
 
 		/**
@@ -484,8 +491,8 @@ public Builder setValue(com.google.protobuf.ByteString value) {
 			if (value == null) {
 				throw new NullPointerException();
 			}
-
 			value_ = value;
+			bitField0_ |= 0x00000001;
 			onChanged();
 			return this;
 		}
@@ -500,7 +507,7 @@ public Builder setValue(com.google.protobuf.ByteString value) {
 		 * @return This builder for chaining.
 		 */
 		public Builder clearValue() {
-
+			bitField0_ = (bitField0_ & ~0x00000001);
 			value_ = getDefaultInstance().getValue();
 			onChanged();
 			return this;
@@ -535,6 +542,7 @@ public long getVersion() {
 		public Builder setVersion(long value) {
 
 			version_ = value;
+			bitField0_ |= 0x00000002;
 			onChanged();
 			return this;
 		}
@@ -549,7 +557,7 @@ public Builder setVersion(long value) {
 		 * @return This builder for chaining.
 		 */
 		public Builder clearVersion() {
-
+			bitField0_ = (bitField0_ & ~0x00000002);
 			version_ = 0L;
 			onChanged();
 			return this;
diff --git a/java/app/src/main/generated/proto/org/vss/PlaintextBlobOrBuilder.java b/java/app/src/main/generated/proto/org/vss/PlaintextBlobOrBuilder.java
index 79275d4..ed6e647 100644
--- a/java/app/src/main/generated/proto/org/vss/PlaintextBlobOrBuilder.java
+++ b/java/app/src/main/generated/proto/org/vss/PlaintextBlobOrBuilder.java
@@ -1,6 +1,7 @@
 // Generated by the protocol buffer compiler.  DO NOT EDIT!
 // source: vss.proto
 
+// Protobuf Java Version: 3.25.5
 package org.vss;
 
 public interface PlaintextBlobOrBuilder extends
diff --git a/java/app/src/main/generated/proto/org/vss/PutObjectRequest.java b/java/app/src/main/generated/proto/org/vss/PutObjectRequest.java
index 9f6c0f7..b349d81 100644
--- a/java/app/src/main/generated/proto/org/vss/PutObjectRequest.java
+++ b/java/app/src/main/generated/proto/org/vss/PutObjectRequest.java
@@ -1,6 +1,7 @@
 // Generated by the protocol buffer compiler.  DO NOT EDIT!
 // source: vss.proto
 
+// Protobuf Java Version: 3.25.5
 package org.vss;
 
 /**
@@ -34,12 +35,6 @@ protected java.lang.Object newInstance(
 		return new PutObjectRequest();
 	}
 
-	@java.lang.Override
-	public final com.google.protobuf.UnknownFieldSet
-	getUnknownFields() {
-		return this.unknownFields;
-	}
-
 	public static final com.google.protobuf.Descriptors.Descriptor
 	getDescriptor() {
 		return org.vss.Vss.internal_static_vss_PutObjectRequest_descriptor;
@@ -55,7 +50,8 @@ protected java.lang.Object newInstance(
 
 	private int bitField0_;
 	public static final int STORE_ID_FIELD_NUMBER = 1;
-	private volatile java.lang.Object storeId_;
+	@SuppressWarnings("serial")
+	private volatile java.lang.Object storeId_ = "";
 
 	/**
 	 * <pre>
@@ -115,23 +111,26 @@ public java.lang.String getStoreId() {
 	}
 
 	public static final int GLOBAL_VERSION_FIELD_NUMBER = 2;
-	private long globalVersion_;
+	private long globalVersion_ = 0L;
 
 	/**
 	 * <pre>
 	 * `global_version` is a sequence-number/version of the whole store. This can be used for versioning
 	 * and ensures that multiple updates in case of multiple devices can only be done linearly, even
 	 * if those updates did not directly conflict with each other based on keys/`transaction_items`.
+	 *
 	 * If present, the write will only succeed if the current server-side `global_version` against
 	 * the `store_id` is same as in the request.
 	 * Clients are expected to store (client-side) the global version against `store_id`.
 	 * The request must contain their client-side value of `global_version` if global versioning and
 	 * conflict detection is desired.
+	 *
 	 * For the first write of the store, global version should be '0'. If the write succeeds, clients
 	 * must increment their global version (client-side) by 1.
 	 * The server increments `global_version` (server-side) for every successful write, hence this
 	 * client-side increment is required to ensure matching versions. This updated global version
 	 * should be used in subsequent `PutObjectRequest`s for the store.
+	 *
 	 * Requests with a conflicting version will fail with `CONFLICT_EXCEPTION` as ErrorCode.
 	 * </pre>
 	 *
@@ -149,16 +148,19 @@ public boolean hasGlobalVersion() {
 	 * `global_version` is a sequence-number/version of the whole store. This can be used for versioning
 	 * and ensures that multiple updates in case of multiple devices can only be done linearly, even
 	 * if those updates did not directly conflict with each other based on keys/`transaction_items`.
+	 *
 	 * If present, the write will only succeed if the current server-side `global_version` against
 	 * the `store_id` is same as in the request.
 	 * Clients are expected to store (client-side) the global version against `store_id`.
 	 * The request must contain their client-side value of `global_version` if global versioning and
 	 * conflict detection is desired.
+	 *
 	 * For the first write of the store, global version should be '0'. If the write succeeds, clients
 	 * must increment their global version (client-side) by 1.
 	 * The server increments `global_version` (server-side) for every successful write, hence this
 	 * client-side increment is required to ensure matching versions. This updated global version
 	 * should be used in subsequent `PutObjectRequest`s for the store.
+	 *
 	 * Requests with a conflicting version will fail with `CONFLICT_EXCEPTION` as ErrorCode.
 	 * </pre>
 	 *
@@ -172,40 +174,49 @@ public long getGlobalVersion() {
 	}
 
 	public static final int TRANSACTION_ITEMS_FIELD_NUMBER = 3;
+	@SuppressWarnings("serial")
 	private java.util.List<org.vss.KeyValue> transactionItems_;
 
 	/**
 	 * <pre>
 	 * Items to be written as a result of this `PutObjectRequest`.
+	 *
 	 * In an item, each `key` is supplied with its corresponding `value` and `version`.
 	 * Clients can choose to encrypt the keys client-side in order to obfuscate their usage patterns.
 	 * If the write is successful, the previous `value` corresponding to the `key` will be overwritten.
+	 *
 	 * Multiple items in `transaction_items` and `delete_items` of a single `PutObjectRequest` are written in
 	 * a database-transaction in an all-or-nothing fashion.
 	 * All Items in a single `PutObjectRequest` must have distinct keys.
+	 *
 	 * Key-level versioning (Conditional Write):
 	 *   Clients are expected to store a `version` against every `key`.
 	 *   The write will succeed if the current DB version against the `key` is the same as in the request.
 	 *   When initiating a `PutObjectRequest`, the request should contain their client-side `version`
 	 *   for that key-value.
+	 *
 	 *   For the first write of any `key`, the `version` should be '0'. If the write succeeds, the client
 	 *   must increment their corresponding key versions (client-side) by 1.
 	 *   The server increments key versions (server-side) for every successful write, hence this
 	 *   client-side increment is required to ensure matching versions. These updated key versions should
 	 *   be used in subsequent `PutObjectRequest`s for the keys.
+	 *
 	 *   Requests with a conflicting/mismatched version will fail with `CONFLICT_EXCEPTION` as ErrorCode
 	 *   for conditional writes.
+	 *
 	 * Skipping key-level versioning (Non-conditional Write):
 	 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 	 *   This will perform a non-conditional write query, after which the `version` against the `key`
 	 *   is reset to '1'. Hence, the next `PutObjectRequest` for the `key` can be either
 	 *   a non-conditional write or a conditional write with `version` set to `1`.
+	 *
 	 * Considerations for transactions:
 	 * Transaction writes of multiple items have a performance overhead, hence it is recommended to use
 	 * them only if required by the client application to ensure logic/code correctness.
 	 * That is, `transaction_items` are not a substitute for batch-write of multiple unrelated items.
 	 * When a write of multiple unrelated items is desired, it is recommended to use separate
 	 * `PutObjectRequest`s.
+	 *
 	 * Consistency guarantee:
 	 * All `PutObjectRequest`s are strongly consistent i.e. they provide read-after-write and
 	 * read-after-update consistency guarantees.
@@ -221,35 +232,43 @@ public java.util.List<org.vss.KeyValue> getTransactionItemsList() {
 	/**
 	 * <pre>
 	 * Items to be written as a result of this `PutObjectRequest`.
+	 *
 	 * In an item, each `key` is supplied with its corresponding `value` and `version`.
 	 * Clients can choose to encrypt the keys client-side in order to obfuscate their usage patterns.
 	 * If the write is successful, the previous `value` corresponding to the `key` will be overwritten.
+	 *
 	 * Multiple items in `transaction_items` and `delete_items` of a single `PutObjectRequest` are written in
 	 * a database-transaction in an all-or-nothing fashion.
 	 * All Items in a single `PutObjectRequest` must have distinct keys.
+	 *
 	 * Key-level versioning (Conditional Write):
 	 *   Clients are expected to store a `version` against every `key`.
 	 *   The write will succeed if the current DB version against the `key` is the same as in the request.
 	 *   When initiating a `PutObjectRequest`, the request should contain their client-side `version`
 	 *   for that key-value.
+	 *
 	 *   For the first write of any `key`, the `version` should be '0'. If the write succeeds, the client
 	 *   must increment their corresponding key versions (client-side) by 1.
 	 *   The server increments key versions (server-side) for every successful write, hence this
 	 *   client-side increment is required to ensure matching versions. These updated key versions should
 	 *   be used in subsequent `PutObjectRequest`s for the keys.
+	 *
 	 *   Requests with a conflicting/mismatched version will fail with `CONFLICT_EXCEPTION` as ErrorCode
 	 *   for conditional writes.
+	 *
 	 * Skipping key-level versioning (Non-conditional Write):
 	 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 	 *   This will perform a non-conditional write query, after which the `version` against the `key`
 	 *   is reset to '1'. Hence, the next `PutObjectRequest` for the `key` can be either
 	 *   a non-conditional write or a conditional write with `version` set to `1`.
+	 *
 	 * Considerations for transactions:
 	 * Transaction writes of multiple items have a performance overhead, hence it is recommended to use
 	 * them only if required by the client application to ensure logic/code correctness.
 	 * That is, `transaction_items` are not a substitute for batch-write of multiple unrelated items.
 	 * When a write of multiple unrelated items is desired, it is recommended to use separate
 	 * `PutObjectRequest`s.
+	 *
 	 * Consistency guarantee:
 	 * All `PutObjectRequest`s are strongly consistent i.e. they provide read-after-write and
 	 * read-after-update consistency guarantees.
@@ -266,35 +285,43 @@ public java.util.List<org.vss.KeyValue> getTransactionItemsList() {
 	/**
 	 * <pre>
 	 * Items to be written as a result of this `PutObjectRequest`.
+	 *
 	 * In an item, each `key` is supplied with its corresponding `value` and `version`.
 	 * Clients can choose to encrypt the keys client-side in order to obfuscate their usage patterns.
 	 * If the write is successful, the previous `value` corresponding to the `key` will be overwritten.
+	 *
 	 * Multiple items in `transaction_items` and `delete_items` of a single `PutObjectRequest` are written in
 	 * a database-transaction in an all-or-nothing fashion.
 	 * All Items in a single `PutObjectRequest` must have distinct keys.
+	 *
 	 * Key-level versioning (Conditional Write):
 	 *   Clients are expected to store a `version` against every `key`.
 	 *   The write will succeed if the current DB version against the `key` is the same as in the request.
 	 *   When initiating a `PutObjectRequest`, the request should contain their client-side `version`
 	 *   for that key-value.
+	 *
 	 *   For the first write of any `key`, the `version` should be '0'. If the write succeeds, the client
 	 *   must increment their corresponding key versions (client-side) by 1.
 	 *   The server increments key versions (server-side) for every successful write, hence this
 	 *   client-side increment is required to ensure matching versions. These updated key versions should
 	 *   be used in subsequent `PutObjectRequest`s for the keys.
+	 *
 	 *   Requests with a conflicting/mismatched version will fail with `CONFLICT_EXCEPTION` as ErrorCode
 	 *   for conditional writes.
+	 *
 	 * Skipping key-level versioning (Non-conditional Write):
 	 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 	 *   This will perform a non-conditional write query, after which the `version` against the `key`
 	 *   is reset to '1'. Hence, the next `PutObjectRequest` for the `key` can be either
 	 *   a non-conditional write or a conditional write with `version` set to `1`.
+	 *
 	 * Considerations for transactions:
 	 * Transaction writes of multiple items have a performance overhead, hence it is recommended to use
 	 * them only if required by the client application to ensure logic/code correctness.
 	 * That is, `transaction_items` are not a substitute for batch-write of multiple unrelated items.
 	 * When a write of multiple unrelated items is desired, it is recommended to use separate
 	 * `PutObjectRequest`s.
+	 *
 	 * Consistency guarantee:
 	 * All `PutObjectRequest`s are strongly consistent i.e. they provide read-after-write and
 	 * read-after-update consistency guarantees.
@@ -310,35 +337,43 @@ public int getTransactionItemsCount() {
 	/**
 	 * <pre>
 	 * Items to be written as a result of this `PutObjectRequest`.
+	 *
 	 * In an item, each `key` is supplied with its corresponding `value` and `version`.
 	 * Clients can choose to encrypt the keys client-side in order to obfuscate their usage patterns.
 	 * If the write is successful, the previous `value` corresponding to the `key` will be overwritten.
+	 *
 	 * Multiple items in `transaction_items` and `delete_items` of a single `PutObjectRequest` are written in
 	 * a database-transaction in an all-or-nothing fashion.
 	 * All Items in a single `PutObjectRequest` must have distinct keys.
+	 *
 	 * Key-level versioning (Conditional Write):
 	 *   Clients are expected to store a `version` against every `key`.
 	 *   The write will succeed if the current DB version against the `key` is the same as in the request.
 	 *   When initiating a `PutObjectRequest`, the request should contain their client-side `version`
 	 *   for that key-value.
+	 *
 	 *   For the first write of any `key`, the `version` should be '0'. If the write succeeds, the client
 	 *   must increment their corresponding key versions (client-side) by 1.
 	 *   The server increments key versions (server-side) for every successful write, hence this
 	 *   client-side increment is required to ensure matching versions. These updated key versions should
 	 *   be used in subsequent `PutObjectRequest`s for the keys.
+	 *
 	 *   Requests with a conflicting/mismatched version will fail with `CONFLICT_EXCEPTION` as ErrorCode
 	 *   for conditional writes.
+	 *
 	 * Skipping key-level versioning (Non-conditional Write):
 	 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 	 *   This will perform a non-conditional write query, after which the `version` against the `key`
 	 *   is reset to '1'. Hence, the next `PutObjectRequest` for the `key` can be either
 	 *   a non-conditional write or a conditional write with `version` set to `1`.
+	 *
 	 * Considerations for transactions:
 	 * Transaction writes of multiple items have a performance overhead, hence it is recommended to use
 	 * them only if required by the client application to ensure logic/code correctness.
 	 * That is, `transaction_items` are not a substitute for batch-write of multiple unrelated items.
 	 * When a write of multiple unrelated items is desired, it is recommended to use separate
 	 * `PutObjectRequest`s.
+	 *
 	 * Consistency guarantee:
 	 * All `PutObjectRequest`s are strongly consistent i.e. they provide read-after-write and
 	 * read-after-update consistency guarantees.
@@ -354,35 +389,43 @@ public org.vss.KeyValue getTransactionItems(int index) {
 	/**
 	 * <pre>
 	 * Items to be written as a result of this `PutObjectRequest`.
+	 *
 	 * In an item, each `key` is supplied with its corresponding `value` and `version`.
 	 * Clients can choose to encrypt the keys client-side in order to obfuscate their usage patterns.
 	 * If the write is successful, the previous `value` corresponding to the `key` will be overwritten.
+	 *
 	 * Multiple items in `transaction_items` and `delete_items` of a single `PutObjectRequest` are written in
 	 * a database-transaction in an all-or-nothing fashion.
 	 * All Items in a single `PutObjectRequest` must have distinct keys.
+	 *
 	 * Key-level versioning (Conditional Write):
 	 *   Clients are expected to store a `version` against every `key`.
 	 *   The write will succeed if the current DB version against the `key` is the same as in the request.
 	 *   When initiating a `PutObjectRequest`, the request should contain their client-side `version`
 	 *   for that key-value.
+	 *
 	 *   For the first write of any `key`, the `version` should be '0'. If the write succeeds, the client
 	 *   must increment their corresponding key versions (client-side) by 1.
 	 *   The server increments key versions (server-side) for every successful write, hence this
 	 *   client-side increment is required to ensure matching versions. These updated key versions should
 	 *   be used in subsequent `PutObjectRequest`s for the keys.
+	 *
 	 *   Requests with a conflicting/mismatched version will fail with `CONFLICT_EXCEPTION` as ErrorCode
 	 *   for conditional writes.
+	 *
 	 * Skipping key-level versioning (Non-conditional Write):
 	 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 	 *   This will perform a non-conditional write query, after which the `version` against the `key`
 	 *   is reset to '1'. Hence, the next `PutObjectRequest` for the `key` can be either
 	 *   a non-conditional write or a conditional write with `version` set to `1`.
+	 *
 	 * Considerations for transactions:
 	 * Transaction writes of multiple items have a performance overhead, hence it is recommended to use
 	 * them only if required by the client application to ensure logic/code correctness.
 	 * That is, `transaction_items` are not a substitute for batch-write of multiple unrelated items.
 	 * When a write of multiple unrelated items is desired, it is recommended to use separate
 	 * `PutObjectRequest`s.
+	 *
 	 * Consistency guarantee:
 	 * All `PutObjectRequest`s are strongly consistent i.e. they provide read-after-write and
 	 * read-after-update consistency guarantees.
@@ -397,25 +440,32 @@ public org.vss.KeyValueOrBuilder getTransactionItemsOrBuilder(
 	}
 
 	public static final int DELETE_ITEMS_FIELD_NUMBER = 4;
+	@SuppressWarnings("serial")
 	private java.util.List<org.vss.KeyValue> deleteItems_;
 
 	/**
 	 * <pre>
 	 * Items to be deleted as a result of this `PutObjectRequest`.
+	 *
 	 * Each item in the `delete_items` field consists of a `key` and its corresponding `version`.
+	 *
 	 * Key-Level Versioning (Conditional Delete):
 	 *   The `version` is used to perform a version check before deleting the item.
 	 *   The delete will only succeed if the current database version against the `key` is the same as
 	 *   the `version` specified in the request.
+	 *
 	 * Skipping key-level versioning (Non-conditional Delete):
 	 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 	 *   This will perform a non-conditional delete query.
+	 *
 	 * Fails with `CONFLICT_EXCEPTION` as the ErrorCode if:
 	 *   * The requested item does not exist.
 	 *   * The requested item does exist but there is a version-number mismatch (in conditional delete)
 	 *     with the one in the database.
+	 *
 	 * Multiple items in the `delete_items` field, along with the `transaction_items`, are written in a
 	 * database transaction in an all-or-nothing fashion.
+	 *
 	 * All items within a single `PutObjectRequest` must have distinct keys.
 	 * </pre>
 	 *
@@ -429,20 +479,26 @@ public java.util.List<org.vss.KeyValue> getDeleteItemsList() {
 	/**
 	 * <pre>
 	 * Items to be deleted as a result of this `PutObjectRequest`.
+	 *
 	 * Each item in the `delete_items` field consists of a `key` and its corresponding `version`.
+	 *
 	 * Key-Level Versioning (Conditional Delete):
 	 *   The `version` is used to perform a version check before deleting the item.
 	 *   The delete will only succeed if the current database version against the `key` is the same as
 	 *   the `version` specified in the request.
+	 *
 	 * Skipping key-level versioning (Non-conditional Delete):
 	 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 	 *   This will perform a non-conditional delete query.
+	 *
 	 * Fails with `CONFLICT_EXCEPTION` as the ErrorCode if:
 	 *   * The requested item does not exist.
 	 *   * The requested item does exist but there is a version-number mismatch (in conditional delete)
 	 *     with the one in the database.
+	 *
 	 * Multiple items in the `delete_items` field, along with the `transaction_items`, are written in a
 	 * database transaction in an all-or-nothing fashion.
+	 *
 	 * All items within a single `PutObjectRequest` must have distinct keys.
 	 * </pre>
 	 *
@@ -457,20 +513,26 @@ public java.util.List<org.vss.KeyValue> getDeleteItemsList() {
 	/**
 	 * <pre>
 	 * Items to be deleted as a result of this `PutObjectRequest`.
+	 *
 	 * Each item in the `delete_items` field consists of a `key` and its corresponding `version`.
+	 *
 	 * Key-Level Versioning (Conditional Delete):
 	 *   The `version` is used to perform a version check before deleting the item.
 	 *   The delete will only succeed if the current database version against the `key` is the same as
 	 *   the `version` specified in the request.
+	 *
 	 * Skipping key-level versioning (Non-conditional Delete):
 	 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 	 *   This will perform a non-conditional delete query.
+	 *
 	 * Fails with `CONFLICT_EXCEPTION` as the ErrorCode if:
 	 *   * The requested item does not exist.
 	 *   * The requested item does exist but there is a version-number mismatch (in conditional delete)
 	 *     with the one in the database.
+	 *
 	 * Multiple items in the `delete_items` field, along with the `transaction_items`, are written in a
 	 * database transaction in an all-or-nothing fashion.
+	 *
 	 * All items within a single `PutObjectRequest` must have distinct keys.
 	 * </pre>
 	 *
@@ -484,20 +546,26 @@ public int getDeleteItemsCount() {
 	/**
 	 * <pre>
 	 * Items to be deleted as a result of this `PutObjectRequest`.
+	 *
 	 * Each item in the `delete_items` field consists of a `key` and its corresponding `version`.
+	 *
 	 * Key-Level Versioning (Conditional Delete):
 	 *   The `version` is used to perform a version check before deleting the item.
 	 *   The delete will only succeed if the current database version against the `key` is the same as
 	 *   the `version` specified in the request.
+	 *
 	 * Skipping key-level versioning (Non-conditional Delete):
 	 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 	 *   This will perform a non-conditional delete query.
+	 *
 	 * Fails with `CONFLICT_EXCEPTION` as the ErrorCode if:
 	 *   * The requested item does not exist.
 	 *   * The requested item does exist but there is a version-number mismatch (in conditional delete)
 	 *     with the one in the database.
+	 *
 	 * Multiple items in the `delete_items` field, along with the `transaction_items`, are written in a
 	 * database transaction in an all-or-nothing fashion.
+	 *
 	 * All items within a single `PutObjectRequest` must have distinct keys.
 	 * </pre>
 	 *
@@ -511,20 +579,26 @@ public org.vss.KeyValue getDeleteItems(int index) {
 	/**
 	 * <pre>
 	 * Items to be deleted as a result of this `PutObjectRequest`.
+	 *
 	 * Each item in the `delete_items` field consists of a `key` and its corresponding `version`.
+	 *
 	 * Key-Level Versioning (Conditional Delete):
 	 *   The `version` is used to perform a version check before deleting the item.
 	 *   The delete will only succeed if the current database version against the `key` is the same as
 	 *   the `version` specified in the request.
+	 *
 	 * Skipping key-level versioning (Non-conditional Delete):
 	 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 	 *   This will perform a non-conditional delete query.
+	 *
 	 * Fails with `CONFLICT_EXCEPTION` as the ErrorCode if:
 	 *   * The requested item does not exist.
 	 *   * The requested item does exist but there is a version-number mismatch (in conditional delete)
 	 *     with the one in the database.
+	 *
 	 * Multiple items in the `delete_items` field, along with the `transaction_items`, are written in a
 	 * database transaction in an all-or-nothing fashion.
+	 *
 	 * All items within a single `PutObjectRequest` must have distinct keys.
 	 * </pre>
 	 *
@@ -789,24 +863,23 @@ private Builder(
 		@java.lang.Override
 		public Builder clear() {
 			super.clear();
+			bitField0_ = 0;
 			storeId_ = "";
-
 			globalVersion_ = 0L;
-			bitField0_ = (bitField0_ & ~0x00000001);
 			if (transactionItemsBuilder_ == null) {
 				transactionItems_ = java.util.Collections.emptyList();
 			} else {
 				transactionItems_ = null;
 				transactionItemsBuilder_.clear();
 			}
-			bitField0_ = (bitField0_ & ~0x00000002);
+			bitField0_ = (bitField0_ & ~0x00000004);
 			if (deleteItemsBuilder_ == null) {
 				deleteItems_ = java.util.Collections.emptyList();
 			} else {
 				deleteItems_ = null;
 				deleteItemsBuilder_.clear();
 			}
-			bitField0_ = (bitField0_ & ~0x00000004);
+			bitField0_ = (bitField0_ & ~0x00000008);
 			return this;
 		}
 
@@ -833,34 +906,46 @@ public org.vss.PutObjectRequest build() {
 		@java.lang.Override
 		public org.vss.PutObjectRequest buildPartial() {
 			org.vss.PutObjectRequest result = new org.vss.PutObjectRequest(this);
-			int from_bitField0_ = bitField0_;
-			int to_bitField0_ = 0;
-			result.storeId_ = storeId_;
-			if (((from_bitField0_ & 0x00000001) != 0)) {
-				result.globalVersion_ = globalVersion_;
-				to_bitField0_ |= 0x00000001;
+			buildPartialRepeatedFields(result);
+			if (bitField0_ != 0) {
+				buildPartial0(result);
 			}
+			onBuilt();
+			return result;
+		}
+
+		private void buildPartialRepeatedFields(org.vss.PutObjectRequest result) {
 			if (transactionItemsBuilder_ == null) {
-				if (((bitField0_ & 0x00000002) != 0)) {
+				if (((bitField0_ & 0x00000004) != 0)) {
 					transactionItems_ = java.util.Collections.unmodifiableList(transactionItems_);
-					bitField0_ = (bitField0_ & ~0x00000002);
+					bitField0_ = (bitField0_ & ~0x00000004);
 				}
 				result.transactionItems_ = transactionItems_;
 			} else {
 				result.transactionItems_ = transactionItemsBuilder_.build();
 			}
 			if (deleteItemsBuilder_ == null) {
-				if (((bitField0_ & 0x00000004) != 0)) {
+				if (((bitField0_ & 0x00000008) != 0)) {
 					deleteItems_ = java.util.Collections.unmodifiableList(deleteItems_);
-					bitField0_ = (bitField0_ & ~0x00000004);
+					bitField0_ = (bitField0_ & ~0x00000008);
 				}
 				result.deleteItems_ = deleteItems_;
 			} else {
 				result.deleteItems_ = deleteItemsBuilder_.build();
 			}
-			result.bitField0_ = to_bitField0_;
-			onBuilt();
-			return result;
+		}
+
+		private void buildPartial0(org.vss.PutObjectRequest result) {
+			int from_bitField0_ = bitField0_;
+			if (((from_bitField0_ & 0x00000001) != 0)) {
+				result.storeId_ = storeId_;
+			}
+			int to_bitField0_ = 0;
+			if (((from_bitField0_ & 0x00000002) != 0)) {
+				result.globalVersion_ = globalVersion_;
+				to_bitField0_ |= 0x00000001;
+			}
+			result.bitField0_ |= to_bitField0_;
 		}
 
 		@java.lang.Override
@@ -915,6 +1000,7 @@ public Builder mergeFrom(org.vss.PutObjectRequest other) {
 			if (other == org.vss.PutObjectRequest.getDefaultInstance()) return this;
 			if (!other.getStoreId().isEmpty()) {
 				storeId_ = other.storeId_;
+				bitField0_ |= 0x00000001;
 				onChanged();
 			}
 			if (other.hasGlobalVersion()) {
@@ -924,7 +1010,7 @@ public Builder mergeFrom(org.vss.PutObjectRequest other) {
 				if (!other.transactionItems_.isEmpty()) {
 					if (transactionItems_.isEmpty()) {
 						transactionItems_ = other.transactionItems_;
-						bitField0_ = (bitField0_ & ~0x00000002);
+						bitField0_ = (bitField0_ & ~0x00000004);
 					} else {
 						ensureTransactionItemsIsMutable();
 						transactionItems_.addAll(other.transactionItems_);
@@ -937,7 +1023,7 @@ public Builder mergeFrom(org.vss.PutObjectRequest other) {
 						transactionItemsBuilder_.dispose();
 						transactionItemsBuilder_ = null;
 						transactionItems_ = other.transactionItems_;
-						bitField0_ = (bitField0_ & ~0x00000002);
+						bitField0_ = (bitField0_ & ~0x00000004);
 						transactionItemsBuilder_ =
 								com.google.protobuf.GeneratedMessageV3.alwaysUseFieldBuilders ?
 										getTransactionItemsFieldBuilder() : null;
@@ -950,7 +1036,7 @@ public Builder mergeFrom(org.vss.PutObjectRequest other) {
 				if (!other.deleteItems_.isEmpty()) {
 					if (deleteItems_.isEmpty()) {
 						deleteItems_ = other.deleteItems_;
-						bitField0_ = (bitField0_ & ~0x00000004);
+						bitField0_ = (bitField0_ & ~0x00000008);
 					} else {
 						ensureDeleteItemsIsMutable();
 						deleteItems_.addAll(other.deleteItems_);
@@ -963,7 +1049,7 @@ public Builder mergeFrom(org.vss.PutObjectRequest other) {
 						deleteItemsBuilder_.dispose();
 						deleteItemsBuilder_ = null;
 						deleteItems_ = other.deleteItems_;
-						bitField0_ = (bitField0_ & ~0x00000004);
+						bitField0_ = (bitField0_ & ~0x00000008);
 						deleteItemsBuilder_ =
 								com.google.protobuf.GeneratedMessageV3.alwaysUseFieldBuilders ?
 										getDeleteItemsFieldBuilder() : null;
@@ -1000,12 +1086,12 @@ public Builder mergeFrom(
 							break;
 						case 10: {
 							storeId_ = input.readStringRequireUtf8();
-
+							bitField0_ |= 0x00000001;
 							break;
 						} // case 10
 						case 16: {
 							globalVersion_ = input.readInt64();
-							bitField0_ |= 0x00000001;
+							bitField0_ |= 0x00000002;
 							break;
 						} // case 16
 						case 26: {
@@ -1129,8 +1215,8 @@ public Builder setStoreId(
 			if (value == null) {
 				throw new NullPointerException();
 			}
-
 			storeId_ = value;
+			bitField0_ |= 0x00000001;
 			onChanged();
 			return this;
 		}
@@ -1150,8 +1236,8 @@ public Builder setStoreId(
 		 * @return This builder for chaining.
 		 */
 		public Builder clearStoreId() {
-
 			storeId_ = getDefaultInstance().getStoreId();
+			bitField0_ = (bitField0_ & ~0x00000001);
 			onChanged();
 			return this;
 		}
@@ -1177,8 +1263,8 @@ public Builder setStoreIdBytes(
 				throw new NullPointerException();
 			}
 			checkByteStringIsUtf8(value);
-
 			storeId_ = value;
+			bitField0_ |= 0x00000001;
 			onChanged();
 			return this;
 		}
@@ -1190,16 +1276,19 @@ public Builder setStoreIdBytes(
 		 * `global_version` is a sequence-number/version of the whole store. This can be used for versioning
 		 * and ensures that multiple updates in case of multiple devices can only be done linearly, even
 		 * if those updates did not directly conflict with each other based on keys/`transaction_items`.
+		 *
 		 * If present, the write will only succeed if the current server-side `global_version` against
 		 * the `store_id` is same as in the request.
 		 * Clients are expected to store (client-side) the global version against `store_id`.
 		 * The request must contain their client-side value of `global_version` if global versioning and
 		 * conflict detection is desired.
+		 *
 		 * For the first write of the store, global version should be '0'. If the write succeeds, clients
 		 * must increment their global version (client-side) by 1.
 		 * The server increments `global_version` (server-side) for every successful write, hence this
 		 * client-side increment is required to ensure matching versions. This updated global version
 		 * should be used in subsequent `PutObjectRequest`s for the store.
+		 *
 		 * Requests with a conflicting version will fail with `CONFLICT_EXCEPTION` as ErrorCode.
 		 * </pre>
 		 *
@@ -1209,7 +1298,7 @@ public Builder setStoreIdBytes(
 		 */
 		@java.lang.Override
 		public boolean hasGlobalVersion() {
-			return ((bitField0_ & 0x00000001) != 0);
+			return ((bitField0_ & 0x00000002) != 0);
 		}
 
 		/**
@@ -1217,16 +1306,19 @@ public boolean hasGlobalVersion() {
 		 * `global_version` is a sequence-number/version of the whole store. This can be used for versioning
 		 * and ensures that multiple updates in case of multiple devices can only be done linearly, even
 		 * if those updates did not directly conflict with each other based on keys/`transaction_items`.
+		 *
 		 * If present, the write will only succeed if the current server-side `global_version` against
 		 * the `store_id` is same as in the request.
 		 * Clients are expected to store (client-side) the global version against `store_id`.
 		 * The request must contain their client-side value of `global_version` if global versioning and
 		 * conflict detection is desired.
+		 *
 		 * For the first write of the store, global version should be '0'. If the write succeeds, clients
 		 * must increment their global version (client-side) by 1.
 		 * The server increments `global_version` (server-side) for every successful write, hence this
 		 * client-side increment is required to ensure matching versions. This updated global version
 		 * should be used in subsequent `PutObjectRequest`s for the store.
+		 *
 		 * Requests with a conflicting version will fail with `CONFLICT_EXCEPTION` as ErrorCode.
 		 * </pre>
 		 *
@@ -1244,16 +1336,19 @@ public long getGlobalVersion() {
 		 * `global_version` is a sequence-number/version of the whole store. This can be used for versioning
 		 * and ensures that multiple updates in case of multiple devices can only be done linearly, even
 		 * if those updates did not directly conflict with each other based on keys/`transaction_items`.
+		 *
 		 * If present, the write will only succeed if the current server-side `global_version` against
 		 * the `store_id` is same as in the request.
 		 * Clients are expected to store (client-side) the global version against `store_id`.
 		 * The request must contain their client-side value of `global_version` if global versioning and
 		 * conflict detection is desired.
+		 *
 		 * For the first write of the store, global version should be '0'. If the write succeeds, clients
 		 * must increment their global version (client-side) by 1.
 		 * The server increments `global_version` (server-side) for every successful write, hence this
 		 * client-side increment is required to ensure matching versions. This updated global version
 		 * should be used in subsequent `PutObjectRequest`s for the store.
+		 *
 		 * Requests with a conflicting version will fail with `CONFLICT_EXCEPTION` as ErrorCode.
 		 * </pre>
 		 *
@@ -1263,8 +1358,9 @@ public long getGlobalVersion() {
 		 * @return This builder for chaining.
 		 */
 		public Builder setGlobalVersion(long value) {
-			bitField0_ |= 0x00000001;
+
 			globalVersion_ = value;
+			bitField0_ |= 0x00000002;
 			onChanged();
 			return this;
 		}
@@ -1274,16 +1370,19 @@ public Builder setGlobalVersion(long value) {
 		 * `global_version` is a sequence-number/version of the whole store. This can be used for versioning
 		 * and ensures that multiple updates in case of multiple devices can only be done linearly, even
 		 * if those updates did not directly conflict with each other based on keys/`transaction_items`.
+		 *
 		 * If present, the write will only succeed if the current server-side `global_version` against
 		 * the `store_id` is same as in the request.
 		 * Clients are expected to store (client-side) the global version against `store_id`.
 		 * The request must contain their client-side value of `global_version` if global versioning and
 		 * conflict detection is desired.
+		 *
 		 * For the first write of the store, global version should be '0'. If the write succeeds, clients
 		 * must increment their global version (client-side) by 1.
 		 * The server increments `global_version` (server-side) for every successful write, hence this
 		 * client-side increment is required to ensure matching versions. This updated global version
 		 * should be used in subsequent `PutObjectRequest`s for the store.
+		 *
 		 * Requests with a conflicting version will fail with `CONFLICT_EXCEPTION` as ErrorCode.
 		 * </pre>
 		 *
@@ -1292,7 +1391,7 @@ public Builder setGlobalVersion(long value) {
 		 * @return This builder for chaining.
 		 */
 		public Builder clearGlobalVersion() {
-			bitField0_ = (bitField0_ & ~0x00000001);
+			bitField0_ = (bitField0_ & ~0x00000002);
 			globalVersion_ = 0L;
 			onChanged();
 			return this;
@@ -1302,9 +1401,9 @@ public Builder clearGlobalVersion() {
 				java.util.Collections.emptyList();
 
 		private void ensureTransactionItemsIsMutable() {
-			if (!((bitField0_ & 0x00000002) != 0)) {
+			if (!((bitField0_ & 0x00000004) != 0)) {
 				transactionItems_ = new java.util.ArrayList<org.vss.KeyValue>(transactionItems_);
-				bitField0_ |= 0x00000002;
+				bitField0_ |= 0x00000004;
 			}
 		}
 
@@ -1314,35 +1413,43 @@ private void ensureTransactionItemsIsMutable() {
 		/**
 		 * <pre>
 		 * Items to be written as a result of this `PutObjectRequest`.
+		 *
 		 * In an item, each `key` is supplied with its corresponding `value` and `version`.
 		 * Clients can choose to encrypt the keys client-side in order to obfuscate their usage patterns.
 		 * If the write is successful, the previous `value` corresponding to the `key` will be overwritten.
+		 *
 		 * Multiple items in `transaction_items` and `delete_items` of a single `PutObjectRequest` are written in
 		 * a database-transaction in an all-or-nothing fashion.
 		 * All Items in a single `PutObjectRequest` must have distinct keys.
+		 *
 		 * Key-level versioning (Conditional Write):
 		 *   Clients are expected to store a `version` against every `key`.
 		 *   The write will succeed if the current DB version against the `key` is the same as in the request.
 		 *   When initiating a `PutObjectRequest`, the request should contain their client-side `version`
 		 *   for that key-value.
+		 *
 		 *   For the first write of any `key`, the `version` should be '0'. If the write succeeds, the client
 		 *   must increment their corresponding key versions (client-side) by 1.
 		 *   The server increments key versions (server-side) for every successful write, hence this
 		 *   client-side increment is required to ensure matching versions. These updated key versions should
 		 *   be used in subsequent `PutObjectRequest`s for the keys.
+		 *
 		 *   Requests with a conflicting/mismatched version will fail with `CONFLICT_EXCEPTION` as ErrorCode
 		 *   for conditional writes.
+		 *
 		 * Skipping key-level versioning (Non-conditional Write):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional write query, after which the `version` against the `key`
 		 *   is reset to '1'. Hence, the next `PutObjectRequest` for the `key` can be either
 		 *   a non-conditional write or a conditional write with `version` set to `1`.
+		 *
 		 * Considerations for transactions:
 		 * Transaction writes of multiple items have a performance overhead, hence it is recommended to use
 		 * them only if required by the client application to ensure logic/code correctness.
 		 * That is, `transaction_items` are not a substitute for batch-write of multiple unrelated items.
 		 * When a write of multiple unrelated items is desired, it is recommended to use separate
 		 * `PutObjectRequest`s.
+		 *
 		 * Consistency guarantee:
 		 * All `PutObjectRequest`s are strongly consistent i.e. they provide read-after-write and
 		 * read-after-update consistency guarantees.
@@ -1361,35 +1468,43 @@ public java.util.List<org.vss.KeyValue> getTransactionItemsList() {
 		/**
 		 * <pre>
 		 * Items to be written as a result of this `PutObjectRequest`.
+		 *
 		 * In an item, each `key` is supplied with its corresponding `value` and `version`.
 		 * Clients can choose to encrypt the keys client-side in order to obfuscate their usage patterns.
 		 * If the write is successful, the previous `value` corresponding to the `key` will be overwritten.
+		 *
 		 * Multiple items in `transaction_items` and `delete_items` of a single `PutObjectRequest` are written in
 		 * a database-transaction in an all-or-nothing fashion.
 		 * All Items in a single `PutObjectRequest` must have distinct keys.
+		 *
 		 * Key-level versioning (Conditional Write):
 		 *   Clients are expected to store a `version` against every `key`.
 		 *   The write will succeed if the current DB version against the `key` is the same as in the request.
 		 *   When initiating a `PutObjectRequest`, the request should contain their client-side `version`
 		 *   for that key-value.
+		 *
 		 *   For the first write of any `key`, the `version` should be '0'. If the write succeeds, the client
 		 *   must increment their corresponding key versions (client-side) by 1.
 		 *   The server increments key versions (server-side) for every successful write, hence this
 		 *   client-side increment is required to ensure matching versions. These updated key versions should
 		 *   be used in subsequent `PutObjectRequest`s for the keys.
+		 *
 		 *   Requests with a conflicting/mismatched version will fail with `CONFLICT_EXCEPTION` as ErrorCode
 		 *   for conditional writes.
+		 *
 		 * Skipping key-level versioning (Non-conditional Write):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional write query, after which the `version` against the `key`
 		 *   is reset to '1'. Hence, the next `PutObjectRequest` for the `key` can be either
 		 *   a non-conditional write or a conditional write with `version` set to `1`.
+		 *
 		 * Considerations for transactions:
 		 * Transaction writes of multiple items have a performance overhead, hence it is recommended to use
 		 * them only if required by the client application to ensure logic/code correctness.
 		 * That is, `transaction_items` are not a substitute for batch-write of multiple unrelated items.
 		 * When a write of multiple unrelated items is desired, it is recommended to use separate
 		 * `PutObjectRequest`s.
+		 *
 		 * Consistency guarantee:
 		 * All `PutObjectRequest`s are strongly consistent i.e. they provide read-after-write and
 		 * read-after-update consistency guarantees.
@@ -1408,35 +1523,43 @@ public int getTransactionItemsCount() {
 		/**
 		 * <pre>
 		 * Items to be written as a result of this `PutObjectRequest`.
+		 *
 		 * In an item, each `key` is supplied with its corresponding `value` and `version`.
 		 * Clients can choose to encrypt the keys client-side in order to obfuscate their usage patterns.
 		 * If the write is successful, the previous `value` corresponding to the `key` will be overwritten.
+		 *
 		 * Multiple items in `transaction_items` and `delete_items` of a single `PutObjectRequest` are written in
 		 * a database-transaction in an all-or-nothing fashion.
 		 * All Items in a single `PutObjectRequest` must have distinct keys.
+		 *
 		 * Key-level versioning (Conditional Write):
 		 *   Clients are expected to store a `version` against every `key`.
 		 *   The write will succeed if the current DB version against the `key` is the same as in the request.
 		 *   When initiating a `PutObjectRequest`, the request should contain their client-side `version`
 		 *   for that key-value.
+		 *
 		 *   For the first write of any `key`, the `version` should be '0'. If the write succeeds, the client
 		 *   must increment their corresponding key versions (client-side) by 1.
 		 *   The server increments key versions (server-side) for every successful write, hence this
 		 *   client-side increment is required to ensure matching versions. These updated key versions should
 		 *   be used in subsequent `PutObjectRequest`s for the keys.
+		 *
 		 *   Requests with a conflicting/mismatched version will fail with `CONFLICT_EXCEPTION` as ErrorCode
 		 *   for conditional writes.
+		 *
 		 * Skipping key-level versioning (Non-conditional Write):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional write query, after which the `version` against the `key`
 		 *   is reset to '1'. Hence, the next `PutObjectRequest` for the `key` can be either
 		 *   a non-conditional write or a conditional write with `version` set to `1`.
+		 *
 		 * Considerations for transactions:
 		 * Transaction writes of multiple items have a performance overhead, hence it is recommended to use
 		 * them only if required by the client application to ensure logic/code correctness.
 		 * That is, `transaction_items` are not a substitute for batch-write of multiple unrelated items.
 		 * When a write of multiple unrelated items is desired, it is recommended to use separate
 		 * `PutObjectRequest`s.
+		 *
 		 * Consistency guarantee:
 		 * All `PutObjectRequest`s are strongly consistent i.e. they provide read-after-write and
 		 * read-after-update consistency guarantees.
@@ -1455,35 +1578,43 @@ public org.vss.KeyValue getTransactionItems(int index) {
 		/**
 		 * <pre>
 		 * Items to be written as a result of this `PutObjectRequest`.
+		 *
 		 * In an item, each `key` is supplied with its corresponding `value` and `version`.
 		 * Clients can choose to encrypt the keys client-side in order to obfuscate their usage patterns.
 		 * If the write is successful, the previous `value` corresponding to the `key` will be overwritten.
+		 *
 		 * Multiple items in `transaction_items` and `delete_items` of a single `PutObjectRequest` are written in
 		 * a database-transaction in an all-or-nothing fashion.
 		 * All Items in a single `PutObjectRequest` must have distinct keys.
+		 *
 		 * Key-level versioning (Conditional Write):
 		 *   Clients are expected to store a `version` against every `key`.
 		 *   The write will succeed if the current DB version against the `key` is the same as in the request.
 		 *   When initiating a `PutObjectRequest`, the request should contain their client-side `version`
 		 *   for that key-value.
+		 *
 		 *   For the first write of any `key`, the `version` should be '0'. If the write succeeds, the client
 		 *   must increment their corresponding key versions (client-side) by 1.
 		 *   The server increments key versions (server-side) for every successful write, hence this
 		 *   client-side increment is required to ensure matching versions. These updated key versions should
 		 *   be used in subsequent `PutObjectRequest`s for the keys.
+		 *
 		 *   Requests with a conflicting/mismatched version will fail with `CONFLICT_EXCEPTION` as ErrorCode
 		 *   for conditional writes.
+		 *
 		 * Skipping key-level versioning (Non-conditional Write):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional write query, after which the `version` against the `key`
 		 *   is reset to '1'. Hence, the next `PutObjectRequest` for the `key` can be either
 		 *   a non-conditional write or a conditional write with `version` set to `1`.
+		 *
 		 * Considerations for transactions:
 		 * Transaction writes of multiple items have a performance overhead, hence it is recommended to use
 		 * them only if required by the client application to ensure logic/code correctness.
 		 * That is, `transaction_items` are not a substitute for batch-write of multiple unrelated items.
 		 * When a write of multiple unrelated items is desired, it is recommended to use separate
 		 * `PutObjectRequest`s.
+		 *
 		 * Consistency guarantee:
 		 * All `PutObjectRequest`s are strongly consistent i.e. they provide read-after-write and
 		 * read-after-update consistency guarantees.
@@ -1509,35 +1640,43 @@ public Builder setTransactionItems(
 		/**
 		 * <pre>
 		 * Items to be written as a result of this `PutObjectRequest`.
+		 *
 		 * In an item, each `key` is supplied with its corresponding `value` and `version`.
 		 * Clients can choose to encrypt the keys client-side in order to obfuscate their usage patterns.
 		 * If the write is successful, the previous `value` corresponding to the `key` will be overwritten.
+		 *
 		 * Multiple items in `transaction_items` and `delete_items` of a single `PutObjectRequest` are written in
 		 * a database-transaction in an all-or-nothing fashion.
 		 * All Items in a single `PutObjectRequest` must have distinct keys.
+		 *
 		 * Key-level versioning (Conditional Write):
 		 *   Clients are expected to store a `version` against every `key`.
 		 *   The write will succeed if the current DB version against the `key` is the same as in the request.
 		 *   When initiating a `PutObjectRequest`, the request should contain their client-side `version`
 		 *   for that key-value.
+		 *
 		 *   For the first write of any `key`, the `version` should be '0'. If the write succeeds, the client
 		 *   must increment their corresponding key versions (client-side) by 1.
 		 *   The server increments key versions (server-side) for every successful write, hence this
 		 *   client-side increment is required to ensure matching versions. These updated key versions should
 		 *   be used in subsequent `PutObjectRequest`s for the keys.
+		 *
 		 *   Requests with a conflicting/mismatched version will fail with `CONFLICT_EXCEPTION` as ErrorCode
 		 *   for conditional writes.
+		 *
 		 * Skipping key-level versioning (Non-conditional Write):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional write query, after which the `version` against the `key`
 		 *   is reset to '1'. Hence, the next `PutObjectRequest` for the `key` can be either
 		 *   a non-conditional write or a conditional write with `version` set to `1`.
+		 *
 		 * Considerations for transactions:
 		 * Transaction writes of multiple items have a performance overhead, hence it is recommended to use
 		 * them only if required by the client application to ensure logic/code correctness.
 		 * That is, `transaction_items` are not a substitute for batch-write of multiple unrelated items.
 		 * When a write of multiple unrelated items is desired, it is recommended to use separate
 		 * `PutObjectRequest`s.
+		 *
 		 * Consistency guarantee:
 		 * All `PutObjectRequest`s are strongly consistent i.e. they provide read-after-write and
 		 * read-after-update consistency guarantees.
@@ -1560,35 +1699,43 @@ public Builder setTransactionItems(
 		/**
 		 * <pre>
 		 * Items to be written as a result of this `PutObjectRequest`.
+		 *
 		 * In an item, each `key` is supplied with its corresponding `value` and `version`.
 		 * Clients can choose to encrypt the keys client-side in order to obfuscate their usage patterns.
 		 * If the write is successful, the previous `value` corresponding to the `key` will be overwritten.
+		 *
 		 * Multiple items in `transaction_items` and `delete_items` of a single `PutObjectRequest` are written in
 		 * a database-transaction in an all-or-nothing fashion.
 		 * All Items in a single `PutObjectRequest` must have distinct keys.
+		 *
 		 * Key-level versioning (Conditional Write):
 		 *   Clients are expected to store a `version` against every `key`.
 		 *   The write will succeed if the current DB version against the `key` is the same as in the request.
 		 *   When initiating a `PutObjectRequest`, the request should contain their client-side `version`
 		 *   for that key-value.
+		 *
 		 *   For the first write of any `key`, the `version` should be '0'. If the write succeeds, the client
 		 *   must increment their corresponding key versions (client-side) by 1.
 		 *   The server increments key versions (server-side) for every successful write, hence this
 		 *   client-side increment is required to ensure matching versions. These updated key versions should
 		 *   be used in subsequent `PutObjectRequest`s for the keys.
+		 *
 		 *   Requests with a conflicting/mismatched version will fail with `CONFLICT_EXCEPTION` as ErrorCode
 		 *   for conditional writes.
+		 *
 		 * Skipping key-level versioning (Non-conditional Write):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional write query, after which the `version` against the `key`
 		 *   is reset to '1'. Hence, the next `PutObjectRequest` for the `key` can be either
 		 *   a non-conditional write or a conditional write with `version` set to `1`.
+		 *
 		 * Considerations for transactions:
 		 * Transaction writes of multiple items have a performance overhead, hence it is recommended to use
 		 * them only if required by the client application to ensure logic/code correctness.
 		 * That is, `transaction_items` are not a substitute for batch-write of multiple unrelated items.
 		 * When a write of multiple unrelated items is desired, it is recommended to use separate
 		 * `PutObjectRequest`s.
+		 *
 		 * Consistency guarantee:
 		 * All `PutObjectRequest`s are strongly consistent i.e. they provide read-after-write and
 		 * read-after-update consistency guarantees.
@@ -1613,35 +1760,43 @@ public Builder addTransactionItems(org.vss.KeyValue value) {
 		/**
 		 * <pre>
 		 * Items to be written as a result of this `PutObjectRequest`.
+		 *
 		 * In an item, each `key` is supplied with its corresponding `value` and `version`.
 		 * Clients can choose to encrypt the keys client-side in order to obfuscate their usage patterns.
 		 * If the write is successful, the previous `value` corresponding to the `key` will be overwritten.
+		 *
 		 * Multiple items in `transaction_items` and `delete_items` of a single `PutObjectRequest` are written in
 		 * a database-transaction in an all-or-nothing fashion.
 		 * All Items in a single `PutObjectRequest` must have distinct keys.
+		 *
 		 * Key-level versioning (Conditional Write):
 		 *   Clients are expected to store a `version` against every `key`.
 		 *   The write will succeed if the current DB version against the `key` is the same as in the request.
 		 *   When initiating a `PutObjectRequest`, the request should contain their client-side `version`
 		 *   for that key-value.
+		 *
 		 *   For the first write of any `key`, the `version` should be '0'. If the write succeeds, the client
 		 *   must increment their corresponding key versions (client-side) by 1.
 		 *   The server increments key versions (server-side) for every successful write, hence this
 		 *   client-side increment is required to ensure matching versions. These updated key versions should
 		 *   be used in subsequent `PutObjectRequest`s for the keys.
+		 *
 		 *   Requests with a conflicting/mismatched version will fail with `CONFLICT_EXCEPTION` as ErrorCode
 		 *   for conditional writes.
+		 *
 		 * Skipping key-level versioning (Non-conditional Write):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional write query, after which the `version` against the `key`
 		 *   is reset to '1'. Hence, the next `PutObjectRequest` for the `key` can be either
 		 *   a non-conditional write or a conditional write with `version` set to `1`.
+		 *
 		 * Considerations for transactions:
 		 * Transaction writes of multiple items have a performance overhead, hence it is recommended to use
 		 * them only if required by the client application to ensure logic/code correctness.
 		 * That is, `transaction_items` are not a substitute for batch-write of multiple unrelated items.
 		 * When a write of multiple unrelated items is desired, it is recommended to use separate
 		 * `PutObjectRequest`s.
+		 *
 		 * Consistency guarantee:
 		 * All `PutObjectRequest`s are strongly consistent i.e. they provide read-after-write and
 		 * read-after-update consistency guarantees.
@@ -1667,35 +1822,43 @@ public Builder addTransactionItems(
 		/**
 		 * <pre>
 		 * Items to be written as a result of this `PutObjectRequest`.
+		 *
 		 * In an item, each `key` is supplied with its corresponding `value` and `version`.
 		 * Clients can choose to encrypt the keys client-side in order to obfuscate their usage patterns.
 		 * If the write is successful, the previous `value` corresponding to the `key` will be overwritten.
+		 *
 		 * Multiple items in `transaction_items` and `delete_items` of a single `PutObjectRequest` are written in
 		 * a database-transaction in an all-or-nothing fashion.
 		 * All Items in a single `PutObjectRequest` must have distinct keys.
+		 *
 		 * Key-level versioning (Conditional Write):
 		 *   Clients are expected to store a `version` against every `key`.
 		 *   The write will succeed if the current DB version against the `key` is the same as in the request.
 		 *   When initiating a `PutObjectRequest`, the request should contain their client-side `version`
 		 *   for that key-value.
+		 *
 		 *   For the first write of any `key`, the `version` should be '0'. If the write succeeds, the client
 		 *   must increment their corresponding key versions (client-side) by 1.
 		 *   The server increments key versions (server-side) for every successful write, hence this
 		 *   client-side increment is required to ensure matching versions. These updated key versions should
 		 *   be used in subsequent `PutObjectRequest`s for the keys.
+		 *
 		 *   Requests with a conflicting/mismatched version will fail with `CONFLICT_EXCEPTION` as ErrorCode
 		 *   for conditional writes.
+		 *
 		 * Skipping key-level versioning (Non-conditional Write):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional write query, after which the `version` against the `key`
 		 *   is reset to '1'. Hence, the next `PutObjectRequest` for the `key` can be either
 		 *   a non-conditional write or a conditional write with `version` set to `1`.
+		 *
 		 * Considerations for transactions:
 		 * Transaction writes of multiple items have a performance overhead, hence it is recommended to use
 		 * them only if required by the client application to ensure logic/code correctness.
 		 * That is, `transaction_items` are not a substitute for batch-write of multiple unrelated items.
 		 * When a write of multiple unrelated items is desired, it is recommended to use separate
 		 * `PutObjectRequest`s.
+		 *
 		 * Consistency guarantee:
 		 * All `PutObjectRequest`s are strongly consistent i.e. they provide read-after-write and
 		 * read-after-update consistency guarantees.
@@ -1718,35 +1881,43 @@ public Builder addTransactionItems(
 		/**
 		 * <pre>
 		 * Items to be written as a result of this `PutObjectRequest`.
+		 *
 		 * In an item, each `key` is supplied with its corresponding `value` and `version`.
 		 * Clients can choose to encrypt the keys client-side in order to obfuscate their usage patterns.
 		 * If the write is successful, the previous `value` corresponding to the `key` will be overwritten.
+		 *
 		 * Multiple items in `transaction_items` and `delete_items` of a single `PutObjectRequest` are written in
 		 * a database-transaction in an all-or-nothing fashion.
 		 * All Items in a single `PutObjectRequest` must have distinct keys.
+		 *
 		 * Key-level versioning (Conditional Write):
 		 *   Clients are expected to store a `version` against every `key`.
 		 *   The write will succeed if the current DB version against the `key` is the same as in the request.
 		 *   When initiating a `PutObjectRequest`, the request should contain their client-side `version`
 		 *   for that key-value.
+		 *
 		 *   For the first write of any `key`, the `version` should be '0'. If the write succeeds, the client
 		 *   must increment their corresponding key versions (client-side) by 1.
 		 *   The server increments key versions (server-side) for every successful write, hence this
 		 *   client-side increment is required to ensure matching versions. These updated key versions should
 		 *   be used in subsequent `PutObjectRequest`s for the keys.
+		 *
 		 *   Requests with a conflicting/mismatched version will fail with `CONFLICT_EXCEPTION` as ErrorCode
 		 *   for conditional writes.
+		 *
 		 * Skipping key-level versioning (Non-conditional Write):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional write query, after which the `version` against the `key`
 		 *   is reset to '1'. Hence, the next `PutObjectRequest` for the `key` can be either
 		 *   a non-conditional write or a conditional write with `version` set to `1`.
+		 *
 		 * Considerations for transactions:
 		 * Transaction writes of multiple items have a performance overhead, hence it is recommended to use
 		 * them only if required by the client application to ensure logic/code correctness.
 		 * That is, `transaction_items` are not a substitute for batch-write of multiple unrelated items.
 		 * When a write of multiple unrelated items is desired, it is recommended to use separate
 		 * `PutObjectRequest`s.
+		 *
 		 * Consistency guarantee:
 		 * All `PutObjectRequest`s are strongly consistent i.e. they provide read-after-write and
 		 * read-after-update consistency guarantees.
@@ -1769,35 +1940,43 @@ public Builder addTransactionItems(
 		/**
 		 * <pre>
 		 * Items to be written as a result of this `PutObjectRequest`.
+		 *
 		 * In an item, each `key` is supplied with its corresponding `value` and `version`.
 		 * Clients can choose to encrypt the keys client-side in order to obfuscate their usage patterns.
 		 * If the write is successful, the previous `value` corresponding to the `key` will be overwritten.
+		 *
 		 * Multiple items in `transaction_items` and `delete_items` of a single `PutObjectRequest` are written in
 		 * a database-transaction in an all-or-nothing fashion.
 		 * All Items in a single `PutObjectRequest` must have distinct keys.
+		 *
 		 * Key-level versioning (Conditional Write):
 		 *   Clients are expected to store a `version` against every `key`.
 		 *   The write will succeed if the current DB version against the `key` is the same as in the request.
 		 *   When initiating a `PutObjectRequest`, the request should contain their client-side `version`
 		 *   for that key-value.
+		 *
 		 *   For the first write of any `key`, the `version` should be '0'. If the write succeeds, the client
 		 *   must increment their corresponding key versions (client-side) by 1.
 		 *   The server increments key versions (server-side) for every successful write, hence this
 		 *   client-side increment is required to ensure matching versions. These updated key versions should
 		 *   be used in subsequent `PutObjectRequest`s for the keys.
+		 *
 		 *   Requests with a conflicting/mismatched version will fail with `CONFLICT_EXCEPTION` as ErrorCode
 		 *   for conditional writes.
+		 *
 		 * Skipping key-level versioning (Non-conditional Write):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional write query, after which the `version` against the `key`
 		 *   is reset to '1'. Hence, the next `PutObjectRequest` for the `key` can be either
 		 *   a non-conditional write or a conditional write with `version` set to `1`.
+		 *
 		 * Considerations for transactions:
 		 * Transaction writes of multiple items have a performance overhead, hence it is recommended to use
 		 * them only if required by the client application to ensure logic/code correctness.
 		 * That is, `transaction_items` are not a substitute for batch-write of multiple unrelated items.
 		 * When a write of multiple unrelated items is desired, it is recommended to use separate
 		 * `PutObjectRequest`s.
+		 *
 		 * Consistency guarantee:
 		 * All `PutObjectRequest`s are strongly consistent i.e. they provide read-after-write and
 		 * read-after-update consistency guarantees.
@@ -1821,35 +2000,43 @@ public Builder addAllTransactionItems(
 		/**
 		 * <pre>
 		 * Items to be written as a result of this `PutObjectRequest`.
+		 *
 		 * In an item, each `key` is supplied with its corresponding `value` and `version`.
 		 * Clients can choose to encrypt the keys client-side in order to obfuscate their usage patterns.
 		 * If the write is successful, the previous `value` corresponding to the `key` will be overwritten.
+		 *
 		 * Multiple items in `transaction_items` and `delete_items` of a single `PutObjectRequest` are written in
 		 * a database-transaction in an all-or-nothing fashion.
 		 * All Items in a single `PutObjectRequest` must have distinct keys.
+		 *
 		 * Key-level versioning (Conditional Write):
 		 *   Clients are expected to store a `version` against every `key`.
 		 *   The write will succeed if the current DB version against the `key` is the same as in the request.
 		 *   When initiating a `PutObjectRequest`, the request should contain their client-side `version`
 		 *   for that key-value.
+		 *
 		 *   For the first write of any `key`, the `version` should be '0'. If the write succeeds, the client
 		 *   must increment their corresponding key versions (client-side) by 1.
 		 *   The server increments key versions (server-side) for every successful write, hence this
 		 *   client-side increment is required to ensure matching versions. These updated key versions should
 		 *   be used in subsequent `PutObjectRequest`s for the keys.
+		 *
 		 *   Requests with a conflicting/mismatched version will fail with `CONFLICT_EXCEPTION` as ErrorCode
 		 *   for conditional writes.
+		 *
 		 * Skipping key-level versioning (Non-conditional Write):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional write query, after which the `version` against the `key`
 		 *   is reset to '1'. Hence, the next `PutObjectRequest` for the `key` can be either
 		 *   a non-conditional write or a conditional write with `version` set to `1`.
+		 *
 		 * Considerations for transactions:
 		 * Transaction writes of multiple items have a performance overhead, hence it is recommended to use
 		 * them only if required by the client application to ensure logic/code correctness.
 		 * That is, `transaction_items` are not a substitute for batch-write of multiple unrelated items.
 		 * When a write of multiple unrelated items is desired, it is recommended to use separate
 		 * `PutObjectRequest`s.
+		 *
 		 * Consistency guarantee:
 		 * All `PutObjectRequest`s are strongly consistent i.e. they provide read-after-write and
 		 * read-after-update consistency guarantees.
@@ -1860,7 +2047,7 @@ public Builder addAllTransactionItems(
 		public Builder clearTransactionItems() {
 			if (transactionItemsBuilder_ == null) {
 				transactionItems_ = java.util.Collections.emptyList();
-				bitField0_ = (bitField0_ & ~0x00000002);
+				bitField0_ = (bitField0_ & ~0x00000004);
 				onChanged();
 			} else {
 				transactionItemsBuilder_.clear();
@@ -1871,35 +2058,43 @@ public Builder clearTransactionItems() {
 		/**
 		 * <pre>
 		 * Items to be written as a result of this `PutObjectRequest`.
+		 *
 		 * In an item, each `key` is supplied with its corresponding `value` and `version`.
 		 * Clients can choose to encrypt the keys client-side in order to obfuscate their usage patterns.
 		 * If the write is successful, the previous `value` corresponding to the `key` will be overwritten.
+		 *
 		 * Multiple items in `transaction_items` and `delete_items` of a single `PutObjectRequest` are written in
 		 * a database-transaction in an all-or-nothing fashion.
 		 * All Items in a single `PutObjectRequest` must have distinct keys.
+		 *
 		 * Key-level versioning (Conditional Write):
 		 *   Clients are expected to store a `version` against every `key`.
 		 *   The write will succeed if the current DB version against the `key` is the same as in the request.
 		 *   When initiating a `PutObjectRequest`, the request should contain their client-side `version`
 		 *   for that key-value.
+		 *
 		 *   For the first write of any `key`, the `version` should be '0'. If the write succeeds, the client
 		 *   must increment their corresponding key versions (client-side) by 1.
 		 *   The server increments key versions (server-side) for every successful write, hence this
 		 *   client-side increment is required to ensure matching versions. These updated key versions should
 		 *   be used in subsequent `PutObjectRequest`s for the keys.
+		 *
 		 *   Requests with a conflicting/mismatched version will fail with `CONFLICT_EXCEPTION` as ErrorCode
 		 *   for conditional writes.
+		 *
 		 * Skipping key-level versioning (Non-conditional Write):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional write query, after which the `version` against the `key`
 		 *   is reset to '1'. Hence, the next `PutObjectRequest` for the `key` can be either
 		 *   a non-conditional write or a conditional write with `version` set to `1`.
+		 *
 		 * Considerations for transactions:
 		 * Transaction writes of multiple items have a performance overhead, hence it is recommended to use
 		 * them only if required by the client application to ensure logic/code correctness.
 		 * That is, `transaction_items` are not a substitute for batch-write of multiple unrelated items.
 		 * When a write of multiple unrelated items is desired, it is recommended to use separate
 		 * `PutObjectRequest`s.
+		 *
 		 * Consistency guarantee:
 		 * All `PutObjectRequest`s are strongly consistent i.e. they provide read-after-write and
 		 * read-after-update consistency guarantees.
@@ -1921,35 +2116,43 @@ public Builder removeTransactionItems(int index) {
 		/**
 		 * <pre>
 		 * Items to be written as a result of this `PutObjectRequest`.
+		 *
 		 * In an item, each `key` is supplied with its corresponding `value` and `version`.
 		 * Clients can choose to encrypt the keys client-side in order to obfuscate their usage patterns.
 		 * If the write is successful, the previous `value` corresponding to the `key` will be overwritten.
+		 *
 		 * Multiple items in `transaction_items` and `delete_items` of a single `PutObjectRequest` are written in
 		 * a database-transaction in an all-or-nothing fashion.
 		 * All Items in a single `PutObjectRequest` must have distinct keys.
+		 *
 		 * Key-level versioning (Conditional Write):
 		 *   Clients are expected to store a `version` against every `key`.
 		 *   The write will succeed if the current DB version against the `key` is the same as in the request.
 		 *   When initiating a `PutObjectRequest`, the request should contain their client-side `version`
 		 *   for that key-value.
+		 *
 		 *   For the first write of any `key`, the `version` should be '0'. If the write succeeds, the client
 		 *   must increment their corresponding key versions (client-side) by 1.
 		 *   The server increments key versions (server-side) for every successful write, hence this
 		 *   client-side increment is required to ensure matching versions. These updated key versions should
 		 *   be used in subsequent `PutObjectRequest`s for the keys.
+		 *
 		 *   Requests with a conflicting/mismatched version will fail with `CONFLICT_EXCEPTION` as ErrorCode
 		 *   for conditional writes.
+		 *
 		 * Skipping key-level versioning (Non-conditional Write):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional write query, after which the `version` against the `key`
 		 *   is reset to '1'. Hence, the next `PutObjectRequest` for the `key` can be either
 		 *   a non-conditional write or a conditional write with `version` set to `1`.
+		 *
 		 * Considerations for transactions:
 		 * Transaction writes of multiple items have a performance overhead, hence it is recommended to use
 		 * them only if required by the client application to ensure logic/code correctness.
 		 * That is, `transaction_items` are not a substitute for batch-write of multiple unrelated items.
 		 * When a write of multiple unrelated items is desired, it is recommended to use separate
 		 * `PutObjectRequest`s.
+		 *
 		 * Consistency guarantee:
 		 * All `PutObjectRequest`s are strongly consistent i.e. they provide read-after-write and
 		 * read-after-update consistency guarantees.
@@ -1965,35 +2168,43 @@ public org.vss.KeyValue.Builder getTransactionItemsBuilder(
 		/**
 		 * <pre>
 		 * Items to be written as a result of this `PutObjectRequest`.
+		 *
 		 * In an item, each `key` is supplied with its corresponding `value` and `version`.
 		 * Clients can choose to encrypt the keys client-side in order to obfuscate their usage patterns.
 		 * If the write is successful, the previous `value` corresponding to the `key` will be overwritten.
+		 *
 		 * Multiple items in `transaction_items` and `delete_items` of a single `PutObjectRequest` are written in
 		 * a database-transaction in an all-or-nothing fashion.
 		 * All Items in a single `PutObjectRequest` must have distinct keys.
+		 *
 		 * Key-level versioning (Conditional Write):
 		 *   Clients are expected to store a `version` against every `key`.
 		 *   The write will succeed if the current DB version against the `key` is the same as in the request.
 		 *   When initiating a `PutObjectRequest`, the request should contain their client-side `version`
 		 *   for that key-value.
+		 *
 		 *   For the first write of any `key`, the `version` should be '0'. If the write succeeds, the client
 		 *   must increment their corresponding key versions (client-side) by 1.
 		 *   The server increments key versions (server-side) for every successful write, hence this
 		 *   client-side increment is required to ensure matching versions. These updated key versions should
 		 *   be used in subsequent `PutObjectRequest`s for the keys.
+		 *
 		 *   Requests with a conflicting/mismatched version will fail with `CONFLICT_EXCEPTION` as ErrorCode
 		 *   for conditional writes.
+		 *
 		 * Skipping key-level versioning (Non-conditional Write):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional write query, after which the `version` against the `key`
 		 *   is reset to '1'. Hence, the next `PutObjectRequest` for the `key` can be either
 		 *   a non-conditional write or a conditional write with `version` set to `1`.
+		 *
 		 * Considerations for transactions:
 		 * Transaction writes of multiple items have a performance overhead, hence it is recommended to use
 		 * them only if required by the client application to ensure logic/code correctness.
 		 * That is, `transaction_items` are not a substitute for batch-write of multiple unrelated items.
 		 * When a write of multiple unrelated items is desired, it is recommended to use separate
 		 * `PutObjectRequest`s.
+		 *
 		 * Consistency guarantee:
 		 * All `PutObjectRequest`s are strongly consistent i.e. they provide read-after-write and
 		 * read-after-update consistency guarantees.
@@ -2013,35 +2224,43 @@ public org.vss.KeyValueOrBuilder getTransactionItemsOrBuilder(
 		/**
 		 * <pre>
 		 * Items to be written as a result of this `PutObjectRequest`.
+		 *
 		 * In an item, each `key` is supplied with its corresponding `value` and `version`.
 		 * Clients can choose to encrypt the keys client-side in order to obfuscate their usage patterns.
 		 * If the write is successful, the previous `value` corresponding to the `key` will be overwritten.
+		 *
 		 * Multiple items in `transaction_items` and `delete_items` of a single `PutObjectRequest` are written in
 		 * a database-transaction in an all-or-nothing fashion.
 		 * All Items in a single `PutObjectRequest` must have distinct keys.
+		 *
 		 * Key-level versioning (Conditional Write):
 		 *   Clients are expected to store a `version` against every `key`.
 		 *   The write will succeed if the current DB version against the `key` is the same as in the request.
 		 *   When initiating a `PutObjectRequest`, the request should contain their client-side `version`
 		 *   for that key-value.
+		 *
 		 *   For the first write of any `key`, the `version` should be '0'. If the write succeeds, the client
 		 *   must increment their corresponding key versions (client-side) by 1.
 		 *   The server increments key versions (server-side) for every successful write, hence this
 		 *   client-side increment is required to ensure matching versions. These updated key versions should
 		 *   be used in subsequent `PutObjectRequest`s for the keys.
+		 *
 		 *   Requests with a conflicting/mismatched version will fail with `CONFLICT_EXCEPTION` as ErrorCode
 		 *   for conditional writes.
+		 *
 		 * Skipping key-level versioning (Non-conditional Write):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional write query, after which the `version` against the `key`
 		 *   is reset to '1'. Hence, the next `PutObjectRequest` for the `key` can be either
 		 *   a non-conditional write or a conditional write with `version` set to `1`.
+		 *
 		 * Considerations for transactions:
 		 * Transaction writes of multiple items have a performance overhead, hence it is recommended to use
 		 * them only if required by the client application to ensure logic/code correctness.
 		 * That is, `transaction_items` are not a substitute for batch-write of multiple unrelated items.
 		 * When a write of multiple unrelated items is desired, it is recommended to use separate
 		 * `PutObjectRequest`s.
+		 *
 		 * Consistency guarantee:
 		 * All `PutObjectRequest`s are strongly consistent i.e. they provide read-after-write and
 		 * read-after-update consistency guarantees.
@@ -2061,35 +2280,43 @@ public org.vss.KeyValueOrBuilder getTransactionItemsOrBuilder(
 		/**
 		 * <pre>
 		 * Items to be written as a result of this `PutObjectRequest`.
+		 *
 		 * In an item, each `key` is supplied with its corresponding `value` and `version`.
 		 * Clients can choose to encrypt the keys client-side in order to obfuscate their usage patterns.
 		 * If the write is successful, the previous `value` corresponding to the `key` will be overwritten.
+		 *
 		 * Multiple items in `transaction_items` and `delete_items` of a single `PutObjectRequest` are written in
 		 * a database-transaction in an all-or-nothing fashion.
 		 * All Items in a single `PutObjectRequest` must have distinct keys.
+		 *
 		 * Key-level versioning (Conditional Write):
 		 *   Clients are expected to store a `version` against every `key`.
 		 *   The write will succeed if the current DB version against the `key` is the same as in the request.
 		 *   When initiating a `PutObjectRequest`, the request should contain their client-side `version`
 		 *   for that key-value.
+		 *
 		 *   For the first write of any `key`, the `version` should be '0'. If the write succeeds, the client
 		 *   must increment their corresponding key versions (client-side) by 1.
 		 *   The server increments key versions (server-side) for every successful write, hence this
 		 *   client-side increment is required to ensure matching versions. These updated key versions should
 		 *   be used in subsequent `PutObjectRequest`s for the keys.
+		 *
 		 *   Requests with a conflicting/mismatched version will fail with `CONFLICT_EXCEPTION` as ErrorCode
 		 *   for conditional writes.
+		 *
 		 * Skipping key-level versioning (Non-conditional Write):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional write query, after which the `version` against the `key`
 		 *   is reset to '1'. Hence, the next `PutObjectRequest` for the `key` can be either
 		 *   a non-conditional write or a conditional write with `version` set to `1`.
+		 *
 		 * Considerations for transactions:
 		 * Transaction writes of multiple items have a performance overhead, hence it is recommended to use
 		 * them only if required by the client application to ensure logic/code correctness.
 		 * That is, `transaction_items` are not a substitute for batch-write of multiple unrelated items.
 		 * When a write of multiple unrelated items is desired, it is recommended to use separate
 		 * `PutObjectRequest`s.
+		 *
 		 * Consistency guarantee:
 		 * All `PutObjectRequest`s are strongly consistent i.e. they provide read-after-write and
 		 * read-after-update consistency guarantees.
@@ -2105,35 +2332,43 @@ public org.vss.KeyValue.Builder addTransactionItemsBuilder() {
 		/**
 		 * <pre>
 		 * Items to be written as a result of this `PutObjectRequest`.
+		 *
 		 * In an item, each `key` is supplied with its corresponding `value` and `version`.
 		 * Clients can choose to encrypt the keys client-side in order to obfuscate their usage patterns.
 		 * If the write is successful, the previous `value` corresponding to the `key` will be overwritten.
+		 *
 		 * Multiple items in `transaction_items` and `delete_items` of a single `PutObjectRequest` are written in
 		 * a database-transaction in an all-or-nothing fashion.
 		 * All Items in a single `PutObjectRequest` must have distinct keys.
+		 *
 		 * Key-level versioning (Conditional Write):
 		 *   Clients are expected to store a `version` against every `key`.
 		 *   The write will succeed if the current DB version against the `key` is the same as in the request.
 		 *   When initiating a `PutObjectRequest`, the request should contain their client-side `version`
 		 *   for that key-value.
+		 *
 		 *   For the first write of any `key`, the `version` should be '0'. If the write succeeds, the client
 		 *   must increment their corresponding key versions (client-side) by 1.
 		 *   The server increments key versions (server-side) for every successful write, hence this
 		 *   client-side increment is required to ensure matching versions. These updated key versions should
 		 *   be used in subsequent `PutObjectRequest`s for the keys.
+		 *
 		 *   Requests with a conflicting/mismatched version will fail with `CONFLICT_EXCEPTION` as ErrorCode
 		 *   for conditional writes.
+		 *
 		 * Skipping key-level versioning (Non-conditional Write):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional write query, after which the `version` against the `key`
 		 *   is reset to '1'. Hence, the next `PutObjectRequest` for the `key` can be either
 		 *   a non-conditional write or a conditional write with `version` set to `1`.
+		 *
 		 * Considerations for transactions:
 		 * Transaction writes of multiple items have a performance overhead, hence it is recommended to use
 		 * them only if required by the client application to ensure logic/code correctness.
 		 * That is, `transaction_items` are not a substitute for batch-write of multiple unrelated items.
 		 * When a write of multiple unrelated items is desired, it is recommended to use separate
 		 * `PutObjectRequest`s.
+		 *
 		 * Consistency guarantee:
 		 * All `PutObjectRequest`s are strongly consistent i.e. they provide read-after-write and
 		 * read-after-update consistency guarantees.
@@ -2150,35 +2385,43 @@ public org.vss.KeyValue.Builder addTransactionItemsBuilder(
 		/**
 		 * <pre>
 		 * Items to be written as a result of this `PutObjectRequest`.
+		 *
 		 * In an item, each `key` is supplied with its corresponding `value` and `version`.
 		 * Clients can choose to encrypt the keys client-side in order to obfuscate their usage patterns.
 		 * If the write is successful, the previous `value` corresponding to the `key` will be overwritten.
+		 *
 		 * Multiple items in `transaction_items` and `delete_items` of a single `PutObjectRequest` are written in
 		 * a database-transaction in an all-or-nothing fashion.
 		 * All Items in a single `PutObjectRequest` must have distinct keys.
+		 *
 		 * Key-level versioning (Conditional Write):
 		 *   Clients are expected to store a `version` against every `key`.
 		 *   The write will succeed if the current DB version against the `key` is the same as in the request.
 		 *   When initiating a `PutObjectRequest`, the request should contain their client-side `version`
 		 *   for that key-value.
+		 *
 		 *   For the first write of any `key`, the `version` should be '0'. If the write succeeds, the client
 		 *   must increment their corresponding key versions (client-side) by 1.
 		 *   The server increments key versions (server-side) for every successful write, hence this
 		 *   client-side increment is required to ensure matching versions. These updated key versions should
 		 *   be used in subsequent `PutObjectRequest`s for the keys.
+		 *
 		 *   Requests with a conflicting/mismatched version will fail with `CONFLICT_EXCEPTION` as ErrorCode
 		 *   for conditional writes.
+		 *
 		 * Skipping key-level versioning (Non-conditional Write):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional write query, after which the `version` against the `key`
 		 *   is reset to '1'. Hence, the next `PutObjectRequest` for the `key` can be either
 		 *   a non-conditional write or a conditional write with `version` set to `1`.
+		 *
 		 * Considerations for transactions:
 		 * Transaction writes of multiple items have a performance overhead, hence it is recommended to use
 		 * them only if required by the client application to ensure logic/code correctness.
 		 * That is, `transaction_items` are not a substitute for batch-write of multiple unrelated items.
 		 * When a write of multiple unrelated items is desired, it is recommended to use separate
 		 * `PutObjectRequest`s.
+		 *
 		 * Consistency guarantee:
 		 * All `PutObjectRequest`s are strongly consistent i.e. they provide read-after-write and
 		 * read-after-update consistency guarantees.
@@ -2198,7 +2441,7 @@ public org.vss.KeyValue.Builder addTransactionItemsBuilder(
 				transactionItemsBuilder_ = new com.google.protobuf.RepeatedFieldBuilderV3<
 						org.vss.KeyValue, org.vss.KeyValue.Builder, org.vss.KeyValueOrBuilder>(
 						transactionItems_,
-						((bitField0_ & 0x00000002) != 0),
+						((bitField0_ & 0x00000004) != 0),
 						getParentForChildren(),
 						isClean());
 				transactionItems_ = null;
@@ -2210,9 +2453,9 @@ public org.vss.KeyValue.Builder addTransactionItemsBuilder(
 				java.util.Collections.emptyList();
 
 		private void ensureDeleteItemsIsMutable() {
-			if (!((bitField0_ & 0x00000004) != 0)) {
+			if (!((bitField0_ & 0x00000008) != 0)) {
 				deleteItems_ = new java.util.ArrayList<org.vss.KeyValue>(deleteItems_);
-				bitField0_ |= 0x00000004;
+				bitField0_ |= 0x00000008;
 			}
 		}
 
@@ -2222,20 +2465,26 @@ private void ensureDeleteItemsIsMutable() {
 		/**
 		 * <pre>
 		 * Items to be deleted as a result of this `PutObjectRequest`.
+		 *
 		 * Each item in the `delete_items` field consists of a `key` and its corresponding `version`.
+		 *
 		 * Key-Level Versioning (Conditional Delete):
 		 *   The `version` is used to perform a version check before deleting the item.
 		 *   The delete will only succeed if the current database version against the `key` is the same as
 		 *   the `version` specified in the request.
+		 *
 		 * Skipping key-level versioning (Non-conditional Delete):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional delete query.
+		 *
 		 * Fails with `CONFLICT_EXCEPTION` as the ErrorCode if:
 		 *   * The requested item does not exist.
 		 *   * The requested item does exist but there is a version-number mismatch (in conditional delete)
 		 *     with the one in the database.
+		 *
 		 * Multiple items in the `delete_items` field, along with the `transaction_items`, are written in a
 		 * database transaction in an all-or-nothing fashion.
+		 *
 		 * All items within a single `PutObjectRequest` must have distinct keys.
 		 * </pre>
 		 *
@@ -2252,20 +2501,26 @@ public java.util.List<org.vss.KeyValue> getDeleteItemsList() {
 		/**
 		 * <pre>
 		 * Items to be deleted as a result of this `PutObjectRequest`.
+		 *
 		 * Each item in the `delete_items` field consists of a `key` and its corresponding `version`.
+		 *
 		 * Key-Level Versioning (Conditional Delete):
 		 *   The `version` is used to perform a version check before deleting the item.
 		 *   The delete will only succeed if the current database version against the `key` is the same as
 		 *   the `version` specified in the request.
+		 *
 		 * Skipping key-level versioning (Non-conditional Delete):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional delete query.
+		 *
 		 * Fails with `CONFLICT_EXCEPTION` as the ErrorCode if:
 		 *   * The requested item does not exist.
 		 *   * The requested item does exist but there is a version-number mismatch (in conditional delete)
 		 *     with the one in the database.
+		 *
 		 * Multiple items in the `delete_items` field, along with the `transaction_items`, are written in a
 		 * database transaction in an all-or-nothing fashion.
+		 *
 		 * All items within a single `PutObjectRequest` must have distinct keys.
 		 * </pre>
 		 *
@@ -2282,20 +2537,26 @@ public int getDeleteItemsCount() {
 		/**
 		 * <pre>
 		 * Items to be deleted as a result of this `PutObjectRequest`.
+		 *
 		 * Each item in the `delete_items` field consists of a `key` and its corresponding `version`.
+		 *
 		 * Key-Level Versioning (Conditional Delete):
 		 *   The `version` is used to perform a version check before deleting the item.
 		 *   The delete will only succeed if the current database version against the `key` is the same as
 		 *   the `version` specified in the request.
+		 *
 		 * Skipping key-level versioning (Non-conditional Delete):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional delete query.
+		 *
 		 * Fails with `CONFLICT_EXCEPTION` as the ErrorCode if:
 		 *   * The requested item does not exist.
 		 *   * The requested item does exist but there is a version-number mismatch (in conditional delete)
 		 *     with the one in the database.
+		 *
 		 * Multiple items in the `delete_items` field, along with the `transaction_items`, are written in a
 		 * database transaction in an all-or-nothing fashion.
+		 *
 		 * All items within a single `PutObjectRequest` must have distinct keys.
 		 * </pre>
 		 *
@@ -2312,20 +2573,26 @@ public org.vss.KeyValue getDeleteItems(int index) {
 		/**
 		 * <pre>
 		 * Items to be deleted as a result of this `PutObjectRequest`.
+		 *
 		 * Each item in the `delete_items` field consists of a `key` and its corresponding `version`.
+		 *
 		 * Key-Level Versioning (Conditional Delete):
 		 *   The `version` is used to perform a version check before deleting the item.
 		 *   The delete will only succeed if the current database version against the `key` is the same as
 		 *   the `version` specified in the request.
+		 *
 		 * Skipping key-level versioning (Non-conditional Delete):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional delete query.
+		 *
 		 * Fails with `CONFLICT_EXCEPTION` as the ErrorCode if:
 		 *   * The requested item does not exist.
 		 *   * The requested item does exist but there is a version-number mismatch (in conditional delete)
 		 *     with the one in the database.
+		 *
 		 * Multiple items in the `delete_items` field, along with the `transaction_items`, are written in a
 		 * database transaction in an all-or-nothing fashion.
+		 *
 		 * All items within a single `PutObjectRequest` must have distinct keys.
 		 * </pre>
 		 *
@@ -2349,20 +2616,26 @@ public Builder setDeleteItems(
 		/**
 		 * <pre>
 		 * Items to be deleted as a result of this `PutObjectRequest`.
+		 *
 		 * Each item in the `delete_items` field consists of a `key` and its corresponding `version`.
+		 *
 		 * Key-Level Versioning (Conditional Delete):
 		 *   The `version` is used to perform a version check before deleting the item.
 		 *   The delete will only succeed if the current database version against the `key` is the same as
 		 *   the `version` specified in the request.
+		 *
 		 * Skipping key-level versioning (Non-conditional Delete):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional delete query.
+		 *
 		 * Fails with `CONFLICT_EXCEPTION` as the ErrorCode if:
 		 *   * The requested item does not exist.
 		 *   * The requested item does exist but there is a version-number mismatch (in conditional delete)
 		 *     with the one in the database.
+		 *
 		 * Multiple items in the `delete_items` field, along with the `transaction_items`, are written in a
 		 * database transaction in an all-or-nothing fashion.
+		 *
 		 * All items within a single `PutObjectRequest` must have distinct keys.
 		 * </pre>
 		 *
@@ -2383,20 +2656,26 @@ public Builder setDeleteItems(
 		/**
 		 * <pre>
 		 * Items to be deleted as a result of this `PutObjectRequest`.
+		 *
 		 * Each item in the `delete_items` field consists of a `key` and its corresponding `version`.
+		 *
 		 * Key-Level Versioning (Conditional Delete):
 		 *   The `version` is used to perform a version check before deleting the item.
 		 *   The delete will only succeed if the current database version against the `key` is the same as
 		 *   the `version` specified in the request.
+		 *
 		 * Skipping key-level versioning (Non-conditional Delete):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional delete query.
+		 *
 		 * Fails with `CONFLICT_EXCEPTION` as the ErrorCode if:
 		 *   * The requested item does not exist.
 		 *   * The requested item does exist but there is a version-number mismatch (in conditional delete)
 		 *     with the one in the database.
+		 *
 		 * Multiple items in the `delete_items` field, along with the `transaction_items`, are written in a
 		 * database transaction in an all-or-nothing fashion.
+		 *
 		 * All items within a single `PutObjectRequest` must have distinct keys.
 		 * </pre>
 		 *
@@ -2419,20 +2698,26 @@ public Builder addDeleteItems(org.vss.KeyValue value) {
 		/**
 		 * <pre>
 		 * Items to be deleted as a result of this `PutObjectRequest`.
+		 *
 		 * Each item in the `delete_items` field consists of a `key` and its corresponding `version`.
+		 *
 		 * Key-Level Versioning (Conditional Delete):
 		 *   The `version` is used to perform a version check before deleting the item.
 		 *   The delete will only succeed if the current database version against the `key` is the same as
 		 *   the `version` specified in the request.
+		 *
 		 * Skipping key-level versioning (Non-conditional Delete):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional delete query.
+		 *
 		 * Fails with `CONFLICT_EXCEPTION` as the ErrorCode if:
 		 *   * The requested item does not exist.
 		 *   * The requested item does exist but there is a version-number mismatch (in conditional delete)
 		 *     with the one in the database.
+		 *
 		 * Multiple items in the `delete_items` field, along with the `transaction_items`, are written in a
 		 * database transaction in an all-or-nothing fashion.
+		 *
 		 * All items within a single `PutObjectRequest` must have distinct keys.
 		 * </pre>
 		 *
@@ -2456,20 +2741,26 @@ public Builder addDeleteItems(
 		/**
 		 * <pre>
 		 * Items to be deleted as a result of this `PutObjectRequest`.
+		 *
 		 * Each item in the `delete_items` field consists of a `key` and its corresponding `version`.
+		 *
 		 * Key-Level Versioning (Conditional Delete):
 		 *   The `version` is used to perform a version check before deleting the item.
 		 *   The delete will only succeed if the current database version against the `key` is the same as
 		 *   the `version` specified in the request.
+		 *
 		 * Skipping key-level versioning (Non-conditional Delete):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional delete query.
+		 *
 		 * Fails with `CONFLICT_EXCEPTION` as the ErrorCode if:
 		 *   * The requested item does not exist.
 		 *   * The requested item does exist but there is a version-number mismatch (in conditional delete)
 		 *     with the one in the database.
+		 *
 		 * Multiple items in the `delete_items` field, along with the `transaction_items`, are written in a
 		 * database transaction in an all-or-nothing fashion.
+		 *
 		 * All items within a single `PutObjectRequest` must have distinct keys.
 		 * </pre>
 		 *
@@ -2490,20 +2781,26 @@ public Builder addDeleteItems(
 		/**
 		 * <pre>
 		 * Items to be deleted as a result of this `PutObjectRequest`.
+		 *
 		 * Each item in the `delete_items` field consists of a `key` and its corresponding `version`.
+		 *
 		 * Key-Level Versioning (Conditional Delete):
 		 *   The `version` is used to perform a version check before deleting the item.
 		 *   The delete will only succeed if the current database version against the `key` is the same as
 		 *   the `version` specified in the request.
+		 *
 		 * Skipping key-level versioning (Non-conditional Delete):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional delete query.
+		 *
 		 * Fails with `CONFLICT_EXCEPTION` as the ErrorCode if:
 		 *   * The requested item does not exist.
 		 *   * The requested item does exist but there is a version-number mismatch (in conditional delete)
 		 *     with the one in the database.
+		 *
 		 * Multiple items in the `delete_items` field, along with the `transaction_items`, are written in a
 		 * database transaction in an all-or-nothing fashion.
+		 *
 		 * All items within a single `PutObjectRequest` must have distinct keys.
 		 * </pre>
 		 *
@@ -2524,20 +2821,26 @@ public Builder addDeleteItems(
 		/**
 		 * <pre>
 		 * Items to be deleted as a result of this `PutObjectRequest`.
+		 *
 		 * Each item in the `delete_items` field consists of a `key` and its corresponding `version`.
+		 *
 		 * Key-Level Versioning (Conditional Delete):
 		 *   The `version` is used to perform a version check before deleting the item.
 		 *   The delete will only succeed if the current database version against the `key` is the same as
 		 *   the `version` specified in the request.
+		 *
 		 * Skipping key-level versioning (Non-conditional Delete):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional delete query.
+		 *
 		 * Fails with `CONFLICT_EXCEPTION` as the ErrorCode if:
 		 *   * The requested item does not exist.
 		 *   * The requested item does exist but there is a version-number mismatch (in conditional delete)
 		 *     with the one in the database.
+		 *
 		 * Multiple items in the `delete_items` field, along with the `transaction_items`, are written in a
 		 * database transaction in an all-or-nothing fashion.
+		 *
 		 * All items within a single `PutObjectRequest` must have distinct keys.
 		 * </pre>
 		 *
@@ -2559,20 +2862,26 @@ public Builder addAllDeleteItems(
 		/**
 		 * <pre>
 		 * Items to be deleted as a result of this `PutObjectRequest`.
+		 *
 		 * Each item in the `delete_items` field consists of a `key` and its corresponding `version`.
+		 *
 		 * Key-Level Versioning (Conditional Delete):
 		 *   The `version` is used to perform a version check before deleting the item.
 		 *   The delete will only succeed if the current database version against the `key` is the same as
 		 *   the `version` specified in the request.
+		 *
 		 * Skipping key-level versioning (Non-conditional Delete):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional delete query.
+		 *
 		 * Fails with `CONFLICT_EXCEPTION` as the ErrorCode if:
 		 *   * The requested item does not exist.
 		 *   * The requested item does exist but there is a version-number mismatch (in conditional delete)
 		 *     with the one in the database.
+		 *
 		 * Multiple items in the `delete_items` field, along with the `transaction_items`, are written in a
 		 * database transaction in an all-or-nothing fashion.
+		 *
 		 * All items within a single `PutObjectRequest` must have distinct keys.
 		 * </pre>
 		 *
@@ -2581,7 +2890,7 @@ public Builder addAllDeleteItems(
 		public Builder clearDeleteItems() {
 			if (deleteItemsBuilder_ == null) {
 				deleteItems_ = java.util.Collections.emptyList();
-				bitField0_ = (bitField0_ & ~0x00000004);
+				bitField0_ = (bitField0_ & ~0x00000008);
 				onChanged();
 			} else {
 				deleteItemsBuilder_.clear();
@@ -2592,20 +2901,26 @@ public Builder clearDeleteItems() {
 		/**
 		 * <pre>
 		 * Items to be deleted as a result of this `PutObjectRequest`.
+		 *
 		 * Each item in the `delete_items` field consists of a `key` and its corresponding `version`.
+		 *
 		 * Key-Level Versioning (Conditional Delete):
 		 *   The `version` is used to perform a version check before deleting the item.
 		 *   The delete will only succeed if the current database version against the `key` is the same as
 		 *   the `version` specified in the request.
+		 *
 		 * Skipping key-level versioning (Non-conditional Delete):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional delete query.
+		 *
 		 * Fails with `CONFLICT_EXCEPTION` as the ErrorCode if:
 		 *   * The requested item does not exist.
 		 *   * The requested item does exist but there is a version-number mismatch (in conditional delete)
 		 *     with the one in the database.
+		 *
 		 * Multiple items in the `delete_items` field, along with the `transaction_items`, are written in a
 		 * database transaction in an all-or-nothing fashion.
+		 *
 		 * All items within a single `PutObjectRequest` must have distinct keys.
 		 * </pre>
 		 *
@@ -2625,20 +2940,26 @@ public Builder removeDeleteItems(int index) {
 		/**
 		 * <pre>
 		 * Items to be deleted as a result of this `PutObjectRequest`.
+		 *
 		 * Each item in the `delete_items` field consists of a `key` and its corresponding `version`.
+		 *
 		 * Key-Level Versioning (Conditional Delete):
 		 *   The `version` is used to perform a version check before deleting the item.
 		 *   The delete will only succeed if the current database version against the `key` is the same as
 		 *   the `version` specified in the request.
+		 *
 		 * Skipping key-level versioning (Non-conditional Delete):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional delete query.
+		 *
 		 * Fails with `CONFLICT_EXCEPTION` as the ErrorCode if:
 		 *   * The requested item does not exist.
 		 *   * The requested item does exist but there is a version-number mismatch (in conditional delete)
 		 *     with the one in the database.
+		 *
 		 * Multiple items in the `delete_items` field, along with the `transaction_items`, are written in a
 		 * database transaction in an all-or-nothing fashion.
+		 *
 		 * All items within a single `PutObjectRequest` must have distinct keys.
 		 * </pre>
 		 *
@@ -2652,20 +2973,26 @@ public org.vss.KeyValue.Builder getDeleteItemsBuilder(
 		/**
 		 * <pre>
 		 * Items to be deleted as a result of this `PutObjectRequest`.
+		 *
 		 * Each item in the `delete_items` field consists of a `key` and its corresponding `version`.
+		 *
 		 * Key-Level Versioning (Conditional Delete):
 		 *   The `version` is used to perform a version check before deleting the item.
 		 *   The delete will only succeed if the current database version against the `key` is the same as
 		 *   the `version` specified in the request.
+		 *
 		 * Skipping key-level versioning (Non-conditional Delete):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional delete query.
+		 *
 		 * Fails with `CONFLICT_EXCEPTION` as the ErrorCode if:
 		 *   * The requested item does not exist.
 		 *   * The requested item does exist but there is a version-number mismatch (in conditional delete)
 		 *     with the one in the database.
+		 *
 		 * Multiple items in the `delete_items` field, along with the `transaction_items`, are written in a
 		 * database transaction in an all-or-nothing fashion.
+		 *
 		 * All items within a single `PutObjectRequest` must have distinct keys.
 		 * </pre>
 		 *
@@ -2683,20 +3010,26 @@ public org.vss.KeyValueOrBuilder getDeleteItemsOrBuilder(
 		/**
 		 * <pre>
 		 * Items to be deleted as a result of this `PutObjectRequest`.
+		 *
 		 * Each item in the `delete_items` field consists of a `key` and its corresponding `version`.
+		 *
 		 * Key-Level Versioning (Conditional Delete):
 		 *   The `version` is used to perform a version check before deleting the item.
 		 *   The delete will only succeed if the current database version against the `key` is the same as
 		 *   the `version` specified in the request.
+		 *
 		 * Skipping key-level versioning (Non-conditional Delete):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional delete query.
+		 *
 		 * Fails with `CONFLICT_EXCEPTION` as the ErrorCode if:
 		 *   * The requested item does not exist.
 		 *   * The requested item does exist but there is a version-number mismatch (in conditional delete)
 		 *     with the one in the database.
+		 *
 		 * Multiple items in the `delete_items` field, along with the `transaction_items`, are written in a
 		 * database transaction in an all-or-nothing fashion.
+		 *
 		 * All items within a single `PutObjectRequest` must have distinct keys.
 		 * </pre>
 		 *
@@ -2714,20 +3047,26 @@ public org.vss.KeyValueOrBuilder getDeleteItemsOrBuilder(
 		/**
 		 * <pre>
 		 * Items to be deleted as a result of this `PutObjectRequest`.
+		 *
 		 * Each item in the `delete_items` field consists of a `key` and its corresponding `version`.
+		 *
 		 * Key-Level Versioning (Conditional Delete):
 		 *   The `version` is used to perform a version check before deleting the item.
 		 *   The delete will only succeed if the current database version against the `key` is the same as
 		 *   the `version` specified in the request.
+		 *
 		 * Skipping key-level versioning (Non-conditional Delete):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional delete query.
+		 *
 		 * Fails with `CONFLICT_EXCEPTION` as the ErrorCode if:
 		 *   * The requested item does not exist.
 		 *   * The requested item does exist but there is a version-number mismatch (in conditional delete)
 		 *     with the one in the database.
+		 *
 		 * Multiple items in the `delete_items` field, along with the `transaction_items`, are written in a
 		 * database transaction in an all-or-nothing fashion.
+		 *
 		 * All items within a single `PutObjectRequest` must have distinct keys.
 		 * </pre>
 		 *
@@ -2741,20 +3080,26 @@ public org.vss.KeyValue.Builder addDeleteItemsBuilder() {
 		/**
 		 * <pre>
 		 * Items to be deleted as a result of this `PutObjectRequest`.
+		 *
 		 * Each item in the `delete_items` field consists of a `key` and its corresponding `version`.
+		 *
 		 * Key-Level Versioning (Conditional Delete):
 		 *   The `version` is used to perform a version check before deleting the item.
 		 *   The delete will only succeed if the current database version against the `key` is the same as
 		 *   the `version` specified in the request.
+		 *
 		 * Skipping key-level versioning (Non-conditional Delete):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional delete query.
+		 *
 		 * Fails with `CONFLICT_EXCEPTION` as the ErrorCode if:
 		 *   * The requested item does not exist.
 		 *   * The requested item does exist but there is a version-number mismatch (in conditional delete)
 		 *     with the one in the database.
+		 *
 		 * Multiple items in the `delete_items` field, along with the `transaction_items`, are written in a
 		 * database transaction in an all-or-nothing fashion.
+		 *
 		 * All items within a single `PutObjectRequest` must have distinct keys.
 		 * </pre>
 		 *
@@ -2769,20 +3114,26 @@ public org.vss.KeyValue.Builder addDeleteItemsBuilder(
 		/**
 		 * <pre>
 		 * Items to be deleted as a result of this `PutObjectRequest`.
+		 *
 		 * Each item in the `delete_items` field consists of a `key` and its corresponding `version`.
+		 *
 		 * Key-Level Versioning (Conditional Delete):
 		 *   The `version` is used to perform a version check before deleting the item.
 		 *   The delete will only succeed if the current database version against the `key` is the same as
 		 *   the `version` specified in the request.
+		 *
 		 * Skipping key-level versioning (Non-conditional Delete):
 		 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 		 *   This will perform a non-conditional delete query.
+		 *
 		 * Fails with `CONFLICT_EXCEPTION` as the ErrorCode if:
 		 *   * The requested item does not exist.
 		 *   * The requested item does exist but there is a version-number mismatch (in conditional delete)
 		 *     with the one in the database.
+		 *
 		 * Multiple items in the `delete_items` field, along with the `transaction_items`, are written in a
 		 * database transaction in an all-or-nothing fashion.
+		 *
 		 * All items within a single `PutObjectRequest` must have distinct keys.
 		 * </pre>
 		 *
@@ -2800,7 +3151,7 @@ public org.vss.KeyValue.Builder addDeleteItemsBuilder(
 				deleteItemsBuilder_ = new com.google.protobuf.RepeatedFieldBuilderV3<
 						org.vss.KeyValue, org.vss.KeyValue.Builder, org.vss.KeyValueOrBuilder>(
 						deleteItems_,
-						((bitField0_ & 0x00000004) != 0),
+						((bitField0_ & 0x00000008) != 0),
 						getParentForChildren(),
 						isClean());
 				deleteItems_ = null;
diff --git a/java/app/src/main/generated/proto/org/vss/PutObjectRequestOrBuilder.java b/java/app/src/main/generated/proto/org/vss/PutObjectRequestOrBuilder.java
index 8265d4e..348ba68 100644
--- a/java/app/src/main/generated/proto/org/vss/PutObjectRequestOrBuilder.java
+++ b/java/app/src/main/generated/proto/org/vss/PutObjectRequestOrBuilder.java
@@ -1,6 +1,7 @@
 // Generated by the protocol buffer compiler.  DO NOT EDIT!
 // source: vss.proto
 
+// Protobuf Java Version: 3.25.5
 package org.vss;
 
 public interface PutObjectRequestOrBuilder extends
@@ -45,16 +46,19 @@ public interface PutObjectRequestOrBuilder extends
 	 * `global_version` is a sequence-number/version of the whole store. This can be used for versioning
 	 * and ensures that multiple updates in case of multiple devices can only be done linearly, even
 	 * if those updates did not directly conflict with each other based on keys/`transaction_items`.
+	 *
 	 * If present, the write will only succeed if the current server-side `global_version` against
 	 * the `store_id` is same as in the request.
 	 * Clients are expected to store (client-side) the global version against `store_id`.
 	 * The request must contain their client-side value of `global_version` if global versioning and
 	 * conflict detection is desired.
+	 *
 	 * For the first write of the store, global version should be '0'. If the write succeeds, clients
 	 * must increment their global version (client-side) by 1.
 	 * The server increments `global_version` (server-side) for every successful write, hence this
 	 * client-side increment is required to ensure matching versions. This updated global version
 	 * should be used in subsequent `PutObjectRequest`s for the store.
+	 *
 	 * Requests with a conflicting version will fail with `CONFLICT_EXCEPTION` as ErrorCode.
 	 * </pre>
 	 *
@@ -69,16 +73,19 @@ public interface PutObjectRequestOrBuilder extends
 	 * `global_version` is a sequence-number/version of the whole store. This can be used for versioning
 	 * and ensures that multiple updates in case of multiple devices can only be done linearly, even
 	 * if those updates did not directly conflict with each other based on keys/`transaction_items`.
+	 *
 	 * If present, the write will only succeed if the current server-side `global_version` against
 	 * the `store_id` is same as in the request.
 	 * Clients are expected to store (client-side) the global version against `store_id`.
 	 * The request must contain their client-side value of `global_version` if global versioning and
 	 * conflict detection is desired.
+	 *
 	 * For the first write of the store, global version should be '0'. If the write succeeds, clients
 	 * must increment their global version (client-side) by 1.
 	 * The server increments `global_version` (server-side) for every successful write, hence this
 	 * client-side increment is required to ensure matching versions. This updated global version
 	 * should be used in subsequent `PutObjectRequest`s for the store.
+	 *
 	 * Requests with a conflicting version will fail with `CONFLICT_EXCEPTION` as ErrorCode.
 	 * </pre>
 	 *
@@ -91,35 +98,43 @@ public interface PutObjectRequestOrBuilder extends
 	/**
 	 * <pre>
 	 * Items to be written as a result of this `PutObjectRequest`.
+	 *
 	 * In an item, each `key` is supplied with its corresponding `value` and `version`.
 	 * Clients can choose to encrypt the keys client-side in order to obfuscate their usage patterns.
 	 * If the write is successful, the previous `value` corresponding to the `key` will be overwritten.
+	 *
 	 * Multiple items in `transaction_items` and `delete_items` of a single `PutObjectRequest` are written in
 	 * a database-transaction in an all-or-nothing fashion.
 	 * All Items in a single `PutObjectRequest` must have distinct keys.
+	 *
 	 * Key-level versioning (Conditional Write):
 	 *   Clients are expected to store a `version` against every `key`.
 	 *   The write will succeed if the current DB version against the `key` is the same as in the request.
 	 *   When initiating a `PutObjectRequest`, the request should contain their client-side `version`
 	 *   for that key-value.
+	 *
 	 *   For the first write of any `key`, the `version` should be '0'. If the write succeeds, the client
 	 *   must increment their corresponding key versions (client-side) by 1.
 	 *   The server increments key versions (server-side) for every successful write, hence this
 	 *   client-side increment is required to ensure matching versions. These updated key versions should
 	 *   be used in subsequent `PutObjectRequest`s for the keys.
+	 *
 	 *   Requests with a conflicting/mismatched version will fail with `CONFLICT_EXCEPTION` as ErrorCode
 	 *   for conditional writes.
+	 *
 	 * Skipping key-level versioning (Non-conditional Write):
 	 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 	 *   This will perform a non-conditional write query, after which the `version` against the `key`
 	 *   is reset to '1'. Hence, the next `PutObjectRequest` for the `key` can be either
 	 *   a non-conditional write or a conditional write with `version` set to `1`.
+	 *
 	 * Considerations for transactions:
 	 * Transaction writes of multiple items have a performance overhead, hence it is recommended to use
 	 * them only if required by the client application to ensure logic/code correctness.
 	 * That is, `transaction_items` are not a substitute for batch-write of multiple unrelated items.
 	 * When a write of multiple unrelated items is desired, it is recommended to use separate
 	 * `PutObjectRequest`s.
+	 *
 	 * Consistency guarantee:
 	 * All `PutObjectRequest`s are strongly consistent i.e. they provide read-after-write and
 	 * read-after-update consistency guarantees.
@@ -133,35 +148,43 @@ public interface PutObjectRequestOrBuilder extends
 	/**
 	 * <pre>
 	 * Items to be written as a result of this `PutObjectRequest`.
+	 *
 	 * In an item, each `key` is supplied with its corresponding `value` and `version`.
 	 * Clients can choose to encrypt the keys client-side in order to obfuscate their usage patterns.
 	 * If the write is successful, the previous `value` corresponding to the `key` will be overwritten.
+	 *
 	 * Multiple items in `transaction_items` and `delete_items` of a single `PutObjectRequest` are written in
 	 * a database-transaction in an all-or-nothing fashion.
 	 * All Items in a single `PutObjectRequest` must have distinct keys.
+	 *
 	 * Key-level versioning (Conditional Write):
 	 *   Clients are expected to store a `version` against every `key`.
 	 *   The write will succeed if the current DB version against the `key` is the same as in the request.
 	 *   When initiating a `PutObjectRequest`, the request should contain their client-side `version`
 	 *   for that key-value.
+	 *
 	 *   For the first write of any `key`, the `version` should be '0'. If the write succeeds, the client
 	 *   must increment their corresponding key versions (client-side) by 1.
 	 *   The server increments key versions (server-side) for every successful write, hence this
 	 *   client-side increment is required to ensure matching versions. These updated key versions should
 	 *   be used in subsequent `PutObjectRequest`s for the keys.
+	 *
 	 *   Requests with a conflicting/mismatched version will fail with `CONFLICT_EXCEPTION` as ErrorCode
 	 *   for conditional writes.
+	 *
 	 * Skipping key-level versioning (Non-conditional Write):
 	 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 	 *   This will perform a non-conditional write query, after which the `version` against the `key`
 	 *   is reset to '1'. Hence, the next `PutObjectRequest` for the `key` can be either
 	 *   a non-conditional write or a conditional write with `version` set to `1`.
+	 *
 	 * Considerations for transactions:
 	 * Transaction writes of multiple items have a performance overhead, hence it is recommended to use
 	 * them only if required by the client application to ensure logic/code correctness.
 	 * That is, `transaction_items` are not a substitute for batch-write of multiple unrelated items.
 	 * When a write of multiple unrelated items is desired, it is recommended to use separate
 	 * `PutObjectRequest`s.
+	 *
 	 * Consistency guarantee:
 	 * All `PutObjectRequest`s are strongly consistent i.e. they provide read-after-write and
 	 * read-after-update consistency guarantees.
@@ -174,35 +197,43 @@ public interface PutObjectRequestOrBuilder extends
 	/**
 	 * <pre>
 	 * Items to be written as a result of this `PutObjectRequest`.
+	 *
 	 * In an item, each `key` is supplied with its corresponding `value` and `version`.
 	 * Clients can choose to encrypt the keys client-side in order to obfuscate their usage patterns.
 	 * If the write is successful, the previous `value` corresponding to the `key` will be overwritten.
+	 *
 	 * Multiple items in `transaction_items` and `delete_items` of a single `PutObjectRequest` are written in
 	 * a database-transaction in an all-or-nothing fashion.
 	 * All Items in a single `PutObjectRequest` must have distinct keys.
+	 *
 	 * Key-level versioning (Conditional Write):
 	 *   Clients are expected to store a `version` against every `key`.
 	 *   The write will succeed if the current DB version against the `key` is the same as in the request.
 	 *   When initiating a `PutObjectRequest`, the request should contain their client-side `version`
 	 *   for that key-value.
+	 *
 	 *   For the first write of any `key`, the `version` should be '0'. If the write succeeds, the client
 	 *   must increment their corresponding key versions (client-side) by 1.
 	 *   The server increments key versions (server-side) for every successful write, hence this
 	 *   client-side increment is required to ensure matching versions. These updated key versions should
 	 *   be used in subsequent `PutObjectRequest`s for the keys.
+	 *
 	 *   Requests with a conflicting/mismatched version will fail with `CONFLICT_EXCEPTION` as ErrorCode
 	 *   for conditional writes.
+	 *
 	 * Skipping key-level versioning (Non-conditional Write):
 	 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 	 *   This will perform a non-conditional write query, after which the `version` against the `key`
 	 *   is reset to '1'. Hence, the next `PutObjectRequest` for the `key` can be either
 	 *   a non-conditional write or a conditional write with `version` set to `1`.
+	 *
 	 * Considerations for transactions:
 	 * Transaction writes of multiple items have a performance overhead, hence it is recommended to use
 	 * them only if required by the client application to ensure logic/code correctness.
 	 * That is, `transaction_items` are not a substitute for batch-write of multiple unrelated items.
 	 * When a write of multiple unrelated items is desired, it is recommended to use separate
 	 * `PutObjectRequest`s.
+	 *
 	 * Consistency guarantee:
 	 * All `PutObjectRequest`s are strongly consistent i.e. they provide read-after-write and
 	 * read-after-update consistency guarantees.
@@ -215,35 +246,43 @@ public interface PutObjectRequestOrBuilder extends
 	/**
 	 * <pre>
 	 * Items to be written as a result of this `PutObjectRequest`.
+	 *
 	 * In an item, each `key` is supplied with its corresponding `value` and `version`.
 	 * Clients can choose to encrypt the keys client-side in order to obfuscate their usage patterns.
 	 * If the write is successful, the previous `value` corresponding to the `key` will be overwritten.
+	 *
 	 * Multiple items in `transaction_items` and `delete_items` of a single `PutObjectRequest` are written in
 	 * a database-transaction in an all-or-nothing fashion.
 	 * All Items in a single `PutObjectRequest` must have distinct keys.
+	 *
 	 * Key-level versioning (Conditional Write):
 	 *   Clients are expected to store a `version` against every `key`.
 	 *   The write will succeed if the current DB version against the `key` is the same as in the request.
 	 *   When initiating a `PutObjectRequest`, the request should contain their client-side `version`
 	 *   for that key-value.
+	 *
 	 *   For the first write of any `key`, the `version` should be '0'. If the write succeeds, the client
 	 *   must increment their corresponding key versions (client-side) by 1.
 	 *   The server increments key versions (server-side) for every successful write, hence this
 	 *   client-side increment is required to ensure matching versions. These updated key versions should
 	 *   be used in subsequent `PutObjectRequest`s for the keys.
+	 *
 	 *   Requests with a conflicting/mismatched version will fail with `CONFLICT_EXCEPTION` as ErrorCode
 	 *   for conditional writes.
+	 *
 	 * Skipping key-level versioning (Non-conditional Write):
 	 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 	 *   This will perform a non-conditional write query, after which the `version` against the `key`
 	 *   is reset to '1'. Hence, the next `PutObjectRequest` for the `key` can be either
 	 *   a non-conditional write or a conditional write with `version` set to `1`.
+	 *
 	 * Considerations for transactions:
 	 * Transaction writes of multiple items have a performance overhead, hence it is recommended to use
 	 * them only if required by the client application to ensure logic/code correctness.
 	 * That is, `transaction_items` are not a substitute for batch-write of multiple unrelated items.
 	 * When a write of multiple unrelated items is desired, it is recommended to use separate
 	 * `PutObjectRequest`s.
+	 *
 	 * Consistency guarantee:
 	 * All `PutObjectRequest`s are strongly consistent i.e. they provide read-after-write and
 	 * read-after-update consistency guarantees.
@@ -257,35 +296,43 @@ public interface PutObjectRequestOrBuilder extends
 	/**
 	 * <pre>
 	 * Items to be written as a result of this `PutObjectRequest`.
+	 *
 	 * In an item, each `key` is supplied with its corresponding `value` and `version`.
 	 * Clients can choose to encrypt the keys client-side in order to obfuscate their usage patterns.
 	 * If the write is successful, the previous `value` corresponding to the `key` will be overwritten.
+	 *
 	 * Multiple items in `transaction_items` and `delete_items` of a single `PutObjectRequest` are written in
 	 * a database-transaction in an all-or-nothing fashion.
 	 * All Items in a single `PutObjectRequest` must have distinct keys.
+	 *
 	 * Key-level versioning (Conditional Write):
 	 *   Clients are expected to store a `version` against every `key`.
 	 *   The write will succeed if the current DB version against the `key` is the same as in the request.
 	 *   When initiating a `PutObjectRequest`, the request should contain their client-side `version`
 	 *   for that key-value.
+	 *
 	 *   For the first write of any `key`, the `version` should be '0'. If the write succeeds, the client
 	 *   must increment their corresponding key versions (client-side) by 1.
 	 *   The server increments key versions (server-side) for every successful write, hence this
 	 *   client-side increment is required to ensure matching versions. These updated key versions should
 	 *   be used in subsequent `PutObjectRequest`s for the keys.
+	 *
 	 *   Requests with a conflicting/mismatched version will fail with `CONFLICT_EXCEPTION` as ErrorCode
 	 *   for conditional writes.
+	 *
 	 * Skipping key-level versioning (Non-conditional Write):
 	 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 	 *   This will perform a non-conditional write query, after which the `version` against the `key`
 	 *   is reset to '1'. Hence, the next `PutObjectRequest` for the `key` can be either
 	 *   a non-conditional write or a conditional write with `version` set to `1`.
+	 *
 	 * Considerations for transactions:
 	 * Transaction writes of multiple items have a performance overhead, hence it is recommended to use
 	 * them only if required by the client application to ensure logic/code correctness.
 	 * That is, `transaction_items` are not a substitute for batch-write of multiple unrelated items.
 	 * When a write of multiple unrelated items is desired, it is recommended to use separate
 	 * `PutObjectRequest`s.
+	 *
 	 * Consistency guarantee:
 	 * All `PutObjectRequest`s are strongly consistent i.e. they provide read-after-write and
 	 * read-after-update consistency guarantees.
@@ -299,20 +346,26 @@ org.vss.KeyValueOrBuilder getTransactionItemsOrBuilder(
 	/**
 	 * <pre>
 	 * Items to be deleted as a result of this `PutObjectRequest`.
+	 *
 	 * Each item in the `delete_items` field consists of a `key` and its corresponding `version`.
+	 *
 	 * Key-Level Versioning (Conditional Delete):
 	 *   The `version` is used to perform a version check before deleting the item.
 	 *   The delete will only succeed if the current database version against the `key` is the same as
 	 *   the `version` specified in the request.
+	 *
 	 * Skipping key-level versioning (Non-conditional Delete):
 	 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 	 *   This will perform a non-conditional delete query.
+	 *
 	 * Fails with `CONFLICT_EXCEPTION` as the ErrorCode if:
 	 *   * The requested item does not exist.
 	 *   * The requested item does exist but there is a version-number mismatch (in conditional delete)
 	 *     with the one in the database.
+	 *
 	 * Multiple items in the `delete_items` field, along with the `transaction_items`, are written in a
 	 * database transaction in an all-or-nothing fashion.
+	 *
 	 * All items within a single `PutObjectRequest` must have distinct keys.
 	 * </pre>
 	 *
@@ -324,20 +377,26 @@ org.vss.KeyValueOrBuilder getTransactionItemsOrBuilder(
 	/**
 	 * <pre>
 	 * Items to be deleted as a result of this `PutObjectRequest`.
+	 *
 	 * Each item in the `delete_items` field consists of a `key` and its corresponding `version`.
+	 *
 	 * Key-Level Versioning (Conditional Delete):
 	 *   The `version` is used to perform a version check before deleting the item.
 	 *   The delete will only succeed if the current database version against the `key` is the same as
 	 *   the `version` specified in the request.
+	 *
 	 * Skipping key-level versioning (Non-conditional Delete):
 	 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 	 *   This will perform a non-conditional delete query.
+	 *
 	 * Fails with `CONFLICT_EXCEPTION` as the ErrorCode if:
 	 *   * The requested item does not exist.
 	 *   * The requested item does exist but there is a version-number mismatch (in conditional delete)
 	 *     with the one in the database.
+	 *
 	 * Multiple items in the `delete_items` field, along with the `transaction_items`, are written in a
 	 * database transaction in an all-or-nothing fashion.
+	 *
 	 * All items within a single `PutObjectRequest` must have distinct keys.
 	 * </pre>
 	 *
@@ -348,20 +407,26 @@ org.vss.KeyValueOrBuilder getTransactionItemsOrBuilder(
 	/**
 	 * <pre>
 	 * Items to be deleted as a result of this `PutObjectRequest`.
+	 *
 	 * Each item in the `delete_items` field consists of a `key` and its corresponding `version`.
+	 *
 	 * Key-Level Versioning (Conditional Delete):
 	 *   The `version` is used to perform a version check before deleting the item.
 	 *   The delete will only succeed if the current database version against the `key` is the same as
 	 *   the `version` specified in the request.
+	 *
 	 * Skipping key-level versioning (Non-conditional Delete):
 	 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 	 *   This will perform a non-conditional delete query.
+	 *
 	 * Fails with `CONFLICT_EXCEPTION` as the ErrorCode if:
 	 *   * The requested item does not exist.
 	 *   * The requested item does exist but there is a version-number mismatch (in conditional delete)
 	 *     with the one in the database.
+	 *
 	 * Multiple items in the `delete_items` field, along with the `transaction_items`, are written in a
 	 * database transaction in an all-or-nothing fashion.
+	 *
 	 * All items within a single `PutObjectRequest` must have distinct keys.
 	 * </pre>
 	 *
@@ -372,20 +437,26 @@ org.vss.KeyValueOrBuilder getTransactionItemsOrBuilder(
 	/**
 	 * <pre>
 	 * Items to be deleted as a result of this `PutObjectRequest`.
+	 *
 	 * Each item in the `delete_items` field consists of a `key` and its corresponding `version`.
+	 *
 	 * Key-Level Versioning (Conditional Delete):
 	 *   The `version` is used to perform a version check before deleting the item.
 	 *   The delete will only succeed if the current database version against the `key` is the same as
 	 *   the `version` specified in the request.
+	 *
 	 * Skipping key-level versioning (Non-conditional Delete):
 	 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 	 *   This will perform a non-conditional delete query.
+	 *
 	 * Fails with `CONFLICT_EXCEPTION` as the ErrorCode if:
 	 *   * The requested item does not exist.
 	 *   * The requested item does exist but there is a version-number mismatch (in conditional delete)
 	 *     with the one in the database.
+	 *
 	 * Multiple items in the `delete_items` field, along with the `transaction_items`, are written in a
 	 * database transaction in an all-or-nothing fashion.
+	 *
 	 * All items within a single `PutObjectRequest` must have distinct keys.
 	 * </pre>
 	 *
@@ -397,20 +468,26 @@ org.vss.KeyValueOrBuilder getTransactionItemsOrBuilder(
 	/**
 	 * <pre>
 	 * Items to be deleted as a result of this `PutObjectRequest`.
+	 *
 	 * Each item in the `delete_items` field consists of a `key` and its corresponding `version`.
+	 *
 	 * Key-Level Versioning (Conditional Delete):
 	 *   The `version` is used to perform a version check before deleting the item.
 	 *   The delete will only succeed if the current database version against the `key` is the same as
 	 *   the `version` specified in the request.
+	 *
 	 * Skipping key-level versioning (Non-conditional Delete):
 	 *   If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
 	 *   This will perform a non-conditional delete query.
+	 *
 	 * Fails with `CONFLICT_EXCEPTION` as the ErrorCode if:
 	 *   * The requested item does not exist.
 	 *   * The requested item does exist but there is a version-number mismatch (in conditional delete)
 	 *     with the one in the database.
+	 *
 	 * Multiple items in the `delete_items` field, along with the `transaction_items`, are written in a
 	 * database transaction in an all-or-nothing fashion.
+	 *
 	 * All items within a single `PutObjectRequest` must have distinct keys.
 	 * </pre>
 	 *
diff --git a/java/app/src/main/generated/proto/org/vss/PutObjectResponse.java b/java/app/src/main/generated/proto/org/vss/PutObjectResponse.java
index 57c2b5f..7ab1b89 100644
--- a/java/app/src/main/generated/proto/org/vss/PutObjectResponse.java
+++ b/java/app/src/main/generated/proto/org/vss/PutObjectResponse.java
@@ -1,6 +1,7 @@
 // Generated by the protocol buffer compiler.  DO NOT EDIT!
 // source: vss.proto
 
+// Protobuf Java Version: 3.25.5
 package org.vss;
 
 /**
@@ -31,12 +32,6 @@ protected java.lang.Object newInstance(
 		return new PutObjectResponse();
 	}
 
-	@java.lang.Override
-	public final com.google.protobuf.UnknownFieldSet
-	getUnknownFields() {
-		return this.unknownFields;
-	}
-
 	public static final com.google.protobuf.Descriptors.Descriptor
 	getDescriptor() {
 		return org.vss.Vss.internal_static_vss_PutObjectResponse_descriptor;
diff --git a/java/app/src/main/generated/proto/org/vss/PutObjectResponseOrBuilder.java b/java/app/src/main/generated/proto/org/vss/PutObjectResponseOrBuilder.java
index 5e7ab21..e537e4e 100644
--- a/java/app/src/main/generated/proto/org/vss/PutObjectResponseOrBuilder.java
+++ b/java/app/src/main/generated/proto/org/vss/PutObjectResponseOrBuilder.java
@@ -1,6 +1,7 @@
 // Generated by the protocol buffer compiler.  DO NOT EDIT!
 // source: vss.proto
 
+// Protobuf Java Version: 3.25.5
 package org.vss;
 
 public interface PutObjectResponseOrBuilder extends
diff --git a/java/app/src/main/generated/proto/org/vss/Storable.java b/java/app/src/main/generated/proto/org/vss/Storable.java
index 70e35b6..304e185 100644
--- a/java/app/src/main/generated/proto/org/vss/Storable.java
+++ b/java/app/src/main/generated/proto/org/vss/Storable.java
@@ -1,6 +1,7 @@
 // Generated by the protocol buffer compiler.  DO NOT EDIT!
 // source: vss.proto
 
+// Protobuf Java Version: 3.25.5
 package org.vss;
 
 /**
@@ -36,12 +37,6 @@ protected java.lang.Object newInstance(
 		return new Storable();
 	}
 
-	@java.lang.Override
-	public final com.google.protobuf.UnknownFieldSet
-	getUnknownFields() {
-		return this.unknownFields;
-	}
-
 	public static final com.google.protobuf.Descriptors.Descriptor
 	getDescriptor() {
 		return org.vss.Vss.internal_static_vss_Storable_descriptor;
@@ -55,8 +50,9 @@ protected java.lang.Object newInstance(
 						org.vss.Storable.class, org.vss.Storable.Builder.class);
 	}
 
+	private int bitField0_;
 	public static final int DATA_FIELD_NUMBER = 1;
-	private com.google.protobuf.ByteString data_;
+	private com.google.protobuf.ByteString data_ = com.google.protobuf.ByteString.EMPTY;
 
 	/**
 	 * <pre>
@@ -87,7 +83,7 @@ public com.google.protobuf.ByteString getData() {
 	 */
 	@java.lang.Override
 	public boolean hasEncryptionMetadata() {
-		return encryptionMetadata_ != null;
+		return ((bitField0_ & 0x00000001) != 0);
 	}
 
 	/**
@@ -113,7 +109,7 @@ public org.vss.EncryptionMetadata getEncryptionMetadata() {
 	 */
 	@java.lang.Override
 	public org.vss.EncryptionMetadataOrBuilder getEncryptionMetadataOrBuilder() {
-		return getEncryptionMetadata();
+		return encryptionMetadata_ == null ? org.vss.EncryptionMetadata.getDefaultInstance() : encryptionMetadata_;
 	}
 
 	private byte memoizedIsInitialized = -1;
@@ -134,7 +130,7 @@ public void writeTo(com.google.protobuf.CodedOutputStream output)
 		if (!data_.isEmpty()) {
 			output.writeBytes(1, data_);
 		}
-		if (encryptionMetadata_ != null) {
+		if (((bitField0_ & 0x00000001) != 0)) {
 			output.writeMessage(2, getEncryptionMetadata());
 		}
 		getUnknownFields().writeTo(output);
@@ -150,7 +146,7 @@ public int getSerializedSize() {
 			size += com.google.protobuf.CodedOutputStream
 					.computeBytesSize(1, data_);
 		}
-		if (encryptionMetadata_ != null) {
+		if (((bitField0_ & 0x00000001) != 0)) {
 			size += com.google.protobuf.CodedOutputStream
 					.computeMessageSize(2, getEncryptionMetadata());
 		}
@@ -335,24 +331,30 @@ public static final class Builder extends
 
 		// Construct using org.vss.Storable.newBuilder()
 		private Builder() {
-
+			maybeForceBuilderInitialization();
 		}
 
 		private Builder(
 				com.google.protobuf.GeneratedMessageV3.BuilderParent parent) {
 			super(parent);
+			maybeForceBuilderInitialization();
+		}
 
+		private void maybeForceBuilderInitialization() {
+			if (com.google.protobuf.GeneratedMessageV3
+					.alwaysUseFieldBuilders) {
+				getEncryptionMetadataFieldBuilder();
+			}
 		}
 
 		@java.lang.Override
 		public Builder clear() {
 			super.clear();
+			bitField0_ = 0;
 			data_ = com.google.protobuf.ByteString.EMPTY;
-
-			if (encryptionMetadataBuilder_ == null) {
-				encryptionMetadata_ = null;
-			} else {
-				encryptionMetadata_ = null;
+			encryptionMetadata_ = null;
+			if (encryptionMetadataBuilder_ != null) {
+				encryptionMetadataBuilder_.dispose();
 				encryptionMetadataBuilder_ = null;
 			}
 			return this;
@@ -381,16 +383,28 @@ public org.vss.Storable build() {
 		@java.lang.Override
 		public org.vss.Storable buildPartial() {
 			org.vss.Storable result = new org.vss.Storable(this);
-			result.data_ = data_;
-			if (encryptionMetadataBuilder_ == null) {
-				result.encryptionMetadata_ = encryptionMetadata_;
-			} else {
-				result.encryptionMetadata_ = encryptionMetadataBuilder_.build();
+			if (bitField0_ != 0) {
+				buildPartial0(result);
 			}
 			onBuilt();
 			return result;
 		}
 
+		private void buildPartial0(org.vss.Storable result) {
+			int from_bitField0_ = bitField0_;
+			if (((from_bitField0_ & 0x00000001) != 0)) {
+				result.data_ = data_;
+			}
+			int to_bitField0_ = 0;
+			if (((from_bitField0_ & 0x00000002) != 0)) {
+				result.encryptionMetadata_ = encryptionMetadataBuilder_ == null
+						? encryptionMetadata_
+						: encryptionMetadataBuilder_.build();
+				to_bitField0_ |= 0x00000001;
+			}
+			result.bitField0_ |= to_bitField0_;
+		}
+
 		@java.lang.Override
 		public Builder clone() {
 			return super.clone();
@@ -475,14 +489,14 @@ public Builder mergeFrom(
 							break;
 						case 10: {
 							data_ = input.readBytes();
-
+							bitField0_ |= 0x00000001;
 							break;
 						} // case 10
 						case 18: {
 							input.readMessage(
 									getEncryptionMetadataFieldBuilder().getBuilder(),
 									extensionRegistry);
-
+							bitField0_ |= 0x00000002;
 							break;
 						} // case 18
 						default: {
@@ -501,6 +515,8 @@ public Builder mergeFrom(
 			return this;
 		}
 
+		private int bitField0_;
+
 		private com.google.protobuf.ByteString data_ = com.google.protobuf.ByteString.EMPTY;
 
 		/**
@@ -533,8 +549,8 @@ public Builder setData(com.google.protobuf.ByteString value) {
 			if (value == null) {
 				throw new NullPointerException();
 			}
-
 			data_ = value;
+			bitField0_ |= 0x00000001;
 			onChanged();
 			return this;
 		}
@@ -550,7 +566,7 @@ public Builder setData(com.google.protobuf.ByteString value) {
 		 * @return This builder for chaining.
 		 */
 		public Builder clearData() {
-
+			bitField0_ = (bitField0_ & ~0x00000001);
 			data_ = getDefaultInstance().getData();
 			onChanged();
 			return this;
@@ -570,7 +586,7 @@ public Builder clearData() {
 		 * @return Whether the encryptionMetadata field is set.
 		 */
 		public boolean hasEncryptionMetadata() {
-			return encryptionMetadataBuilder_ != null || encryptionMetadata_ != null;
+			return ((bitField0_ & 0x00000002) != 0);
 		}
 
 		/**
@@ -603,11 +619,11 @@ public Builder setEncryptionMetadata(org.vss.EncryptionMetadata value) {
 					throw new NullPointerException();
 				}
 				encryptionMetadata_ = value;
-				onChanged();
 			} else {
 				encryptionMetadataBuilder_.setMessage(value);
 			}
-
+			bitField0_ |= 0x00000002;
+			onChanged();
 			return this;
 		}
 
@@ -622,11 +638,11 @@ public Builder setEncryptionMetadata(
 				org.vss.EncryptionMetadata.Builder builderForValue) {
 			if (encryptionMetadataBuilder_ == null) {
 				encryptionMetadata_ = builderForValue.build();
-				onChanged();
 			} else {
 				encryptionMetadataBuilder_.setMessage(builderForValue.build());
 			}
-
+			bitField0_ |= 0x00000002;
+			onChanged();
 			return this;
 		}
 
@@ -639,17 +655,20 @@ public Builder setEncryptionMetadata(
 		 */
 		public Builder mergeEncryptionMetadata(org.vss.EncryptionMetadata value) {
 			if (encryptionMetadataBuilder_ == null) {
-				if (encryptionMetadata_ != null) {
-					encryptionMetadata_ =
-							org.vss.EncryptionMetadata.newBuilder(encryptionMetadata_).mergeFrom(value).buildPartial();
+				if (((bitField0_ & 0x00000002) != 0) &&
+						encryptionMetadata_ != null &&
+						encryptionMetadata_ != org.vss.EncryptionMetadata.getDefaultInstance()) {
+					getEncryptionMetadataBuilder().mergeFrom(value);
 				} else {
 					encryptionMetadata_ = value;
 				}
-				onChanged();
 			} else {
 				encryptionMetadataBuilder_.mergeFrom(value);
 			}
-
+			if (encryptionMetadata_ != null) {
+				bitField0_ |= 0x00000002;
+				onChanged();
+			}
 			return this;
 		}
 
@@ -661,14 +680,13 @@ public Builder mergeEncryptionMetadata(org.vss.EncryptionMetadata value) {
 		 * <code>.vss.EncryptionMetadata encryption_metadata = 2;</code>
 		 */
 		public Builder clearEncryptionMetadata() {
-			if (encryptionMetadataBuilder_ == null) {
-				encryptionMetadata_ = null;
-				onChanged();
-			} else {
-				encryptionMetadata_ = null;
+			bitField0_ = (bitField0_ & ~0x00000002);
+			encryptionMetadata_ = null;
+			if (encryptionMetadataBuilder_ != null) {
+				encryptionMetadataBuilder_.dispose();
 				encryptionMetadataBuilder_ = null;
 			}
-
+			onChanged();
 			return this;
 		}
 
@@ -680,7 +698,7 @@ public Builder clearEncryptionMetadata() {
 		 * <code>.vss.EncryptionMetadata encryption_metadata = 2;</code>
 		 */
 		public org.vss.EncryptionMetadata.Builder getEncryptionMetadataBuilder() {
-
+			bitField0_ |= 0x00000002;
 			onChanged();
 			return getEncryptionMetadataFieldBuilder().getBuilder();
 		}
diff --git a/java/app/src/main/generated/proto/org/vss/StorableOrBuilder.java b/java/app/src/main/generated/proto/org/vss/StorableOrBuilder.java
index ba05db9..8d7b972 100644
--- a/java/app/src/main/generated/proto/org/vss/StorableOrBuilder.java
+++ b/java/app/src/main/generated/proto/org/vss/StorableOrBuilder.java
@@ -1,6 +1,7 @@
 // Generated by the protocol buffer compiler.  DO NOT EDIT!
 // source: vss.proto
 
+// Protobuf Java Version: 3.25.5
 package org.vss;
 
 public interface StorableOrBuilder extends
diff --git a/java/app/src/main/generated/proto/org/vss/Vss.java b/java/app/src/main/generated/proto/org/vss/Vss.java
index a768d82..f61117e 100644
--- a/java/app/src/main/generated/proto/org/vss/Vss.java
+++ b/java/app/src/main/generated/proto/org/vss/Vss.java
@@ -1,6 +1,7 @@
 // Generated by the protocol buffer compiler.  DO NOT EDIT!
 // source: vss.proto
 
+// Protobuf Java Version: 3.25.5
 package org.vss;
 
 public final class Vss {
@@ -146,7 +147,7 @@ public static void registerAllExtensions(
 		internal_static_vss_PutObjectRequest_fieldAccessorTable = new
 				com.google.protobuf.GeneratedMessageV3.FieldAccessorTable(
 				internal_static_vss_PutObjectRequest_descriptor,
-				new java.lang.String[]{"StoreId", "GlobalVersion", "TransactionItems", "DeleteItems", "GlobalVersion",});
+				new java.lang.String[]{"StoreId", "GlobalVersion", "TransactionItems", "DeleteItems",});
 		internal_static_vss_PutObjectResponse_descriptor =
 				getDescriptor().getMessageTypes().get(3);
 		internal_static_vss_PutObjectResponse_fieldAccessorTable = new
@@ -170,13 +171,13 @@ public static void registerAllExtensions(
 		internal_static_vss_ListKeyVersionsRequest_fieldAccessorTable = new
 				com.google.protobuf.GeneratedMessageV3.FieldAccessorTable(
 				internal_static_vss_ListKeyVersionsRequest_descriptor,
-				new java.lang.String[]{"StoreId", "KeyPrefix", "PageSize", "PageToken", "KeyPrefix", "PageSize", "PageToken",});
+				new java.lang.String[]{"StoreId", "KeyPrefix", "PageSize", "PageToken",});
 		internal_static_vss_ListKeyVersionsResponse_descriptor =
 				getDescriptor().getMessageTypes().get(7);
 		internal_static_vss_ListKeyVersionsResponse_fieldAccessorTable = new
 				com.google.protobuf.GeneratedMessageV3.FieldAccessorTable(
 				internal_static_vss_ListKeyVersionsResponse_descriptor,
-				new java.lang.String[]{"KeyVersions", "NextPageToken", "GlobalVersion", "NextPageToken", "GlobalVersion",});
+				new java.lang.String[]{"KeyVersions", "NextPageToken", "GlobalVersion",});
 		internal_static_vss_ErrorResponse_descriptor =
 				getDescriptor().getMessageTypes().get(8);
 		internal_static_vss_ErrorResponse_fieldAccessorTable = new