继承jpa Repository 写自定义方法查询

本文探讨了在Spring Data JPA中自定义查询方法的命名规则,解释了项目启动时报错的原因,并提供了遵循规则的解决方案及自定义查询的替代方案。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

今天在写jpa查询的时候,遇到了添加自定义方法,项目启动报错原因,现总结如下:

首先定义实体类

@Entity
@Table(name = "user")

Class User{

     @Id
    @GeneratedValue 

      int id;

      @Column

      String age;

      @Column

      String school;

      @Column

      String userName;

  set,get方法 (省略)

 

}
 

public interface UserRepository extends JpaRepository<User, Long> {

      List<User> findByUsernameLike(String username);

     List<User> aaa();

}

启动项目时,项目报错提示信息为:org.springframework.data.mapping.PropertyReferenceException: No property aaa found for type com.fpi.safety.common.entity.po.User

再将List<User> aaa();方法去掉后,项目又可以正常启动运行

是什么原因呢?

经查找,原来是继承jpa,必须满足一些规则,规则如下

 

Spring Data JPA框架在进行方法名解析时,会先把方法名多余的前缀截取掉,比如find,findBy,read,readBy,get,getBy,然后对剩下的部分进行解析。

假如创建如下的查询:findByUserName(),框架在解析该方法时,首先剔除findBy,然后对剩下的属性进行解析,假设查询实体为User

1:先判断userName(根据POJO规范,首字母变为小写)是否为查询实体的一个属性,如果是,则表示根据该属性进行查询;如果没有该属性,继续第二步;

2:从右往左截取第一个大写字母开头的字符串此处是Name),然后检查剩下的字符串是否为查询实体的一个属性,如果是,则表示根据该属性进行查询;如果没有该属性,则重复第二步,继续从右往左截取;最后假设用户为查询实体的一个属性;

3:接着处理剩下部分(UserName),先判断用户所对应的类型是否有userName属性,如果有,则表示该方法最终是根据“User.userName”的取值进行查询;否则继续按照步骤2的规则从右往左截取,最终表示根据“User.userName”的值进行查询。

4:可能会存在一种特殊情况,比如User包含一个的属性,也有一个userNameChange属性,此时会存在混合。可以明确在属性之间加上“_”以显式表达意思,比如“findByUser_NameChange )“或者”findByUserName_Change()“

从上面,我们可以得知,jap在解析是,aaa在user类中是没有属性的,所以报错No property aaa found.

如果我们想要使用jap框架,又不想再多增加一个自定义类,则必须符合其命名规则

如果,你记不住jpa的规则也没关系,你可以自己再多写一个类来实现自定义查询方法

如下:

. 自定义一个接口,该接口用来声明自己额外定义的查询。

public interface UseerRepositoryTwo {

    public List<User> searchUser(String name, int id);
}

2. 创建一个接口,该接口 extends JpaRepository 或者 CurdRepository, 以及上面自己定义的接口 UseerRepositoryTwo

public interface UserRepositoryTwoService extends CrudRepository<LogDTO, Integer>, CustomizedLogRepository {

}

3. 实现UserRepositoryTwoService
注意此处的类名,必须以 2 中创建的接口的名字UserRepositoryTwoService,后面加上 Impl 来声明,而不是写成 UseerRepositoryTwoImpl

public class UserRepositoryTwoServiceImpl implements UserRepositoryTwoService {

    @Autowired
    @PersistenceContext
    private EntityManager entityManager;

    @Override
    public List<User> searchLogs(int Id, String name) {
        ......
    }
}

自己在写自定义实现即可
 

### JPA 中 `JpaSpecificationExecutor` 与 `JpaRepository` 的区别 #### 功能对比 `JpaRepository` 提供了一组标准的 CRUD 方法以及分页和排序功能,适用于大多数基本的数据访问需求。通过继承 `JpaRepository<T, ID>` 接口,开发者可以立即获得诸如保存、删除、查找等常用操作的支持[^4]。 而 `JpaSpecificationExecutor` 则专注于动态查询构建的功能。它允许使用 Specifications 来创建复杂的条件组合,从而实现更灵活多变的查询逻辑。Specifications 可以看作是一种可重用的查询片段定义方式,能够方便地拼接多个查询条件来满足不同的业务需求。 ```java public interface IBigDao extends JpaRepository<BigEntity, Long>, JpaSpecificationExecutor<BigEntity> { BigEntity findByAlarmContentAndAlarmState(String alarmContent, EAlarmState alarmState); } ``` 此代码展示了如何在一个自定义仓库接口中同时集成这两种能力,既保留了基础的操作又增强了高级查询的能力。 #### 使用场景 对于简单的数据存取任务或者固定模式下的检索请求来说,仅依赖于 `JpaRepository` 就已经足够强大并易于维护;然而当面对复杂且变化频繁的查询要求时,则推荐引入 `JpaSpecificationExecutor` 。这不仅有助于提高代码复用率,还能让应用程序更好地适应未来可能发生的改动或扩展。 #### 继承关系说明 值得注意的是,在 Spring Data JPA 的设计体系里,`QueryByExampleExecutor` 被视为 `JpaRepository` 的父级接口之一,意味着所有实现了前者特性的库也会自动拥有后者的一部分行为特性[^3]。不过这里提到的关系并不直接影响到 `JpaSpecificationExecutor` 和 `JpaRepository` 之间的差异比较。
评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值