Skip to content
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

feat: support for templating in table names #24

Merged
merged 3 commits into from
Jun 18, 2024
Merged

Conversation

jerrinot
Copy link
Collaborator

@jerrinot jerrinot commented Jun 18, 2024

This changeset introduces a simple templating language in the target table configuration.

Previously, there were two options:

  1. Unset Table Configuration (=default): The connector used the same QuestDB table as the topic name from which the message originated. When the connector was set to listen on multiple topics, it ingested into multiple QuestDB tables.

  2. Explicit Table Configuration: The connector ingested into the one configured table, regardless of the topic from which the messages originated.

This change allows the use of templates in table configurations. For example, setting table to ${topic} will cause ingestion into the table named after the topic from which the message originated. This behavior mirrors the scenario where the table configuration is not set.

However, it also supports more advanced scenarios, such as ${topic}_${key}, where key is a string representation of the message key.

Supported Placeholders:

  1. ${topic}
  2. ${key} - string representation of the message key or 'null'

More placeholders may be added in the future.

Caveats:

  1. The key is intended for use with simple values and not with complex objects such as structs or arrays.
  2. Using ${key} can result in a large number of tables. QuestDB might require tuning when handling thousands of tables.

This changeset introduces a simple templating language in the target
`table` configuration.

Previously, there were two options:
1. Unset Table Configuration (=default): The connector used the same QuestDB
   table as the topic name from which the message originated. When the connector
   was set to listen on multiple topics, it ingested into multiple QuestDB
   tables.

2. Explicit Table Configuration: The connector ingested into the one configured
   table, regardless of the topic from which the messages originated.

This change allows the use of templates in table configurations.
For example, setting table to `${topic}` will cause ingestion
into the table named after the topic from which the message
originated. This behavior mirrors the scenario where the table
configuration is not set.

However, it also supports more advanced scenarios, such as `${topic}_${key}``,
where key is a string representation of the message key.

Supported Placeholders:
1. ${topic}
2. ${key} - string representation of the message key or 'null'

More placeholders may be added in the future.

Caveats:
1. The key is intended for use with simple values and not with complex objects
   such as structs or arrays.
2. Using ${key} can result in a large number of tables. QuestDB might require
   tuning when handling thousands of tables.
@jerrinot jerrinot added the enhancement New feature or request label Jun 18, 2024
@jerrinot jerrinot merged commit 45e4b7c into main Jun 18, 2024
2 checks passed
@jerrinot jerrinot deleted the jh_table_name_templating branch June 18, 2024 13:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant