-
Notifications
You must be signed in to change notification settings - Fork 301
[MCP]Fixed CLI bug in fields.primary-key updation when using update entity command.
#3077
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
base: main
Are you sure you want to change the base?
Conversation
|
/azp run |
|
Azure Pipelines will not run the associated pipelines, because the pull request was updated after the run command was issued. Review the pull request again and issue a new run command. |
|
/azp run |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
Fixes a CLI dab update behavior where updating field metadata (e.g., description) unintentionally reset existing primary-key flags when --fields.primary-key was not provided.
Changes:
- Preserve existing
FieldMetadata.PrimaryKeyvalues during field merges unless--fields.primary-keyis explicitly supplied. - Add a regression unit test ensuring a field’s
primary-keyflag remains unchanged when only updatingfields.description.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| src/Cli/ConfigGenerator.cs | Adjusts field merge logic to keep existing PrimaryKey unless the primary-key option was provided. |
| src/Cli.Tests/UpdateEntityTests.cs | Adds a regression test verifying primary-key is preserved when updating only field description. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
Azure Pipelines successfully started running 6 pipeline(s). |
JerryNixon
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider adding an additional test case for the inverse scenario: verify that when --fields.primary-key false IS explicitly provided, it correctly changes the flag from true to false
Why make this change?
When updating an entity with a command like:
dab update Incident --fields.name "Id" --fields.description "Unique Key", the existingprimary-keyflag on Id was being changed tofalseeven though noprimary-keyoption was specified.This change removes that surprise so primary-key metadata only changes when explicitly requested.
What is this change?
-Adds a regression test that:
fields.nameandfields.description.How was this tested?
primary-keyis preserved when only the field description is updated.Sample Request(s)
dab update Incident --fields.name "Id" --fields.description "Unique Key 2"Set Id as primary key:
dab update Incident --fields.name "Id" --fields.primary-key trueClear Id as primary key:
dab update Incident --fields.name "Id" --fields.primary-key false