-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
CDK: private configuration option _limit and _page_size #5617
Conversation
a780d0f
to
bdebac1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, just small comment
@@ -135,6 +147,9 @@ def _read_stream( | |||
for record in record_iterator: | |||
if record.type == MessageType.RECORD: | |||
record_counter += 1 | |||
if internal_config.limit and record_counter > internal_config.limit: | |||
logger.info("Reached limit defined by internal config, stop reading") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please add number, like so:
logger.info("Reached limit defined by internal config, stop reading") | |
logger.info(f"Reached limit defined by internal config ({internal_config.limit}), stop reading") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed
bdebac1
to
e36793f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Like this idea. The limit
keyword makes total sense and could be used by any cdk stream off the bat with this change, nice!
For page_size
, iiuc, it needs to be individually implemented per stream for this setting to have any effect? I think right now it's not entirely clear what page_size
actually is... is it a limit to number of pages to paginate through? Is it limit for number of records per page? Could either / both of those settings be useful depending on the connector?
Ultimately, I'm wondering if just implementing the ability to create any _internal_setting
would provide more flexibility, including allowing implementing a _page_size
if needs be, but since there's no high-level logic changes for it, it could fit into the generic box too.
|
||
|
||
class InternalConfig(BaseModel): | ||
KEYWORDS: ClassVar[set] = {"_limit", "_page_size"} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can see why we'd be explicit here to avoid accidentally putting actual config values in the internal config... however, in adding this feature does it perhaps make sense to enable adding any internal flags without the need to update cdk code each time (e.g. taking any keywords that start with _)?
This is more of an open question than a suggestion, so wdyt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See my overall review comment which links to this :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For page_size, iiuc, it needs to be individually implemented per stream for this setting to have any effect? I think right now it's not entirely clear what page_size actually is... is it a limit to number of pages to paginate through? Is it limit for number of records per page? Could either / both of those settings be useful depending on the connector?
Its number of record per page. Right now its not a standard property but some streams use page_size name to configure number of records per page. It works only for instances of HttpStream class.
Ultimately, I'm wondering if just implementing the ability to create any _internal_setting would provide more flexibility, including allowing implementing a _page_size if needs be, but since there's no high-level logic changes for it, it could fit into the generic box too.
Do you mean filtering out records that starts with _ ? In this case we need somehow distinguish internal config for cdk and connector itself. We don't want to filter out connector config and also we don't want to pass cdk config to the connector.
I can see why we'd be explicit here to avoid accidentally putting actual config values in the internal config... however, in adding this feature does it perhaps make sense to enable adding any internal flags without the need to update cdk code each time (e.g. taking any keywords that start with _)?
This is more of an open question than a suggestion, so wdyt?
Its good suggestion but there is some connectors that using its own internal config. From the connector side we can set additionalproperties flag to true for spec jsonschema and we are sure that any config with any internal properties will pass checking against spec schema. But for cdk we need to filter out cdk specific configs to make this check pass, that's why there is split_config function. It still allows adding connector specific internal parameters but the should not be same as ones that as used for cdk. If we going to make it too generic it would be a mess with cdk and connector paramters
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for detailed responses on previous review. Understand and happy with approach based on that.
One thing I think is needed for clarity in adding these is detail around the availability of these flags, descriptions and how to use (for example, in the CDK tutorial in the docs maybe add a section on it?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Meant to approve with comment above ^
/publish-cdk dry-run=false
|
What
Resolves #4985 issue
How
Describe the solution
Recommended reading order
x.java
y.python
Pre-merge Checklist
Expand the relevant checklist and delete the others.
New Connector
Community member or Airbyter
airbyte_secret
./gradlew :airbyte-integrations:connectors:<name>:integrationTest
.README.md
docs/SUMMARY.md
docs/integrations/<source or destination>/<name>.md
including changelog. See changelog exampledocs/integrations/README.md
airbyte-integrations/builds.md
Airbyter
If this is a community PR, the Airbyte engineer reviewing this PR is responsible for the below items.
/test connector=connectors/<name>
command is passing./publish
command described hereUpdating a connector
Community member or Airbyter
airbyte_secret
./gradlew :airbyte-integrations:connectors:<name>:integrationTest
.README.md
docs/integrations/<source or destination>/<name>.md
including changelog. See changelog exampleAirbyter
If this is a community PR, the Airbyte engineer reviewing this PR is responsible for the below items.
/test connector=connectors/<name>
command is passing./publish
command described hereConnector Generator
-scaffold
in their name) have been updated with the latest scaffold by running./gradlew :airbyte-integrations:connector-templates:generator:testScaffoldTemplates
then checking in your changes