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)