java中的接口是类吗
618
2022-10-20
基于Spring Boot使用JpaRepository删除数据时的注意事项
问题:
在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] LgnqWvBcwjine: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
{
}
调用代码也是简单明了
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框架的两个坑。
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。
发表评论
暂时没有评论,来抢沙发吧~