Search and Filtering

Search and Filtering — the catalog's query-oriented entry point. Free-text search across entity names plus seven faceted filters.

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 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 (multi-select).

• Groups — show entities that are members of one or more selected Data Entity Groups (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).
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.

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). 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.

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.)

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.

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, 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). 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, 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 — the hierarchy-driven counterpart for browsing without typing a query.

• Data entity detail page — the destination of every result-row click; explains the Overview tab composition you land on and the class-driven panel matrix.

• Manual Object Tagging — the Tag facet's source data.

• Data Entity Groups & Domains — the Groups facet's source data.

• Housekeeping Settings Configuration — the housekeeping.ttl.search_facets_days knob that controls how long a /search/{uuid} session lives.

• Main Concepts → Data Governance map — where Data Discovery (Search + Directory) sits among the governance pillars.