airbyte
airbyte copied to clipboard
✨ Introduce StateIteratorProcessor in CDK
What
Add SourceStateIterator
and SourceStateIteratorProcessor
interface.
Add count into AirbyteStateMessage
.
Idea is that all source connector will use the standard SourceStateIterator
to emit state. SourceStateIterator
will composite with SourceStateIteratorProcessor
interface and inside of the interface each connector will have its own implementation to define:
- whether it has reached a checkpoint
- how to process a record message
- how to emit a checkpoint state message
- how to emit a final state message.
How
See doc: https://docs.google.com/document/d/14Qg_lXMzMvMO5oP0RYIe11JIwuCzR9QexcEaSiPJKEk/edit#heading=h.fa72b39y2m99 for details.
This PR demonstrate how do we refactor mysql connector.
We need to apply the same refactoring logic towards:
Postgres:
- CtidStateIterator
- XminStateIterator
MongoDB:
- MongoDbStateIterator
Recommended reading order
- SourceStateIterator.java and SourceStateIteratorProcessor.java - these two are created in CDK
- MySqlInitialSyncStateIteratorProcessor.java - individual processor
- Note I've deleted the old MySqlInitialSyncStateIterator.java - logic have been moved to the previous classes.
🚨 User Impact 🚨
Are there any breaking changes? What is the end result perceived by the user?
For connector PRs, use this section to explain which type of semantic versioning bump occurs as a result of the changes. Refer to our Semantic Versioning for Connectors guidelines for more information. Breaking changes to connectors must be documented by an Airbyte engineer (PR author, or reviewer for community PRs) by using the Breaking Change Release Playbook.
If there are breaking changes, please merge this PR with the 🚨🚨 emoji so changelog authors can further highlight this if needed.
Pre-merge Actions
Expand the relevant checklist and delete the others.
New Connector
Community member or Airbyter
- Community member? Grant edit access to maintainers (instructions)
- Unit & integration tests added and passing. Community members, please provide proof of success locally e.g: screenshot or copy-paste unit, integration, and acceptance test output. To run acceptance tests for a Python connector, follow instructions in the README. For java connectors run
./gradlew :airbyte-integrations:connectors:<name>:integrationTest
. - Connector version is set to
0.0.1
-
Dockerfile
has version0.0.1
-
- Documentation updated
- Connector's
README.md
- Connector's
bootstrap.md
. See description and examples -
docs/integrations/<source or destination>/<name>.md
including changelog with an entry for the initial version. See changelog example -
docs/integrations/README.md
- Connector's
Airbyter
If this is a community PR, the Airbyte engineer reviewing this PR is responsible for the below items.
- Create a non-forked branch based on this PR and test the below items on it
- Build is successful
- If new credentials are required for use in CI, add them to GSM. Instructions.
Updating a connector
Community member or Airbyter
- Grant edit access to maintainers (instructions)
- Unit & integration tests added
Airbyter
If this is a community PR, the Airbyte engineer reviewing this PR is responsible for the below items.
- Create a non-forked branch based on this PR and test the below items on it
- Build is successful
- If new credentials are required for use in CI, add them to GSM. Instructions.
Connector Generator
- Issue acceptance criteria met
- PR name follows PR naming conventions
- If adding a new generator, add it to the list of scaffold modules being tested
- The generator test modules (all connectors with
-scaffold
in their name) have been updated with the latest scaffold by running./gradlew :airbyte-integrations:connector-templates:generator:generateScaffolds
then checking in your changes - Documentation which references the generator is updated as needed
Updating the Python CDK
Airbyter
Before merging:
- Pull Request description explains what problem it is solving
- Code change is unit tested
- Build and my-py check pass
- Smoke test the change on at least one affected connector
- On Github: Run this workflow, passing
--use-local-cdk --name=source-<connector>
as options - Locally:
airbyte-ci connectors --use-local-cdk --name=source-<connector> test
- On Github: Run this workflow, passing
- PR is reviewed and approved
After merging:
-
Publish the CDK
- The CDK does not follow proper semantic versioning. Choose minor if this the change has significant user impact or is a breaking change. Choose patch otherwise.
- Write a thoughtful changelog message so we know what was updated.
- Merge the platform PR that was auto-created for updating the Connector Builder's CDK version
- This step is optional if the change does not affect the connector builder or declarative connectors.
The latest updates on your projects. Learn more about Vercel for Git ↗︎
Name | Status | Preview | Comments | Updated (UTC) |
---|---|---|---|---|
airbyte-docs | ✅ Ready (Inspect) | Visit Preview | 💬 Add feedback | Jan 3, 2024 11:11pm |
Before Merging a Connector Pull Request
Wow! What a great pull request you have here! 🎉
To merge this PR, ensure the following has been done/considered for each connector added or updated:
- [x] PR name follows PR naming conventions
- [x] Breaking changes are considered. If a Breaking Change is being introduced, ensure an Airbyte engineer has created a Breaking Change Plan.
- [x] Connector version has been incremented in the Dockerfile and metadata.yaml according to our Semantic Versioning for Connectors guidelines
- [x] You've updated the connector's
metadata.yaml
file any other relevant changes, including abreakingChanges
entry for major version bumps. See metadata.yaml docs - [x] Secrets in the connector's spec are annotated with
airbyte_secret
- [x] All documentation files are up to date. (README.md, bootstrap.md, docs.md, etc...)
- [x] Changelog updated in
docs/integrations/<source or destination>/<name>.md
with an entry for the new version. See changelog example - [x] Migration guide updated in
docs/integrations/<source or destination>/<name>-migrations.md
with an entry for the new version, if the version is a breaking change. See migration guide example - [x] If set, you've ensured the icon is present in the
platform-internal
repo. (Docs)
If the checklist is complete, but the CI check is failing,
-
Check for hidden checklists in your PR description
-
Toggle the github label
checklist-action-run
on/off to re-run the checklist CI.
This is a weird one. Usually in java, an iterator is a class that allows one to iterate and run business logic. Your change seems to build a class that takes a processor and calls it iteratively behind the scene. I really don't think the name is right. I'm not convinced about the abstraction either, but I don't know enough to have a strong opinion about it
[!WARNING] 🚨 Connector code freeze is in effect until 2024-01-02. This PR is changing connector code. Please contact the current OC engineers if you want to merge this change to master.
/publish-cdk-java
/publish-java-cdk
:clock2: https://github.com/airbytehq/airbyte/actions/runs/7403247875 :white_check_mark: Successfully published Java CDK version=0.10.3!