You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@metron.apache.org by "Tamas Fodor (Jira)" <ji...@apache.org> on 2019/12/11 13:58:00 UTC

[jira] [Updated] (METRON-2335) [UI] Implement synchronization between browser user state and Hbase user state

     [ https://issues.apache.org/jira/browse/METRON-2335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tamas Fodor updated METRON-2335:
--------------------------------
    Description: 
This change request includes tasks regarding where to store user related settings and the removal of the DataSource abstract class and its implementation called ElasticSearchLocalstorageImpl.

We understand the basic idea behind the concept of having an abstract class and its implementations but I believe that it was wrongly used and had many problems.

First of all, in that case, having an interface instead of an abstract class would have been more appropriate.

Secondly, the name of the implementation class is ElasticSearchLocalstorageImpl. Yes it persists data in the Browser's local storage but has nothing to do with Elasticsearch. Also, this frontend service should not know about the chosen tool on the backend side because it's irrelevant from this perspective.

I believe that the original idea was to easily switch between approaches of storing this kind of data on the backend but since the frontend should not know about these details, it's not necessary to use this concept anymore.

Also, if you take a look at the implementation class (ElasticSearchLocalstorageImpl), there are methods which aren't required by the abstract class and they communicate with an http server directly in order to save or get alerts data. But these methods are unused, we rather get this data independently from the data source class however it was the original idea behind having it.

Long story short, we decided to completely eliminate the DataSource class and its implementation and rather have a so-called UserSettingsService in order to get and store user specific settings on the backend.

They used to be stored in the browser's local storage but this approach works only on one computer but we would like the users to be able to get they desired settings on every computer they're logged in.

The following user settings are replaced from the local storage to Hbase:
 * time zone configuration
 * show/hide dismissed and resolved alserts
 * auto-polling settings
 * table configuration
 * saved and recently used saved searches

We decided to store everything simply in Hbase because it provides us the freedom to store basically anything without having backend work involved (declaring Java classes and additional Java properties, etc.).

> [UI] Implement synchronization between browser user state and Hbase user state
> ------------------------------------------------------------------------------
>
>                 Key: METRON-2335
>                 URL: https://issues.apache.org/jira/browse/METRON-2335
>             Project: Metron
>          Issue Type: Improvement
>            Reporter: Tamas Fodor
>            Assignee: Tamas Fodor
>            Priority: Minor
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> This change request includes tasks regarding where to store user related settings and the removal of the DataSource abstract class and its implementation called ElasticSearchLocalstorageImpl.
> We understand the basic idea behind the concept of having an abstract class and its implementations but I believe that it was wrongly used and had many problems.
> First of all, in that case, having an interface instead of an abstract class would have been more appropriate.
> Secondly, the name of the implementation class is ElasticSearchLocalstorageImpl. Yes it persists data in the Browser's local storage but has nothing to do with Elasticsearch. Also, this frontend service should not know about the chosen tool on the backend side because it's irrelevant from this perspective.
> I believe that the original idea was to easily switch between approaches of storing this kind of data on the backend but since the frontend should not know about these details, it's not necessary to use this concept anymore.
> Also, if you take a look at the implementation class (ElasticSearchLocalstorageImpl), there are methods which aren't required by the abstract class and they communicate with an http server directly in order to save or get alerts data. But these methods are unused, we rather get this data independently from the data source class however it was the original idea behind having it.
> Long story short, we decided to completely eliminate the DataSource class and its implementation and rather have a so-called UserSettingsService in order to get and store user specific settings on the backend.
> They used to be stored in the browser's local storage but this approach works only on one computer but we would like the users to be able to get they desired settings on every computer they're logged in.
> The following user settings are replaced from the local storage to Hbase:
>  * time zone configuration
>  * show/hide dismissed and resolved alserts
>  * auto-polling settings
>  * table configuration
>  * saved and recently used saved searches
> We decided to store everything simply in Hbase because it provides us the freedom to store basically anything without having backend work involved (declaring Java classes and additional Java properties, etc.).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)