Problem
The Java SDK's SzFlag enum defines two export composites that Python's SzEngineFlags does not:
SZ_EXPORT_ALL_FLAGSSZ_EXPORT_FLAGS
Reaching for either in Python raises AttributeError on SDK 4.3.3. Because cross-binding documentation and flag references describe them without noting they are Java-only, callers translating an export from Java to Python hit a runtime failure with no forward pointer.
Verified against the published API docs:
| Binding |
SZ_EXPORT_ALL_FLAGS |
SZ_EXPORT_FLAGS |
SZ_EXPORT_DEFAULT_FLAGS |
SZ_EXPORT_INCLUDE_* family |
Java (sz-sdk-java) |
✅ |
✅ |
✅ |
✅ |
Python (sz-sdk-python) |
❌ |
❌ |
✅ |
✅ |
(SZ_EXPORT_INCLUDE_ALL_ENTITIES, _ALL_HAVING_RELATIONSHIPS, _DISCLOSED, _MULTI_RECORD_ENTITIES, _NAME_ONLY, _POSSIBLY_RELATED, _POSSIBLY_SAME, _SINGLE_RECORD_ENTITIES are present in both.)
Ask
Either add the two composites to SzEngineFlags for parity, or — if the omission is deliberate — state in the Python flag documentation that they are Java-only and name SZ_EXPORT_DEFAULT_FLAGS as the Python starting point. Right now the absence is silent, which is indistinguishable from a docs gap.
We are adding a per-binding availability note downstream in the Senzing MCP server either way, but the authoritative answer belongs here.
Related, and arguably the more expensive problem
The two export flag families answer different questions, and this is not documented anywhere we can find:
SZ_EXPORT_INCLUDE_* selects which entities appear as rowsSZ_ENTITY_INCLUDE_* selects what detail each row carries
An export flagged with only the former succeeds and writes one row per entity containing nothing but ENTITY_ID. Reported case: 4,587 rows with no usable fields and no error. Worth an explicit note in the export flag docs, since the failure is silent and looks like an empty database rather than a flag mistake.
Sibling issue filed on sz-sdk-java for the same divergence from the other side.
Problem
The Java SDK's
SzFlagenum defines two export composites that Python'sSzEngineFlagsdoes not:SZ_EXPORT_ALL_FLAGSSZ_EXPORT_FLAGSReaching for either in Python raises
AttributeErroron SDK 4.3.3. Because cross-binding documentation and flag references describe them without noting they are Java-only, callers translating an export from Java to Python hit a runtime failure with no forward pointer.Verified against the published API docs:
SZ_EXPORT_ALL_FLAGSSZ_EXPORT_FLAGSSZ_EXPORT_DEFAULT_FLAGSSZ_EXPORT_INCLUDE_*familysz-sdk-java)sz-sdk-python)(
SZ_EXPORT_INCLUDE_ALL_ENTITIES,_ALL_HAVING_RELATIONSHIPS,_DISCLOSED,_MULTI_RECORD_ENTITIES,_NAME_ONLY,_POSSIBLY_RELATED,_POSSIBLY_SAME,_SINGLE_RECORD_ENTITIESare present in both.)Ask
Either add the two composites to
SzEngineFlagsfor parity, or — if the omission is deliberate — state in the Python flag documentation that they are Java-only and nameSZ_EXPORT_DEFAULT_FLAGSas the Python starting point. Right now the absence is silent, which is indistinguishable from a docs gap.We are adding a per-binding availability note downstream in the Senzing MCP server either way, but the authoritative answer belongs here.
Related, and arguably the more expensive problem
The two export flag families answer different questions, and this is not documented anywhere we can find:
SZ_EXPORT_INCLUDE_*selects which entities appear as rowsSZ_ENTITY_INCLUDE_*selects what detail each row carriesAn export flagged with only the former succeeds and writes one row per entity containing nothing but
ENTITY_ID. Reported case: 4,587 rows with no usable fields and no error. Worth an explicit note in the export flag docs, since the failure is silent and looks like an empty database rather than a flag mistake.Sibling issue filed on
sz-sdk-javafor the same divergence from the other side.