You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@oozie.apache.org by "Hadoop QA (JIRA)" <ji...@apache.org> on 2018/09/04 08:42:06 UTC
[jira] [Commented] (OOZIE-3229) Improved filtering options in
V2SLAServlet
[ https://issues.apache.org/jira/browse/OOZIE-3229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16602763#comment-16602763 ]
Hadoop QA commented on OOZIE-3229:
----------------------------------
PreCommit-OOZIE-Build started
> Improved filtering options in V2SLAServlet
> ------------------------------------------
>
> Key: OOZIE-3229
> URL: https://issues.apache.org/jira/browse/OOZIE-3229
> Project: Oozie
> Issue Type: New Feature
> Components: client
> Affects Versions: 5.0.0, 4.3.1
> Reporter: Andras Piros
> Assignee: Andras Salamon
> Priority: Major
> Fix For: 5.1.0
>
> Attachments: OOZIE-3229-1.patch, OOZIE-3229-2.patch, OOZIE-3229-3.patch, OOZIE-3229-4.patch, OOZIE-3229-5.patch, OOZIE-3229-6.patch, OOZIE-3229-7.patch
>
>
> Currently we can apply a range of filters on top of {{V2SLAServlet}} that can be used in a rich but undocumented set of ways:
> * {{id}}
> * {{parent_id}}
> * {{event_status}}
> * {{app_name}}
> * {{nominal_start}}
> * {{nominal_end}}
> Need to refactor {{V2SLAServlet}} to feature:
> * a richer set of {{SLAEvent}}, {{SLARegistration}}, and {{SLASummary}} filtering based on their attributes
> * filter options will always be {{AND}}-ed, never {{OR}}-ed to each other
> * maintain compatibility with the parameter names and behavior used thus far
> * remove {{SLASummaryFilter}} and refactor {{SLASummaryGetForFilterJPAExecutor}} as just another possibility for confusion
> * document new functionality with rich use case / example library so that users can leverage
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)