From e3931e0923e2a3edc4d17c0ae60a69f06a2818ac Mon Sep 17 00:00:00 2001 From: Sameer6305 Date: Mon, 20 Jul 2026 13:21:58 +0530 Subject: [PATCH] docs: update construct_templates docstring to reflect dual add_triplets failure signalling The exception-propagation comment and Raises docstring in execute_construct_template stated that add_triplets signals failure exclusively via a returned dict. This became stale after the JenaStore fix (previous commit) which introduced ProcessingError propagation for complete batch failures. Updated to document both paths: - dict-based failure: success=False in returned dict (BlazegraphStore, RDF4J, etc.) - raised ProcessingError: JenaStore full-batch failure now raises directly No logic changed. 262 tests pass. --- semantica/triplet_store/construct_templates.py | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/semantica/triplet_store/construct_templates.py b/semantica/triplet_store/construct_templates.py index 4051b9cd..0e2e586d 100644 --- a/semantica/triplet_store/construct_templates.py +++ b/semantica/triplet_store/construct_templates.py @@ -573,7 +573,10 @@ def execute_construct_template( Raises: ValidationError: propagated from render_construct_template. ProcessingError: if store_backend lacks execute_sparql/add_triplets, - or if persistence via add_triplets does not report success. + or if persistence via add_triplets does not report success (either + via a returned dict with success=False, or a raised ProcessingError + from backends such as JenaStore that raise on a complete batch + failure rather than returning a dict). Exception-propagation convention: This function does not wrap or catch exceptions raised by @@ -583,11 +586,12 @@ def execute_construct_template( for execution failures, as BlazegraphStore.execute_sparql already does internally for connection/request/Turtle-parse errors). Adding a second wrapping layer here would only obscure the original error - with no new information. The one exception this function DOES raise - itself is the add_triplets write-failure case immediately below, - because add_triplets signals failure via a returned dict rather than - an exception, so there is no pre-existing typed exception to let - propagate. + with no new information. This extends to add_triplets: most backends + signal failure via a returned dict (checked immediately after the call + below), but some backends (e.g. JenaStore) raise ProcessingError + directly on a complete batch failure — that exception is intentionally + allowed to propagate uncaught here, as it is already a correctly-typed + ProcessingError and carries the right diagnostic information. Why store_backend.execute_sparql is called directly instead of QueryEngine.execute_query (investigated for issue #322 item on reusing