Background

Apache Beam is a unified programming model for user developing data processing pipelines capable running in distributed systems. Apache Beam SDK officially supports Java, Python, and Go. While Java SDK was historically dominant, Python SDK is increasingly popular thanks to Beam ML. Python APIs are crucial for developers. We plan to port highly anticipated basic streaming transforms made convenient for Beam Python developers.

Tasks

1. Python UnboundedSource (

Apache DolphinScheduler

Apache DolphinScheduler is a distributed and extensible workflow scheduler platform with powerful DAG visual interfaces, dedicated to solving complex job dependencies in the data pipeline and providing various types of jobs available out of box.

Website: https://dolphinscheduler.apache.org/en-us/index.html

GitHub: https://github.com/apache/dolphinschedulerLinked GitHub Issue: /beam/issues/19137)

While Splittable DoFn has been introduced as a Beam primitive transform handling IO sources, UnboundedSource arguably remains an easier API for users to author their own IOs. In the Java SDK, UnboundedSource/UnboundedReader has been (re)implemented as a wrapper of Splittable DoFn, we can follow the Java implementation and add it to Python.

Stretch goal: implement a native Python streaming IO based on UnboundedSource.

2. Python Watch Transform (https://github.com/apache/dolphinschedulerbeam/issues/897521521)

Background

Currently, DolphinScheduler requires a separate alert-server to handle workflow and task alerts. Although the alert-server is lightweight, maintaining and deploying it separately adds operational complexity.

We aim to remove the standalone alert-server and embed its alerting functionality directly into the API server.

Task

Integrate the alert-server functionality into the API server so that it can handle workflow and task alerts natively.

Deliverables

• Remove the standalone alert-server.

• Enable the API server to handle all alerting tasks.
• Add Integration test case.

Recommended Skills

• Proficiency in Java.
• Familiarity with microservice, e.g. spring-boot.

• Familiarity with DolphinScheduler’s architecture and alerting mechanisms is a plus.

Mentors

Currently we have a Watch transform in the Java SDK that is very useful when periodically polling for new input to a pipeline. We would like a parallel transform in Python.

Stretch goal: Update Python FileIO.readContinuously to use watch transform

Deliverables

• Implementation of Python UnboundedSource: A functional wrapper API for UnboundedSource and UnboundedReader built on Splittable DoFn (a merged pull request to the Apache Beam repo).
• Implementation of Python Watch Transform: A parallel transform to the Java Watch API for periodic polling (a merged pull request to the Apache Beam repo).
• Unit and Integration Tests: tests for both features, specifically covering watermarks, checkpointing, and polling termination conditions.
• User Documentation: Updated SDK guides and Docstrings explaining how to author custom IOs using UnboundedSource and how to use the Watch transform in pipelines.
• Refactored FileIO.readContinuously (Stretch Goal): A pull request updating FileIO.read_continuously to utilize the new Watch transform logic.

Recommended Skills

• Proficiency in Python, experience with pytest
• Java-to-Python Porting: Ability to read and interpret Java source code
• Version control: Git, development with GitHub
• nice to have: exposure to streaming data processing tools (e.g. Apache Beam/Flink/Spark, etc)
• Wenjun Ruan(Apache DolphinScheduler PMC member), wenjun@apache.org^{Image Removed}
• Zihao Xiang(Apache DolphinScheduler PMC member),   zihaoxiang@apache.org^{Image Removed}

Apache DolphinScheduler

Apache DolphinScheduler is a distributed and extensible workflow scheduler platform with powerful DAG visual interfaces, dedicated to solving complex job dependencies in the data pipeline and providing various types of jobs available out of box.

Website: https://dolphinscheduler.apache.org/en-us/index.html

GitHub: https://github.com/apache/dolphinscheduler

Linked GitHub Issue: https://github.com/apache/dolphinscheduler/issues/8975

Background

Currently, DolphinScheduler requires a separate alert-server to handle workflow and task alerts. Although the alert-server is lightweight, maintaining and deploying it separately adds operational complexity.

We aim to remove the standalone alert-server and embed its alerting functionality directly into the API server.

Task

Integrate the alert-server functionality into the API server so that it can handle workflow and task alerts natively.

Deliverables

• Remove the standalone alert-server.

• Enable the API server to handle all alerting tasks.
• Add Integration test case.

Recommended Skills

• Proficiency in Java.
• Familiarity with microservice, e.g. spring-boot.

• Familiarity with DolphinScheduler’s architecture and alerting mechanisms is a plus.

Mentors

• Wenjun Ruan(Apache DolphinScheduler PMC member), wenjun@apache.org^{Image Added}
• Zihao Xiang(Apache DolphinScheduler PMC member),   zihaoxiang@apache.org^{Image Added}

Summary

Implement an automated API documentation pipeline that generates and publishes API reference documentation from the Python (Qumat, QDP) and Rust (qdp-core) codebases, integrated into the project's Docusaurus website and CI.

Background

• Apache Mahout exposes two main API surfaces:
  • Qumat: Python library for quantum circuits (backends: Qiskit, Cirq, Amazon Braket).
  • QDP (Quantum Data Plane): GPU-accelerated encoding (Rust core + PyO3 Python bindings, qumat.qdp / _qdp).
• Manual doc updates are error-prone and don’t scale. Automating from source keeps docs accurate and reduces maintainer burden.

Current state

• QuMat API is maintained by hand and can drift from code.
• QDP API is waiting for new website migration to be finished.
• Rust (qdp-core) has extensive doc comments but no published rustdoc in the website.

Goals

1. Generate API reference from source for Python (Qumat).
2. Integrate generated docs into the existing Docusaurus site.
3. Automate the pipeline in CI so doc builds run on changes.
4. Define conventions (docstrings, public API) for future contributors.

Deliverables

• Python API doc pipeline (Sphinx or pdoc) for qumat and QDP.
• QuMat API reference either generated or explicitly linked.
• Rust (qdp-core) rustdoc built and linked from the website.
• CI job(s) that build Python API docs and rustdoc and fail on errors.
• Short contribution guide on docstring style and how to update API docs.

Tracked github issue

https://github.com/apache/mahout/issues/1012

Backgroud

ZZFeatureMap is the most widely-used data encoding in quantum machine learning. It's the default in Qiskit and PennyLane for quantum kernel methods and variational classifiers.

QDP currently supports amplitude, angle, basis, and IQP encodings. Adding ZZFeatureMap completes our QML encoding suite.

What is ZZFeatureMap?

Maps classical features to quantum states using:
1. Hadamard gates (superposition)
2. RZ gates (single-qubit rotations)
3. ZZ interactions (two-qubit entanglement)
4. Repetition layers for expressivity

Tracked github issue

https://github.com/apache/mahout/issues/1008

Project Overview

Title

Enhance the Seata framework Golang SDK’s support for multiple databases

Abstract

Apache Seata(incubating) is a popular distributed transaction solution, providing solutions like AT, TCC, and XA for ensuring data consistency in microservice architectures.

The AT mode (Automatic Transaction) provides applications with non-intrusive distributed transaction capabilities by proxying SQL statements and parsing protocols. Although Seata-go currently supports MySQL and has initial compatibility with PostgreSQL, it still falls short in covering commonly used production databases, and precise compatibility with Oracle and MariaDB is an urgent need.

This project aims to align with the mature ecosystem of Seata Java and introduce AT mode support for Oracle and MariaDB in Seata-go. This not only involves parsing and adapting SQL dialects, but also includes metadata management, handling differences in Undo Log serialization, and integrating with the specific locking mechanisms of each database. It is a critical step in expanding the capability boundaries of Seata-go.

Detailed Description Objectives

• Console Metrics Visualization: Develop functionality to view various metrics related to the connection pool in the Seata console. The metrics should be displayed based on IP/connection pool granularity, helping users easily identify resource allocation and utilization.

• Metrics Control via Console: Allow users to control various aspects of the connection pools directly from the Seata console. This includes the ability to adjust minimum and maximum connection counts, configure connection acquisition timeout, and manage connection pool keep-alive settings.

Deliverables

• Complete MariaDB AT Mode Support (Priority P0)
  • Implement MariaDB driver adapter layer (seata-at-mariadb Driver)
  • Implement MariaDB TableMetaCache and Trigger
  • Implement MariaDB UndoLogManager
  • Handle dialect differences between MariaDB and MySQL (e.g., RETURNING clause, system variables)
• Complete Oracle AT Mode Support (Priority P1)
  • Implement Oracle driver adapter layer (seata-at-oracle Driver)
  • Implement Oracle metadata query adaptation (based on ALL_TAB_COLUMNS, ALL_INDEXES system views)
  • Implement Oracle data type to JDBC type mapping (NUMBER, VARCHAR2, CLOB, DATE, etc.)
  • Implement Oracle UndoLogManager with Undo Log serialization differences
  • Adapt Oracle SQL dialect (ROWNUM pagination, Sequence retrieval, DUAL table, etc.)
• Integration Testing and Validation (Priority P1)
  • Write comprehensive unit tests and integration tests covering single-table CRUD, multi-table join operations, and transaction rollback scenarios
  • Validate accuracy of Before/After Image generation
  • Validate correctness of global locks and Undo Log
• Samples and Documentation (Priority P2)
  • Add Oracle and MariaDB usage demos in seata-go-samples
  • Write a technical blog "Seata-Go Multi-Database Adaptation Design" explaining design concepts and implementation details

Implementation Plan

Phase 1: Requirement Analysis and Design

• Align scope and acceptance criteria with mentors/community: prioritize MariaDB (P0) and Oracle (confirm final priority as per topic), and define the must-cover SQL/transaction scenarios (CRUD, rollback, lock conflict, batch ops, joins where applicable).

• Study and benchmark Seata Java AT implementation: produce a gap list for Dialect, TableMeta, UndoLog, Before/After Image, and global lock integration, and decide what to port vs. re-design for Go.

• Design a pluggable multi-database architecture for Seata-Go: define clear interfaces (Dialect, MetaQuery, TypeMapper, UndoLogManager, DriverAdapter) and module boundaries for MariaDB/Oracle implementations; write a short design spec.

• Prepare baseline environments and regression safety: stand up MariaDB/Oracle test environments (local and/or CI) and create baseline test cases to ensure existing MySQL AT behavior does not regress.

Phase 2: MariaDB AT Mode Support (P0)

• Implement seata-at-mariadb driver adapter: integrate with database/sql, hook into key execution points, and ensure Seata AT context is correctly propagated.

• MariaDB dialect adaptation: handle MariaDB vs. MySQL differences (syntax/behaviors such as RETURNING-related cases, system variables, and any MariaDB-specific edge cases affecting parsing and image SQL).

• Metadata and caching: implement MariaDB TableMetaCache and metadata queries (columns, primary keys, indexes) with robust caching/invalidations as needed.

• MariaDB UndoLogManager: implement undo log write/read/delete and serialization strategy consistent with Seata-Go conventions; ensure rollback works for common and edge data types.

• Scenario-driven hardening: validate with integration tests covering single-table DML, unique key updates, batch updates, idempotent rollback, and lock conflict/retry behaviors.

Phase 3: Oracle AT Mode Support (P0/P1)

• Implement seata-at-oracle driver adapter: adapt to the chosen Oracle driver (godror / go-ora, per community decision), addressing bind variables, result set handling, and transaction boundary behaviors.

• Oracle metadata adaptation: implement metadata queries using Oracle system views (e.g., ALL_TAB_COLUMNS, ALL_INDEXES) and cache results effectively.

• Oracle type mapping: map Oracle types to Seata-Go internal types (NUMBER, VARCHAR2, CLOB, DATE, TIMESTAMP, etc.) to ensure image capture and undo serialization are consistent.

• Oracle dialect adaptation: support Oracle-specific SQL behaviors (ROWNUM pagination patterns, sequences, DUAL table usage, locking semantics where relevant).

• Oracle UndoLogManager: implement Oracle-compatible undo log persistence and serialization differences; validate large objects and time types in rollback.

Phase 4: Testing, Samples, and Documentation

• Testing: add unit tests (Dialect/TypeMapper/MetaQuery/UndoLog) and integration tests (real DB) to verify:
  • Before/After Image correctness
  • Global lock correctness (conflicts, concurrency, retries)
  • Rollback correctness and idempotency
  • No regressions for existing MySQL AT
• CI enablement (if feasible): make MariaDB/Oracle tests repeatable in CI or provide a documented script-based workflow for contributors.

• Samples: add full MariaDB and Oracle examples to incubator-seata-go-samples (config, schema, demo transactions, rollback demos).

• Documentation/blog: write “Seata-Go Multi-Database Adaptation Design” and user/developer docs covering configuration, driver selection, supported SQL patterns, and known limitations.

Required Skills

• Have Go language development experience, familiar with database/sql standard library and common database drivers (e.g., go-sql-driver/mysql, godror, go-ora)

• Proficient in SQL syntax, deep understanding of relational database principles, familiar with transaction isolation levels and row/table locking mechanisms

• Understand the core principles of Seata AT mode (Before/After Image, Undo Log, Global Lock)

• Have experience with Oracle or MariaDB databases, understand their dialect differences from MySQL

• Possess good documentation habits and code standards awareness, able to read Seata Java source code for reference

Benefits to Apache Seata

• Broader database coverage for Seata-Go AT mode: enables production adoption in enterprises that rely on MariaDB and Oracle.

• Lower migration and adoption cost: users can extend distributed transaction capability beyond MySQL with minimal application changes.

• Better maintainability and extensibility: a clean, interface-driven design (Dialect/Meta/UndoLog/TypeMapping) reduces future effort to add more databases.

• Higher reliability through verification: comprehensive integration tests and samples make correctness measurable and reduce regressions.

• Stronger community value: aligning with Seata Java’s proven approach and producing clear docs/design guidance improves contributor productivity and ecosystem confidence.

Conclusion

This project strengthens Seata-Go AT mode by adding robust MariaDB and Oracle support aligned with Seata Java’s mature implementation. By delivering dialect adaptation, metadata management, undo log handling, type mapping, and thorough testing plus samples and documentation, it significantly expands Seata-Go’s multi-database capabilities and improves its production readiness for real-world enterprise environments.

Useful Link

Apache Seata website

https://github.com/apache/incubator-seata-go

https://github.com/apache/incubator-seata-go-samples

Contact Information

• Mentor Name: FengZhang [zfeng@apache.org], Apache Seata(incubating) PPMC member

Project Overview

Title

Enhance Seata-Go Multi-Registry Support and seata-ctl Diagnostic Tool Capability

Abstract

Apache Seata (incubating) is a popular distributed transaction solution for ensuring data consistency in microservice architectures. Seata-Go, as its Go language SDK, is responsible for implementing core TM/RM functionalities in the Go ecosystem.

Currently, Seata-Go lags behind the Java version in terms of registry support richness at the infrastructure layer, and its production-level transaction troubleshooting and operational toolchain (seata-ctl) is still in its early stages. This results in limited options for users in non-Etcd/Raft scenarios and high troubleshooting costs when transaction anomalies occur.

This project aims to align with Seata's infrastructure ecosystem by introducing support for four mainstream registries: Nacos, ZooKeeper, Consul, and Redis to Seata-Go. Additionally, it will significantly enhance seata-ctl's diagnostic capabilities through full-chain environment checks, transaction state insights, and an interactive terminal interface, reducing the operational threshold for distributed transactions.

Detailed Description / Objectives

• Infrastructure Alignment: Ensure Seata-Go can seamlessly integrate into existing enterprise-level microservice governance systems by implementing adapters for various mainstream registries.
• Operational Efficiency Improvement: Build a complete diagnostic command set enabling developers to quickly locate network, database, and transaction state anomalies, and simplify operation workflows through an interactive interface.
• Community Ecosystem Contribution: Produce high-quality design documents and technical blogs to help community users understand Seata-Go's underlying governance logic and operational best practices.

Deliverables

1. Multi-Registry Cluster Support (Priority P0)

• Mainstream Registry Adapter Implementation:

• • Implement Nacos and ZooKeeper registry adapters with support for service instance subscription, real-time listening, and multi-tenant isolation configuration.
  • Implement Consul and Redis adapters with support for service registration/discovery and heartbeat monitoring mechanisms.
  • Bug fixes for Seata NamingServer Golang SDK.
  • Ensure service registration path formats for all registries are fully compatible with Java version Seata.
• Configuration and Initialization System Integration:

• • Extend configuration structure to standardize registry-specific configuration parameters.
  • Optimize factory initialization logic to support smooth registry type switching via configuration files.

2. seata-ctl Diagnostic Tool Enhancement (Priority P1)

• Full-Chain Self-Check Functionality:

• • Implement automated environment checks covering network connectivity verification with the server.
  • Implement database-level health checks including connection availability and validation of transaction core system table structures.
  • Implement configuration file format and required field legality validation.
• Transaction State Insight Capability:

• • Implement real-time query functionality for active transaction lists.
  • Implement query functionality for resource lock records corresponding to specific transaction identifiers (XID).
  • Support structured output formats (e.g., table, JSON, YAML).
• Interactive Terminal Interface (TUI):

• • Introduce a visual interactive mode for the tool, simplifying complex command input through interface guidance to enhance operational experience.

3. Testing, Samples, and Community Output (Priority P2)

• Testing and Validation:

• • Write unit tests and integration tests for each registry adapter to verify node change awareness capabilities.
  • Validate diagnostic tool accuracy across different database dialects.
• Samples and Documentation:

• • Add complete multi-registry integration examples in seata-go-samples.
  • Write technical articles: "Seata-Go Registry Extension Design and Practice Guide" and "Distributed Transaction Troubleshooting in Practice: Quickly Locating Anomalies with Diagnostic Tools".

Implementation Plan

• Phase 1: Research and Architecture Design

• • Research existing Seata-Go registry implementations and study Seata NamingServer implementation logic.
  • Design diagnostic tool's interaction logic and command set architecture, ensuring tool extensibility.
• Phase 2: Registry Adapter Development (P0)

• • Prioritize completion of core functionality implementation and compatibility testing for Nacos and ZooKeeper.
  • Perform bug fixes for Seata NamingServer to optimize its stability in the Go SDK.
  • Integrate Consul and Redis support and unify configuration initialization entry points.
• Phase 3: Diagnostic Tool and Interactive Interface Development (P1)

• • Develop core logic for environment checks and transaction state queries.
  • Build interactive terminal interface (TUI), encapsulating underlying commands into intuitive visual operations.
• Phase 4: Testing Validation and Community Promotion (P2)

• • Improve test cases to ensure stability across different registry environments.
  • Complete community technical article output and submit related sample code.

Required Skills

• Have Go language development experience, familiar with concurrent programming and network communication.
• Understand service discovery principles, familiar with mainstream registries (e.g., Nacos, ZooKeeper).
• Understand basic distributed transaction principles, familiar with Seata's interaction architecture (TM/RM/TC).
• Familiar with command-line tool development, possess good code standards awareness and documentation writing skills.

Benefits to Apache Seata

• Expand Infrastructure Boundaries: Enable Seata-Go to adapt to more diverse enterprise production environments, eliminating selection barriers.
• Improve Operational Convenience: Fill the gap in operational diagnostic tools for the Go version, significantly reducing user learning and maintenance costs.
• Enhance Ecosystem Interoperability: Ensure consistency in governance between Go and Java versions, supporting Seata's unified multi-language ecosystem.

Conclusion

This project addresses Seata-Go's shortcomings in infrastructure adaptation and operational troubleshooting by enhancing multi-registry support and diagnostic tool capabilities. This not only improves Seata-Go's production readiness but also strengthens the Apache Seata community ecosystem through user-friendly interactive tools and comprehensive technical documentation.

Useful Link

• https://seata.apache.org/
• https://github.com/apache/incubator-seata-go

Summary

Implement an automated API documentation pipeline that generates and publishes API reference documentation from the Python (Qumat, QDP) and Rust (qdp-core) codebases, integrated into the project's Docusaurus website and CI.

Background

• Apache Mahout exposes two main API surfaces:
  • Qumat: Python library for quantum circuits (backends: Qiskit, Cirq, Amazon Braket).
  • QDP (Quantum Data Plane): GPU-accelerated encoding (Rust core + PyO3 Python bindings, qumat.qdp / _qdp).
• Manual doc updates are error-prone and don’t scale. Automating from source keeps docs accurate and reduces maintainer burden.

Current state

• QuMat API is maintained by hand and can drift from code.
• QDP API is waiting for new website migration to be finished.
• Rust (qdp-core) has extensive doc comments but no published rustdoc in the website.

Goals

1. Generate API reference from source for Python (Qumat).
2. Integrate generated docs into the existing Docusaurus site.
3. Automate the pipeline in CI so doc builds run on changes.
4. Define conventions (docstrings, public API) for future contributors.

Deliverables

• Python API doc pipeline (Sphinx or pdoc) for qumat and QDP.
• QuMat API reference either generated or explicitly linked.
• Rust (qdp-core) rustdoc built and linked from the website.
• CI job(s) that build Python API docs and rustdoc and fail on errors.
• Short contribution guide on docstring style and how to update API docs.

Tracked github issue

https://github.com/apache/mahout/issues/1012

Backgroud

ZZFeatureMap is the most widely-used data encoding in quantum machine learning. It's the default in Qiskit and PennyLane for quantum kernel methods and variational classifiers.

QDP currently supports amplitude, angle, basis, and IQP encodings. Adding ZZFeatureMap completes our QML encoding suite.

What is ZZFeatureMap?

Maps classical features to quantum states using:
1. Hadamard gates (superposition)
2. RZ gates (single-qubit rotations)
3. ZZ interactions (two-qubit entanglement)
4. Repetition layers for expressivity

• https://github.com/apache/

• incubator-seata-go-samples
• https://github.com/apache/incubator-seata-ctl

Contact Information

• Mentor Name: TunGuo [tew@apache.org], Apache Seata(incubating) Committer