第三方库
ClickHouse 利用第三方库来实现不同的目的，例如，连接到其他数据库，在从/向磁盘加载/保存数据期间解码/编码数据，或实现某些专门的 SQL 函数。为了独立于目标系统中可用的库，每个第三方库都作为 Git 子模块导入到 ClickHouse 的源代码树中，并与 ClickHouse 一起编译和链接。可以通过以下查询获得第三方库及其许可证的列表
SELECT library_name, license_type, license_path FROM system.licenses ORDER BY library_name COLLATE 'en';
请注意，列出的库是位于 ClickHouse 存储库的 contrib/ 目录中的库。根据构建选项，某些库可能未被编译，因此，它们的功能可能在运行时不可用。
添加和维护第三方库
每个第三方库必须驻留在 ClickHouse 存储库的 contrib/ 目录下的专用目录中。避免将外部代码的副本转储到库目录中。而是创建一个 Git 子模块，以从外部上游存储库拉取第三方代码。
ClickHouse 使用的所有子模块都列在 .gitmodule 文件中。
- 如果该库可以按原样使用（默认情况），则可以直接引用上游存储库。
- 如果该库需要修补，请在 GitHub 上的 ClickHouse 组织中创建上游存储库的分支。
在后一种情况下，我们的目标是将自定义补丁与上游提交尽可能隔离。为此，从要集成的分支或标签创建一个带有前缀 ClickHouse/ 的分支，例如 ClickHouse/2024_2（对于分支 2024_2）或 ClickHouse/release/vX.Y.Z（对于标签 release/vX.Y.Z）。避免跟踪上游开发分支 master/ main / dev（即，在前叉存储库中前缀分支 ClickHouse/master / ClickHouse/main / ClickHouse/dev）。此类分支是移动目标，这使得正确的版本控制更加困难。“前缀分支”确保从上游存储库拉取到前叉将不会影响自定义 ClickHouse/ 分支。contrib/ 中的子模块必须仅跟踪分叉的第三方存储库的 ClickHouse/ 分支。
补丁仅应用于外部库的 ClickHouse/ 分支。
有两种方法可以做到这一点
- 您想针对分叉存储库中的
ClickHouse/-prefix 分支进行新的修复，例如，sanitizer 修复。在这种情况下，将修复程序作为带有ClickHouse/前缀的分支推送，例如ClickHouse/fix-sanitizer-disaster。然后从新分支创建一个 PR，以针对自定义跟踪分支，例如ClickHouse/2024_2 <-- ClickHouse/fix-sanitizer-disaster并合并 PR。 - 您更新了子模块，需要重新应用较早的补丁。在这种情况下，重新创建旧的 PR 是过度的。相反，只需将较旧的提交 cherry-pick 到新的
ClickHouse/分支（对应于新版本）。随意 squash 具有多个提交的 PR 的提交。在最佳情况下，我们将自定义补丁贡献回了上游，并且可以在新版本中省略补丁。
更新子模块后，在 ClickHouse 中 bump 子模块以指向 fork 中的新哈希。
创建第三方库的补丁时，请牢记官方存储库，并考虑将补丁贡献回上游存储库。这确保其他人也将从补丁中受益，并且不会成为 ClickHouse 团队的维护负担。