Repository navigation
feat(dr-egeria): Promise classification support, lineage-graph for_lineage, JSON Dictionary parsing fix - #402
Merged
Conversation
…xplorer)
Egeria added setElementAsPromise / clearElementAsPromise to Classification
Explorer (POST .../elements/{guid}/promise and .../promise/remove). A Promise
marks an element as a placeholder for a real-world digital resource that has
not yet been delivered; once classified, the element is only returned to
lineage requests (forLineage=true).
- pyegeria: set_element_as_promise / clear_element_as_promise (async + sync)
on ClassificationExplorer. The clear defaults to forLineage=true, which
Egeria requires for this request.
- pyegeria: __async_get_guid__ gains an opt-in for_lineage parameter
(default False, so existing lookups are unchanged); it previously
hardcoded forLineage=false, so a promised element could never be found
by name.
- Dr.Egeria: Classify Promise / Declassify Promise in the Curation family,
with Deployment Status, User Defined Deployment Status, Start/Due/Last
Review/Completion Time and Additional Properties. Routed through
CurationClassifyProcessor via a new CLASSIFICATION_METHODS entry.
Declassify Promise resolves its Target Element with forLineage=true (new
AsyncBaseCommandProcessor.lookup_for_lineage hook, default False) and
sends its clear request with forLineage=true.
- Regression: CT-63/CT-64 in dr_test_curation.md, plus a micro-test driving
both commands through the real dispatcher.
Verified end to end against a live server: classify -> element hidden from
normal lookups but found with forLineage=true, properties stored ->
Declassify by name from a fresh process -> element visible again with no
Promise classification.
Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com>
AssetLineageGraphRequestBody inherits forLineage from BasicOptions, but get_asset_lineage_graph_by_guid had no way to set it, so consumers (the Egeria Portal's lineage handler) had to inject it into the body themselves to see lineage-only elements such as Promises. Adds for_lineage to the async and sync methods and to get_asset_lineage_mermaid_graph. It defaults to None, so the field is left out of the body and Egeria's own default applies -- existing callers send exactly the same request as before. Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com>
…evel
- parse_key_value treated a JSON object such as {"owner": "x"} as a
"Key: Value" line and split it on its first ':', silently storing the key
'{"owner"' and value '"x"}'. Every Dictionary-style attribute written in
JSON form (e.g. Additional Properties) was affected -- including existing
regression files -- with no error. A JSON object is now parsed as JSON.
Values stay strings, as callers expect (Map<String,String>); non-string
JSON values are JSON-encoded, which report.py's _coerce_analytic_value
already decodes back to their real types. Other formats are unchanged.
- config/config.json set file_logging_level to "WARN", which loguru rejects,
so dr_egeria crashed at startup whenever PYEGERIA_CONFIG_DIRECTORY pointed
at it. Now "WARNING".
Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com>
dwolfson
added a commit
to dwolfson/egeria-python
that referenced
this pull request
Oct 1, 2026
…t-body tests AssetCatalog's constructor calls check_connection(), so these tests only passed on machines with an Egeria server at localhost:9443 -- CI has none, and main has failed since odpi#402 added test_asset_lineage_for_lineage.py. Stub check_connection and use a port nothing listens on, so any real network call fails loudly instead of silently relying on a local server. Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com>
dwolfson
added a commit
that referenced
this pull request
Oct 1, 2026
…n Component deployment status (#403) * feat(dr-egeria): default editing commands to forLineage=true; Solution Component deployment status Requested by Mandy Chessell. forLineage defaults (Promise support) - Egeria only returns Promise-classified elements (and Memento, logically deleted, elements) to requests with forLineage=true. Setting For Lineage on a command did not help: it only reached the request body, while the existence check, name lookups and fetch-by-GUID always used false -- so e.g. Update Solution Component on a promised component missed it and was rewritten into a Create. - pyegeria: new lineage_visible() context manager. Inside it, every JSON request body sent by any client (both BasePlatformClient and BaseServerClient request paths) goes out with forLineage=true, including bodies SDK helpers build with it false. - Dr.Egeria: editing commands run inside lineage_visible(True); report commands (View/List/Run) default to false. An explicit For Lineage value wins, except Declassify Promise, which always uses true. A Memento element found by an editing command is treated as not found, so a Create for a deleted element's name still creates rather than updating the deleted one. Solution Component (0730) - Create Solution Component gains Deployment Status / User Defined Deployment Status, sent as deploymentStatus / userDefinedDeploymentStatus. Shared attribute definitions kept identical in the Curation and Solution Architect families (global attribute namespace). - Fix "compoent(s)" typos in Link Solution Components / Link SubComponent. Verified against a live server: a promised Solution Component was found and updated in place by Update Solution Component with no For Lineage attribute (same GUID, no duplicate), deploymentStatus stored, report-style find hid it by default and showed it inside lineage_visible(). Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com> * test: don't depend on a live Egeria server in the AssetCatalog request-body tests AssetCatalog's constructor calls check_connection(), so these tests only passed on machines with an Egeria server at localhost:9443 -- CI has none, and main has failed since #402 added test_asset_lineage_for_lineage.py. Stub check_connection and use a port nothing listens on, so any real network call fails loudly instead of silently relying on a local server. Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com> --------- Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com>
dwolfson
added a commit
to dwolfson/egeria-python
that referenced
this pull request
Oct 1, 2026
Release carrying forLineage=true defaults for Dr.Egeria editing commands (Promise support), lineage_visible() in the SDK, Solution Component deployment status, the Promise classification commands (odpi#402), and the JSON Dictionary parsing fix (odpi#402). Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com>
dwolfson
added a commit
that referenced
this pull request
Oct 1, 2026
Release carrying forLineage=true defaults for Dr.Egeria editing commands (Promise support), lineage_visible() in the SDK, Solution Component deployment status, the Promise classification commands (#402), and the JSON Dictionary parsing fix (#402). Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com>
dwolfson
added a commit
that referenced
this pull request
Oct 1, 2026
Release carrying the forLineage=true defaults for Dr.Egeria editing commands, lineage_visible() in the SDK and Solution Component deployment status (#403), plus the Promise classification commands and the JSON Dictionary parsing fix (#402). 6.1.24 is skipped as a tagged release: a 6.1.24 build was uploaded to PyPI on 2026-09-30 ahead of #402/#403 merging, so the release workflow could not publish the merged code under that version (PyPI files are immutable). 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
Adds Dr.Egeria and pyegeria support for Egeria's new Promise classification (Classification Explorer), requested by Mandy Chessell, plus two related fixes found while testing it.
1. Promise classification
Egeria added
setElementAsPromise/clearElementAsPromise(POST .../classification-explorer/elements/{guid}/promiseand.../promise/remove). A Promise marks an element as a placeholder for a real-world digital resource that hasn't been delivered yet. Once promised, the element is only returned to lineage requests (forLineage=true).set_element_as_promise/clear_element_as_promise(async + sync). The clear defaults toforLineage=true, which Egeria requires.__async_get_guid__gains an opt-infor_lineageparameter. It previously hardcodedforLineage: false, so a promised element could never be found by name. The default is unchanged.Classify Promise/Declassify Promisecommands in the Curation family, with Deployment Status, User Defined Deployment Status, Start / Due / Last Review / Completion Time and Additional Properties.Declassify Promiselooks up its Target Element withforLineage=trueand sends the clear withforLineage=true. This uses a newlookup_for_lineage()hook onAsyncBaseCommandProcessor, which is off by default.2.
for_lineageonget_asset_lineage_graph_by_guidRequested by the Egeria Portal, which currently injects
forLineageinto this body itself. Added to the async/sync methods andget_asset_lineage_mermaid_graph. It defaults toNone, so the field is omitted and existing callers send the same request as before.3. Fixes found along the way
parse_key_valuegarbled JSON-object Dictionary values.{"owner": "x"}was split on its first:and stored as the key{"owner", with no error. This affected every Dictionary attribute written as JSON (e.g. Additional Properties), including existing regression files. A JSON object is now parsed as JSON. Values stay strings; values that aren't strings are stored as their JSON text.config/config.json:file_logging_levelwas"WARN", which loguru rejects, sodr_egeriacrashed at startup wheneverPYEGERIA_CONFIG_DIRECTORYpointed at it. It's now"WARNING".Testing
test_curation_promise.py(both commands through the real dispatcher; fails without the lineage lookup),test_asset_lineage_for_lineage.py, and a JSON case intest_parse_key_value. The fulltests/micro-testssuite passes.validate_compact_specs: 0 errors.dr_test_curation.mdgains CT-63/CT-64, which validate. Its 11 other validation failures (Governance Status: ACTIVE) were already onmain.forLineage=true, and the properties are stored.get_asset_lineage_graph_by_guid(for_lineage=True)was accepted by the server.🤖 Generated with Claude Code