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

Search #7237

Merged
merged 57 commits into from
Oct 3, 2024
Merged

Search #7237

merged 57 commits into from
Oct 3, 2024

Conversation

ijreilly
Copy link
Collaborator

@ijreilly ijreilly commented Sep 24, 2024

Steps to test

  1. Run metadata migrations
  2. Run sync-metadata on your workspace
  3. Enable the following feature flags:
    IS_SEARCH_ENABLED
    IS_QUERY_RUNNER_TWENTY_ORM_ENABLED
    IS_WORKSPACE_MIGRATED_FOR_SEARCH
  4. Type Cmd + K and search anything

@ijreilly ijreilly marked this pull request as ready for review September 30, 2024 17:45
@ijreilly ijreilly requested a review from Weiko September 30, 2024 17:47
Copy link
Contributor

@greptile-apps greptile-apps bot left a comment

Choose a reason for hiding this comment

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

PR Summary

This PR introduces comprehensive search functionality across the Twenty application, focusing on both frontend and backend implementations. Here are the key changes:

  • Added new search GraphQL query and resolver for efficient full-text search
  • Implemented TsVector field type and GIN indexing for PostgreSQL full-text search
  • Created frontend hooks and utilities for search operations (useSearchRecords, useSearchRecordsQuery)
  • Integrated feature flags for controlled rollout of search functionality
  • Modified CommandMenu component to utilize new search capabilities
  • Updated GraphQL schema and type definitions to support search operations
  • Added migrations for new database structures supporting search features

30 file(s) reviewed, 13 comment(s)
Edit PR Review Bot Settings

import { getSearchRecordsQueryResponseField } from '@/object-record/utils/getSearchRecordsQueryResponseField';
import { capitalize } from '~/utils/string/capitalize';

export type QueryCursorDirection = 'before' | 'after';
Copy link
Contributor

Choose a reason for hiding this comment

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

style: QueryCursorDirection is defined but not used in this file. Consider removing if unnecessary.

Comment on lines 8 to 11
import { FieldMetadataType } from 'src/engine/metadata-modules/field-metadata/field-metadata.entity';
import { isCompositeFieldMetadataType } from 'src/engine/metadata-modules/field-metadata/utils/is-composite-field-metadata-type.util';
import { isRelationFieldMetadataType } from 'src/engine/utils/is-relation-field-metadata-type.util';
import { pascalCase } from 'src/utils/pascal-case';
Copy link
Contributor

Choose a reason for hiding this comment

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

style: Import order changed. Consider using a consistent import ordering strategy across the codebase.

Copy link
Member

@Weiko Weiko left a comment

Choose a reason for hiding this comment

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

Great Job @ijreilly! I left a few comments and still need to test a bit locally. Can't wait to merge it 💪

icon: 'IconUser',
generatedType: 'STORED',
asExpression: getTsVectorColumnExpressionFromFields([
{ name: NAME_FIELD_NAME, type: FieldMetadataType.TEXT },
Copy link
Member

Choose a reason for hiding this comment

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

Should we use standardFieldId instead here?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

In the util at this stage we cannot fetch fieldMetadata based on the standardFieldId, can we?

Copy link
Member

Choose a reason for hiding this comment

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

Probably not yet. Should be part of the refactoring of sync-metadata but we already started to use hashmap in some places with standard-id, nameSingular, namePlural, etc... as keys.
You can keep it as it is for now indeed

Copy link
Member

@Weiko Weiko left a comment

Choose a reason for hiding this comment

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

Almost there 💪
Also I noticed we were not querying search for custom objects on the FE, is it expected? Looks like the BE should be ready? LGTM if we want to do it in another PR 👍

isActive: false,
isSystem: true,
type: FieldMetadataType.TS_VECTOR,
name: SEARCH_VECTOR_FIELD_NAME,
Copy link
Member

Choose a reason for hiding this comment

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

I see, maybe we can create an object then?

const SEARCH_VECTOR_FIELD = {
   name: 'searchVector',
   label: 'Search Vector',
...
}

not a strong requirement, up to you if you feel like those const are enough

icon: 'IconUser',
generatedType: 'STORED',
asExpression: getTsVectorColumnExpressionFromFields([
{ name: NAME_FIELD_NAME, type: FieldMetadataType.TEXT },
Copy link
Member

Choose a reason for hiding this comment

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

Probably not yet. Should be part of the refactoring of sync-metadata but we already started to use hashmap in some places with standard-id, nameSingular, namePlural, etc... as keys.
You can keep it as it is for now indeed

Copy link
Member

@Weiko Weiko left a comment

Choose a reason for hiding this comment

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

Great job!! Just left a few comments but LGTM 👏


public async up(queryRunner: QueryRunner): Promise<void> {
await queryRunner.query(
`CREATE TYPE metadata.INDEX_TYPES AS ENUM ('BTREE', 'GIN')`,
Copy link
Member

Choose a reason for hiding this comment

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

Just realised but I think that's not the naming convention we follow currently.
We put the name of the table as well. Can you double check please? 🙏

}

if (!args.searchInput) {
return {} as IConnection<ObjectRecord>;
Copy link
Member

Choose a reason for hiding this comment

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

You should be able to return this

          return typeORMObjectRecordsParser.createConnection(
            [],
            objectMetadataItem.nameSingular,
            0,
            0,
            [{ id: OrderByDirection.AscNullsFirst }],
            false,
            false,
          );

@ijreilly ijreilly merged commit 5f9435c into main Oct 3, 2024
7 of 13 checks passed
@ijreilly ijreilly deleted the search branch October 3, 2024 15:18
harshit078 pushed a commit to harshit078/twenty that referenced this pull request Oct 14, 2024
Steps to test

1. Run metadata migrations
2. Run sync-metadata on your workspace
3. Enable the following feature flags: 
IS_SEARCH_ENABLED
IS_QUERY_RUNNER_TWENTY_ORM_ENABLED
IS_WORKSPACE_MIGRATED_FOR_SEARCH
4. Type Cmd + K and search anything
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.

3 participants