fix: Remove like condition for column condition #231
Conversation
WalkthroughThe changes introduced in this pull request primarily enhance the search and filtering functionalities across various components by replacing the use of string literals with structured operators from the Changes
Possibly related PRs
Suggested reviewers
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Outside diff range and nitpick comments (7)
apps/webservice/src/app/[workspaceSlug]/(app)/_components/target-condition/NameConditionRender.tsx (1)
15-22: Consider making the title configurableThe component looks clean and properly forwards all necessary props. However, consider making the "Name" title configurable through props for better reusability.
export const NameConditionRender: React.FC< TargetConditionRenderProps<NameCondition> -> = ({ condition, onChange, className }) => { +> = ({ condition, onChange, className, title = "Name" }) => { const setOperator = (operator: ColumnOperatorType) => onChange({ ...condition, operator }); const setValue = (value: string) => onChange({ ...condition, value }); return ( <ColumnConditionRender operator={condition.operator} value={condition.value} setOperator={setOperator} setValue={setValue} className={className} - title="Name" + title={title} /> ); };apps/webservice/src/app/[workspaceSlug]/(app)/_components/filter/ColumnConditionRender.tsx (1)
43-47: LGTM! Consider adding tooltips for better UX.The new operators (Contains, StartsWith, EndsWith) provide more precise filtering capabilities compared to the previous Like operator. The implementation is clean and type-safe.
Consider adding tooltips to explain each operator's behavior with examples, especially for non-technical users. For instance:
- Contains: Matches if the value appears anywhere (e.g., "cat" matches "scatter")
- Starts with: Matches if the value appears at the start (e.g., "cat" matches "category")
- Ends with: Matches if the value appears at the end (e.g., "cat" matches "wildcat")
apps/webservice/src/app/[workspaceSlug]/(app)/_components/release-condition/ReleaseConditionBadge.tsx (1)
45-47: LGTM! Column operators are properly mapped.The new operator mappings are consistent with the existing pattern and provide clear, descriptive verbs for the UI.
Consider internationalizing these strings for multi-language support in the future. You could move these to a translation file or use a translation framework.
Example approach:
const operatorVerbs = { [ColumnOperator.StartsWith]: t('operators.startsWith'), [ColumnOperator.EndsWith]: t('operators.endsWith'), [ColumnOperator.Contains]: t('operators.contains'), // ... other operators };packages/db/src/schema/release.ts (2)
288-293: Consider handling special characters in search patternsThe implementation correctly uses
ilikefor case-insensitive pattern matching. However, consider escaping special characters incond.valueto prevent unexpected behavior when users input values containing SQL pattern characters (%, _).+const escapePattern = (value: string) => value.replace(/[%_]/g, char => `\\${char}`); + const buildVersionCondition = (cond: VersionCondition): SQL => { if (cond.operator === ColumnOperator.Equals) return eq(release.version, cond.value); if (cond.operator === ColumnOperator.StartsWith) - return ilike(release.version, `${cond.value}%`); + return ilike(release.version, `${escapePattern(cond.value)}%`); if (cond.operator === ColumnOperator.EndsWith) - return ilike(release.version, `%${cond.value}`); + return ilike(release.version, `%${escapePattern(cond.value)}`); if (cond.operator === ColumnOperator.Contains) - return ilike(release.version, `%${cond.value}%`); + return ilike(release.version, `%${escapePattern(cond.value)}%`); return sql`${release.version} ~ ${cond.value}`; };
288-293: Consider adding index hints for ILIKE queriesThe new
ilikeconditions might benefit from proper indexing for better performance, especially for large tables. Consider adding index hints or documenting the need for appropriate indexes.Options to consider:
- Add a GiST index for pattern matching:
CREATE INDEX idx_release_version_pattern ON release USING gist (version gist_trgm_ops);
- Add a B-tree index with functional lower() for case-insensitive matches:
CREATE INDEX idx_release_version_lower ON release (lower(version));packages/db/src/schema/resource.ts (2)
225-230: Consider adding error handling for invalid operatorsThe implementation correctly handles the new operators with appropriate pattern matching. However, consider adding an explicit error case for unsupported operators to improve maintainability.
const buildIdentifierCondition = (tx: Tx, cond: IdentifierCondition): SQL => { if (cond.operator === ColumnOperator.Equals) return eq(resource.identifier, cond.value); if (cond.operator === ColumnOperator.StartsWith) return ilike(resource.identifier, `${cond.value}%`); if (cond.operator === ColumnOperator.EndsWith) return ilike(resource.identifier, `%${cond.value}`); if (cond.operator === ColumnOperator.Contains) return ilike(resource.identifier, `%${cond.value}%`); + if (cond.operator === ColumnOperator.Regex) return sql`${resource.identifier} ~ ${cond.value}`; + throw new Error(`Unsupported operator: ${cond.operator}`); };
234-244: Consider reducing code duplication with identifier conditionsThe
buildNameConditionfunction duplicates the logic frombuildIdentifierCondition. Consider extracting the common pattern matching logic into a shared utility function.+const buildColumnCondition = (column: SQL, cond: NameCondition | IdentifierCondition): SQL => { + if (cond.operator === ColumnOperator.Equals) + return eq(column, cond.value); + if (cond.operator === ColumnOperator.StartsWith) + return ilike(column, `${cond.value}%`); + if (cond.operator === ColumnOperator.EndsWith) + return ilike(column, `%${cond.value}`); + if (cond.operator === ColumnOperator.Contains) + return ilike(column, `%${cond.value}%`); + if (cond.operator === ColumnOperator.Regex) + return sql`${column} ~ ${cond.value}`; + throw new Error(`Unsupported operator: ${cond.operator}`); +}; + +const buildNameCondition = (tx: Tx, cond: NameCondition): SQL => + buildColumnCondition(resource.name, cond); + +const buildIdentifierCondition = (tx: Tx, cond: IdentifierCondition): SQL => + buildColumnCondition(resource.identifier, cond);
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (15)
apps/webservice/src/app/[workspaceSlug]/(app)/_components/SearchDialog.tsx(2 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/_components/filter/ColumnConditionRender.tsx(1 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/_components/job-condition/JobConditionBadge.tsx(2 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/_components/job-condition/JobTargetConditionRender.tsx(2 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/_components/release-condition/ReleaseConditionBadge.tsx(2 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/_components/target-condition/ComparisonConditionRender.tsx(2 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/_components/target-condition/NameConditionRender.tsx(1 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/_components/target-condition/TargetConditionBadge.tsx(2 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/systems/[systemSlug]/_components/variables/VariableResourceInput.tsx(2 hunks)packages/db/src/schema/job.ts(2 hunks)packages/db/src/schema/release.ts(2 hunks)packages/db/src/schema/resource.ts(2 hunks)packages/validators/src/conditions/index.ts(1 hunks)packages/validators/src/resources/conditions/identifier-condition.ts(0 hunks)packages/validators/src/resources/conditions/name-condition.ts(1 hunks)
💤 Files with no reviewable changes (1)
- packages/validators/src/resources/conditions/identifier-condition.ts
🔇 Additional comments (25)
packages/validators/src/resources/conditions/name-condition.ts (2)
3-3: LGTM!
The import statement is correctly added and follows proper ESM import conventions.
7-7: Verify the impact of this breaking schema change
The change from z.literal("like") to columnOperator is a breaking change that modifies the validation schema. This could affect existing code that relies on the previous schema.
Let's verify the usage and potential impact:
✅ Verification successful
The schema change is safe and improves type consistency
The change from z.literal("like") to columnOperator is actually an improvement in the schema that maintains backward compatibility while providing better type safety. The columnOperator enum includes more specific operators (equals, regex, starts-with, ends-with, contains) that offer better functionality than the simple like operator. This change aligns with the operator patterns used across the codebase.
Key findings:
- The
columnOperatorenum is well-defined inconditions/index.tswith clear, specific operators - The change provides better type safety through the enum
- No breaking changes found in the validation schema usage across the codebase
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Search for usages of nameCondition to identify potential breaking changes
# Find direct references to nameCondition
echo "=== Direct references to nameCondition ==="
rg -l "nameCondition" --type ts
# Find potential validation calls that might be affected
echo -e "\n=== Validation calls that might use this schema ==="
rg -A 3 "\.parse\(|\.parseAsync\(|\.safeParse\(" --type ts
# Look for test files that might need updates
echo -e "\n=== Test files that might need updates ==="
fd "test|spec" -e ts -e tsx | rg -l "name.*condition"
Length of output: 12486
Script:
#!/bin/bash
# Let's examine the specific schema changes and their usage
# Check the content of name-condition.ts to understand the schema change
echo "=== Content of name-condition.ts ==="
cat packages/validators/src/resources/conditions/name-condition.ts
# Check how nameCondition is used in resource-condition.ts
echo -e "\n=== Content of resource-condition.ts ==="
cat packages/validators/src/resources/conditions/resource-condition.ts
# Check how nameCondition is used in comparison-condition.ts
echo -e "\n=== Content of comparison-condition.ts ==="
cat packages/validators/src/resources/conditions/comparison-condition.ts
# Look for any tests that might validate the schema
echo -e "\n=== Test files containing nameCondition ==="
fd "test|spec" -e ts -e tsx | xargs rg "nameCondition"
Length of output: 5989
Script:
#!/bin/bash
# Let's check the columnOperator definition and its previous usage
# Check the content of conditions/index.js to see columnOperator definition
echo "=== Content of conditions/index.js ==="
cat packages/validators/src/conditions/index.js
# Also check for .ts extension
echo -e "\n=== Content of conditions/index.ts ==="
cat packages/validators/src/conditions/index.ts
# Search for any previous versions or references to 'like' operator
echo -e "\n=== References to 'like' operator ==="
rg -A 2 "\"like\"" --type ts
Length of output: 2440
apps/webservice/src/app/[workspaceSlug]/(app)/_components/target-condition/NameConditionRender.tsx (3)
1-5: LGTM! Clean and well-organized imports
The imports are properly structured and include all necessary types and components.
7-9: LGTM! Well-typed component definition
The component follows React best practices with proper TypeScript typing using generics.
10-12: Verify supported operator types
The handlers look clean and maintain immutability. Since this is part of a larger change replacing "like" conditions, let's verify the supported operators.
✅ Verification successful
Based on the gathered information, I can now provide the final response:
Handler functions are correctly implemented and operators are properly supported
The handlers maintain immutability and delegate to ColumnConditionRender which supports all the necessary operators:
- equals
- contains
- starts-with
- ends-with
- regex
The implementation correctly uses the typed ColumnOperatorType from validators package and provides a proper UI for operator selection.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the operator types being used with this component
# Look for ColumnOperator enum definition and its usage
# Find the ColumnOperator enum definition
echo "Looking for ColumnOperator definition:"
rg -A 10 "enum ColumnOperator"
# Find usage patterns of operators with this component
echo "\nLooking for NameConditionRender usage with operators:"
rg -A 5 "NameConditionRender.*operator="
Length of output: 1046
Script:
#!/bin/bash
# Let's look for usage patterns of this component and its operators more broadly
# Find the component definition and its props
echo "Looking for NameConditionRender component definition:"
rg -B 5 -A 15 "NameConditionRender.*=.*"
# Find where this component is used
echo "\nLooking for NameConditionRender usage:"
rg -B 2 -A 2 "<NameConditionRender"
# Look for imports of ColumnOperator
echo "\nLooking for ColumnOperator imports and usage:"
rg "ColumnOperator.*from.*validators"
Length of output: 2784
Script:
#!/bin/bash
# Let's examine the NameConditionRender component implementation and its operator usage
# Look at the NameConditionRender component implementation
echo "NameConditionRender component implementation:"
cat "apps/webservice/src/app/[workspaceSlug]/(app)/_components/target-condition/NameConditionRender.tsx"
# Look for operator selection UI components that might be used
echo "\nLooking for operator selection components:"
rg -A 10 "Select.*operator"
Length of output: 9222
Script:
#!/bin/bash
# Let's examine the ColumnConditionRender component since NameConditionRender delegates to it
echo "Looking at ColumnConditionRender implementation:"
cat "apps/webservice/src/app/[workspaceSlug]/(app)/_components/filter/ColumnConditionRender.tsx"
# Also check for any type definitions of NameCondition
echo "\nLooking for NameCondition type definition:"
rg -A 5 "type.*NameCondition.*="
Length of output: 2595
packages/validators/src/conditions/index.ts (1)
14-14: Great improvement in validation approach!
The switch to z.nativeEnum(ColumnOperator) is a more maintainable and efficient approach compared to manual literal unions. It automatically stays in sync with enum changes and provides better type inference.
apps/webservice/src/app/[workspaceSlug]/(app)/_components/filter/ColumnConditionRender.tsx (1)
43-47: Verify consistent operator usage across the application.
Since this change removes the Like operator in favor of more specific operators, we should ensure consistency across the codebase.
✅ Verification successful
Changes are consistent and properly implemented across the codebase
The verification shows that:
- The ColumnOperator enum is properly defined with Contains, StartsWith, and EndsWith operators
- Backend implementation in schema files correctly handles all operators using SQL ILIKE with appropriate wildcards
- Frontend components consistently use these operators in filters, badges, and condition renders
- No instances of the old "Like" operator were found
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for any remaining uses of ColumnOperator.Like
rg -l "ColumnOperator\.Like"
# Check for proper adoption of new operators
rg -l "ColumnOperator\.(Contains|StartsWith|EndsWith)"
# Look for potential missed SQL/query updates
rg -l "LIKE\s+['\"]%.*%['\"]"
Length of output: 900
Script:
#!/bin/bash
# Let's check the actual implementation of these operators in schema files
rg -A 5 "ColumnOperator\.(Contains|StartsWith|EndsWith)" packages/db/src/schema/
# Check the actual usage in components to ensure consistent patterns
rg -A 5 "ColumnOperator\.(Contains|StartsWith|EndsWith)" apps/webservice/src/app/
# Look for any enum definition of ColumnOperator to verify the complete set of operators
ast-grep --pattern 'enum ColumnOperator {
$$$
}'
Length of output: 10321
apps/webservice/src/app/[workspaceSlug]/(app)/_components/SearchDialog.tsx (2)
18-18: LGTM! Clean import addition
The import of ColumnOperator enum follows TypeScript best practices and improves type safety.
44-45: LGTM! Good migration to enum-based operator
The change from string literal to ColumnOperator.Contains improves type safety and maintainability. Let's verify that all "like" operators have been consistently replaced across the codebase.
✅ Verification successful
Based on the comprehensive search results, I can now provide a final response:
Migration to ColumnOperator.Contains is consistent across the codebase
The search results confirm that:
- All string-based search operations use
ColumnOperator.Containsconsistently - The old string literal "like" only appears in enum definitions and validators, not in actual operator usage
- The codebase follows a consistent pattern using the
ColumnOperatorenum for all column operations
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify that no string literals for "like" operator remain and all uses of ColumnOperator are consistent
# Check for any remaining "like" string literals in operator contexts
rg -i '"like".*operator'
# Check for consistent usage of ColumnOperator.Contains
ast-grep --pattern 'operator: ColumnOperator.$$$'
Length of output: 78
Script:
#!/bin/bash
# Let's try a more comprehensive search approach
# Search for any "like" string literals in the codebase
rg -i '"like"' -A 2 -B 2
# Search for all usages of ColumnOperator
rg "ColumnOperator\." -A 1 -B 1
# Search for operator assignments in general
rg "operator:\s*" -A 1 -B 1
Length of output: 67646
apps/webservice/src/app/[workspaceSlug]/(app)/systems/[systemSlug]/_components/variables/VariableResourceInput.tsx (2)
19-19: LGTM: Import of ColumnOperator
The addition of ColumnOperator import aligns with the PR objective to update the filtering mechanism.
78-79: Verify backend handling of Contains operator
The change from pattern matching to substring search looks good, but let's ensure the backend properly handles the ColumnOperator.Contains for resource filtering.
✅ Verification successful
Let me try another search strategy to verify the backend handling of the Contains operator.
Let me try one more search to find the implementation of the filtering logic.
Backend properly handles the Contains operator
The backend implementation correctly handles the ColumnOperator.Contains operator. The search is implemented using SQL's ILIKE operator with wildcards (%) on both sides of the search value, which is the correct way to perform case-insensitive substring matching. This is evidenced in multiple schema files:
packages/db/src/schema/resource.tsimplements it for both resource name and identifier- The implementation uses
ilike(resource.name, '%${cond.value}%')which is the proper SQL pattern for substring matching
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify backend implementation of Contains operator
# Look for resource filtering implementation and operator handling
# Check resource-related files for operator handling
echo "Checking resource filtering implementation..."
rg -t typescript -t javascript "ColumnOperator.Contains" -A 5
# Check database query construction
echo "Checking database query construction..."
ast-grep --pattern 'function $_($$_) {
$$$
ColumnOperator.Contains
$$$
}'
Length of output: 368
Script:
#!/bin/bash
# Search for ColumnOperator enum definition and its usage
echo "Searching for ColumnOperator enum definition..."
rg -g "*.{ts,tsx}" "enum ColumnOperator" -A 10
echo "Searching for Contains operator usage in filtering logic..."
rg -g "*.{ts,tsx}" "Contains.*operator" -B 2 -A 2
# Look for database query or filtering implementation
echo "Checking filtering implementation..."
rg -g "*.{ts,tsx}" "filter.*operator" -B 2 -A 5
Length of output: 1230
Script:
#!/bin/bash
# Search for filtering implementation in backend code
echo "Searching for condition handling in backend..."
rg -g "*.{ts,tsx}" "operator.*contains" -i -B 3 -A 3
echo "Looking for database query construction..."
rg -g "*.{ts,tsx}" "case.*contains" -i -B 2 -A 3
# Search for resource filtering implementation
echo "Checking resource filtering implementation..."
ast-grep --pattern 'switch ($operator) {
$$$
case ColumnOperator.Contains:
$$$
}'
Length of output: 11051
apps/webservice/src/app/[workspaceSlug]/(app)/_components/job-condition/JobTargetConditionRender.tsx (2)
20-24: LGTM: Import changes align with the operator transition.
The addition of ColumnOperator import is consistent with the PR's objective of updating the filtering mechanism.
50-51: LGTM: Search filter changes improve semantic clarity.
The transition to ColumnOperator.Contains with direct value usage is more semantically accurate for text search implementation.
Let's verify consistent operator usage across the codebase:
✅ Verification successful
The previous results show consistent usage of ColumnOperator.Contains across the UI components, but we need to verify how these operators are translated into database queries to ensure correct implementation.
Based on the analysis of the schema files and API routes, I can now provide a definitive response about the search filter changes:
Search filter changes are correctly implemented and safe to use
The codebase consistently handles ColumnOperator.Contains by translating it to SQL ILIKE with proper wildcards:
- In
resource.ts:ilike(resource.identifier, \%${cond.value}%`)` - In
release.ts:ilike(release.version, \%${cond.value}%`)` - In
job.ts: Similar pattern for name and identifier searches
The operator change from Like to Contains is properly supported by the database layer and consistently implemented across all relevant schema files.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any remaining instances of LIKE operators and verify consistent Contains usage
# Check for any remaining LIKE operators
echo "Checking for remaining LIKE operators..."
rg -i "like.*operator"
# Check for consistent Contains operator usage
echo "Checking Contains operator usage..."
rg "ColumnOperator\.Contains"
# Check for potential SQL query handlers
echo "Checking query handlers..."
fd -e ts -e tsx -x rg -l "sql.*where|query.*where" {}
Length of output: 1871
Script:
#!/bin/bash
# Let's check the database query handlers to verify how Contains operator is processed
# Check implementation in schema files
echo "Checking schema implementations for Contains operator..."
cat packages/db/src/schema/{resource,release,job}.ts
# Check SQL query construction in API routes
echo "Checking API routes for query handling..."
cat packages/api/src/router/{deployment,resources,team}.ts
Length of output: 75187
apps/webservice/src/app/[workspaceSlug]/(app)/_components/release-condition/ReleaseConditionBadge.tsx (1)
21-21: LGTM! Import statement is correctly updated.
The addition of ColumnOperator import aligns with the PR objective of using structured operators instead of string literals.
apps/webservice/src/app/[workspaceSlug]/(app)/_components/target-condition/TargetConditionBadge.tsx (2)
20-20: LGTM: Type-safe operator import
The addition of ColumnOperator import supports the transition from string literals to structured operators, improving type safety.
44-46: LGTM: Enhanced operator granularity
The new operators (StartsWith, EndsWith, Contains) provide more specific filtering capabilities compared to the generic "like" operator, improving the clarity and flexibility of condition expressions.
Let's verify that the "like" operator has been completely replaced throughout the codebase:
✅ Verification successful
Verified: "like" operator successfully replaced with granular alternatives
The ColumnOperator enum definition in packages/validators/src/conditions/index.ts confirms that:
- The "like" operator has been completely removed
- It's been replaced with the three new operators: StartsWith, EndsWith, and Contains
- No legacy references to the "like" operator remain in the codebase
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any remaining usage of the "like" operator
# Expected: No occurrences of ColumnOperator.Like or string literal "like" in conditions
# Search for ColumnOperator.Like
echo "Checking for ColumnOperator.Like usage:"
rg "ColumnOperator\.Like" -g '!{*.test.*,*.spec.*}'
# Search for "like" string literal in condition contexts
echo -e "\nChecking for 'like' string literals in condition contexts:"
rg '"like".*operator' -g '!{*.test.*,*.spec.*}'
Length of output: 331
Script:
#!/bin/bash
# Let's try a broader search to ensure we catch all potential references to "like" operator
# and also verify the enum definition
# Check for any "like" references in TypeScript/JavaScript files
echo "Checking for 'like' keyword in TS/JS files:"
rg -i "like" --type ts --type tsx -C 2
# Find and check the ColumnOperator enum definition
echo -e "\nChecking ColumnOperator enum definition:"
ast-grep --pattern 'enum ColumnOperator {
$$$
}'
# Check for any migration files that might handle the operator change
echo -e "\nChecking for relevant migration files:"
fd -e sql -e ts -e js migration
Length of output: 923
packages/db/src/schema/release.ts (1)
14-14: Verify if the like import is still needed
The like import might be redundant since the code now uses ilike for pattern matching.
✅ Verification successful
Keep the like import as it's actively used in the codebase
The like function is actively used in multiple files for pattern matching:
packages/db/src/schema/release.ts: Used in metadata value matchingpackages/db/src/schema/resource.ts: Used in resource metadata matchingpackages/db/src/schema/job.ts: Used in job metadata matchingpackages/api/src/router/system.ts: Used for name and slug filtering
Both like and ilike operators serve different purposes in the codebase, with like being used for case-sensitive pattern matching and ilike for case-insensitive matching.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any remaining usage of the `like` function
rg '\blike\(' --type ts
Length of output: 460
Script:
#!/bin/bash
# Get more context around the usage of 'like' function to understand if it's intentionally kept
rg '\blike\(' --type ts -B 2 -A 2
Length of output: 1685
apps/webservice/src/app/[workspaceSlug]/(app)/_components/job-condition/JobConditionBadge.tsx (2)
27-27: LGTM! Import of ColumnOperator is well-placed.
The addition of ColumnOperator import aligns with the PR objective of moving from string literals to structured operators.
Line range hint 1-300: LGTM! Well-structured component hierarchy.
The component maintains a clean and consistent structure while incorporating the new column operators. Each condition type is handled separately with proper type checking, making the code maintainable and extensible.
packages/db/src/schema/resource.ts (3)
4-4: LGTM: Import changes align with the new case-insensitive search functionality
The addition of ilike and NameCondition imports supports the enhanced filtering capabilities while making searches more user-friendly through case-insensitive matching.
Also applies to: 8-17
252-252: LGTM: Build condition update is correct
The update to use buildNameCondition is consistent with the function's pattern and maintains the existing logic structure.
225-252: Verify the migration from Like operator across the codebase
Let's ensure all components have been updated to use the new operators and there are no remaining uses of the Like operator for resources.
✅ Verification successful
Based on the comprehensive search results, I can now provide a final response:
Migration from Like operator is complete and consistent
The codebase shows a complete and consistent implementation of string matching operations:
- The
ColumnOperatorenum inpackages/validators/src/conditions/index.tsdefines the new operators:Equals,StartsWith,EndsWith,Contains, andRegex - The implementation in
resource.tscorrectly usesilikewith appropriate pattern matching for each operator:StartsWith->ilike(field, ${value}%)EndsWith->ilike(field, %${value})Contains->ilike(field, %${value}%)- Regex -> SQL regex operator
~
No instances of the old Like operator were found in resource filtering operations, confirming a complete migration.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any remaining uses of the Like operator in resource filtering
# Search for Like operator usage in TypeScript/JavaScript files
echo "Checking for Like operator usage in resource filtering..."
rg -t ts -t js "ColumnOperator\.Like.*resource" -A 5 -B 5
# Search for direct SQL LIKE queries related to resources
echo "Checking for direct SQL LIKE queries..."
rg -t ts -t js "LIKE.*resource\." -A 5 -B 5
Length of output: 319
Script:
#!/bin/bash
# Let's try a more comprehensive search strategy
# 1. First, let's understand what operators are defined in ColumnOperator enum
echo "Checking ColumnOperator enum definition..."
ast-grep --pattern 'enum ColumnOperator {
$$$
}'
# 2. Let's search for any LIKE/ILIKE SQL operations
echo "Checking SQL LIKE/ILIKE operations..."
rg -t ts -t js "(LIKE|ILIKE|like|ilike)" -A 3 -B 3
# 3. Let's find all resource filtering conditions
echo "Checking resource filtering conditions..."
rg -t ts -t js "ResourceFilterType|ResourceCondition" -A 3 -B 3
# 4. Let's specifically look at the resource schema file
echo "Checking resource schema file..."
fd "resource.ts" --exec cat {}
Length of output: 105213
apps/webservice/src/app/[workspaceSlug]/(app)/_components/target-condition/ComparisonConditionRender.tsx (1)
302-302: LGTM! Good choice of operator for Identifier
Using ColumnOperator.Equals for identifier matching is appropriate since identifiers typically require exact matches.
packages/db/src/schema/job.ts (2)
14-14: Importing ilike for case-insensitive matching
The addition of ilike from drizzle-orm is appropriate and necessary for implementing case-insensitive pattern matching in the buildVersionCondition function.
212-220: Enhanced version condition handling with ilike
The updated buildVersionCondition function now handles operators like Equals, StartsWith, EndsWith, and Contains using ilike for case-insensitive matching. This improves the flexibility and accuracy of version filtering.
| StartsWith = "starts-with", | ||
| EndsWith = "ends-with", | ||
| Contains = "contains", |
There was a problem hiding this comment.
💡 Codebase verification
Based on the results, I can now generate the final response:
Migration from Like to new string operators needs attention
The verification reveals several files still using the "like" operator that need to be updated:
packages/validators/src/resources/conditions/resource-condition.tspackages/validators/src/releases/conditions/release-condition.tspackages/validators/src/conditions/metadata-condition.ts
The new operators (StartsWith, EndsWith, Contains) are properly referenced in the UI components and database schema, but the validator conditions still use the old Like operator.
🔗 Analysis chain
Improved string matching granularity, but verify migration and naming.
The change from a generic Like operator to specific string matching operators (StartsWith, EndsWith, Contains) provides better control and clarity. However, this is a breaking change that requires careful migration.
Let's verify all usages have been updated:
Consider using consistent casing for enum values:
export enum ColumnOperator {
Equals = "equals",
Regex = "regex",
- StartsWith = "starts-with",
- EndsWith = "ends-with",
- Contains = "contains",
+ StartsWith = "startsWith",
+ EndsWith = "endsWith",
+ Contains = "contains",
}🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any remaining uses of the old "like" operator
rg -i "\"like\"" --type ts
# Search for uses of the new operators to ensure proper adoption
rg -i "\"(starts-with|ends-with|contains)\"" --type ts
# Search for ColumnOperator usage to verify migration
ast-grep --pattern 'ColumnOperator.$_'
Length of output: 39934
| : operator === ColumnOperator.Like | ||
| ? "%value%" | ||
| : "Value" | ||
| operator === ColumnOperator.Regex ? "^[a-zA-Z]+$" : "Value" |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider enhancing regex input validation and guidance.
While the regex placeholder is helpful, consider these improvements for better user experience:
- Add real-time validation for regex patterns
- Use a more generic regex example that demonstrates common use cases
- Provide visual feedback for invalid patterns
Here's a suggested implementation:
- placeholder={operator === ColumnOperator.Regex ? "^[a-zA-Z]+$" : "Value"}
+ placeholder={operator === ColumnOperator.Regex ? "e.g., ^user-\\d+$" : "Value"}
+ pattern={operator === ColumnOperator.Regex ? ".*" : undefined}
+ onInvalid={operator === ColumnOperator.Regex ? (e) => {
+ e.target.setCustomValidity("Invalid regex pattern")
+ } : undefined}Committable suggestion skipped: line range outside the PR's diff.
| [ColumnOperator.StartsWith]: "starts with", | ||
| [ColumnOperator.EndsWith]: "ends with", | ||
| [ColumnOperator.Contains]: "contains", |
There was a problem hiding this comment.
💡 Codebase verification
Found remaining "like" operator usages that need migration
The verification revealed that the "like" operator is still present in several validator files:
packages/validators/src/releases/conditions/release-condition.tspackages/validators/src/resources/conditions/resource-condition.tspackages/validators/src/conditions/metadata-condition.ts
These files still define and use the "like" operator, which should be migrated to the new specific operators (startsWith, endsWith, contains) for consistency with the UI changes.
🔗 Analysis chain
Verify complete migration from "like" operator.
Let's ensure all usages of the old "like" operator have been properly migrated to the new column operators.
Let me try a different search strategy to find any remaining usages of the "like" operator in the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any remaining "like" string literals in TypeScript/JavaScript files
# that might indicate missed migrations
rg -t ts -t tsx -t js "['\"](like|LIKE)['\"]" -g '!{*.test.*,*.spec.*}'
# Search for ColumnOperator.Like usage that should have been migrated
ast-grep --pattern 'ColumnOperator.Like'
Length of output: 31028
Script:
#!/bin/bash
# Search for ColumnOperator enum definition and its usages
ast-grep --pattern 'enum ColumnOperator'
# Search for any remaining "like" string literals specifically in the context of operators
rg -t ts -t js "operator.*like" -g '!{*.test.*,*.spec.*}'
# Search for any comparison with "like" in TypeScript/JavaScript files
rg -t ts -t js "=.*['\"]like['\"]" -g '!{*.test.*,*.spec.*}'
Length of output: 497
| [ColumnOperator.StartsWith]: "starts with", | ||
| [ColumnOperator.EndsWith]: "ends with", | ||
| [ColumnOperator.Contains]: "contains", |
There was a problem hiding this comment.
💡 Codebase verification
Based on the codebase analysis, I can now generate the final response:
Remove MetadataOperator.Like and consolidate with ColumnOperator.Contains
The codebase shows that MetadataOperator.Like and ColumnOperator.Contains serve the same purpose, with Contains being the newer, more specific operator. The Like operator is still being used in several places:
- Database schema files (
job.ts,release.ts,resource.ts) - Metadata condition validators
- UI components for condition rendering
Please:
- Remove
MetadataOperator.Likefrom the metadata-condition.ts enum - Update database schema files to use
Containsinstead ofLike - Update UI components to remove the
Likeoption from metadata condition selectors
🔗 Analysis chain
Verify removal of MetadataOperator.Like.
While the new ColumnOperator entries are good additions, there seems to be an overlap between MetadataOperator.Like and ColumnOperator.Contains - both mapping to "contains". According to the PR objective, we should remove the "like" condition.
Let's verify the usage of MetadataOperator.Like in the codebase:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if MetadataOperator.Like is still being used elsewhere in the codebase
# Search for MetadataOperator.Like usage
echo "Searching for MetadataOperator.Like usage..."
rg "MetadataOperator\.Like"
# Search for potential string literal "like" in conditions
echo "Searching for 'like' string literals in condition files..."
rg -g "**/condition*.{ts,tsx}" '"like"'
Length of output: 1366
Script:
#!/bin/bash
# Let's check the implementation details of MetadataOperator and ColumnOperator
# First, let's find the enum definitions
echo "=== Searching for MetadataOperator definition ==="
ast-grep --pattern 'enum MetadataOperator {
$$$
}'
echo -e "\n=== Searching for ColumnOperator definition ==="
ast-grep --pattern 'enum ColumnOperator {
$$$
}'
# Let's also check if there are any direct usages of these operators in condition-related files
echo -e "\n=== Checking condition files for operator usage ==="
fd "condition.*\.(ts|tsx)$" --exec cat {}
Length of output: 135584
| @@ -288,7 +288,7 @@ export const ComparisonConditionRender: React.FC< | |||
| onClick={() => | |||
| addCondition({ | |||
| type: ResourceFilterType.Name, | |||
| operator: ResourceOperator.Like, | |||
| operator: ColumnOperator.Equals, | |||
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider using Contains instead of Equals for Name filtering
Using ColumnOperator.Equals for name matching might be too restrictive for users. Names often require partial matches for better usability.
Consider using ColumnOperator.Contains instead:
- operator: ColumnOperator.Equals,
+ operator: ColumnOperator.Contains,This would allow users to find resources by partial name matches, which is a common use case in resource filtering.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| operator: ColumnOperator.Equals, | |
| operator: ColumnOperator.Contains, |
Summary by CodeRabbit
Release Notes
New Features
Contains,StartsWith, andEndsWith.Bug Fixes
Documentation
These updates improve the overall search and filtering capabilities, providing users with a more intuitive and powerful experience.