Repository navigation
fix(sdk): leave deepCopy, isOwnAnchor, startsWith and ignoreCase to Egeria's defaults - #399
Merged
Merged
Conversation
TemplateRequestBody.deep_copy defaulted to False while Egeria's TemplateOptions defaults deepCopy to true. Every create-from-template body is validated through the model and serialised with exclude_none=True, so any caller that did not mention deepCopy sent "deepCopy": false and Egeria copied only the top-level element -- none of the template's anchored attachments. A data set created from a PostgreSQL template therefore had no connection and could not be read, provisioned or surveyed, with no error at the time. This affected the generic create_elem_from_template, every typed *_element_from_template creator in AutomatedCuration, and Dr.Egeria's Create Element / Create <Type> Element. - deep_copy now defaults to None, so an unset value is left out of the JSON and Egeria's own default applies. - Dr.Egeria's Create Element gains an optional Deep Copy attribute (Bool, default true) mapped to deepCopy, for the rare case where a shallow copy is wanted. Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com>
…faults A sweep of every request model's bool defaults against the Egeria bean it mirrors (following each Java class's extends chain) found three more that differed, besides deepCopy: - NewOpenMetadataElementRequestBody.is_own_anchor: pyegeria False, AnchorOptions.isOwnAnchor true - SearchStringRequestBody.starts_with: pyegeria True, SearchOptions false - SearchStringRequestBody.ignore_case: pyegeria False, SearchOptions true All three now default to None, so an unset value is omitted and Egeria's default applies; callers that pass an explicit value are unaffected. The find_* method signatures still pass starts_with explicitly (pyegeria's prefix-match convention), so search behaviour through those methods is unchanged. The sweep now reports no mismatches. Validate results for all 21 Dr.Egeria test documents are identical with and without this change. Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com>
dwolfson
force-pushed
the
fix/request-defaults-match-egeria
branch
from
September 29, 2026 19:23
0fe71fc to
89fb714
Compare
dwolfson
added a commit
that referenced
this pull request
Sep 29, 2026
1 task done
dwolfson
added a commit
that referenced
this pull request
Oct 6, 2026
…(2026-10-05) (#433) * docs(issues): fold in the Egeria team's response and our corrections (2026-10-05) The Egeria team answered the open server-bug list (source oak2026 fb3d6fce53; fixes are in two unmerged PRs, so no build has them, and nothing was tested live). Recorded per entry: 90, 112, 117, 124, 125 valid with fixes pending merge; 102 and 108 not reproduced by them; 95 and 85 confirmed. Corrections to our own entries: ISSUE-125's cause was an argument-order bug at OMRSRepositoryContentValidator:877, not a GUID map (our hypothesis was wrong, confirmed in source); ISSUE-89's claim that rsa.key-id stops key regeneration was wrong (RSAGenerator always generates a new pair); ISSUE-79 is probably a pyegeria bug, since deep_copy defaulted to False until #399 (2026-09-29) and the folder helper never set it. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com> * docs(issues): ISSUE-122 is fixed and released (#421, 6.1.28), not pending The entry still said 'fixed on branch ..., pending PR/merge'; that branch merged in #421 and shipped in 6.1.28 (and 6.1.29). Re-verified read-only on the 2026-10-05 rebuilt platform: get_catalog_targets returns 'No elements found' in all three formats with no server error. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com> --------- Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com> Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Four pyegeria request-model defaults differed from the Egeria beans they mirror. Request bodies are serialised with
exclude_none=True, so a non-None default is always sent and overrides Egeria's own default, even when the caller never mentioned the field. All four now default toNone: an unset value is left out and Egeria's default applies.TemplateRequestBody.deep_copyFalseTemplateOptions.deepCopy = trueNewOpenMetadataElementRequestBody.is_own_anchorFalseAnchorOptions.isOwnAnchor = trueSearchStringRequestBody.starts_withTrueSearchOptions.startsWith = falseSearchStringRequestBody.ignore_caseFalseSearchOptions.ignoreCase = trueThe user-visible bug:
deepCopyWith
deepCopy: false, Egeria creates only the top-level element from a template and none of its anchored attachments. A data set created from the PostgreSQL Tabular Data Set Collection template got no connection, so it couldn't be read, provisioned or surveyed, and nothing reported an error.create_elem_from_template, every typed*_element_from_templatecreator inAutomatedCuration, and Dr.Egeria's Create Element / Create<Type>Element.TabularDataSetCollectionassets had to be recreated.Deep Copyattribute (Bool, default true) for when a shallow copy is actually wanted.The other three
Found by comparing every request model's bool defaults against its Java bean, including inherited fields. That comparison now reports no mismatches.
The
find_*method signatures still passstarts_withexplicitly (pyegeria's prefix-match convention), so searches through those methods behave the same as before. Only callers passing raw dict bodies without these keys see a change.Test plan
tests/micro-tests/test_template_deep_copy_default.py:Deep Copymaps todeepCopydeepCopy)deepCopyVirtualConnection→ embeddedVirtualConnection→Endpoint, with placeholders substituted (jdbc:postgresql://host.docker.internal:5442/coco_data_hub?currentSchema=dd0580_deepcopy_test)cascadeDelete; all four GUIDs now return 404🤖 Generated with Claude Code