Skip to content

fix(sdk): leave deepCopy, isOwnAnchor, startsWith and ignoreCase to Egeria's defaults - #399

Merged
dwolfson merged 2 commits into
odpi:mainfrom
dwolfson:fix/request-defaults-match-egeria
Sep 29, 2026
Merged

dwolfson merged 2 commits into
odpi:mainfrom
dwolfson:fix/request-defaults-match-egeria

Conversation

@dwolfson

Copy link
Copy Markdown
Member

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 to None: an unset value is left out and Egeria's default applies.

Model / field pyegeria default was Egeria default
TemplateRequestBody.deep_copy False TemplateOptions.deepCopy = true
NewOpenMetadataElementRequestBody.is_own_anchor False AnchorOptions.isOwnAnchor = true
SearchStringRequestBody.starts_with True SearchOptions.startsWith = false
SearchStringRequestBody.ignore_case False SearchOptions.ignoreCase = true

The user-visible bug: deepCopy

With 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.

  • Affected: create_elem_from_template, every typed *_element_from_template creator in AutomatedCuration, and Dr.Egeria's Create Element / Create <Type> Element.
  • Reported impact: 81 Coco TabularDataSetCollection assets had to be recreated.
  • Dr.Egeria: Create Element gains an optional Deep Copy attribute (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 pass starts_with explicitly (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

  • New tests/micro-tests/test_template_deep_copy_default.py:
    • unset flags are omitted and explicit values are still sent
    • Dr.Egeria Deep Copy maps to deepCopy
    • the key test fails without the fix
  • 724 micro-tests pass
  • All 21 Dr.Egeria test documents give identical validate results with and without the change
  • Live, against a local Egeria server: the reporter's exact call (PostgreSQL template, no deepCopy)
    • the request body contained no deepCopy
    • the new asset got its own copied VirtualConnection → embedded VirtualConnection → Endpoint, with placeholders substituted (jdbc:postgresql://host.docker.internal:5442/coco_data_hub?currentSchema=dd0580_deepcopy_test)
    • deleted with cascadeDelete; all four GUIDs now return 404

🤖 Generated with Claude Code

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
dwolfson force-pushed the fix/request-defaults-match-egeria branch from 0fe71fc to 89fb714 Compare September 29, 2026 19:23
@dwolfson
dwolfson merged commit 4ebd515 into odpi:main Sep 29, 2026
5 checks passed
dwolfson added a commit that referenced this pull request Sep 29, 2026
Release carrying the create-from-template deepCopy fix and the other request
defaults aligned with Egeria (#399), and the get_*_by_name filter_string fix
(#398).

Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com>
@dwolfson
dwolfson deleted the fix/request-defaults-match-egeria branch October 5, 2026 00:40
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>
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.

1 participant