[
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 their
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.).
was:
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 their
> 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)
