Skip to content

Minor docs corrections plus single-side-join docs rewrite #8229

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: staging
Choose a base branch
from

Conversation

ZbyszekMM
Copy link
Contributor

@ZbyszekMM ZbyszekMM commented Jun 11, 2025

A set of unrelated small corrections

  • complete rewrite of the single-side-join component
  • deeper corrections of previousValue component. Here, the groupBy parameter name was changed to key.

@@ -77,7 +77,7 @@ components {
| namePattern | false | .* | Regexp for filtering operations by operationId or by created service name (concatenation of HTTP method, path and parameters) |
| security | false | | Configuration for [authentication](https://swagger.io/docs/specification/authentication/) for each `securitySchemas` defined in the *OpenAPI interface definition* |
| security.*.type | false | | Type of security configuration for a given security schema. Currently only `apiKey` is supported |
| security.*.apiKeyValue | false | | API key that will be passed into the service via header, query parameter or cookie (depending on definition provided in OpenAPI) |
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find it difficult to understand statement like "depending on definition provided in OpenAPI".

OpenAPI is too vague for me, it can mean standard defitinition, a particular service (interface) definition or maybe something else. I prefer to be more helpful here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

imho previous description is simpler (it doesn't use huge world "interface") and points out that behaviour is dependent on specific service configuration

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

...as configured in the given service definition?

is statically validated and typed on an ongoing basis.
is statically validated and typed on an ongoing basis.

The internal Nussknacker's `Typing Information` "system" is based on Java datatypes. Consequently, the data mappings presented in the remaining part of this document map data types between the non Java datatypes and Java datatypes.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mby just "typing" instead of "Typing information" system?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thia, "system" is too much probably, I will remove it. However the document uses "Typing information" all over the place, so it is probably better to keep it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

type system

@@ -77,7 +77,7 @@ components {
| namePattern | false | .* | Regexp for filtering operations by operationId or by created service name (concatenation of HTTP method, path and parameters) |
| security | false | | Configuration for [authentication](https://swagger.io/docs/specification/authentication/) for each `securitySchemas` defined in the *OpenAPI interface definition* |
| security.*.type | false | | Type of security configuration for a given security schema. Currently only `apiKey` is supported |
| security.*.apiKeyValue | false | | API key that will be passed into the service via header, query parameter or cookie (depending on definition provided in OpenAPI) |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

imho previous description is simpler (it doesn't use huge world "interface") and points out that behaviour is dependent on specific service configuration

* The `#outputVar` will be available downstream of the outer-join aggregate.
![alt_text](img/singleSideJoinScenario.png "single-side-join in an example scenario")

The configuration of the Single-side-join would be as in the picture below; note how Nussknacker Designer helps you to decide which branch is which.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note how Nussknacker Designer helps you to decide which branch is which. <- imho we can skip this part.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants