> For the complete documentation index, see [llms.txt](https://docs.opendatadiscovery.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.opendatadiscovery.org/features/data-discovery/search.md). # Search and Filtering **Search** is the catalog's primary query-oriented entry path — type what you are looking for, and ODD finds entities matching across names, descriptions, and metadata. Where the [Directory](/features/data-discovery/directory.md) walks the catalog hierarchically, Search is free-text + faceted. With the user-friendly search interface, finding the information you need is easier than ever. Type your search query into the search bar and ODD does the rest. To get started, navigate to the main page of ODD Platform and select the **Catalog** tab. There you will find the **Search bar** and **Filter** options.

Type your search query into the search bar

## Faceted search The platform incorporates **faceted** search capabilities. This means you can refine your search results based on specific attributes, ensuring that you find exactly what you are looking for. The Filters panel on the Catalog page exposes seven facets: * **Datasource** — restrict results to entities ingested from a specific datasource (single-select). * **Type** — restrict results to one or more data entity types (e.g., `TABLE`, `JOB`, `DASHBOARD`; multi-select). Only shown after an entity-class tab is selected at the top of the Catalog (Datasets / Transformers / Data Consumers / Data Inputs / Quality Tests / Groups / Relationships). * **Namespace** — restrict to entities in a given namespace (single-select). Useful in multi-team setups where each team owns its own namespace and wants to see only its own datasets, jobs, and quality tests in one click. * **Owner** — show entities owned by one or more selected owners (multi-select). * **Tag** — show entities carrying one or more selected [tags](/features/data-discovery/tagging.md) (multi-select). * **Groups** — show entities that are members of one or more selected [Data Entity Groups](/features/data-discovery/groups-domains.md) (multi-select). Useful for narrowing the search to a logical project, domain, or pipeline group rather than a flat datasource list. * **Statuses** — show entities in one or more selected statuses (multi-select; e.g., `STABLE`, `DEPRECATED`).

Filters

## Result-class tabs Above the result list the Catalog page renders a tab strip — a second filter axis, independent of the Filters sidebar. Selecting a tab narrows the result list to entities of that class (or the personal scope, for `My Objects`) and unlocks the **Type** sidebar facet, which is hidden until a specific class is chosen. The nine tabs, left to right: | Tab | What it scopes to | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------ | | **All** | Every entity matching the query and the active facets, regardless of class. | | **My Objects** | The subset of the above owned by the authenticated user. The personal-namespace tab. | | **Datasets** | Entities of class `SET` (tables, views, files, topics). | | **Transformers** | Entities of class `TRANSFORMER` (jobs, pipelines, dbt models). | | **Data Consumers** | Entities of class `CONSUMER` (microservices, BI dashboards). | | **Data Inputs** | Entities of class `INPUT` (source data feeds). | | **Quality Tests** | Entities of class `QUALITY_TEST` (test definitions; per-run history lives on the [detail page](/features/data-discovery/entity-detail-page.md)). | | **Groups** | Entities of class `ENTITY_GROUP` (Data Entity Groups, including domain-flagged ones). | | **Relationships** | Entities of class `RELATIONSHIP` (ERD relationship metadata). | The tab counts update with the active query and facet selection. The **Type** facet in the sidebar is class-conditional: it appears only once a specific class tab is selected (because type values are only meaningful within a class). ## Per-result transparency As you type your search and adjust filters, ODD dynamically responds, delivering results in seconds. Each entity in the search results is accompanied by an information and a question icon, offering additional clarity and insight:

The information icon shows you what you see in your search results

The question icon shows you why you see it in your search results

## Technical details The underlying constants used by the search engine are defined in [FTSConstants.java](https://github.com/opendatadiscovery/odd-platform/blob/main/odd-platform-api/src/main/java/org/opendatadiscovery/oddplatform/repository/util/FTSConstants.java). **Step 1.** Metadata ingested into the platform goes through indexing to improve search efficiency. **Step 2.** When you search or apply filters, the search engine processes your inputs by recognizing search terms, applying relevant constraints, and identifying metadata entries closely related to the query. **Step 3.** Next, ODD ranks these matching metadata entries based on a specific criteria and their relevance to your search.

Metadata ranking for search within ODD

## Known limitations and operator caveats The catalog search runtime carries several behaviours that are non-obvious from the UI alone. Each item below states what an operator might assume, what actually happens, and what to do today. ### The `/search/{id}` URL is a server-side session, not a frozen query The address bar on the Catalog page is `/search/{uuid}` once you've typed a query. The UUID is the primary key of a row in the platform's `search_facets` table — a server-side **session** that carries the query string, the facet selections, and the current page state. It is **not** an encoded snapshot of your search and **not** a saved search. Three consequences operators routinely bump into: * **Sharing a `/search/{uuid}` URL with a teammate hands them an interactive cursor, not a snapshot.** When they open the link they reach the same server-side row; if you keep clicking facets, their view drifts with yours. To share a frozen result, send the entity URLs (`/dataentities/{id}`) directly. (Opening a shared link — and reloading the page — loads the session as of 0.28.0; earlier releases had a front-end defect that silently discarded the pasted id and started a fresh empty session.) * **The session UUID is not bound to a user.** Any authenticated caller who has the UUID reaches the row; under `auth.type=DISABLED` the row is reachable anonymously. Treat the URL as you would any other unguarded internal link. * **Clicking the `Catalog` top-nav tab drops the UUID and starts a fresh session.** The "Catalog" link points at bare `/search`, which mints a new server-side row on the next keystroke. There is no "go back to my last search" affordance on the top nav — use the browser back button instead, or re-paste the previous URL. * **The session row is evicted by the housekeeping job.** A session row lives until 30 days after its last access (configurable via [`housekeeping.ttl.search_facets_days`](/configuration-and-deployment/odd-platform.md#housekeeping-settings-configuration)). Opening an evicted URL shows a "This search has expired" notice with a one-click **Start new search** recovery (as of 0.28.0; earlier releases silently dropped the dead id and opened a fresh empty session). Bookmarking a `/search/{uuid}` URL for long-term reference is still unreliable — for durable references, share entity URLs instead. ### Facet aggregators enumerate cross-owner data by default The Filters sidebar facets — Datasource, Namespace, Owner, Tag, Groups, Statuses, Type — list every value visible to the platform, with per-value counts that span the entire catalog. The Owner facet in particular returns the full Owner directory and per-owner counts to any authenticated caller; under `auth.type=DISABLED` the same lists are reachable anonymously. This is the catalog's **read-collaborative posture**: anyone who can read the catalog can see who owns what, which sources have how many entities, and which tags are most common. If your deployment must avoid exposing the Owner directory or cross-source enumeration to all authenticated users, treat catalog access as a privileged role and do not enable `auth.type=DISABLED` in production. {% hint style="info" %} **`tsquery` operator characters in the search box are treated as word separators.** PostgreSQL full-text search parses the query as a `tsquery`, so characters such as `( ) : & | ! '` are not searchable literals — the search box strips them and matches the remaining words as prefixes. A name like `user(id)` is searched as `user` and `id` (and still matches an entity called `user(id)`); a query made up of only these characters returns **No matches found**. The same handling applies to the Dictionary (term) search box. (As of 0.28.0; in earlier releases these characters were not stripped — such a query failed with HTTP 500 and persisted a broken `/search/{uuid}` session, reproduced on every later read of that URL until the housekeeping job evicted the row.) {% endhint %} ### The Datasource and Namespace dropdowns cap at 100 options The Filters sidebar fetches at most 100 datasources and 100 namespaces for the Datasource and Namespace single-select dropdowns. In a deployment with more than 100 of either, the dropdown silently shows the first 100 the API returned — with no `+N more`, no pagination, and no search-within-dropdown affordance. To filter by a source that does not appear, use the Search bar with a query that pre-narrows the result set (e.g. typing the namespace name as free text), then apply remaining facets. ### `exclude_from_search` is a full-text-search signal only The `exclude_from_search` flag on a data entity does what its name implies — it removes the entity from the platform's full-text search results — but **it does not remove the entity from the catalog's other list surfaces**. The predicate that honours the flag is added only on the full-text-search query paths. The Recommended panel's Popular column, the By-Owner list, the By-Term list, the DEG-experiment runs view, the entity dimensions surfaces, the entity-detail GET, and the query-suggestions endpoint each build their own list query and several of those queries never add the `exclude_from_search` predicate at all. An operator setting the flag on a staging or internal entity should expect it to disappear from search results but still appear on every other list surface in the platform. See the same caveat from the catalog-front-door angle on [Catalog Overview → Recommended](/features/data-discovery/catalog-overview.md#recommended). ### Clicking a result row records a view — and feeds the Popular ranking Each click on a result row navigates to the entity's [detail page](/features/data-discovery/entity-detail-page.md), which records a view on the entity's `viewCount` — exactly one per open as of 0.28.0 (releases up to 0.27.x double-counted each open as +2; see [Data entity detail page → view count](/features/data-discovery/entity-detail-page.md#general-panel-view-count-caveats)). The Catalog Overview's **Popular** and **Recommended** tiles read from the same counter, so routine browsing through search results still biases those rankings toward whatever entities you happened to open from search — every open counts, however you arrive (a search-row click and direct navigation to `/dataentities/{id}` record the same single view). Returning to the results with the browser back button does not add another view. ## Where else search appears Search and filtering are available not only in the Catalog tab, but in **Query examples**, **Master Data**, [**Management**](/features/management.md), and **Dictionary** tabs as well — each Management sub-tab (Datasources, Owners, Tags, …) has its own list-level filter. The Catalog-level full-text search across data entities is exclusive to the Catalog tab. ## Where to next * [Directory](/features/data-discovery/directory.md) — the hierarchy-driven counterpart for browsing without typing a query. * [Data entity detail page](/features/data-discovery/entity-detail-page.md) — the destination of every result-row click; explains the Overview tab composition you land on and the class-driven panel matrix. * [Manual Object Tagging](/features/data-discovery/tagging.md) — the Tag facet's source data. * [Data Entity Groups & Domains](/features/data-discovery/groups-domains.md) — the Groups facet's source data. * [Housekeeping Settings Configuration](/configuration-and-deployment/odd-platform.md#housekeeping-settings-configuration) — the `housekeeping.ttl.search_facets_days` knob that controls how long a `/search/{uuid}` session lives. * [Main Concepts → Data Governance map](/introduction/main-concepts.md#data-governance-map) — where Data Discovery (Search + Directory) sits among the governance pillars. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.opendatadiscovery.org/features/data-discovery/search.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.