Search docs #871
Search docs #871
Conversation
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
what env flag? what does the flag set/enable?
|  | ||
|
|
||
| ## Prerequisites | ||
| - Local data must be configured |
There was a problem hiding this comment.
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. | |
There was a problem hiding this comment.
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 | |
There was a problem hiding this comment.
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" | |
There was a problem hiding this comment.
👍
We should list the possible statuses and what they mean.
|
@ciaranschutte mermaid diag |
justincorrigible
force-pushed
the
develop
branch
3 times, most recently
from
6b33e90 to
7f882d1
Compare
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