问题:
在Spring Boot中使用JpaRepository的deleteById(ID id)方法删除数据时,首先要使用existsById(ID id)方法判断数据是否存在。如果存在,再删除。
否则,删除一个id不存在的数据会抛出org.springframework.dao.EmptyResultDataAccessException异常:
2019-01-02 15:57:24.122 WARN org.springframework.boot.autoconfigure.orm.jpa.JpaBaseConfiguration$JpaWebConfiguration$JpaWebMvcConfiguration Line:234 - spring.jpa.open-in-view is enabled by default. Therefore, database queries may be performed during view rendering. Explicitly configure spring.jpa.open-in-view to disable this warning 2019-01-02 15:57:24.673 ERROR org.apache.catalina.core.ContainerBase.[Tomcat].[localhost].[/].[dispatcherServlet] Line:175 - Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is org.springframework.dao.EmptyResultDataAccessException: No class com.qiqi.model.entity.UserBean entity with id 33 exists!] with root cause org.springframework.dao.EmptyResultDataAccessException: No class com.qiqi.model.entity.UserBean entity with id 33 exists! at org.springframework.data.jpa.repository.support.SimpleJpaRepository.lambda$deleteById$0(SimpleJpaRepository.java:150) at org.springframework.data.jpa.repository.support.SimpleJpaRepository$$Lambda$798/1206249587.get(Unknown Source) at java.util.Optional.orElseThrow(Optional.java:290) at org.springframework.data.jpa.repository.support.SimpleJpaRepository.deleteById(SimpleJpaRepository.java:149) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.springframework.data.repository.core.support.RepositoryComposition$RepositoryFragments.invoke(RepositoryComposition.java:359) at org.springframework.data.repository.core.support.RepositoryComposition.invoke(RepositoryComposition.java:200) at org.springframework.data.repository.core.support.RepositoryFactorySupport$ImplementationMethodExecutionInterceptor.invoke(RepositoryFactorySupport.java:644) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186) at org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor.doInvoke(RepositoryFactorySupport.java:608) at org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor.lambda$invoke$3(RepositoryFactorySupport.java:595) at org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor$$Lambda$787/1363172555.get(Unknown Source) at org.springframework.data.repository.util.QueryExecutionConverters$$Lambda$786/1029051888.apply(Unknown Source) at org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor.invoke(RepositoryFactorySupport.java:595) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186) at org.springframework.data.projection.DefaultMethodInvokingMethodInterceptor.invoke(DefaultMethodInvokingMethodInterceptor.java:59) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
在使用其他方法时,例如:deleteAllByName(name),不进行判断也可以删除,不会抛出异常。
springboot的jpa数据库操作的坑
前一段用springboot写了篇 springboot整合多数据源小博文,从三个数据库里面抓取合适的数据。存在另外一个数据库里面。在客户生产环境运行了一段时间,感觉似乎很良好。
客户觉得意犹未尽,又提了点需求,顺便提了点bug,于是乎又改了改代码。客户居然提出一个问题,说有时候查不出数据来,过一会又好了,我在本地试了试,发现在本地竟然也存在这个问题。问题其实一直都有,只是似乎不影响什么,所以便没当一回事。
经过反复测试,原来是往数据库写数据的时候卡住了,有点奇怪。大概过程是先把表里面数据清除,然后再写入,数据不到1000条,居然耗时差不多10秒,什么springboot,什么jpa太不靠谱了吧?
看代码 ,Repository
package net.springboot.repository.sqlserver; import java.util.List; import org.springframework.data.jpa.repository.JpaRepository; import net.springboot.entity.sqlserver.RealData; public interface XXDataRepository extends JpaRepository<XXData, String> { }
调用代码也是简单明了
db.deleteAll(); db.saveAll(list); //组合list这里就不写了
其实说白了,没有自己的代码,都是springboot + jpa 框架实现的,框架难道有问题,这个一般不会吧。把SQL放出来看看。
原来这个样子,删除全表数据,居然是一条一条数据删除,批量保存居然是先查询一下,然后再插入,JPA难道不考虑效率的吗?
问题找到了,怎么解决了?删除功能好办,自己写SQL嘛,简单方便,翠花上川菜,代码拿来。
@Transactional @Modifying @Query(value = "TRUNCATE TABLE table",nativeQuery = true) int TruncateTable(); @Transactional @Modifying @Query(value = "delete from table",nativeQuery = true) int deleteTable();
效果是立竿见影,删除效率上来了。清空表里数据一秒不到。不过,后来又仔细看了一下,jpa似乎还提供了另外一个删除全部数据的方法 deleteAllInBatch,这个方法在删除前似乎没有查询,懒得做测试了,习惯了自己写SQL解决问题。
但是批量插入这个不好办了,总不可能自己写成一条一条插入啊,那还不如不改了。百度一下,网上说改一下配置文件即可。
spring.jpa.properties.hibernate.jdbc.batch_size=500 spring.jpa.properties.hibernate.jdbc.batch_versioned_data=true spring.jpa.properties.hibernate.order_inserts=true spring.jpa.properties.hibernate.order_updates=true
但是好像效果不行,show sql 还是一样,先查询后插入,效率依然不行。想了很多,百度了很多,为什么了,为什么啊?JPA这玩意为什么会在插入前查询一下了,查询又是怎么个查询方式了?这个应该与主键ID有关系。所以改一下实体类,id统一为uuid模式。
@Id @GenericGenerator(name = "id-generator", strategy = "uuid") @GeneratedValue(generator = "id-generator") @Column(name = "pid") public String pid;
效果明显,问题立马解决。但是有的系统主键ID是生成好的,有自己的规则,不可以随便uuid,比如我这个系统就是,都是在各个系统里面已经生成好了,而且还因为业务需要不能改。
没办法只有另加一个字段做为@id 虽然没啥实际意义,但是批量写入数据的问题得到彻底解决,你好,我好,大家好。
不过话说回来,插入前查询一下,这个功能是可以有,在大多数的业务场景也是很有用的。springboot的jpa就这样,在系统中,具体怎么用,码农们各显神通。
也算是趟过 springboot,jpa框架的两个坑。
以上为个人经验,希望能给大家一个参考,也希望大家多多支持自学编程网。
- 本文固定链接: https://www.zxbcw.cn/post/214644/
- 转载请注明:必须在正文中标注并保留原文链接
- QQ群: PHP高手阵营官方总群(344148542)
- QQ群: Yii2.0开发(304864863)