bbeaudreault commented on code in PR #5326:
URL: https://github.com/apache/hbase/pull/5326#discussion_r1269507081
##########
hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncTableBuilder.java:
##########
@@ -137,6 +138,11 @@ default AsyncTableBuilder<C> setMaxRetries(int maxRetries)
{
*/
AsyncTableBuilder<C> setStartLogErrorsCnt(int startLogErrorsCnt);
+ /**
+ * Sets the map of request attributes
+ */
+ AsyncTableBuilder<C> setRequestAttributes(Map<String, byte[]>
requestAttributes);
Review Comment:
it may be worth simplifying this to all just be additive. I was thinking
about it and this is just a temporary builder. To one of your earlier comments,
I don't think we need to support removal of attributes and here it's hard to
imagine the case for someone to do something like:
```java
getTableBuilder(table)
.setRequestAttribute("foo", "bar")
.setRequestAttribute("abc", "def")
.setRequestAttributes(Map.of("foo", "asdfa")) // actually forget those, i
want to just use this
.build()
```
I could see needing to support replacement/removal/etc if we allowed
modifying the longer-lived Table objects. I know some builders out there have
like a BuiltObject.toBuilder() method, in which case maybe it'd be good to
support these things for evolving Tables over time. But our builders are pretty
simple and one-off, so not necessary.
So trying to think about KISS here, and to me that means simply additive. I
could even imagine changing the plural method to be named
`setAllRequestAttributes` so its maybe a little clearer (along with javadoc)
that we're just iterating and calling set on each. If anything, I could imagine
a more useful bit of complexity to be supporting typed set methods, like
`setRequestAttribute(String, String)` which does the byte[] conversion for you,
along with other primitives. But we can skip that for now :)
One other note -- many people will not use request attributes. Let's default
the `requestAttributes` map to null, and only instantiate a hashmap if one of
these setters is called.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
