Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add multi data source support #315

Merged
merged 4 commits into from
Apr 22, 2024

Conversation

wanglam
Copy link
Collaborator

@wanglam wanglam commented Apr 16, 2024

Description

  1. Add multi data source support for admin UI
  2. Add missing unit tests for server side
image

image

Issues Resolved

List any issues this PR will resolve, e.g. Closes [...].

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

}: MlCommonsPluginAppDeps) => {
const dataSourceEnabled = !!dataSource?.dataSourceEnabled;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: we should be able to tell if the data source plugin is enabled via !!dataSource

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean we don't need to read the dataSourceEnabled property in dataSource? The multi data source will always be enabled if dataSource is truly.

setActionMenu,
dataSourceManagement,
}: DataSourceTopNavMenuProps) => {
const dataSourceEnabled = !!dataSource?.dataSourceEnabled;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This component is only mounted when the dataSourceEnabled flag is true, do we need to double check the flag?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we mean the dataSourceEnabled will always be true, if the top nav menu mounted? Add check here is for dataSourceEnabled changed. The dataSourceEnabled in DataSourceContextProvider will be updated if enabled status changed from outside.

@wanglam wanglam force-pushed the add-multi-datasource-support branch from 92616a6 to 057a0f5 Compare April 18, 2024 07:59
@@ -5,13 +5,20 @@

import { useCallback, useEffect, useRef, useState } from 'react';

export const DO_NOT_FETCH = Symbol('DO_NOT_FETCH');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you elaborate why we need DO_NOT_FETCH? I couldn't capture the idea, maybe leave a comment?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The fetcher will be automatic execute if Component mounted. Add this DO_NOT_FETCH here is for prevent this default behavior. If this parameter present, the fetcher won't be executed. In the real world, we don't want any API be execute until data source id finalized.

@ruanyl
Copy link
Member

ruanyl commented Apr 19, 2024

I'm still concerning the current implementation as it requires the components to pass data source id explicitly. This is a bit overwhelming if we need to do this in the future for all the components we add that interact with apis.

I think data source is data layer configuration, presentation layer shouldn't be aware of that. How do you like this idea:

  1. since we need UI to reload when data source changed without refreshing the page, we can simply call reload in useFetcher when data source changed.
+ export const currentDataSourceId$ = new BehaviorSubject<string>('');
export const useFetcher = (...) => {
+  const dataSourceId = useObservable(currentDataSourceId$);

+  useEffect(() => {
+    if (dataSourceId) {
+      reload();
 +   }
+  }, [currentDataSourceId$, reload]);
}
  1. For apis, we could add the data source id by default
export class Connector {
  public getAll() {
    return InnerHttpProvider.getHttp().get<GetAllConnectorResponse>(CONNECTOR_API_ENDPOINT, {
      query: {
+        data_source_id: currentDataSourceId$.value,
      },
    });
  }
}

Then basically, no components need to be changed, and once data source id changed, it reload the data and component get updated.

@wanglam
Copy link
Collaborator Author

wanglam commented Apr 19, 2024

I'm still concerning the current implementation as it requires the components to pass data source id explicitly. This is a bit overwhelming if we need to do this in the future for all the components we add that interact with apis.

I think data source is data layer configuration, presentation layer shouldn't be aware of that. How do you like this idea:

  1. since we need UI to reload when data source changed without refreshing the page, we can simply call reload in useFetcher when data source changed.
+ export const currentDataSourceId$ = new BehaviorSubject<string>('');
export const useFetcher = (...) => {
+  const dataSourceId = useObservable(currentDataSourceId$);

+  useEffect(() => {
+    if (dataSourceId) {
+      reload();
 +   }
+  }, [currentDataSourceId$, reload]);
}
  1. For apis, we could add the data source id by default
export class Connector {
  public getAll() {
    return InnerHttpProvider.getHttp().get<GetAllConnectorResponse>(CONNECTOR_API_ENDPOINT, {
      query: {
+        data_source_id: currentDataSourceId$.value,
      },
    });
  }
}

Then basically, no components need to be changed, and once data source id changed, it reload the data and component get updated.

This is a good idea, especially for model registry. There is still one question need to be figure out after move automatic reload logic to useFetcher. Sometimes the search params need to updated imediality after data source change. That will cause two requests send. One triggered by automatic reload, another triggered by params change. The useFetcher hook should cancel the previous request. The useFetcher doesn't support this now. I've raised a refactor issue to track it. Will refactor this part in model registry.

@wanglam wanglam merged commit 6bcecf5 into opensearch-project:main Apr 22, 2024
6 checks passed
@opensearch-trigger-bot
Copy link
Contributor

The backport to 2.x failed:

The process '/usr/bin/git' failed with exit code 1

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-2.x 2.x
# Navigate to the new working tree
cd .worktrees/backport-2.x
# Create a new branch
git switch --create backport/backport-315-to-2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 6bcecf5a970546d4c3f852581d9bf9cb4a93888e
# Push it to GitHub
git push --set-upstream origin backport/backport-315-to-2.x
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-2.x

Then, create a pull request where the base branch is 2.x and the compare/head branch is backport/backport-315-to-2.x.

wanglam added a commit to wanglam/ml-commons-dashboards that referenced this pull request Apr 22, 2024
* add multi data source support

Signed-off-by: Lin Wang <[email protected]>

* add unit tests for server side

Signed-off-by: Lin Wang <[email protected]>

* Use dataSource to check if data source enabled

Signed-off-by: Lin Wang <[email protected]>

* Add comments for DO_NOT_FETCH

Signed-off-by: Lin Wang <[email protected]>

---------

Signed-off-by: Lin Wang <[email protected]>
wanglam added a commit that referenced this pull request Apr 23, 2024
* add multi data source support



* add unit tests for server side



* Use dataSource to check if data source enabled



* Add comments for DO_NOT_FETCH



---------

Signed-off-by: Lin Wang <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants