feat(metadata-expert): add push_down param for ISSUE-38 (PY-18) - #335
Merged
Conversation
Egeria core added a pushDown query parameter to both count endpoints (omf-metadata-spring/omf-metadata-server, merged 2026-08-30) to let callers choose between the fast repository-side count (existing behavior, may disagree with a corresponding find's visibility-filtered list) and a count that agrees with the list by construction, at the cost of reading every matching relationship/element server-side. Added push_down: Optional[bool] = None to count_metadata_elements/ _async_count_metadata_elements and count_relationships_between_elements/ _async_count_relationships_between_elements. None omits the query parameter entirely (zero behavior change for existing callers); True/ False append ?pushDown=true/false explicitly, following the existing conditional-append convention (valid_metadata.py's typeName handling). Attempted the entry's own live verification (live-patched into quickstart-pyegeria-web via docker cp + restart, diff-confirmed) but it came out blocked, not failed: the deployed odpi/egeria-platform:latest image (build-date 2026-08-24, re-pulled fresh 2026-09-02 to confirm no newer image has been published) predates the 2026-08-30 server-side merge, so pushDown is silently accepted but has no effect yet. Also re-confirmed ISSUE-18/PY-7 (get_valid_metadata_values ignores asOfTime) is unchanged and unrelated to this fix. Full writeup in PYEGERIA_ISSUES.md. Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com>
Docker Hub shows the odpi/egeria-platform:latest tag was re-pushed 2026-08-31, after this entry's own build-date-label check (2026-08-24). Pulled that exact digest and diffed the actual server jar (omag-server-platform-6.2-SNAPSHOT.jar) against what's already deployed: identical SHA-256 in both. The 2026-08-31 push is a container-image rebuild around the same, still-pre-fix application jar, not a new Egeria build -- confirms the "verification blocked, not failed" conclusion with checksum evidence rather than a label alone. Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com>
dwolfson
added a commit
to dwolfson/egeria-workspaces
that referenced
this pull request
Sep 2, 2026
PY-7: re-confirmed live against qs-metadata-store, unchanged — the get-valid-metadata-values endpoint still ignores asOfTime entirely. PY-18: Egeria's server-side fix (new pushDown count parameter, merged 2026-08-30) is real and pyegeria now supports it (odpi/egeria-python#335), but verification against real data is blocked, not failed — checksum-confirmed the deployed platform's application jar is still pre-fix even after Docker Hub's 2026-08-31 image re-push (same base app, just a rebuilt container layer). Full detail in PYEGERIA_ISSUES.md's ISSUE-38 (canonical) entry. Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.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
1 participant
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
Egeria core added a
pushDownquery parameter to both count endpoints (omf-metadata-spring/omf-metadata-server, merged 2026-08-30) to let callers choose between the fast repository-side count (existing behavior, may disagree with a corresponding find's visibility-filtered list) and a count that agrees with the list by construction, at the cost of reading every matching relationship/element server-side.push_down: Optional[bool] = Nonetocount_metadata_elements/_async_count_metadata_elementsandcount_relationships_between_elements/_async_count_relationships_between_elements.Noneomits the query parameter entirely (zero behavior change for existing callers);True/Falseappend?pushDown=true/?pushDown=falseexplicitly, following the existing conditional-append convention (valid_metadata.py'stypeNamehandling).PYEGERIA_ISSUES.mdupdated for ISSUE-38 (PY-18) and ISSUE-18 (part of PY-7/8/11).Testing
Attempted ISSUE-38's own live verification (live-patched into
quickstart-pyegeria-webviadocker cp+ restart, diff-confirmed) but it came out blocked, not failed: the deployedodpi/egeria-platform:latestimage (build-date: 2026-08-24, re-pulled fresh 2026-09-02 to confirm no newer image has been published) predates the 2026-08-30 server-side merge, sopushDownis silently accepted but has no effect yet. Full test numbers and reasoning are in thePYEGERIA_ISSUES.mdwriteup.Also re-confirmed ISSUE-18/PY-7 (
get_valid_metadata_valuesignoresasOfTime) is unchanged and unrelated to this fix — live-tested with a far-pastasOfTimeagainst a property with real registered values, same result both times.🤖 Generated with Claude Code