wuhunyu

@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 服务，已运行就不管。话说工厂也不至于全厂都停电吧，像是一些监控设备，难道人走了也断电吗？要工厂单独拉一条不断电的线就行了，每天强制断电这不是折磨服务器吗，硬盘的寿命肯定长不了