Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce operation attributes #2333

Merged
merged 4 commits into from
Nov 14, 2024
Merged

Conversation

brfrn169
Copy link
Collaborator

@brfrn169 brfrn169 commented Nov 13, 2024

Description

This PR introduces operation attributes, providing the capability to include additional key-value information in operations.

Related issues and/or PRs

N/A

Changes made

  • Added operation attributes to Operation.
  • Updated operation builders to support operation attributes.

Checklist

  • I have commented my code, particularly in hard-to-understand areas.
  • I have updated the documentation to reflect the changes.
  • Any remaining open issues linked to this PR are documented and up-to-date (Jira, GitHub, etc.).
  • Tests (unit, integration, etc.) have been added for the changes.
  • My changes generate no new warnings.
  • Any dependent changes in other PRs have been merged and published.

Additional notes (optional)

N/A

Release notes

Introduced operation attributes, providing the capability to include additional key-value information in operations.

@brfrn169 brfrn169 added the enhancement New feature or request label Nov 13, 2024
@brfrn169 brfrn169 self-assigned this Nov 13, 2024
@@ -25,18 +25,21 @@ public abstract class Operation {
@Nullable private String namespace;
private String tableName;
private Consistency consistency;
private final ImmutableMap<String, String> attributes;
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added operation attributes to Operation.

@Nullable Key clusteringKey;
@Nullable com.scalar.db.api.Consistency consistency;
@Nullable MutationCondition condition;
Map<String, String> attributes = new HashMap<>();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can be final?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in 241b26e. Thanks.

*
* @return the attributes
*/
public Map<String, String> getAttributes() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[minor] I think this can return ImmutableMap<> to make it easy to construct Immutable objects without copying on the caller side.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since getAttributes() is a user-facing API, I didn’t expose the implementation of the Map interface here. I usually use immutable collections like ImmutableMap for internal APIs, but I avoid using them in exposed APIs. What do you think?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since getAttributes() is a user-facing API

Oh, I see. Agreed. Let's go with returning Map as is.

final Map<String, Column<?>> columns = new LinkedHashMap<>();
@Nullable Key clusteringKey;
@Nullable MutationCondition condition;
Map<String, String> attributes = new HashMap<>();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above.

Copy link
Collaborator Author

@brfrn169 brfrn169 Nov 14, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in 241b26e. Thanks.

Copy link
Contributor

@feeblefakie feeblefakie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left several very minor comments on the definition order consistency.
But, it's my preference, so it's up to you.
LGTM! Thank you!

@Nullable MutationCondition condition) {
super(namespace, tableName, partitionKey, clusteringKey, consistency, condition);
super(namespace, tableName, partitionKey, clusteringKey, consistency, attributes, condition);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just wondering if there is any reason for putting it in the middle of existing arguments?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason is that the first six arguments are for Operation. I arranged the arguments in hierarchical order: Operation, Mutation, and Delete.

.add("condition", getCondition())
.add("consistency", getConsistency())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is a super minor thing, but I think it's slightly better that the order is consistent with the order of the constructor arguments.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me make them consistent. Thanks.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in c00f0b4. Thanks.

@@ -90,10 +99,31 @@ public Buildable consistency(com.scalar.db.api.Consistency consistency) {
return this;
}

@Override
public Buildable attribute(String name, String value) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's again a super minor comment, but the definition order of the variables (consistency, condition, and attributes) and the method definition order can be consistent to make it slightly better.
It's most probably my preference, so I don't argue about it.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me make them consistent. Thanks.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I thought I would do that this time, but it looks like it’s very time-consuming… Actually, the original method definition order is already inconsistent. Let’s tackle it when we have more time. 🙇

@brfrn169 brfrn169 requested a review from komamitsu November 14, 2024 06:03
Copy link
Contributor

@Torch3333 Torch3333 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thank you!

Copy link
Contributor

@komamitsu komamitsu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! 👍

@brfrn169 brfrn169 merged commit 7140bee into master Nov 14, 2024
48 checks passed
@brfrn169 brfrn169 deleted the introduce-operation-attributes branch November 14, 2024 09:50
feeblefakie pushed a commit that referenced this pull request Nov 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants