@kome 试了一个安装最新的 5.4.3 版本是没问题的，我先用 Garmin VIRB EDIT 试试吧。DJI Mimo 在激活 action 的时候用了一次，倒是没发现它有这个能力，也可以作为备用方案研究一下

@qdsearoc 格式问题不大，谢谢友友答复

@kome 老哥给的访问域名有点点问题，但思路是对的。国内应该使用 connect.garmin.cn ，有点让我恶心的地方在于注册的时候要求必须提供手机号和邮箱，而国外的 connect.garmin.com 只需要邮箱即可注册。导入之后位置没有偏移，也不需要做额外的转换。遗憾的是，导出的文件中没有心率的数据。如果无法提供心率数据的话，我觉得我不必须使用小米运动健康。最后 Garmin VIRB EDIT ，官网的最后更新时间已经是 2018 年底了，有点担心软件适配的问题（我的 mac 是 M1 芯片的），晚上来试一下

@kome 好的好的，我试试看

@superchijinpeng 这个软件的如果想要使用 MCP 服务的话，需要升级到 Pro 版本，看介绍有 7 天免费试用，一口价 29 美刀

python 怎么这么多依赖管理工具，poetry ，pdm ，uv ，还有过时的 pip

使用乐观锁更新的话，如果出现了并发有概率出现部分用户无法更新成功的情况，也就是数据库返回受影响行数为 0 ，这个时候需要提示用户修改失败，并要求重新刷新表单数据之后重新提交修改，并发量大的情况下，用户仍然有可能第二次提交也是失败的

使用锁的话，大概率是可以更新成功的，但可能遇到的问题有，并发量大时可能会等待，表现为用户提交表单等待的时间会长一点或者直接等待超时（这种情况下，有可能修改成功，也可能失败）。此外还有一个问题是，后提交的用户有可能会把之前提前的信息给覆盖掉（比如 #13 提到的问题）

如果按照锁升级策略来看的话，是否可以考虑如下策略
默认使用乐观锁，当出现冲突时，也就是数据库返回受影响行数为 0 时，进入重锁模式，重锁模式释放完毕之后，再做一个判断，如果当前没有使用资源的线程，则切换回乐观锁模式

@fantasy0v0
嗯，我之前没有使用 `spring-boot-starter-jooq` 启动器，而是单独引入的 `jooq` 依赖。直接删除那部分配置肯定是不行的。

换成引入 `spring-boot-starter-jooq` 之后，把自己的配置删除确实可以了。

不过我发现另一个问题是默认情况下使用 spring 的事务是正常的，但换用 jooq 自身的事务 api （比如 `dslContext.transaction`），就出现异常了。具体异常提示是 `Cannot use ContextTransactionalCallable with TransactionProvider of type class org.springframework.boot.autoconfigure.jooq.SpringTransactionProvider`。此时我还需要手动将 `org.jooq.TransactionProvider` 的实现从 `org.springframework.boot.autoconfigure.jooq.SpringTransactionProvider` 换成 `org.jooq.impl.ThreadLocalTransactionProvider` 才行

@fms 好的，明天摸鱼的时候 debug 调试看看

@Gilgamesh7 不管是 jooq 还是 mybatis ，示例中都是使用 spring 的 @Transactional 注解来声明事务的。我的代码写的有一些歧义，但事务应该都要能正常生效才对。自调用是可能导致事务失效，但自调用的方法自身是已经开启了事务的，那么事务就应该继续生效才对。现在我换用了 jooq 的事务方法使用编程式事务，测试代码如下
```java
@Test
@DisplayName("jooq 编程式事务")
@Order(5)
public void testJooqExceptionByProgrammatic() {
TUser tUser = null;
try {
// 开启事务
tUser = dslContext.transactionResult(() -> {
return userService4Jooq.insertRetuningThrow(userId4Jooq, userName4Jooq);
});
} catch (Exception e) {
// 不需要关注此异常
}

Assertions.assertNull(tUser, "事务回滚失败");
}
```
事务可以正常运行，插入的结果正常回滚了

但声明式事务还不清楚是什么原因失效了

我遇到一个问题是，我在发起一个堆的提问之后，发现之前的一个提问是我发出的指令有问题，这个时候如果我再发起一个撤回提问往往都是无法达到我想要的撤回效果的。也就是说，我以为的撤回是把之前的一个操作剔除掉，但 ai 的操作往往是通过增量动作去尝试到达我要的撤回效果

看样子是纯前端的工具，不过就像是网友们说的，idea 中已经有满足你需求的插件了，甚至还少一次复制类的动作。不过还是提几个可优化的点
1. 给出的 json 输出中，未适配的数据类型不能给出正确的值。基本的 Long ，Integer 得做一下适配吧，我不信作者的类中没用到的基本数据类型的包装类
2. 静态字段也输出在 json 中。对象实例在序列化后不会包含静态属性。其他的比较少见的 transient ，以及 jackson 的 @JsonIgnore 都没有做忽略
3. 无法读取类的上下文依赖情况。试想一下这种情况，一个用户类中，有拥有的角色类属性，所属部门类属性等等，在这个工具中，如果要被正确识别角色属性和部门属性，要把用户类，角色类和部门类都复制出来，才能生成正确的 json 输出。这个场景应该是比较常见的。如果是在 idea 的插件中，可以读取到项目的上下文环境。但在作者的这个工具中，需要使用者把这些类都复制出来才行。这是一个硬伤

@leeonsoft Termius 不满足题主说的第 3 点，而且收费也太贵了，一个月 $10 ，如果只需要最基本的 ssh 使用需求，倒是可以用

有一说一，6.1 寸的手机我都嫌大。近一年内应该没有低于这个尺寸的手机上市吧。我知道的低于 6.1 寸的还在售新机的就只有 iPhone se 了，最后一代 iPhone 13 mini ，官网都不卖，只能找第三方了。关键是我现在用的 iPhone 13 已经比较卡了，猜测 iPhone 13 mini 只会更卡。小屏意味着 续航低 或者 性能低，估计近几年都打破不了这个魔咒

还有一个问题是，如果要切换数据库引擎，不知道题主的系统做新数据库的适配有多大的成本，这也是要考虑的，而且迁移到新的数据库引擎，旧数据是不是也要迁移过去，也是一个问题。所以我认为，换数据库引擎应该是最后应该考虑的，因为迁移的成本可能并不小

不在乎数据丢失的话，就写一个脚本，开机之后一段时间（比如 3 分钟内）监听 mysql 服务是否正常运行，如果未运行，就删除 redo log ，然后重启 mysql 服务，已运行就不管。话说工厂也不至于全厂都停电吧，像是一些监控设备，难道人走了也断电吗？要工厂单独拉一条不断电的线就行了，每天强制断电这不是折磨服务器吗，硬盘的寿命肯定长不了

这个问题说不建议数据库安装到容器中，主要的考量应该还是容器部署性能有下降。性能足够的情况我觉得容器化部署挺方便的

@xaoflysho 我的 13 经常卡，本来想今年换 16 的，但感觉今年的 16 像个半成品，而且今年的安卓也挺强的，估计明年的 iPhone 会挤牙膏多一些吧。现在我的 13 电池健康度还有 89%，再忍一年换 17pro 吧

@yinmin 这样做前端是简单了，后端服务器压力平白无故多做很多无用功。我觉得每隔几分钟主动 ping 一次，取最快的那个域名，如果最快的那个域名也超时，就主动 ping 一次，更新域名列表，再用最快的域名尝试一次，还是超时就提示用户服务不可用吧