Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[Roadmap] Incremental Rust modernization for HugeGraph core modules

Abierto
  • ¿Algo no está bien?
#3,110 4 comentarios 3 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Refactorización
Claridad
Necesita aclaración
Estado de actividad
Tranquilo
Stack tecnológico
java, rust
Área
backend, databases, distributed-systems

Línea de trabajo

Esta es una hoja de ruta principal, no una tarea de código concreta, y no se ha indicado ningún punto de entrada de archivo o de prueba. Empieza leyendo la guía de contribución y la lista de comprobación; después, elige un candidato acotado, como límites de interoperabilidad, fixtures diferenciales o benchmarks. Se considera completado cuando existe un Issue hijo aprobado y con alcance definido, con una persona responsable o un mentor, criterios de compatibilidad y pruebas, benchmarks y requisitos de despliegue o rollback.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

feature help wanted improvement

Goal

Explore an incremental Rust implementation for selected HugeGraph Server, HStore, and PD components, especially performance- or memory-sensitive paths where Rust can provide measurable safety and efficiency benefits.

This is a parent tracking issue, not a commitment to rewrite the whole server. The current implementation remains the compatibility baseline, and Java/Rust components may coexist behind stable process, protocol, or storage boundaries.

Roadmap at a glance

Toolchain foundations
        │
        v
┌─ This repository ─────────────────┐
│  Server core -> HStore -> PD      │
└───────────────────────────────────┘
        │
        v
Computer kernels -> Vermeer/OLAP

Each arrow is a review gate, not an automatic rewrite.

Proposed priority

  1. Server core
    • Begin with bounded leaf components, memory management, codecs, or performance-sensitive data structures rather than the whole request path.
    • Preserve REST/Gremlin behavior, authentication, observability, and plugin contracts.
  2. HStore
    • Evaluate storage/replication paths only after workload baselines, on-disk and wire compatibility, failure recovery, and rolling-upgrade requirements are explicit.
  3. PD
    • Evaluate scheduling and metadata components after their distributed-system invariants and compatibility contract are covered by repeatable tests.

The sequence may change based on benchmark evidence and maintainer consensus.

Delivery model

proposal/RFC -> isolated component -> differential/fault tests
             -> benchmark -> opt-in deployment -> staged adoption

Planning guardrails (required)

Before implementation starts, each child issue must define:

  • scope, owner/mentor, and non-goals;
  • API, protocol, storage-format, and operational compatibility;
  • differential, concurrency, fault-injection, and upgrade/rollback tests;
  • reproducible latency, throughput, memory, and recovery benchmarks;
  • security/dependency checks and supported platforms;
  • observability, deployment, coexistence, migration, and rollback plans;
  • explicit acceptance criteria and user/operator/contributor documentation.

No large rewrite PR should start before its design and acceptance criteria are reviewed. Correctness, recoverability, and compatibility take precedence over headline benchmark numbers. Small, reviewable PRs and stable interoperability boundaries are required; an unplanned rewrite PR may be closed or asked to return to the RFC/design stage.

Candidate work items

  • Select the first small server-side proof of concept
  • Document stable Java/Rust interoperability boundaries
  • Build shared differential and compatibility test fixtures
  • Establish representative OLTP and storage workload baselines
  • Define CI, packaging, security, and release conventions
  • Define rolling-upgrade and rollback requirements before HStore/PD work
  • Split approved work into newcomer-friendly child issues

This checklist will link to concrete child issues as proposals are accepted.

Project-wide roadmap

  • Toolchain: apache/hugegraph-toolchain#748
  • Server / HStore / PD (this issue): apache/hugegraph#3110
  • Computer / Vermeer: apache/hugegraph-computer#355
  • Documentation hub: apache/hugegraph-doc#462

How to participate

Interested in open source, Rust, databases, distributed systems, storage engines, or infrastructure? Comment with the area you want to work on and any relevant experience. RFC review, failure-model analysis, benchmarks, tests, and documentation are all valuable.

First-time contributors can start with the HugeGraph contribution guide and the repository's good first issue / help wanted tasks.

Lenguaje dominante
Java
Estrellas
3.2k
Forks
640
Merge medio
1 d 7 h
PR fusionados (30 d)
88

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de apache/hugegraph

Todos los issues de apache/hugegraph

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.