- 1 前言
- 2 项目元数据
- 3 使用条件
- 4 玩转Spring Data Repositories
- 4.1 核心概念
- 4.2 查询方法
- 4.3 repository接口定义
- 4.3.1 调整repository定义
- 4.4 定义查询方法
- 4.4.1 查询策略
- 4.4.2 创建查询
- 4.4.3 属性表达式
- 4.4.4 处理特殊参数
- 4.4.5 限定查询结果集大小
- 4.4.6 Stream处理查询结果
- 4.4.7 异步处理查询结果
- 4.5 创建repository实例
- 4.5.1 XML配置
- 4.5.2 JavaConfig
- 4.5.3 独立使用
- 4.6 自定义repository实现
- 4.6.1 为单一的repositories添加自定义方法
- 4.6.2 为所有的repositories添加自定义方法
- 4.7 扩展Spring Data
- 4.7.1 WEB支持
- 4.7.2 Repository填充
- 5 Elasticsearch Repositories
- 5.1.1 Spring命名空间
- 5.1.2 基于注解的配置
- 5.1.3 使用CDI
- 5.2.1 查询策略
- 5.2.2 创建查询
- 5.2.3 使用@Query注解
- 5.3 其他Elasticsearch操作的支持
- 5.3.1 构建Filter
- 5.3.2 利用Scan和Scroll处理大结果集
- 6.1 附录A 命名空间参考文档
- 6.2 附录B Populators命名空间参考文档
- 6.3 附录C Repository查询关键字
- 6.4 附录D Repository查询返回类型
文章来源于网络收集而来,版权归原创者所有,如有侵权请及时联系!
4.4.3 属性表达式
接下来我们来看看属性表达式。在之前的例子中,属性表达式只涉及到被管理的实体类的直接属性,在创建查询时我们已经确保解析出的属性是被管理实体类的属性之一。实际上,我们可以定义嵌套属性。假设Person类有一个Address,Address中又有ZipCode。在这种情况下,下面方法的方法名会通过x.address.zipCode来检索属性。
List<Person> findByAddressZipCode(ZipCode zipCode);
Spring Data的查询构造器会先把AddressZipCode当做一个整体,检查其是不是实体类的一个属性。如果是,就使用这个属性。如果不是,会按照驼峰式从右向左进行分割,再进行属性匹配。在上面的例子中,会将AddressZipCode分为AddressZip和Code。如果第一次分割之后还没有找到相匹配的属性,构造器会左移分割点重新进行分割,分为Address和ZipCode,并继续解析是否有相匹配的属性。 在大多数情况下,构造器都能够正确的解析出相匹配的属性。但在某些特殊情况下,可能会选择了错误的属性。假设Person类中除了address外,还有一个addressZip属性。那么构造器会在第一次分割后就匹配到相应的属性,然后报错(因为addressZip中没有code属性)。 为了避免的解析的歧义问题,我们可以在方法名中使用'_'符号来显式的表达意图,更改后的方法名如下:
List<Person> findByAddress_ZipCode(ZipCode zipCode);
因为构造器已经将下划线作为保留字符,所以强烈建议开发者遵循标准的Java命名规范,不要在属性名中使用下划线,采用驼峰式命名。
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
![扫码二维码加入Web技术交流群](/public/img/jiaqun_03.jpg)
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论