跳至主内容区

TypeORM – Google 夏季代码计划 (GSoC) 项目提案列表

非官方测试版翻译

本页面由 PageTurner AI 翻译（测试版）。未经项目官方认可。 发现错误？ 报告问题 →

本文档列出了 TypeORM 潜在的 GSoC 项目提案。每个提案均包含描述、目标、预期成果及难度等级。

在 TypeORM 中实现一等公民级的多态关联​

描述​

TypeORM 当前缺乏对多态关联（单个关联指向多个实体类型）的原生支持。用户需依赖变通方案，这些方案存在类型标注困难、易出错且在不同数据库间行为不一致的问题。

导师​

目标​

  • 为 TypeORM 设计一等公民级的多态关联 API

  • 确保与现有关联装饰器的兼容性

  • 提供迁移和模式同步支持

预期成果​

  • 用于多态关联的新装饰器

  • QueryBuilder 支持多态连接查询

  • 清晰的文档和示例

  • 向后兼容的实现方案

难度​

中等 - 预计耗时 175 小时

所需技能​

TypeScript、ORM 内部原理、SQL 模式设计

提升 TypeORM 全栈类型安全与类型推断能力​

描述​

尽管采用 TypeScript 编写，TypeORM 在关联关系、QueryBuilder 结果和 Repository 方法等环节仍存在弱类型区域。改进类型推断能力将显著提升开发者体验与代码正确性。

导师​

目标​

  • 增强关联类型推断能力（延迟加载与即时加载关联）

  • 强化 QueryBuilder 结果的类型约束

  • 减少公共 API 中的 any 使用

  • 优化 Repository 和 EntityManager 的泛型设计

预期成果​

  • 更完善的编译时保障

  • 减少运行时错误

  • 渐进式非破坏性改进

  • 推荐类型模式文档

难度​

中等 - 预计耗时 175 小时

所需技能​

高级 TypeScript、泛型、库 API 设计

向量支持：跨数据库的类型定义、索引与搜索​

描述​

向量嵌入在现代应用（AI、搜索、推荐系统）中日渐普及。尽管 TypeORM 已部分支持向量列类型，但仍缺乏跨数据库的向量存储、索引与查询的统一完整解决方案。

本项目旨在为 TypeORM 提供端到端的向量支持，涵盖向量列类型、数据库特定映射、向量索引及高层级向量搜索抽象。

导师​

目标​

  • 为剩余数据库（如 Oracle）添加向量列支持

  • 调研 SQLite 限制并在可能时支持 libsql 向量

  • 定义统一的跨数据库向量列 API

  • 在数据库允许的情况下实现向量索引支持

  • 通过 QueryBuilder 暴露向量相似度查询

  • 在 repository 之上实现高级向量存储抽象

  • 可选：探索知识图谱风格的查询（例如受 SPARQL 启发的 API）

预期成果​

  • 跨数据库的新 @Column({ type: "vector" }) 支持

  • 特定于数据库的向量映射、回退方案和限制

  • 跨数据库的向量索引支持

  • 高级向量搜索和相似度查询 API

  • 可扩展的架构，用于未来的 AI 和搜索相关功能

  • 清晰的文档和示例

难度​

中等 — 预计 175 小时

所需技能​

SQL 方言、数据库内部原理、TypeORM 驱动架构、索引策略、查询优化、API 设计

实体定义 API 的模块化​

导师​

描述​

TypeORM 目前支持两种不同的实体定义方式：基于类的实体（使用装饰器）和实体模式（entity schemas）。随着时间的推移，这两种方式逐渐出现了差异，实体模式的支持在功能和类型安全上常常落后于基于类的实体。

本项目旨在将实体定义风格提取并模块化为更清晰、更隔离的组件，目标是保持两种方式的同步，并为未来的架构改进铺平道路。项目并非尝试完整的 monorepo 重构，而是专注于其中定义明确且可实现的子集。

目标​

  • 将实体定义逻辑提取到清晰分离的模块或包中

  • 提高基于类的实体与实体模式之间的功能对等性

  • 探索具有强类型推断的函数式实体定义 API

  • 减少不同实体定义风格之间的重复代码

  • 为未来的模块化（如 CLI、日志、缓存）奠定基础

预期成果​

  • 实体模式与基于类的实体之间更好的功能同步

  • 更清晰的实体元数据定义内部抽象

  • 改进非基于类的实体定义的类型推断

  • 清晰的边界，使未来的重构和模块化更安全

难度​

高难度 - 预计 350 小时

所需技能​

TypeScript、TypeORM 元数据系统、API 设计、大型代码库重构

用于自定义驱动开发的 SQL 方言抽象​

描述​

目前在 TypeORM 中添加或维护数据库驱动非常复杂，且与现有驱动实现紧密耦合。引入更清晰的 SQL 方言抽象将使支持新数据库变得更容易，并减少不同驱动之间的重复代码。

本项目旨在定义并引入一个 SQL 方言层，封装特定于数据库的 SQL 行为，从而更轻松地开发新驱动，并在 TypeORM 内部实现更好的关注点分离。

导师​

目标​

  • 设计一个捕获数据库特定行为的 SQL 方言抽象

  • 从现有驱动中提取通用的 SQL 生成逻辑

  • 定义清晰的扩展点以实现新方言

  • 记录如何使用方言系统构建自定义驱动

预期成果​

  • 定义清晰的 SQL 方言接口

  • 减少现有驱动间的代码重复

  • 提升现有驱动的可维护性

  • 为社区贡献数据库驱动提供明确路径

难度​

高难度 - 预计 350 小时

所需技能​

SQL 方言、数据库内部原理、TypeScript、TypeORM 驱动架构

社区提案征集​

TypeORM 欢迎贡献者和社区成员提出 Google Summer of Code 项目创意。

如果您有 TypeORM 使用经验，并发现了痛点、缺失功能或架构改进机会，我们鼓励您提交 GSoC 项目提案。

提案可包含但不限于：

  • 现有驱动或数据库支持的改进

  • 性能优化

  • 开发者体验和工具链增强

  • 文档或测试基础设施改进

  • 新功能开发

提案应包含：

  • 简要问题陈述

  • 预期成果和范围

  • 难度预估

  • 相关技术领域（TypeScript、SQL、驱动开发等）

社区提案将由维护者审核，可能被纳入官方 GSoC 项目列表。

现代化迁移工具与快照机制​

描述​

TypeORM 当前的迁移工作流主要围绕 CLI 展开，这在基于 TypeScript 的项目中尤为笨重，并限制了高级使用场景的实现。此外，具有长期迁移历史的项目在搭建新环境时，会面临缓慢且易出错的数据库引导过程。

本项目旨在通过引入编程式迁移生成 API 和可选的模式快照机制，对 TypeORM 的迁移工具进行现代化改造。这些改进将使迁移生成更加灵活，并能通过快照机制快速初始化新数据库，无需重放所有历史迁移。

导师​

目标​

  • 引入不依赖 CLI 的编程式 API 用于生成迁移

  • 支持可定制的迁移模板

  • 设计代表最终数据库结构的模式快照机制

  • 允许使用快照引导新数据库，同时保留迁移历史

  • 确保与现有迁移工作流的兼容性

预期成果​

  • 针对 TypeScript 和非 CLI 工作流改进开发者体验

  • 为大型项目提供更快速可靠的数据库设置

  • 更灵活的迁移生成和模板定制能力

  • 清晰的文档和推荐使用模式

难度​

中等 - 预计 175 小时

所需技能​

TypeScript、SQL、TypeORM 迁移系统、CLI 内部原理、API 与工具设计

准备工作​

建议有意参与 Google Summer of Code 的学生尽早熟悉项目。提交提案前，强烈推荐先了解代码库、贡献流程和社区实践。

准备步骤：

  • 加入我们的 Discord 社区

  • 阅读 CONTRIBUTING.md

  • 探索 TypeORM 仓库和文档，了解架构和支持的数据库

  • 尝试修复小问题或改进文档以熟悉贡献流程