electron + sqlite3 解决打包后无法写入数据库

前言

window环境。

electron@28.0.0

sqlite3@5.1.6

使用 electron-builder 打包。

本文旨在解决打包后无法写入数据库的问题。

但如果你是打包后无法访问sqlite,且有报错弹窗,不妨也看看本文。

也许是同一种原因。

错误原因分析

打包后无法创建db文件,是因为大部分人连接db,

都是用path模块,采用
path.join(__dirname, 'data.db') 类似这样的写法。

因为网上的垃圾教程都是这么教的,笔者也深受其害。

默认情况下,打包后获得的目录格式为(假设你的输出目录是dist/)

/dist/xxx.exe

/dist/resources/app.asar

xxx.exe是你的主程序。

electron打包后的项目根目录,指向app.asar 文件。

所以如果你在node里写的源代码是

js 复制代码
const filePath = path.resolve(app.getAppPath(), 'storage', 'data.db')
const db = new sqlite3.Database(filePath)

在打包后,程序执行到这里,会去请求/dist/resources/app.asar/storage/data.sb文件。

再举一个例子,

假如你的项目目录是

myproject/package.json

myproject/main.js

myproject/src/dbserver/mydb.js

myproject/src/storage/data.db

然后在你mydb.js中这样写

js 复制代码
const filePath = path.resolve(__dirname, '../storage/data.db')
const db = new sqlite3.Database(filePath)

在调试时候肯定是没问题的。

但是打包后,所有资源默认都被打包进app.asar,且根目录符号链接到app.asar。

程序执行到这里就会请求/resources/app.asar/src/storage/data.db这个地址。

如果你的打包设置是正确的,这一步并不会报错,因为data.db的的确确被打包进了这个路径。

你可以正确读取。

但是 app.asar是一个只可读不可写的文件。

当你要写入数据库的时候,就会发现怎么都无法写,甚至程序不报错。

因为用promise封装的db写入请求,只会一直pending,而不会reject。

为什么 app.asar只可读不可写?

某种意义上你可以把它看成程序的一部分。

如果app.asar被改写了,你可以认为你的程序遭到了入侵。

一般而言electron甚至鼓励你去校验app.asar的完整性,来确保自己的分发版本是正确的。

看起来这是一个合理的设计。

所以我们要做的应该是,让我们的db请求路径,不要指向app.asar。

正确解法

不要使用node提供的相对路径功能。

不要使用__dirname 变量。

不要使用electron.app.getAppPath()。

这些东西最后都会指向app.asar。

在生产环境就写一个相对路径字符串。

js 复制代码
const isPackaged = app.isPackaged;
let filePath;
if(isPackaged){
	filePath = path.resolve('./resources/storage/data.db')
}
else{
	filePath = path.resolve(__dirname, '../storage/data.db')
}
const db = new sqlite3.Database(filePath)

同时在pakcge.json中配置extraResources字段。

复制代码
"build":{
	 "extraResources":  {
	        "from": "./src/storage/",
	        "to": "storage"
	    },
}

这样整个/myproject/src/storage 目录都会被复制到/dist/resources/storage/位置。

这样最后程序执行db时,会指向/dist/resources/storage/data.db位置。

因为在path.resolve('./resources/storage/data.db') 这条命令中的,. 指向当前xxx.exe的运行位置。

这同样暗示我们,data.db应该作为一个外部文件管理,不应该放在src里。
src应该视为程序本体,在打包后,运行时,永远不变。

而data.db这种属于外部资源,打包后运行时会动态改变。

外部资源不应该在src里。

我上面举例的这种项目结构是不合理的。

相关推荐
FungLeo26 分钟前
成为全栈·基础补充·数据库索引:为什么加了索引还是慢
mysql·postgresql·sqlite·sql优化·数据库索引·成为全栈
codeejun27 分钟前
每日一Go·MySQL-11、覆盖索引 & 回表原理
javascript·数据库·mysql
CoderYanger1 小时前
Java EE 进阶:8.MyBatis 操作数据库(入门)(第一弹)
java·数据库·spring·面试·职场和发展·java-ee·mybatis
XLYcmy1 小时前
信息检索报告数字经济赋能城市低碳治理的路径研究——基于“传统数据库 + 生成式人工智能”双轮驱动的检索实践 检索实施与结果分析 Web of Science
数据库·ai·llm·prompt·ssci·deepseek·wos
Decay__1 小时前
21_MySQL 优化案例集 —— 慢 SQL 优化、索引重构与参数调整收益对比
运维·数据库·sql·mysql·架构
codigger2 小时前
MySQL 深分页优化:limit 100000, 10 慢在哪,怎么救
数据库·sql·mysql·程序员
麦壳饼3 小时前
SonnetDB 5.0 正式发布:增强 SQL 与事务,开放九模型 MCP 读写
数据库·人工智能·sql·sonnetdb
Decay__12 小时前
18_MySQL 智能巡检方案 —— 巡检项清单 / 一键巡检脚本 / 健康评分
运维·数据库·sql·mysql·架构
java_logo12 小时前
Docker 部署 Liquibase:轻松搭建数据库变更管理
数据库·docker·容器·数据库管理·liquibase·轩辕镜像·数据库变更
凤凰院凶涛QAQ13 小时前
《MySQL内核拆解:从SQL到InnoDB》(四) : 联合查询 & 视图
数据库·sql·mysql