[ 
https://issues.apache.org/jira/browse/METRON-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16607682#comment-16607682
 ] 

ASF GitHub Bot commented on METRON-1771:
----------------------------------------

Github user merrimanr commented on a diff in the pull request:

    https://github.com/apache/metron/pull/1190#discussion_r216090740
  
    --- Diff: 
metron-platform/metron-indexing/src/main/java/org/apache/metron/indexing/dao/metaalert/lucene/AbstractLuceneMetaAlertUpdateDao.java
 ---
    @@ -170,21 +169,51 @@ protected Document 
buildCreateDocument(Iterable<Document> alerts, List<String> g
         return updates;
       }
     
    +  /**
    +   * Adds alerts to a metaalert, based on a list of GetRequests provided 
for retrieval.
    +   * @param metaAlertGuid The GUID of the metaalert to be given new 
children.
    +   * @param alertRequests GetRequests for the appropriate alerts to add.
    +   * @return The updated metaalert with alerts added.
    +   */
    +  @Override
    +  public Document addAlertsToMetaAlert(String metaAlertGuid, 
List<GetRequest> alertRequests)
    --- End diff --
    
    This was moved from the Elasticsearch Dao implementation essentially making 
it the default method for adding alerts to metaalerts (the logic in the Solr 
implementation is different).  This allows us to reuse this code in the 
InMemory implementation.


> Update REST endpoints to support eventually consistent UI updates
> -----------------------------------------------------------------
>
>                 Key: METRON-1771
>                 URL: https://issues.apache.org/jira/browse/METRON-1771
>             Project: Metron
>          Issue Type: Improvement
>            Reporter: Ryan Merriman
>            Priority: Major
>
> Currently the REST endpoints that perform document updates either return 
> true/false or nothing.  This puts the responsibility of retrieving the 
> updated state of the object on the client in a separate call or 
> optimistically applying the changes and reverting when an update fails.  This 
> can be problematic if a client attempts to get the current state immediately 
> after an update and the change isn't visible yet in the back end.
> Ideally they should return the updated state of the object, eliminating the 
> need to look up the updated state in a separate call.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to