From 3bbc16935348559dc47475b3926bb9fe4c66202f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Geir=20Ove=20Gr=C3=B8nmo?= Date: Tue, 9 Dec 2025 12:02:22 +0100 Subject: [PATCH 1/2] IS-18610: Added kafka source and sink to list of those who add and remove namespaces --- hub/features/namespaces.rst | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/hub/features/namespaces.rst b/hub/features/namespaces.rst index 892c5f6f6e..81470611d7 100644 --- a/hub/features/namespaces.rst +++ b/hub/features/namespaces.rst @@ -7,7 +7,7 @@ Namespaces Namespaces in Sesam are inspired by the Resource Description Framework `(RDF) `_ where namespaces are URL references that allows us to reuse names from different sources without loosing context. In Sesam namespaces are used to determine the origin of attributes, which is essential for master data management in :ref:`global pipes `. Inside global pipes we often wish to merge entities with other similar entities, such as person data from a CRM system and the equivalent person data from an HR system. Sesam prefixes namespaces to each attribute name in order to merge data from multiple sources without losing context. Namespaces in Sesam are also essential for :ref:`late schema binding ` where we map global models to target models. -With some exceptions, attributes will always inherit the pipe name where the attribute was first created as its namespace, i.e. an attribute ``x`` created in pipe ``y`` will use the namespace ``y:``, becoming ``y:x``. +With some exceptions, attributes will always inherit the pipe name where the attribute was first created as its namespace, i.e. an attribute ``x`` created in pipe ``y`` will use the namespace ``y:``, becoming ``y:x``. See examples below. @@ -26,7 +26,7 @@ See examples below. - visma-person:name * - hubspot-company - company_name - - hubspot-company:company_name + - hubspot-company:company_name * - visma-company - company_name - visma-company:company_name @@ -35,10 +35,10 @@ How to enable ------------- **Enable on specific pipes:** -Namespaces can be enabled on specific pipes by setting the required property/properties in the pipe configuration (see properties below). +Namespaces can be enabled on specific pipes by setting the required property/properties in the pipe configuration (see properties below). **Enable globally in a subscription:** -You can enable namespaces in the service metadata for all the pipes in your subscription. This can be overridden at the pipe level. +You can enable namespaces in the service metadata for all the pipes in your subscription. This can be overridden at the pipe level. .. important:: @@ -80,7 +80,7 @@ Properties - Boolean - If ``true`` then the current identity namespace will be added to ``_id`` and the current property namespace will be added to all properties. The namespaces are added before the first transform. This property is normally only specified on inbound pipes. - If ``namespaced_identifiers`` is enabled in the service metadata then the source default value is used. The following sources has a default value of ``true``: :ref:`csv `, :ref:`ldap `, :ref:`sql `, :ref:`embedded `, :ref:`http_endpoint `, and :ref:`json `. + If ``namespaced_identifiers`` is enabled in the service metadata then the source default value is used. The following sources has a default value of ``true``: :ref:`csv `, :ref:`kafka `, :ref:`ldap `, :ref:`sql `, :ref:`embedded `, :ref:`http_endpoint `, and :ref:`json `. - Source default - @@ -88,6 +88,6 @@ Properties - Boolean - If ``true`` then namespaces will be removed from ``_id``, properties and namespaced identifier values. The namespaces are removed after the last transform. This property is normally only specified on outbound pipes. - If ``namespaced_identifiers`` is enabled in the service metadata then the sink default value is used. The following sinks has a default value of ``true``: :ref:`csv_endpoint `, :ref:`elasticsearch `, :ref:`mail `, :ref:`rest `, :ref:`sms `, :ref:`solr `, :ref:`sql `, :ref:`http_endpoint `, and :ref:`json `. + If ``namespaced_identifiers`` is enabled in the service metadata then the sink default value is used. The following sinks has a default value of ``true``: :ref:`csv_endpoint `, :ref:`elasticsearch `, :ref:`mail `, :ref:`rest `, :ref:`sms `, :ref:`solr `, :ref:`kafka `, :ref:`sql `, :ref:`http_endpoint `, and :ref:`json `. - Sink default - - \ No newline at end of file + - From 089063ebb5639f56baa8531439465806c1cbaf1d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Geir=20Ove=20Gr=C3=B8nmo?= Date: Tue, 9 Dec 2025 12:06:20 +0100 Subject: [PATCH 2/2] IS-18610: Removed some invalid trailing commas --- .../pipes/configuration-sources-merge.rst | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/hub/documentation/service-configuration/pipes/configuration-sources-merge.rst b/hub/documentation/service-configuration/pipes/configuration-sources-merge.rst index d8a5904a20..7cf13736ef 100644 --- a/hub/documentation/service-configuration/pipes/configuration-sources-merge.rst +++ b/hub/documentation/service-configuration/pipes/configuration-sources-merge.rst @@ -73,7 +73,7 @@ Variant 1: Explicit equality-rules with the ``equality`` property "equality": [ ["eq", "a.x", "b.x"], ["eq", "b.x", "c.y"], - ["eq", "c.z", "d.z"], + ["eq", "c.z", "d.z"] ], "supports_signalling": false } @@ -88,7 +88,7 @@ Variant 2: Implicit equality-rules with the ``equality_sets`` property "datasets": ["A a", "B b", "C c", "D d"], "equality_sets": [ ["a.x", "b.x", "c.y"], - ["c.z", "d.z"], + ["c.z", "d.z"] ], "supports_signalling": false } @@ -273,7 +273,7 @@ one at a time, like this: "equality": [ ["eq", "a.x", "b.x"], ["eq", "b.x", "c.y"], - ["eq", "c.z", "d.z"], + ["eq", "c.z", "d.z"] ], The ``equality_sets`` property was added as a way to makes it clearer which equality-rules belong together. @@ -283,7 +283,7 @@ The equality-rules above could be expressed like this: "equality_sets": [ ["a.x", "b.x", "c.y"], - ["c.z", "d.z"], + ["c.z", "d.z"] ], Note that the ``equality_sets`` property is just a bit of syntactic sugar; behind the scenes the implicit @@ -296,7 +296,7 @@ if you accidentally specify two equality-sets that are actually overlapping. If "equality_sets": [ ["a.x", "b.x", "c.y"], - ["c.y", "d.y"], + ["c.y", "d.y"] ], you won't actually get two equality-sets, since behind the scenes you end up with these equality-rules: @@ -314,7 +314,7 @@ which is equivalent to specifying a single equality-set, like this: .. code-block :: json "equality_sets": [ - ["a.x", "b.x", "c.y", "d.y"], + ["a.x", "b.x", "c.y", "d.y"] ], Continuation support @@ -369,7 +369,7 @@ Dataset ``C``: [ {"_id": "c1", "f3": "X"}, {"_id": "c2", "_deleted": true, "f3": "Y"}, - {"_id": "c3", "_deleted": true, "f3": "X"}, + {"_id": "c3", "_deleted": true, "f3": "X"} ] @@ -384,7 +384,7 @@ Pipe configuration: "datasets": ["A a", "B b", "C c"], "equality": [ ["eq", "a.f1", "b.f1"], - ["eq", "b.f2", ["lower", "c.f3"]], + ["eq", "b.f2", ["lower", "c.f3"]] ] } }