[
https://issues.apache.org/jira/browse/YARN-6027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15886893#comment-15886893
]
Sangjin Lee commented on YARN-6027:
-----------------------------------
To me {{RowKeyConverter}} is really an orthogonal conversion from the existing
key conversion and operates on the string representation. In that sense, I
would slightly prefer if it is not an extension of {{KeyConverter}}. Any
converter class that does both can implement both separate interfaces.
Also, perhaps we could find a better name for {{RowKeyConverter}}. The key
thing is not so much that it is dealing with a row key as opposed to other
{{KeyConverter}} types aren't. Most of {{KeyConverter}} implementations do deal
with row keys after all. I think what separates this interface is the fact that
it deals with the string representation (to be suitable for embedding it in
URLs). Perhaps something like {{KeyConverterToString}} or some other name
that's explicit to its purpose would be good.
I am also not 100% sold on {{RowKey}}. Again, it is not really about them being
a row key type. Should we not introduce this interface (and even the converter
interface for that matter) for now until it becomes clear we need polymorphism
on this?
In terms of method names, how about making them very explicit about dealing
with strings? I would be more comfortable with names such as
{{encodeAsString()}}, {{decodeFromString()}}, {{getRowKeyAsString()}},
{{parseRowKeyFromString()}}, and so on.
In terms of separator characters, I am of a little different opinion from
Varun's. IMO it would be better if we could reuse the same separator character
(Separator.QUALIFIERS) as a constant (not a new constant with the same value).
It is not so easy to keep track of many encoding schemes, and it would be hard
to keep track of all encoding characters. If we can reuse the same whenever
possible, it would help understand and maintain this code. I can be persuaded
otherwise, but I wanted to state my current take for the record.
bq. utils classes are not expected to be subclassed. Right? They just
encapsulate a bunch of static methods and constants.
Agree. It can be both public and final.
> Support fromid(offset) filter for /flows API
> --------------------------------------------
>
> Key: YARN-6027
> URL: https://issues.apache.org/jira/browse/YARN-6027
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: timelineserver
> Reporter: Rohith Sharma K S
> Assignee: Rohith Sharma K S
> Labels: yarn-5355-merge-blocker
> Attachments: YARN-6027-YARN-5355.0001.patch,
> YARN-6027-YARN-5355.0002.patch, YARN-6027-YARN-5355.0003.patch,
> YARN-6027-YARN-5355.0004.patch, YARN-6027-YARN-5355.0005.patch
>
>
> In YARN-5585 , fromId is supported for retrieving entities. We need similar
> filter for flows/flowRun apps and flow run and flow as well.
> Along with supporting fromId, this JIRA should also discuss following points
> * Should we throw an exception for entities/entity retrieval if duplicates
> found?
> * TimelieEntity :
> ** Should equals method also check for idPrefix?
> ** Does idPrefix is part of identifiers?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
