Add Delete functionality by G8XSU · Pull Request #15 · lightningdevkit/vss-server

G8XSU · 2023-07-25T20:15:24Z

We add delete functionality as both:

Transaction support in PutObject Api, which allows simultaneous delete of keys while writing other keys. This is necessary in order to support CRUD transactions.
An idempotent api to allow for applications which can safely merge deletes and don't require transactions with put&delete.

This follows similar pattern followed in popular KVStore Databases, such as aws-dynamodb which allows for both delete api and transaction write api.

For now, ignore the naming for "PutObject" API, will rename it to WriteObject in separate rename-commit.

jkczyz

Concept ACK.

jkczyz · 2023-07-27T02:44:30Z

+ batchQueries.addAll(vssPutRecords.stream()
+ .map(vssRecord -> buildPutObjectQuery(dsl, vssRecord)).toList());
+ batchQueries.addAll(vssDeleteRecords.stream()
+ .map(vssRecord -> buildDeleteObjectQuery(dsl, vssRecord)).toList());


Does there need to be a check for distinct keys across both lists?

We will implement request validation as part of api class and not db-implementation.
Currently we assume all requests are valid and there are couple of pending request validations to be added.
For example, we are also not checking if keys in put_items are unique currently or size or number of keys. (will work on this separately)

G8XSU · 2023-08-02T00:51:58Z

Ready for review ! :D

jkczyz · 2023-08-02T19:47:05Z

+ // 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.


No need to do so in this PR, but we should be consistent with using ticks for identifiers. Or possibly not use them at all, for that matter. In Rust, they are used to format the markdown. But that's not the case for proto docs, presumably.

Opening another PR to consistently add ticks around all identifiers.

Part of #16

jkczyz · 2023-08-02T19:50:36Z

 KeyValue.newBuilder()
 .setKey(GLOBAL_VERSION_KEY)
 .setVersion(request.getGlobalVersion())
+ .setValue(ByteString.EMPTY)


Is there different behavior if this is omitted?

Not really,
it was just some inconcstency that i noticed and just to make it more explicit.

G8XSU · 2023-07-25T20:15:24Z

We add delete functionality as both:

Transaction support in PutObject Api, which allows simultaneous delete of keys while writing other keys. This is necessary in order to support CRUD transactions.
An idempotent api to allow for applications which can safely merge deletes and don't require transactions with put&delete.

This follows similar pattern followed in popular KVStore Databases, such as aws-dynamodb which allows for both delete api and transaction write api.

For now, ignore the naming for "PutObject" API, will rename it to WriteObject in separate rename-commit.

jkczyz

Concept ACK.

jkczyz · 2023-07-27T02:44:30Z

+ batchQueries.addAll(vssPutRecords.stream()
+ .map(vssRecord -> buildPutObjectQuery(dsl, vssRecord)).toList());
+ batchQueries.addAll(vssDeleteRecords.stream()
+ .map(vssRecord -> buildDeleteObjectQuery(dsl, vssRecord)).toList());


Does there need to be a check for distinct keys across both lists?

We will implement request validation as part of api class and not db-implementation.
Currently we assume all requests are valid and there are couple of pending request validations to be added.
For example, we are also not checking if keys in put_items are unique currently or size or number of keys. (will work on this separately)

G8XSU · 2023-08-02T00:51:58Z

Ready for review ! :D

jkczyz · 2023-08-02T19:47:05Z

+ // 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.


No need to do so in this PR, but we should be consistent with using ticks for identifiers. Or possibly not use them at all, for that matter. In Rust, they are used to format the markdown. But that's not the case for proto docs, presumably.

Opening another PR to consistently add ticks around all identifiers.

Part of #16

jkczyz · 2023-08-02T19:50:36Z

 KeyValue.newBuilder()
 .setKey(GLOBAL_VERSION_KEY)
 .setVersion(request.getGlobalVersion())
+ .setValue(ByteString.EMPTY)


Is there different behavior if this is omitted?

Not really,
it was just some inconcstency that i noticed and just to make it more explicit.

G8XSU · 2023-07-25T20:15:24Z

We add delete functionality as both:

Transaction support in PutObject Api, which allows simultaneous delete of keys while writing other keys. This is necessary in order to support CRUD transactions.
An idempotent api to allow for applications which can safely merge deletes and don't require transactions with put&delete.

This follows similar pattern followed in popular KVStore Databases, such as aws-dynamodb which allows for both delete api and transaction write api.

For now, ignore the naming for "PutObject" API, will rename it to WriteObject in separate rename-commit.

jkczyz

Concept ACK.

jkczyz · 2023-07-27T02:44:30Z

+ batchQueries.addAll(vssPutRecords.stream()
+ .map(vssRecord -> buildPutObjectQuery(dsl, vssRecord)).toList());
+ batchQueries.addAll(vssDeleteRecords.stream()
+ .map(vssRecord -> buildDeleteObjectQuery(dsl, vssRecord)).toList());


Does there need to be a check for distinct keys across both lists?

We will implement request validation as part of api class and not db-implementation.
Currently we assume all requests are valid and there are couple of pending request validations to be added.
For example, we are also not checking if keys in put_items are unique currently or size or number of keys. (will work on this separately)

G8XSU · 2023-08-02T00:51:58Z

Ready for review ! :D

jkczyz · 2023-08-02T19:47:05Z

+ // 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.


No need to do so in this PR, but we should be consistent with using ticks for identifiers. Or possibly not use them at all, for that matter. In Rust, they are used to format the markdown. But that's not the case for proto docs, presumably.

Opening another PR to consistently add ticks around all identifiers.

Part of #16

jkczyz · 2023-08-02T19:50:36Z

 KeyValue.newBuilder()
 .setKey(GLOBAL_VERSION_KEY)
 .setVersion(request.getGlobalVersion())
+ .setValue(ByteString.EMPTY)


Is there different behavior if this is omitted?

Not really,
it was just some inconcstency that i noticed and just to make it more explicit.

G8XSU · 2023-07-25T20:15:24Z

We add delete functionality as both:

Transaction support in PutObject Api, which allows simultaneous delete of keys while writing other keys. This is necessary in order to support CRUD transactions.
An idempotent api to allow for applications which can safely merge deletes and don't require transactions with put&delete.

This follows similar pattern followed in popular KVStore Databases, such as aws-dynamodb which allows for both delete api and transaction write api.

For now, ignore the naming for "PutObject" API, will rename it to WriteObject in separate rename-commit.

jkczyz

Concept ACK.

jkczyz · 2023-07-27T02:44:30Z

+ batchQueries.addAll(vssPutRecords.stream()
+ .map(vssRecord -> buildPutObjectQuery(dsl, vssRecord)).toList());
+ batchQueries.addAll(vssDeleteRecords.stream()
+ .map(vssRecord -> buildDeleteObjectQuery(dsl, vssRecord)).toList());


Does there need to be a check for distinct keys across both lists?

We will implement request validation as part of api class and not db-implementation.
Currently we assume all requests are valid and there are couple of pending request validations to be added.
For example, we are also not checking if keys in put_items are unique currently or size or number of keys. (will work on this separately)

G8XSU · 2023-08-02T00:51:58Z

Ready for review ! :D

jkczyz · 2023-08-02T19:47:05Z

+ // 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.


No need to do so in this PR, but we should be consistent with using ticks for identifiers. Or possibly not use them at all, for that matter. In Rust, they are used to format the markdown. But that's not the case for proto docs, presumably.

Opening another PR to consistently add ticks around all identifiers.

Part of #16

jkczyz · 2023-08-02T19:50:36Z

 KeyValue.newBuilder()
 .setKey(GLOBAL_VERSION_KEY)
 .setVersion(request.getGlobalVersion())
+ .setValue(ByteString.EMPTY)


Is there different behavior if this is omitted?

Not really,
it was just some inconcstency that i noticed and just to make it more explicit.

G8XSU · 2023-07-25T20:15:24Z

We add delete functionality as both:

Transaction support in PutObject Api, which allows simultaneous delete of keys while writing other keys. This is necessary in order to support CRUD transactions.
An idempotent api to allow for applications which can safely merge deletes and don't require transactions with put&delete.

This follows similar pattern followed in popular KVStore Databases, such as aws-dynamodb which allows for both delete api and transaction write api.

For now, ignore the naming for "PutObject" API, will rename it to WriteObject in separate rename-commit.

jkczyz

Concept ACK.

jkczyz · 2023-07-27T02:44:30Z

+ batchQueries.addAll(vssPutRecords.stream()
+ .map(vssRecord -> buildPutObjectQuery(dsl, vssRecord)).toList());
+ batchQueries.addAll(vssDeleteRecords.stream()
+ .map(vssRecord -> buildDeleteObjectQuery(dsl, vssRecord)).toList());


Does there need to be a check for distinct keys across both lists?

We will implement request validation as part of api class and not db-implementation.
Currently we assume all requests are valid and there are couple of pending request validations to be added.
For example, we are also not checking if keys in put_items are unique currently or size or number of keys. (will work on this separately)

G8XSU · 2023-08-02T00:51:58Z

Ready for review ! :D

jkczyz · 2023-08-02T19:47:05Z

+ // 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.


No need to do so in this PR, but we should be consistent with using ticks for identifiers. Or possibly not use them at all, for that matter. In Rust, they are used to format the markdown. But that's not the case for proto docs, presumably.

Opening another PR to consistently add ticks around all identifiers.

Part of #16

jkczyz · 2023-08-02T19:50:36Z

 KeyValue.newBuilder()
 .setKey(GLOBAL_VERSION_KEY)
 .setVersion(request.getGlobalVersion())
+ .setValue(ByteString.EMPTY)


Is there different behavior if this is omitted?

Not really,
it was just some inconcstency that i noticed and just to make it more explicit.

G8XSU · 2023-07-25T20:15:24Z

We add delete functionality as both:

Transaction support in PutObject Api, which allows simultaneous delete of keys while writing other keys. This is necessary in order to support CRUD transactions.
An idempotent api to allow for applications which can safely merge deletes and don't require transactions with put&delete.

This follows similar pattern followed in popular KVStore Databases, such as aws-dynamodb which allows for both delete api and transaction write api.

For now, ignore the naming for "PutObject" API, will rename it to WriteObject in separate rename-commit.

jkczyz

Concept ACK.

jkczyz · 2023-07-27T02:44:30Z

+ batchQueries.addAll(vssPutRecords.stream()
+ .map(vssRecord -> buildPutObjectQuery(dsl, vssRecord)).toList());
+ batchQueries.addAll(vssDeleteRecords.stream()
+ .map(vssRecord -> buildDeleteObjectQuery(dsl, vssRecord)).toList());


Does there need to be a check for distinct keys across both lists?

We will implement request validation as part of api class and not db-implementation.
Currently we assume all requests are valid and there are couple of pending request validations to be added.
For example, we are also not checking if keys in put_items are unique currently or size or number of keys. (will work on this separately)

G8XSU · 2023-08-02T00:51:58Z

Ready for review ! :D

jkczyz · 2023-08-02T19:47:05Z

+ // 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.


No need to do so in this PR, but we should be consistent with using ticks for identifiers. Or possibly not use them at all, for that matter. In Rust, they are used to format the markdown. But that's not the case for proto docs, presumably.

Opening another PR to consistently add ticks around all identifiers.

Part of #16

jkczyz · 2023-08-02T19:50:36Z

 KeyValue.newBuilder()
 .setKey(GLOBAL_VERSION_KEY)
 .setVersion(request.getGlobalVersion())
+ .setValue(ByteString.EMPTY)


Is there different behavior if this is omitted?

Not really,
it was just some inconcstency that i noticed and just to make it more explicit.

G8XSU · 2023-07-25T20:15:24Z

We add delete functionality as both:

Transaction support in PutObject Api, which allows simultaneous delete of keys while writing other keys. This is necessary in order to support CRUD transactions.
An idempotent api to allow for applications which can safely merge deletes and don't require transactions with put&delete.

This follows similar pattern followed in popular KVStore Databases, such as aws-dynamodb which allows for both delete api and transaction write api.

For now, ignore the naming for "PutObject" API, will rename it to WriteObject in separate rename-commit.

jkczyz

Concept ACK.

jkczyz · 2023-07-27T02:44:30Z

+ batchQueries.addAll(vssPutRecords.stream()
+ .map(vssRecord -> buildPutObjectQuery(dsl, vssRecord)).toList());
+ batchQueries.addAll(vssDeleteRecords.stream()
+ .map(vssRecord -> buildDeleteObjectQuery(dsl, vssRecord)).toList());


Does there need to be a check for distinct keys across both lists?

We will implement request validation as part of api class and not db-implementation.
Currently we assume all requests are valid and there are couple of pending request validations to be added.
For example, we are also not checking if keys in put_items are unique currently or size or number of keys. (will work on this separately)

G8XSU · 2023-08-02T00:51:58Z

Ready for review ! :D

jkczyz · 2023-08-02T19:47:05Z

+ // 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.


No need to do so in this PR, but we should be consistent with using ticks for identifiers. Or possibly not use them at all, for that matter. In Rust, they are used to format the markdown. But that's not the case for proto docs, presumably.

Opening another PR to consistently add ticks around all identifiers.

Part of #16

jkczyz · 2023-08-02T19:50:36Z

 KeyValue.newBuilder()
 .setKey(GLOBAL_VERSION_KEY)
 .setVersion(request.getGlobalVersion())
+ .setValue(ByteString.EMPTY)


Is there different behavior if this is omitted?

Not really,
it was just some inconcstency that i noticed and just to make it more explicit.

G8XSU · 2023-07-25T20:15:24Z

We add delete functionality as both:

Transaction support in PutObject Api, which allows simultaneous delete of keys while writing other keys. This is necessary in order to support CRUD transactions.
An idempotent api to allow for applications which can safely merge deletes and don't require transactions with put&delete.

This follows similar pattern followed in popular KVStore Databases, such as aws-dynamodb which allows for both delete api and transaction write api.

For now, ignore the naming for "PutObject" API, will rename it to WriteObject in separate rename-commit.

jkczyz

Concept ACK.

jkczyz · 2023-07-27T02:44:30Z

+ batchQueries.addAll(vssPutRecords.stream()
+ .map(vssRecord -> buildPutObjectQuery(dsl, vssRecord)).toList());
+ batchQueries.addAll(vssDeleteRecords.stream()
+ .map(vssRecord -> buildDeleteObjectQuery(dsl, vssRecord)).toList());


Does there need to be a check for distinct keys across both lists?

We will implement request validation as part of api class and not db-implementation.
Currently we assume all requests are valid and there are couple of pending request validations to be added.
For example, we are also not checking if keys in put_items are unique currently or size or number of keys. (will work on this separately)

G8XSU · 2023-08-02T00:51:58Z

Ready for review ! :D

jkczyz · 2023-08-02T19:47:05Z

+ // 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.


No need to do so in this PR, but we should be consistent with using ticks for identifiers. Or possibly not use them at all, for that matter. In Rust, they are used to format the markdown. But that's not the case for proto docs, presumably.

Opening another PR to consistently add ticks around all identifiers.

Part of #16

jkczyz · 2023-08-02T19:50:36Z

 KeyValue.newBuilder()
 .setKey(GLOBAL_VERSION_KEY)
 .setVersion(request.getGlobalVersion())
+ .setValue(ByteString.EMPTY)


Is there different behavior if this is omitted?

Not really,
it was just some inconcstency that i noticed and just to make it more explicit.

G8XSU requested a review from jkczyz July 25, 2023 20:15

G8XSU force-pushed the delete-api branch from e15db9b to bb28d87Compare July 25, 2023 22:45

G8XSU mentioned this pull request Jul 20, 2023
VSS Tracking Issue #9
Closed
31 tasks

G8XSU force-pushed the delete-api branch from bb28d87 to d3052a5Compare July 25, 2023 22:58

jkczyz reviewed Jul 27, 2023
View reviewed changes

G8XSU force-pushed the delete-api branch from d3052a5 to 1b66590Compare August 2, 2023 00:51

G8XSU requested a review from jkczyz August 2, 2023 00:52

jkczyz reviewed Aug 2, 2023
View reviewed changes

G8XSU requested a review from jkczyz August 2, 2023 22:56

G8XSU added 3 commits August 3, 2023 10:39

Add delete functionality proto changes
064f3db

Modify PutObject API to add delete functionality
6cec109

Add DeleteObject API Implementation
899347c

G8XSU force-pushed the delete-api branch from 1b66590 to 899347cCompare August 7, 2023 02:23

jkczyz approved these changes Aug 7, 2023
View reviewed changes

G8XSU merged commit 9c94974 into lightningdevkit:mainAug 8, 2023

G8XSU requested a review from jkczyz July 25, 2023 20:15

G8XSU force-pushed the delete-api branch from e15db9b to bb28d87Compare July 25, 2023 22:45

G8XSU mentioned this pull request Jul 20, 2023
VSS Tracking Issue #9
Closed
31 tasks

G8XSU force-pushed the delete-api branch from bb28d87 to d3052a5Compare July 25, 2023 22:58

jkczyz reviewed Jul 27, 2023
View reviewed changes

G8XSU force-pushed the delete-api branch from d3052a5 to 1b66590Compare August 2, 2023 00:51

G8XSU requested a review from jkczyz August 2, 2023 00:52

jkczyz reviewed Aug 2, 2023
View reviewed changes

G8XSU requested a review from jkczyz August 2, 2023 22:56

G8XSU added 3 commits August 3, 2023 10:39

Add delete functionality proto changes
064f3db

Modify PutObject API to add delete functionality
6cec109

Add DeleteObject API Implementation
899347c

G8XSU force-pushed the delete-api branch from 1b66590 to 899347cCompare August 7, 2023 02:23

jkczyz approved these changes Aug 7, 2023
View reviewed changes

G8XSU merged commit 9c94974 into lightningdevkit:mainAug 8, 2023

G8XSU requested a review from jkczyz July 25, 2023 20:15

G8XSU force-pushed the delete-api branch from e15db9b to bb28d87Compare July 25, 2023 22:45

G8XSU mentioned this pull request Jul 20, 2023
VSS Tracking Issue #9
Closed
31 tasks

G8XSU force-pushed the delete-api branch from bb28d87 to d3052a5Compare July 25, 2023 22:58

jkczyz reviewed Jul 27, 2023
View reviewed changes

G8XSU force-pushed the delete-api branch from d3052a5 to 1b66590Compare August 2, 2023 00:51

G8XSU requested a review from jkczyz August 2, 2023 00:52

jkczyz reviewed Aug 2, 2023
View reviewed changes

G8XSU requested a review from jkczyz August 2, 2023 22:56

G8XSU added 3 commits August 3, 2023 10:39

Add delete functionality proto changes
064f3db

Modify PutObject API to add delete functionality
6cec109

Add DeleteObject API Implementation
899347c

G8XSU force-pushed the delete-api branch from 1b66590 to 899347cCompare August 7, 2023 02:23

jkczyz approved these changes Aug 7, 2023
View reviewed changes

G8XSU merged commit 9c94974 into lightningdevkit:mainAug 8, 2023

G8XSU requested a review from jkczyz July 25, 2023 20:15

G8XSU force-pushed the delete-api branch from e15db9b to bb28d87Compare July 25, 2023 22:45

G8XSU mentioned this pull request Jul 20, 2023
VSS Tracking Issue #9
Closed
31 tasks

G8XSU force-pushed the delete-api branch from bb28d87 to d3052a5Compare July 25, 2023 22:58

jkczyz reviewed Jul 27, 2023
View reviewed changes

G8XSU force-pushed the delete-api branch from d3052a5 to 1b66590Compare August 2, 2023 00:51

G8XSU requested a review from jkczyz August 2, 2023 00:52

jkczyz reviewed Aug 2, 2023
View reviewed changes

G8XSU requested a review from jkczyz August 2, 2023 22:56

G8XSU added 3 commits August 3, 2023 10:39

Add delete functionality proto changes
064f3db

Modify PutObject API to add delete functionality
6cec109

Add DeleteObject API Implementation
899347c

G8XSU force-pushed the delete-api branch from 1b66590 to 899347cCompare August 7, 2023 02:23

jkczyz approved these changes Aug 7, 2023
View reviewed changes

G8XSU merged commit 9c94974 into lightningdevkit:mainAug 8, 2023

G8XSU requested a review from jkczyz July 25, 2023 20:15

G8XSU force-pushed the delete-api branch from e15db9b to bb28d87Compare July 25, 2023 22:45

G8XSU mentioned this pull request Jul 20, 2023
VSS Tracking Issue #9
Closed
31 tasks

G8XSU force-pushed the delete-api branch from bb28d87 to d3052a5Compare July 25, 2023 22:58

jkczyz reviewed Jul 27, 2023
View reviewed changes

G8XSU force-pushed the delete-api branch from d3052a5 to 1b66590Compare August 2, 2023 00:51

G8XSU requested a review from jkczyz August 2, 2023 00:52

jkczyz reviewed Aug 2, 2023
View reviewed changes

G8XSU requested a review from jkczyz August 2, 2023 22:56

G8XSU added 3 commits August 3, 2023 10:39

Add delete functionality proto changes
064f3db

Modify PutObject API to add delete functionality
6cec109

Add DeleteObject API Implementation
899347c

G8XSU force-pushed the delete-api branch from 1b66590 to 899347cCompare August 7, 2023 02:23

jkczyz approved these changes Aug 7, 2023
View reviewed changes

G8XSU merged commit 9c94974 into lightningdevkit:mainAug 8, 2023

G8XSU requested a review from jkczyz July 25, 2023 20:15

G8XSU force-pushed the delete-api branch from e15db9b to bb28d87Compare July 25, 2023 22:45

G8XSU mentioned this pull request Jul 20, 2023
VSS Tracking Issue #9
Closed
31 tasks

G8XSU force-pushed the delete-api branch from bb28d87 to d3052a5Compare July 25, 2023 22:58

jkczyz reviewed Jul 27, 2023
View reviewed changes

G8XSU force-pushed the delete-api branch from d3052a5 to 1b66590Compare August 2, 2023 00:51

G8XSU requested a review from jkczyz August 2, 2023 00:52

jkczyz reviewed Aug 2, 2023
View reviewed changes

G8XSU requested a review from jkczyz August 2, 2023 22:56

G8XSU added 3 commits August 3, 2023 10:39

Add delete functionality proto changes
064f3db

Modify PutObject API to add delete functionality
6cec109

Add DeleteObject API Implementation
899347c

G8XSU force-pushed the delete-api branch from 1b66590 to 899347cCompare August 7, 2023 02:23

jkczyz approved these changes Aug 7, 2023
View reviewed changes

G8XSU merged commit 9c94974 into lightningdevkit:mainAug 8, 2023

G8XSU requested a review from jkczyz July 25, 2023 20:15

G8XSU force-pushed the delete-api branch from e15db9b to bb28d87Compare July 25, 2023 22:45

G8XSU mentioned this pull request Jul 20, 2023
VSS Tracking Issue #9
Closed
31 tasks

G8XSU force-pushed the delete-api branch from bb28d87 to d3052a5Compare July 25, 2023 22:58

jkczyz reviewed Jul 27, 2023
View reviewed changes

G8XSU force-pushed the delete-api branch from d3052a5 to 1b66590Compare August 2, 2023 00:51

G8XSU requested a review from jkczyz August 2, 2023 00:52

jkczyz reviewed Aug 2, 2023
View reviewed changes

G8XSU requested a review from jkczyz August 2, 2023 22:56

G8XSU added 3 commits August 3, 2023 10:39

Add delete functionality proto changes
064f3db

Modify PutObject API to add delete functionality
6cec109

Add DeleteObject API Implementation
899347c

G8XSU force-pushed the delete-api branch from 1b66590 to 899347cCompare August 7, 2023 02:23

jkczyz approved these changes Aug 7, 2023
View reviewed changes

G8XSU merged commit 9c94974 into lightningdevkit:mainAug 8, 2023

G8XSU requested a review from jkczyz July 25, 2023 20:15

G8XSU force-pushed the delete-api branch from e15db9b to bb28d87Compare July 25, 2023 22:45

G8XSU mentioned this pull request Jul 20, 2023
VSS Tracking Issue #9
Closed
31 tasks

G8XSU force-pushed the delete-api branch from bb28d87 to d3052a5Compare July 25, 2023 22:58

jkczyz reviewed Jul 27, 2023
View reviewed changes

G8XSU force-pushed the delete-api branch from d3052a5 to 1b66590Compare August 2, 2023 00:51

G8XSU requested a review from jkczyz August 2, 2023 00:52

jkczyz reviewed Aug 2, 2023
View reviewed changes

G8XSU requested a review from jkczyz August 2, 2023 22:56

G8XSU added 3 commits August 3, 2023 10:39

Add delete functionality proto changes
064f3db

Modify PutObject API to add delete functionality
6cec109

Add DeleteObject API Implementation
899347c

G8XSU force-pushed the delete-api branch from 1b66590 to 899347cCompare August 7, 2023 02:23

jkczyz approved these changes Aug 7, 2023
View reviewed changes

G8XSU merged commit 9c94974 into lightningdevkit:mainAug 8, 2023

Uh oh!

Conversation

G8XSU commented Jul 25, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jkczyz left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

G8XSU commented Aug 2, 2023

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

G8XSU commented Jul 25, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jkczyz left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

G8XSU commented Aug 2, 2023

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

G8XSU commented Jul 25, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jkczyz left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

G8XSU commented Jul 25, 2023•
edited
Loading

G8XSU commented Jul 25, 2023•
edited
Loading

G8XSU commented Jul 25, 2023•
edited
Loading

G8XSU commented Jul 25, 2023•
edited
Loading