Quarkus中使用Panache Reactive Repository无法持久化数据求助

核心问题点 #

• 错误嵌套Uni对象：服务类里用Uni.createFrom().item()把persistAll返回的Uni<Void>包装成了Uni<Uni<Void>>，后续的await()仅等待外层Uni完成，内层的持久化逻辑根本没被触发执行。
• 同步调用flush操作：仓库类中直接调用session.flush()是同步方法，违背了Mutiny响应式异步设计的原则，会导致事务逻辑异常中断。
• 冗余的SessionFactory管理：既然已经实现PanacheRepository，完全可以直接使用Panache内置的响应式API，无需手动注入和管理SessionFactory。

修正后的代码 #

1. 仓库类优化（推荐方案）

直接复用Panache的响应式事务与持久化能力，简化代码：

@ApplicationScoped
public class GraviteeIndexRepository implements PanacheRepository<GraviteeIndex> {

    public Uni<Void> persistAll(List<GraviteeIndex> graviteeIndices) {
        return Panache.withTransaction(() -> persistAll(graviteeIndices));
    }
}

如果需要自定义Session逻辑，需改用异步flush的链式调用：

@ApplicationScoped
public class GraviteeIndexRepository implements PanacheRepository<GraviteeIndex> {

    @Inject
    Mutiny.SessionFactory sf;

    public Uni<Void> persistAll(List<GraviteeIndex> graviteeIndices) {
        return sf.withTransaction(session -> 
            session.persistAll(graviteeIndices)
                   .chain(session::flush) // 用异步链式调用替代同步flush
        );
    }
}

2. 服务类修正

移除Uni嵌套，正确使用await()等待异步操作完成：

@ApplicationScoped
public class GraviteeIndexService {

    private final GraviteeIndexRepository graviteeIndexRepository;

    public GraviteeIndexService(GraviteeIndexRepository graviteeIndexRepository) {
        this.graviteeIndexRepository = graviteeIndexRepository;
    }

    public void saveAll(List<GraviteeIndex> graviteeIndices) {
        graviteeIndexRepository.persistAll(graviteeIndices)
                               .await().indefinitely();
    }
}

额外注意事项 #

• 确保pom.xml中引入的是响应式依赖：比如quarkus-hibernate-reactive-panache与对应数据库的响应式驱动（如quarkus-reactive-pg-client），而非命令式的quarkus-hibernate-orm-panache。
• 实体类当前依赖外部传入UUID作为ID，需保证每次传入的UUID唯一，避免主键冲突。

内容的提问来源于stack exchange，提问作者François F.