[
https://issues.apache.org/jira/browse/YARN-6027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15887442#comment-15887442
]
Varun Saxena edited comment on YARN-6027 at 2/28/17 7:09 AM:
-------------------------------------------------------------
bq. Any converter class that does both can implement both separate interfaces.
To be honest, this is what I meant when I first made the comment about
separating this out into an interface. But after seeing Rohith's patch thought
that as all row key converters will be requiring encoding/decoding string row
key variant so let us go with what's in the patch. However, your point about
this being orthogonal to current key version. And this being more about
conversion to/from String makes sense to me. So let us go with 2 separate
interfaces.
bq. 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).
Actually, the current patch does not use Separator enum for from id conversion.
It uses 2 constants. My comment was more about using these constants in tests.
However, I did think of reusing Separator enum. But how do we fit in the escape
char? Move ESCAPE char also to Separator enum? Probably can be done but then it
will not be used at all in Separator enum. Picking one from Separator enum and
other from a constant I thought would be weird.
Also, I thought we will be mixing it up because for FROM_ID we would want URL
safe characters as separator and escape characters because this will be carried
in URL in eventually. Whereas Separator class is primarily used for conversion
fo HBase bytes. So if somebody wishes to change separator in HBase row key,
would he have to take care of this being URL safe character as well? We can
probably leave a comment but then it would be somewhat restrictive.
I had even thought of moving split and join methods used for String escaping to
Separator enum but Separator enum is defined at the storage layer and these
methods are also used for UID conversion.
This was the thought process behind not suggesting reuse of
Separator#QUALIFIERS. Your thoughts on the same?
was (Author: varun_saxena):
bq. Any converter class that does both can implement both separate interfaces.
To be honest, this is what I meant when I first made the comment about
separating this out into an interface. But after seeing Rohith's patch thought
that as all row key converters will be requiring encoding/decoding string row
key variant so let us go with what's in the patch. However, your point about
this being orthogonal to current key version. And this being more about
conversion to/from String makes sense to me. So let us go with 2 separate
interfaces.
bq. 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).
Actually, the current patch does not use Separator enum for from id conversion.
It uses 2 constants. My comment was more about using these constants in tests.
However, I did think of reusing Separator enum. But how do we fit in the escape
char? Move ESCAPE char also to Separator enum? Probably can be done but then it
will not be used at all in Separator enum. Picking one from Separator enum and
other from a constant I thought would be weird.
Also, I thought we will be mixing it up because for FROM_ID we would want URL
safe characters as separator and escape characters because this will be carried
in URL in eventually. Whereas Separator class is primarily used for conversion
fo HBase bytes. So if somebody wishes to change separator in HBase row key,
would he have to take care of this being URL safe character as well? We can
probably leave a comment but then it would be somewhat restrictive.
This was the thought process behind not suggesting reuse of
Separator#QUALIFIERS. Your thoughts on the same?
> 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]
