SQLite JDBC驱动不支持哪些SQL特性导致“not implemented”异常？

Question

SQLite JDBC驱动（如sqlite-jdbc）本身不实现SQL语法解析与执行，而是封装原生SQLite C库能力。因此，“not implemented”异常并非驱动自身限制，而是SQLite数据库引擎固有的功能边界所致。常见触发场景包括：使用`FULL OUTER JOIN`（仅支持LEFT/INNER）、`WITH RECURSIVE`在旧版本中不可用、`ALTER TABLE ... DROP COLUMN`（v3.35.0+才支持）、`WINDOW FUNCTIONS`需v3.25.0+且驱动需匹配新版；此外，`CREATE OR REPLACE VIEW/TRIGGER`、`MERGE INTO`、标准`LIMIT … OFFSET`在子查询中的受限使用，以及部分日期函数（如`DATEADD`、`DATEDIFF`）均会抛出该异常。开发者易误以为是JDBC驱动缺陷，实则需检查SQLite运行时版本（`SELECT sqlite_version()`）并与官方文档比对。建议升级至最新sqlite-jdbc（如4.7.x+），并避免在SQL中使用非SQLite原生语法——这是十年实践中最常被忽视的根本原因。

Answer 1

```html

一、现象层：识别“not implemented”异常的典型表征

当执行SELECT * FROM t1 FULL OUTER JOIN t2 ON t1.id = t2.t1_id或ALTER TABLE users DROP COLUMN phone时，JDBC抛出java.sql.SQLException: not implemented——该异常不带堆栈指向驱动内部，而是直接来自SQLite C接口的SQLITE_NOTIMPLEMENTED错误码。注意：此异常从不出现在sqlite-jdbc Java源码中（如SQLiteConnection.java），而是由JNI层透传的底层引擎错误。

二、机制层：驱动本质是C库的“零语义封装”

sqlite-jdbc并非ORM或SQL翻译器，其核心设计哲学是“最小抽象”：

• 所有SQL文本原样传递至SQLite C库（sqlite3_prepare_v2）
• 语法解析、查询优化、执行计划生成均由libsqlite3.so/.dll/.dylib完成
• JDBC驱动仅负责内存管理（如sqlite3_bind_*）、结果集映射与异常转译

因此，驱动版本升级≠功能扩展——它只是桥接了新版SQLite C库的能力。

三、版本层：SQLite运行时能力矩阵对照

以下为关键功能与SQLite版本强绑定关系（需通过SELECT sqlite_version()确认）：

SQL特性	最低SQLite版本	对应sqlite-jdbc建议版本
ALTER TABLE ... DROP COLUMN	v3.35.0 (2021-03-12)	4.7.0+
WINDOW FUNCTIONS	v3.25.0 (2018-09-15)	3.25.2+ 或 4.6.0+
WITH RECURSIVE（完整支持）	v3.8.3 (2014-02-03)	3.8.11.2+
CREATE OR REPLACE VIEW	v3.30.0 (2019-10-04)	3.30.1+

四、诊断层：三步精准定位问题根源

1. 验证运行时版本：SELECT sqlite_version(), sqlite_source_id();
2. 比对官方文档：访问https://www.sqlite.org/lang_altertable.html确认DROP COLUMN支持状态
3. 检查驱动绑定库：调用org.sqlite.core.CoreLibrary.getNativeLibraryVersion()获取实际加载的C库版本（可能被系统PATH污染）

五、实践层：高阶兼容性规避策略

针对无法升级SQLite环境的遗留系统，推荐以下生产级方案：

-- 替代 FULL OUTER JOIN 的标准写法（兼容v3.0.0+）
SELECT t1.*, t2.* FROM t1 LEFT JOIN t2 ON t1.id = t2.t1_id
UNION ALL
SELECT t1.*, t2.* FROM t2 LEFT JOIN t1 ON t1.id = t2.t1_id WHERE t1.id IS NULL;

-- 替代 DATEADD 的跨平台写法（使用 julianday + modifiers）
SELECT datetime(julianday('now') + 7, 'julianday'); -- 加7天

六、架构层：嵌入式数据库的权衡本质

SQLite的设计信条是“small, fast, reliable, embedded”，其功能裁剪遵循严格原则：

• 无服务进程 → 无并发锁管理 → 不支持MERGE INTO（需应用层实现UPSERT逻辑）
• 单文件存储 → 无在线DDL → DROP COLUMN需重建表（v3.35+才内建支持）
• 零配置 → 无用户/权限系统 → CREATE OR REPLACE等语法为简化部署而后期引入

七、演进层：sqlite-jdbc的版本演进关键节点

下图展示驱动与SQLite C库的绑定关系演进（mermaid流程图）：

graph LR
    A[sqlite-jdbc 3.8.11.2] -->|捆绑 SQLite v3.8.11| B[v3.8.x]
    C[sqlite-jdbc 3.28.0] -->|捆绑 SQLite v3.28.0| D[v3.28.x]
    E[sqlite-jdbc 4.7.0] -->|捆绑 SQLite v3.40.1| F[v3.40.x]
    G[sqlite-jdbc 4.7.4] -->|支持自定义 libsqlite3 路径| H[可动态链接任意v3.25+]

八、反模式层：十年实践中最常误判的三类陷阱

1. 语法移植幻觉：将PostgreSQL/SQL Server语法直接迁移（如DATEADD(day, 1, date)）
2. 驱动版本迷信：升级到sqlite-jdbc-4.7.4.jar但宿主环境仍加载系统自带libsqlite3.so.0（v3.7.17）
3. 子查询过度依赖：在WHERE EXISTS(SELECT ... LIMIT 1 OFFSET 10)中使用OFFSET——SQLite仅允许TOP-LEVEL LIMIT/OFFSET

九、治理层：企业级SQLite兼容性基线规范

建议在pom.xml中强制约束：

<properties>
  <sqlite-jdbc.version>4.7.4</sqlite-jdbc.version>
  <sqlite.native.version>3.40.1</sqlite.native.version>
</properties>
<dependency>
  <groupId>org.xerial</groupId>
  <artifactId>sqlite-jdbc</artifactId>
  <version>${sqlite-jdbc.version}</version>
  <exclusions>
    <exclusion>
      <groupId>org.xerial</groupId>
      <artifactId>sqlite-jdbc-native</artifactId>
    </exclusion>
  </exclusions>
</dependency>

十、认知层：重新定义“数据库驱动”的技术内涵

对于嵌入式数据库，JDBC驱动的本质是ABI适配器而非SQL翻译器。这解释了为何：

• HikariCP连接池能无缝切换MySQL/PostgreSQL/SQLite——因为协议抽象在JDBC API层
• QueryDSL/JOOQ生成的SQL必须经SQLTemplates定制化（如SQLiteTemplates）才能规避语法越界
• 数据库迁移工具（Liquibase/Flyway）需启用sqlite方言插件而非通用SQL模式

```