Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Search docs #871

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

Open
ciaranschutte wants to merge 2 commits into feature/federated_search
base: feature/federated_search
Choose a base branch
Loading
from search-docs
Open

Search docs #871

ciaranschutte wants to merge 2 commits into feature/federated_search from search-docs

Conversation

@ciaranschutte
Copy link
Contributor

@ciaranschutte ciaranschutte commented May 31, 2024
edited
Loading

  • adding design doc in this location is temporary. there is an existing docs folder that needs some attention on what to do with it.

  • initial design doc for federated search

  • preferring the term "search_node" over "node" when talking about gql as there is already "node" data in Arranger

  • view PR in "rich diff" to display as rendered markdown

Copy link
Contributor

@joneubank joneubank left a comment

Choose a reason for hiding this comment

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

This is a good start at capturing our process. I wouldn't mind an example of the config file, and I think we should consider adding a name property to each search node in that config.

It would be good to add a bit of description at the start describing how arranger will support local and network search and that this document describes how network search is setup.


## Prerequisites
- Local data must be configured
- ENV flag passed into process
Copy link
Contributor

@joneubank joneubank May 31, 2024

Choose a reason for hiding this comment

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

what env flag? what does the flag set/enable?

![VPCzJyCm48Pt_ufJftP0x1bGAuIgIhG22XDYEE9hQicnW-qW-FVu8qT2HTlfSkzpxtrONVg0BlIj5bW7ww3yNZnnY3v_YIvYgbOTcW2pbNDe6d8LR56PMOHoS0wwjUQWceoLy1ou9tJrCOCbl0oEninVjjzPIJ1trDf0YrILCqA8lE_LJLu2edkw2N1Tr7C-wiM-WYVwwCa7gFCt79GcKRI_5Ce1yV2h3stuAcpEsOrH (1)](https://github.com/overture-stack/arranger/assets/1486054/87bb0689-38c6-49eb-ab65-96696a04d86a)

## Prerequisites
- Local data must be configured
Copy link
Contributor

@joneubank joneubank May 31, 2024

Choose a reason for hiding this comment

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

This was a bit confusing cause I read it assuming it meant local developer setup should have data available, but now I assume this is "local" in the context of "local search" vs "network search". This is a bit unclear.

Perhaps it could be phrased like Local Search configuration of this arranger node is performed separately from Network Search, since we do not require a local search config for network search

| Field | Type | Note |
| ------------- | ------ | ------------------------------------------------------------------------------------------------------------------------------- |
| endpoint | string | Full url to gql endpoint |
| arrangerField | string | Endpoints can have other data on the root object. Need to get specific Arranger config object. Appears to be "file" by default. |
Copy link
Contributor

@joneubank joneubank May 31, 2024

Choose a reason for hiding this comment

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

I don't think it is file by default, but this is common for setups that use maestro to index files from song.

| Field | Description |
| ------ | --------------------------- |
| url | gql endpoint |
| name | name of node eg. Toronto |
Copy link
Contributor

@joneubank joneubank May 31, 2024

Choose a reason for hiding this comment

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

Seeing this here, we may want to include a name property to our node config. Arranger nodes aren't currently reporting a name of their own, so this would help us label each node in our responses.

| url | gql endpoint |
| name | name of node eg. Toronto |
| schema | version of Arranger running |
| status | node status eg. "connected" |
Copy link
Contributor

@joneubank joneubank May 31, 2024

Choose a reason for hiding this comment

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

👍
We should list the possible statuses and what they mean.

Copy link
Contributor Author

@ciaranschutte mermaid diag

@ciaranschutte ciaranschutte changed the base branch from main to feature/federated_search December 14, 2024 23:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@joneubank joneubank joneubank left review comments

@justincorrigible justincorrigible Awaiting requested review from justincorrigible

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

AltStyle によって変換されたページ (->オリジナル) /