[
https://issues.apache.org/jira/browse/YARN-6027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15886195#comment-15886195
]
Varun Saxena edited comment on YARN-6027 at 2/27/17 5:51 PM:
-------------------------------------------------------------
[~rohithsharma],
bq. both are same right? any issues will happen because of enum? I debug the
code, the value is ! itself in cluster. May be need to add more combination of
tests.
They are both same right now. But what if somebody changes them in future? The
variables/enums used are different. FlowActivityRowKeyConverter#decode(byte[])
uses Separator#QUALIFIERS whereas FlowActivityRowKeyConverter#decode(String)
uses the constants defined in TimelineReaderUtils. Same goes for encode methods.
If somebody in future changes either one of them i.e. changes QUALIFIERS but
not SEPARATOR_CHAR to something other than "!", the intention of test case
won't be served. So it would be better to use the respective constant/enum as
per the converter method being invoked. This was the intention behind comment.
bq. IIUC, public static final constants need not to be annotated
Sorry, my bad. We do use FROM_ID outside the scope of tests and
TimelineReaderUtils.
bq. RowKeyConvertor interface extended from KeyConvertor interface. RowKey is
interface which is implemented by HBase table row key class . Both
RowKeyConvertor and RowKey interfaces are different.
What I meant was to define RowKeyConverter interface as under. We do not expect
RowKeyConverter to be extended for anything other than type parameter being
subtype of RowKey. Right? As your javadoc also says this interface has to be
implemented *for encoding and decoding row keys only*. Defining it like below
would sort of enforce this condition if all row keys implement RowKey interface.
{code}
public interface RowKeyConverter<R extends RowKey> extends KeyConverter<R>
{code}
bq. Even I got doubt while removing final, why it should be final? utils class
should be public
utils classes are not expected to be subclassed. Right? They just encapsulate a
bunch of static methods and constants.
was (Author: varun_saxena):
[~rohithsharma],
bq. both are same right? any issues will happen because of enum? I debug the
code, the value is ! itself in cluster. May be need to add more combination of
tests.
They are both same right now. But what if somebody changes them in future? The
variables/enums used are different. FlowActivityRowKeyConverter#decode(byte[])
uses Separator#QUALIFIERS whereas FlowActivityRowKeyConverter#decode(String)
uses the constants defined in TimelineReaderUtils. Same goes for encode methods.
If somebody in future changes either one of them i.e. changes QUALIFIERS but
not SEPARATOR_CHAR to something other than "!", the intention of test case
won't be served. So it would be better to use the respective constant/enum as
per the converter method being invoked. This was the intention behind comment.
bq. IIUC, public static final constants need not to be annotated
Sorry, my bad. We do use FROM_ID outside the scope of tests and
TimelineReaderUtils.
bq. RowKeyConvertor interface extended from KeyConvertor interface. RowKey is
interface which is implemented by HBase table row key class . Both
RowKeyConvertor and RowKey interfaces are different.
What I meant was to define RowKeyConverter interface as under. We do not expect
RowKeyConverter to be extended for anything other than type parameter being
subtype of RowKey. Right?
{code}
public interface RowKeyConverter<R extends RowKey> extends KeyConverter<R>
{code}
bq. Even I got doubt while removing final, why it should be final? utils class
should be public
utils classes are not expected to be subclassed. Right? They just encapsulate a
bunch of static methods and constants.
> 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]
