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

fix: object single index mapping #127

Merged
merged 1 commit into from
Jan 20, 2025
Merged

fix: object single index mapping #127

merged 1 commit into from
Jan 20, 2025

Conversation

koladilip
Copy link
Collaborator

@koladilip koladilip commented Jan 20, 2025

What are the changes introduced in this PR?

when path $.a["b"] used in the output mapping is not working as expected.

What is the related Linear task?

Resolves INT-3049

Please explain the objectives of your changes below

Put down any required details on the broader aspect of your changes. If there are any dependent changes, mandatorily mention them here

Any changes to existing capabilities/behaviour, mention the reason & what are the changes ?

N/A

Any new dependencies introduced with this change?

N/A

Any new generic utility introduced or modified. Please explain the changes.

N/A

Any technical or performance related pointers to consider with the change?

N/A

@coderabbitai review


Developer checklist

  • My code follows the style guidelines of this project

  • No breaking changes are being introduced.

  • All related docs linked with the PR?

  • All changes manually tested?

  • Any documentation changes needed with this change?

  • Is the PR limited to 10 file changes?

  • Is the PR limited to one linear task?

  • Are relevant unit and component test-cases added?

Reviewer checklist

  • Is the type of change in the PR title appropriate as per the changes?

  • Verified that there are no credentials or confidential data exposed with the changes.

Summary by CodeRabbit

Release Notes

  • New Features

    • Enhanced expression parsing capabilities for array and selector expressions
    • Added support for a new PathExpression type for more flexible path handling
  • Improvements

    • Refined type definitions for expressions, including updates to the SelectorExpression
    • Updated parsing logic to support more complex data access patterns
  • Test Updates

    • Updated test scenarios to reflect new parsing and mapping behaviors
    • Modified test data to validate new expression handling and output structures

@koladilip koladilip requested a review from a team as a code owner January 20, 2025 10:28
Copy link

coderabbitai bot commented Jan 20, 2025

Walkthrough

This pull request introduces modifications to the JSON template parsing system, focusing on enhancing the handling of array filters and path expressions. The changes primarily affect the JsonTemplateParser class in src/parser.ts, introducing a new method handleArrayFilterExpr and updating the parseArrayFilterExpr method. Additionally, a new PathExpression interface is added to src/types.ts, and some test scenarios are updated to reflect the new parsing behavior. The modifications aim to provide more flexible expression parsing and improve the syntax for accessing object properties.

Changes

File Change Summary
src/parser.ts - Updated parseArrayFilterExpr method to return additional expression types
- Added new handleArrayFilterExpr method for processing array filters
src/types.ts - Introduced new PathExpression interface with multiple properties
- Modified SelectorExpression to exclude range from prop property
test/scenarios/mappings/object_mappings.json - Changed output path from dot notation to bracket notation
test/scenarios/paths/data.ts - Modified output array for simple_path.jt scenario
test/scenarios/paths/simple_path.jt - Updated property access syntax from dot notation to bracket notation

Sequence Diagram

sequenceDiagram
    participant Parser as JsonTemplateParser
    participant Handler as handleArrayFilterExpr
    participant Expressions as Expressions

    Parser->>Handler: Parse array filter
    Handler-->>Expressions: Determine expression type
    alt Is single element array index
        Handler->>Expressions: Create SelectorExpression
    else Standard array filter
        Handler->>Expressions: Create ArrayFilterExpression
    end
    Expressions-->>Parser: Return appropriate expression
Loading

Possibly related PRs

Poem

🐰 Parsing paths with rabbit might,
Brackets dance, expressions take flight!
Array filters now more clear,
Code refactored without fear,
JSON templates shine so bright! 🔍


📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between f56c361 and 1cbc1db.

⛔ Files ignored due to path filters (1)
  • package-lock.json is excluded by !**/package-lock.json
📒 Files selected for processing (5)
  • src/parser.ts (1 hunks)
  • src/types.ts (2 hunks)
  • test/scenarios/mappings/object_mappings.json (1 hunks)
  • test/scenarios/paths/data.ts (1 hunks)
  • test/scenarios/paths/simple_path.jt (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (3)
  • test/scenarios/paths/simple_path.jt
  • test/scenarios/mappings/object_mappings.json
  • test/scenarios/paths/data.ts
🧰 Additional context used
🪛 GitHub Check: Coverage annotations (🧪 jest-coverage-report-action)
src/parser.ts

[warning] 634-634: 🧾 Statement is not covered
Warning! Not covered statement


[warning] 635-635: 🧾 Statement is not covered
Warning! Not covered statement


[warning] 636-636: 🧾 Statement is not covered
Warning! Not covered statement


[warning] 637-637: 🧾 Statement is not covered
Warning! Not covered statement


[warning] 638-638: 🧾 Statement is not covered
Warning! Not covered statement


[warning] 639-639: 🧾 Statement is not covered
Warning! Not covered statement


[warning] 633-639: 🌿 Branch is not covered
Warning! Not covered branch

🔇 Additional comments (6)
src/types.ts (2)

Line range hint 223-229: LGTM! Well-structured interface definition.

The new PathExpression interface is well-designed with clear property definitions that support the path mapping functionality.


240-241: LGTM! Good type refinement.

Removing the range property from the prop type is a good optimization as selector expressions don't need position information.

src/parser.ts (4)

625-643: LGTM! Clean implementation of array filter handling.

The method effectively handles the conversion between array filters and selector expressions, which aligns with the PR objective of fixing object single index mapping.

🧰 Tools
🪛 GitHub Check: Coverage annotations (🧪 jest-coverage-report-action)

[warning] 634-634: 🧾 Statement is not covered
Warning! Not covered statement


[warning] 635-635: 🧾 Statement is not covered
Warning! Not covered statement


[warning] 636-636: 🧾 Statement is not covered
Warning! Not covered statement


[warning] 637-637: 🧾 Statement is not covered
Warning! Not covered statement


[warning] 638-638: 🧾 Statement is not covered
Warning! Not covered statement


[warning] 639-639: 🧾 Statement is not covered
Warning! Not covered statement


[warning] 633-639: 🌿 Branch is not covered
Warning! Not covered branch


645-648: LGTM! Appropriate signature update.

The return type has been correctly updated to include SelectorExpression, reflecting the new array filter handling functionality.


650-657: LGTM! Clean integration of new functionality.

The implementation properly integrates the new array filter handling while maintaining existing error handling and filter types.


633-639: Add test coverage for selector expression conversion.

The code path for converting array filters to selector expressions is not covered by tests. Please add test cases to ensure this critical functionality works as expected.

Run the following script to verify current test coverage:

🧰 Tools
🪛 GitHub Check: Coverage annotations (🧪 jest-coverage-report-action)

[warning] 634-634: 🧾 Statement is not covered
Warning! Not covered statement


[warning] 635-635: 🧾 Statement is not covered
Warning! Not covered statement


[warning] 636-636: 🧾 Statement is not covered
Warning! Not covered statement


[warning] 637-637: 🧾 Statement is not covered
Warning! Not covered statement


[warning] 638-638: 🧾 Statement is not covered
Warning! Not covered statement


[warning] 639-639: 🧾 Statement is not covered
Warning! Not covered statement


[warning] 633-639: 🌿 Branch is not covered
Warning! Not covered branch

✨ Finishing Touches
  • 📝 Generate Docstrings (Beta)

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?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

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)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR. (Beta)
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link
Contributor

github-actions bot commented Jan 20, 2025

Coverage report

St.
Category Percentage Covered / Total
🟢 Statements
91.63% (-8.25% 🔻)
4743/5176
🟢 Branches
89.46% (-10.47% 🔻)
1129/1262
🟢 Functions 100% 386/386
🟢 Lines
91.63% (-8.25% 🔻)
4743/5176
Show files with reduced coverage 🔻
St.
File Statements Branches Functions Lines
🟢 engine.ts
95.33% (-4.67% 🔻)
88.46% (-11.54% 🔻)
100%
95.33% (-4.67% 🔻)
🟢 lexer.ts
86.22% (-13.78% 🔻)
90.78% (-9.22% 🔻)
100%
86.22% (-13.78% 🔻)
🟢 parser.ts
86.83% (-13.17% 🔻)
87.18% (-12.82% 🔻)
100%
86.83% (-13.17% 🔻)
🟢 reverse_translator.ts
90.08% (-9.92% 🔻)
82.58% (-17.42% 🔻)
100%
90.08% (-9.92% 🔻)
🟢 utils/common.ts 100%
88.89% (-11.11% 🔻)
100% 100%
🟢 utils/converter.ts
89.72% (-9.07% 🔻)
82.05% (-17.21% 🔻)
100%
89.72% (-9.07% 🔻)

Test suite run success

217 tests passing in 7 suites.

Report generated by 🧪jest coverage report action from 1cbc1db

@github-advanced-security
Copy link

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 0

🧹 Nitpick comments (1)
test/scenarios/mappings/object_mappings.json (1)

24-24: Consider standardizing the notation style.

There's an inconsistency in the notation style:

  • Line 24 uses bracket notation: $.properties3['custom']
  • Line 29 uses dot notation: $.properties3.custom.foo

While both notations are valid, maintaining a consistent style throughout the mappings would improve readability and maintainability.

Also applies to: 28-29

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 1aa57fe and f56c361.

⛔ Files ignored due to path filters (1)
  • package-lock.json is excluded by !**/package-lock.json
📒 Files selected for processing (5)
  • src/parser.ts (1 hunks)
  • src/types.ts (2 hunks)
  • test/scenarios/mappings/object_mappings.json (1 hunks)
  • test/scenarios/paths/data.ts (1 hunks)
  • test/scenarios/paths/simple_path.jt (1 hunks)
✅ Files skipped from review due to trivial changes (1)
  • test/scenarios/paths/simple_path.jt
🧰 Additional context used
🪛 GitHub Check: Coverage annotations (🧪 jest-coverage-report-action)
src/parser.ts

[warning] 637-637: 🧾 Statement is not covered
Warning! Not covered statement


[warning] 638-638: 🧾 Statement is not covered
Warning! Not covered statement


[warning] 639-639: 🧾 Statement is not covered
Warning! Not covered statement


[warning] 640-640: 🧾 Statement is not covered
Warning! Not covered statement


[warning] 641-641: 🧾 Statement is not covered
Warning! Not covered statement


[warning] 642-642: 🧾 Statement is not covered
Warning! Not covered statement


[warning] 643-643: 🧾 Statement is not covered
Warning! Not covered statement


[warning] 644-644: 🧾 Statement is not covered
Warning! Not covered statement


[warning] 645-645: 🧾 Statement is not covered
Warning! Not covered statement


[warning] 636-645: 🌿 Branch is not covered
Warning! Not covered branch

⏰ Context from checks skipped due to timeout of 90000ms (2)
  • GitHub Check: Check for formatting & lint errors
  • GitHub Check: Run Tests
🔇 Additional comments (6)
src/parser.ts (2)

625-650: Add unit tests for the new handleArrayFilterExpr method

The newly introduced handleArrayFilterExpr method is not covered by unit tests, especially the code path where a SelectorExpression is returned when the filter is a string literal (lines 637-645). Adding tests for these scenarios will ensure the method behaves correctly and prevent future regressions.

Would you like me to help create unit tests to cover these cases or open a new issue to track this task?

🧰 Tools
🪛 GitHub Check: Coverage annotations (🧪 jest-coverage-report-action)

[warning] 637-637: 🧾 Statement is not covered
Warning! Not covered statement


[warning] 638-638: 🧾 Statement is not covered
Warning! Not covered statement


[warning] 639-639: 🧾 Statement is not covered
Warning! Not covered statement


[warning] 640-640: 🧾 Statement is not covered
Warning! Not covered statement


[warning] 641-641: 🧾 Statement is not covered
Warning! Not covered statement


[warning] 642-642: 🧾 Statement is not covered
Warning! Not covered statement


[warning] 643-643: 🧾 Statement is not covered
Warning! Not covered statement


[warning] 644-644: 🧾 Statement is not covered
Warning! Not covered statement


[warning] 645-645: 🧾 Statement is not covered
Warning! Not covered statement


[warning] 636-645: 🌿 Branch is not covered
Warning! Not covered branch


652-663: Ensure all usages can handle the new SelectorExpression return type

The parseArrayFilterExpr method now returns a SelectorExpression in addition to ArrayFilterExpression and ObjectFilterExpression. Please verify that all places where parseArrayFilterExpr is called can handle the new return type without causing any runtime errors or unexpected behavior.

If necessary, update downstream code to handle the SelectorExpression and consider adding unit tests to cover these new scenarios.

test/scenarios/paths/data.ts (1)

191-191: Validate the updated test output for simple_path.jt

The output array for the simple_path.jt template has been modified to [1, 1, [4], 2, 1]. Please verify that this change accurately reflects the expected behavior of the template after your updates. If this change is intentional, ensure that it aligns with the modifications in the parsing logic and update any related documentation or comments accordingly.

src/types.ts (2)

Line range hint 223-228: Verify integration of the new PathExpression interface

A new PathExpression interface has been added to define the structure of path expressions. Please ensure that all relevant parts of the codebase are updated to utilize this interface where appropriate, and that there are no inconsistencies or missed updates that could lead to type errors or unexpected behavior.


240-240: Check for impacts due to change in prop type in SelectorExpression

The prop property in SelectorExpression has been modified to Omit<Token, 'range'>, omitting the range property. Ensure that any code accessing prop does not rely on the range property and that this change does not introduce any issues in expression handling or parsing logic.

test/scenarios/mappings/object_mappings.json (1)

24-24: LGTM! The change aligns with the PR objective.

The modification from dot notation to bracket notation appears to be the intended fix for the object single index mapping issue mentioned in PR #127.

Let's verify consistency with other mapping files:

✅ Verification successful

The notation change is intentional and correct

The use of bracket notation ($.properties3['custom']) specifically addresses the object single index mapping issue, while dot notation remains appropriate for nested property access ($.properties3.custom.foo). This mixed notation pattern is intentional and doesn't require standardization across the codebase.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for similar property access patterns in other mapping files
# to ensure consistent notation style across the codebase

# Search for similar property access patterns in JSON files
rg -t json '"output":\s*".*\.(custom|properties\d+)"' 

# Search for bracket notation patterns
rg -t json '"output":\s*".*\[[\'\"].*[\'\"]"'

Length of output: 247


Script:

#!/bin/bash
# First, find all JSON mapping files
echo "=== JSON Mapping Files ==="
fd -e json -e JSON mapping

# Search for dot notation access patterns
echo -e "\n=== Dot Notation Patterns ==="
rg -t json '"output":\s*"\$\.[^"]*\.[^"]*"' -A 1

# Search for bracket notation access patterns
echo -e "\n=== Bracket Notation Patterns ==="
rg -t json '"output":\s*"\$\.[^"]*\[[\'\""][^\]]*[\'\""]\]"' -A 1

Length of output: 8300


Script:

#!/bin/bash
# Search for bracket notation patterns with proper escaping
echo "=== Bracket Notation Patterns ==="
rg -t json "output.*\[['\"].*['\"]" -A 1

# Also search specifically for the custom property pattern
echo -e "\n=== Custom Property Patterns ==="
rg -t json "custom" test/scenarios/mappings/object_mappings.json -A 1

Length of output: 594

Copy link

codecov bot commented Jan 20, 2025

Codecov Report

Attention: Patch coverage is 78.57143% with 6 lines in your changes missing coverage. Please review.

Project coverage is 91.63%. Comparing base (97d95e8) to head (1cbc1db).
Report is 63 commits behind head on main.

Files with missing lines Patch % Lines
src/parser.ts 76.92% 6 Missing ⚠️
Additional details and impacted files
@@             Coverage Diff             @@
##              main     #127      +/-   ##
===========================================
- Coverage   100.00%   91.63%   -8.37%     
===========================================
  Files           14       18       +4     
  Lines         4565     5176     +611     
  Branches      1082     1142      +60     
===========================================
+ Hits          4565     4743     +178     
- Misses           0      423     +423     
- Partials         0       10      +10     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@utsabc
Copy link
Member

utsabc commented Jan 20, 2025

Checked test cases mostly

@koladilip koladilip merged commit 55f3d53 into main Jan 20, 2025
17 checks passed
@koladilip koladilip deleted the fix/mapping-issues branch January 20, 2025 16:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants