hibernate报类型转换异常

本文解决了一个Hibernate在更新标记版本字段时出现的NullPointerException问题,原因是数据库字段默认值为null,导致类型转换失败。

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

java.lang.NullPointerException
at org.hibernate.type.LongType.next(LongType.java:76)
at org.hibernate.type.LongType.next(LongType.java:40)
at org.hibernate.engine.Versioning.increment(Versioning.java:131)
atorg.hibernate.event.def.DefaultFlushEntityEventListener.getNextVersion(DefaultFlushEntityEventListener.java:406)
at org.hibernate.event.def.DefaultFlushEntityEventListener.scheduleUpdate(DefaultFlushEntityEventListener.java:296) 
at org.hibernate.event.def.DefaultFlushEntityEventListener.onFlushEntity(DefaultFlushEntityEventListener.java:155)
at org.hibernate.event.def.AbstractFlushingEventListener.flushEntities(AbstractFlushingEventListener.java:219)
at org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:99)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:50)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1216)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:383)
at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:133)
at org.springframework.orm.hibernate3.HibernateTransactionManager.doCommit(HibernateTransactionManager.java:558)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:662)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:632)
at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:319)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:116)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at com.saicmotor.framework.exception.MethodExceptionAdvice.invoke(MethodExceptionAdvice.java:20)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at com.sun.proxy.$Proxy382.doSaveECUList(Unknown Source)
at com.saicmotor.gbom.webapp.action.tggb.GbECUChangeAction.executeEcu(GbECUChangeAction.java:182)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.apache.commons.beanutils.MethodUtils.invokeMethod(MethodUtils.java:216)
at com.saicmotor.framework.webapp.action.BaseDataGridAction.dynamicInvoke(BaseDataGridAction.java:1021)
at sun.reflect.GeneratedMethodAccessor1125.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

    报数据类型错误,说明是转换类型的时候错误。要么存在垃圾数据,要么代码中没有准换类型,或者是数据库中有字段类型不匹配。但是无法定位到是哪里出错了,通过跟踪代码发现,是标记版本的地方出现了类型错误。在hibernate中是体重没有标记字段是version的字段,最终找到有使用@version标注的字段。
    Bug:数据库字段定义了一个长整形字段,但是默认填充为null。
    Bug原因:查询得到的数据包含此字段,但是对数据进行修改时,由于null和正行之间无法转换所以报错类型转换错误。
解决方案:修改数据库默认值为0
<think>好的,我现在需要回答用户关于Java项目包结构的问题。用户之前已经询问过数据库开发规范,现在转向Java项目的结构,可能是想了解如何组织他们的Java项目代码。首先,我要回想一下常见的Java项目包结构标准,比如Maven的约定,以及一些行业内的最佳实践。 用户可能是一个刚入门的开发者,或者是需要规范项目结构的中级开发者。他们可能对包命名、分层架构(如MVC)、模块化设计等方面感兴趣。需要确保回答清晰,结构分明,提供足够的示例和解释,同时涵盖不同的项目类型,比如传统Web应用、Spring Boot项目、多模块项目等。 首先,我应该从包结构的基本原则开始,比如按功能分包、分层分包,或者按模块分包。然后详细说明每层的职责,例如controller、service、repository、model等。同时,提到一些常见的包名,如config、util、exception等,并解释它们的用途。 还需要注意不同的项目类型可能有不同的结构,比如传统的Spring MVC项目和Spring Boot项目可能有细微差别,多模块项目如Maven或Gradle多模块结构也需要说明。此外,可能用户对测试代码的结构也有疑问,所以应该包括测试包的位置,比如src/test/java下的相同包结构。 另外,用户可能关心如何避免常见的包结构错误,比如循环依赖、包过大或过小的问题,以及如何保持结构的一致性。可能需要给出一些最佳实践,如避免深层嵌套包、合理使用模块化拆分等。 最后,应该提供示例结构,用树状图或代码块展示典型的包结构,并附上解释,帮助用户直观理解。同时,提醒用户根据项目规模和团队规范进行调整,但保持一定的统一性以利于维护和协作。 需要确保语言简洁,避免技术术语过多,必要时进行解释。同时,检查是否有遗漏的部分,比如资源文件的位置(如配置文件、静态资源),以及第三方库的管理等,是否需要包含在包结构介绍中。可能资源文件的位置也是结构的一部分,可以简要提及。 总结来说,回答应该包括: 1. Java项目包结构的基本原则 2. 常见的分层结构(如MVC) 3. 各层的职责和示例包名 4. 不同项目类型的结构差异(如Spring Boot) 5. 多模块项目的结构 6. 测试代码的结构 7. 资源文件和配置文件的组织 8. 最佳实践和常见错误避免 9. 示例结构图示或代码块 需要确保信息准确,结构清晰,易于理解,并针对用户可能的实际应用场景提供实用建议。</think>以下是 Java 项目包结构的通用规范和常见分层方式,适用于 **Web 应用、微服务、模块化项目**等场景: --- ## **1. 核心分层原则** ### **按职责分层** - **垂直分层**:按功能职责划分层级(如 Controller、Service、DAO)。 - **水平分层**:按业务模块划分包(如 `user`、`order` 模块)。 ### **按技术分层** ```lua com.example.project ├── config -- 配置类(Spring Boot 配置、安全配置等) ├── controller -- 请求入口层(REST API/Web 控制器) ├── service -- 业务逻辑层(接口+实现类) ├── repository -- 数据访问层(JPA/Hibernate/MyBatis) ├── model -- 数据模型(DTO/Entity/VO) ├── util -- 工具类(日期处理、加密等) ├── exception -- 自定义异常和全局处理器 └── aspect -- AOP 切面(日志、权限、事务等) ``` --- ## **2. 常见包结构示例** ### **2.1 传统 Web 项目(Spring MVC)** ```lua com.example.ecommerce ├── controller │ ├── UserController.java │ └── OrderController.java ├── service │ ├── UserService.java │ ├── impl │ │ ├── UserServiceImpl.java │ │ └── OrderServiceImpl.java │ └── OrderService.java ├── dao -- 或 repository │ ├── UserDao.java │ └── OrderDao.java ├── model │ ├── dto -- 数据传输对象 │ ├── entity -- 数据库实体 │ └── vo -- 视图对象 └── config ├── WebConfig.java └── SecurityConfig.java ``` ### **2.2 Spring Boot 微服务项目** ```lua com.example.payment ├── application -- 应用层(用例编排、事务管理) ├── domain -- 领域层(领域模型、领域服务) ├── infrastructure -- 基础设施层(数据库、消息队列实现) ├── interfaces -- 接口层(REST API、RPC 接口) └── common -- 公共模块(通用工具、常量) ``` --- ## **3. 模块化项目结构** ### **Maven/Gradle 多模块项目** ```lua project-root ├── module-api -- API 定义(DTO、Feign 客户端) ├── module-common -- 公共依赖(工具类、通用配置) ├── module-dao -- 数据访问层(MyBatis Mapper) ├── module-service -- 业务逻辑实现 └── module-web -- Web 层(Controller 和启动类) ``` --- ## **4. 关键规范与最佳实践** ### **4.1 包命名规则** - **全小写**:包名使用小写字母(如 `com.example.user.service`)。 - **避免缩写**:除非广泛认可(如 `dto` 代替 `dataTransferObject`)。 - **禁止无意义包名**:如 `abc`、`misc`。 ### **4.2 分层依赖方向** - **单向依赖**:`Controller → Service → Repository`,禁止反向依赖。 - **领域驱动设计(DDD)**: - 领域层(domain)独立,不依赖基础设施层。 - 基础设施层实现领域层的接口。 ### **4.3 其他规范** - **DTO 隔离**:`controller` 层使用 `dto` 接收请求,避免直接传递 `Entity`。 - **接口与实现分离**: ```lua service ├── UserService.java -- 接口 └── impl └── UserServiceImpl.java -- 实现类 ``` - **测试代码结构**:测试类放在 `src/test/java` 的相同包路径下。 --- ## **5. 反模式示例** | 错误做法 | 改进方案 | |-------------------------|------------------------------| | 包名 `com.example.Util` | 改为 `com.example.util` | | Controller 直接调用 DAO | 必须通过 Service 层中转 | | Entity 直接暴露给前端 | 通过 DTO 转换 | | 包内混合多种职责 | 按功能拆分(如 `model` 与 `service` 分离) | --- ## **6. 典型项目结构示例** ### **Spring Boot + MyBatis 项目** ```lua src/main/java └── com.example.warehouse ├── config │ ├── MyBatisConfig.java │ └── SwaggerConfig.java ├── controller │ └── InventoryController.java ├── service │ ├── InventoryService.java │ └── impl │ └── InventoryServiceImpl.java ├── dao │ └── InventoryMapper.java -- MyBatis Mapper 接口 ├── model │ ├── dto │ │ └── InventoryRequest.java │ └── entity │ └── Inventory.java └── exception └── GlobalExceptionHandler.java ``` --- 通过合理的包结构设计,可以显著提升代码的 **可读性、可维护性和扩展性**。建议结合具体框架(如 Spring Boot、DDD)和团队规范进一步细化!
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值