JDBC和Ibatis中的Date,Time,Timestamp处理

在此前,遇到过使用Ibatis操作Oracle时时间精度丢失的问题,昨天又遇到JDBC操作MySQL时间字段的问题,从网上看到各种式样的解释这些问题的博文/帖子,但多是雾里看花,不得要领。

  1. 理解JDBC中的时间类型
  2. MySQL与JDBC之间的类型映射
  3. Oracle与JDBC之间的类型映射
  4. Ibatis是怎么处理日期时间类型的
  5. 注释
  6. 参考资料

理解JDBC中的时间类型

java.sql包中包括三个类,Date, Time, 和 Timestamp,分别用来表示日期(无时间信息,eg: YYYY-MM-DD),时间(只处理时间,无日期部分, eg: HH:MM:SS)和时间戳(精确到纳秒级别)。在 它们都继承自java.util.Date。java.sql.Date和java.sql.Time都存有一个时间域,该时间域是精确到秒级别的,但是,他们只处理日期或者时间部分。在MySQL Connector/J(v5.1.13)的实现中可以看到,PrepareStatement#setDate 时会将时间重新format成”yyyy-MM-dd”格式。

因为历史遗留以及各种数据库本身的不同,各种JDBC实现中留下了格式各样的花招, 某些特殊场景下不遵照此情况可能也能工作,但不推荐这样做。

你必须根据你的实际需要来选择不同的类型,通常应该选用精确度与相应的数据库字段类型相比相同或者更高的JDBC类型

除此以外,还可以使用java.uitl.Date类型来处理时间。java.util.Date类型是上面各个类型的父类型,JDBC的API大都可以使用。

除此以外,在JDK1.6之前版本的构造java.sql.{Date|Time|TimeStamp}对象时存在性能问题,尤其是在多线程环境下更严重。这个Bug在这里。其原因是java.util.Date的相关方法调用了TimeZone.getDefaultRef(),而此方法是同步方法注1

MySQL的JDBC类型映射

DATEjava.sql.Date
DATETIMEjava.sql.Timestamp
TIMESTAMP[(M)]java.sql.Timestamp
TIMEjava.sql.Time
YEAR[(2|4)]If yearIsDateType configuration property is set to false, then
the returned object type is java.sql.Short. If set to true (the
default) then an object of type java.sql.Date (with the date
set to January 1st, at midnight).

MySQL的DATETIME、TIMESTAMP两种字段类型的显著区别在于TIMESTAMP的取值在’1970-01-01 00:00:01′ UTC 和 ‘2038-01-19 03:14:07′ UTC之间。

MySQL在时间处理方面也有一个问题,当Datetimes类型的字段的值为0000-00-00时取值方法会得到下面的异常:

Cannot convert value '0000-00-00 00:00:00' from column xx to TIMESTAMP

这个问题的原因在于,MySQL中默认使用0000-00-00等来表示时间的特殊值(参见文档)。而在Java中,并没有一个合适的方式来表示这个时间(因为Java中时间轴上0是1970-01-01 00:00:00),早于这个时间的用负数表示,这个最小的负数在时间轴上是表示不出来的。Connector/J提供了一个属性zeroDateTimeBehavior来解决此问题。

  • exception (the default), which throws an SQLException with an SQLState of S1009.(默认行为)
  • convertToNull, which returns NULL instead of the date.
  • round, which rounds the date to the nearest closest value which is 0001-01-01.

如下所示的jdbc连接将指定该行为转化为null值。

jdbc:mysql://localhost/myDatabase?zeroDateTimeBehavior=convertToNull

Oracle与JDBC之间的类型映射

DATEjava.sql.Date
DATEjava.sql.Time
TIMESTAMPjava.sql.Timestamp

Oracle数据库字段类型主要有DATE、TIMESTAMP。

在9i以后、11g以前的Oracle JDBC驱动中存在一个会丢失DATE类型字段的时间信息的bug,原因是其JDBC驱动将Oracle的Date类型处理为java.sql.Date类型,这就丢失了时间部分(看来对java.sql包下三种时间类型认识不足的问题还很普遍的)。关于这个问题,这篇帖子给出了不错的解释(墙外),此文中的方法适用于11g JDBC以前的各版本驱动。在11g JDBC驱动中,此问题已经解决了,Oracle 11g JDBC驱动的手册中也给出了解释注2

事实上,如果是使用Ibatis,pojo属性的类型设置为java.util.Date,确保 jdbcType不为 DATE或者TIME,则避免了这个bug。因为此时Ibatis会以java.sql.Timestamp来处理该字段。我专门对此做了验证,点此看测试项目源码

Ibatis是怎么处理日期类型的

注意:本文皆基于ibatis 2.3.4.726源码分析。不过根据我初略观察,Ibatis3也适用,但请遇到问题时有所留意。

在此前工作中碰到Oracle中的Date字段会只剩下日期部分的数据,丢失了,Google发现一些人的解决方法是将JDBCType指定为datetime。有人甚至自己编写一个自定义的TypeHandler来解决这个问题。其实这完全是瞎猫撞上死耗子,那个datetime根本没意义,却歪打正着。一般的错误都是如下的配置(或者是pojo的属性为java.sql.Date类型):

<sqlMap namespace="Info" >
  <resultMap id="Info" class="pojo.Info" >
    <result column="INFO_BEGINTIME" property="begin" jdbcType="DATE" />
    <result column="INFO_ENDTIME" property="end" jdbcType="DATE" />
  </resultMap>

此时不论你pojo.Info中的字段类型(或者的javaType属性)是java.util.Date还是java.sql.Date,最终都会丢失数据。实际上,在pojo.Info中的字段类型(或者javaType属性)为java.util.Date时,如果指定jdbcType为DATE或TIME(区分大小写),则将分别得到DateOnlyTypeHandler或TimeOnlyTypeHandler。如果你不指定jdbcType,或者指定一个错误的值,例如datetime,或者xxxx等,都会得到DateTypeHandler(日期时间都会处理)。

如果pojo.Info中的属性类型(或者配置中的javaType属性)是java.sql.Date,则选择处理handler类时不会使用jdbcType,而是根据属性类型得到SqlDateTypeHandler(只包含日期)。

在Ibatis的手册中,指出来jdbcType一般情况下是不用于判断处理方式的注3。大部分情况下是依据javaType或者pojo属性类型来判断处理方式,在少部分无法根据pojo属性类型判断的情况下才使用。如果你用java.util.Date对应到MySQL,则就是这种少数情况之一。因为MySQL可以将多个数据库字段类型映射到java.util.Date,所以需要指定是DATE还是TIME(必须是大写),如果不指定则默认是完整的日期时间(此时按JDBC的timestamp操作)。

针对ibatis对时间的处理,我写了个测试,点此看测试代码。

对于Ibatis操作Date/Time/DateTime,总结如下:

  • 将pojo的属性类型设置为java.sql.Date(或java.sql.Time, java.sql.Timestamp),此时会严格遵循这三种类型的语义。但此方法因存在前文中提到的性能问题,在JDK1.6以前的JDK版本中能少使用就少使用。
  • 如果你想在pojo中使用java.util.Date, 则要注意:
    • 完整的日期时间,要确保jdbcType为空,或为DATE,TIME以外的值
    • 只需要时间,要指定jdbcType=”TIME”
    • 只需要日期,要指定jdbcType=”DATE”

注释

注释1:Use oracle.sql.DATE or oracle.sql.TIMESTAMP rather than
java.sql.Date or java.sql.Timestamp if you are using JDK 1.5 or earlier versions or require maximum performance. You may also use the oracle.sql data type if you want to read many date values or compute or display only a small percentage. Due to a bug in all versions of Java prior to JDK 1.6, construction of java.lang.Date and java.lang.Timestamp objects is slow, especially in multithreaded environments. This bug is fixed in JDK 1.6.

注释2:Mapping SQL DATE Data type to Java Oracle Database 8i and earlier versions did not support TIMESTAMP data, but Oracle DATE data used to have a time component as an extension to the SQL standard. So, Oracle Database 8i and earlier versions of JDBC drivers mapped oracle.sql.DATE to java.sql.Timestamp to preserve the time component. Starting with Oracle Database 9.0.1, TIMESTAMP support was included and 9i JDBC drivers started mapping oracle.sql.DATE to java.sql.Date. This mapping was incorrect as it truncated the time component of Oracle DATE data. To overcome this problem, Oracle Database 11.1 introduces a new flag mapDateToTimestamp. The default value of this flag is true, which means that by default the drivers will correctly map oracle.sql.DATE to java.sql.Timestamp, retaining the time information. If you still want the incorrect but 10g compatible oracle.sql.DATE to java.sql.Date mapping, then you can get it by setting the value of mapDateToTimestamp flag to false.

注释3: Ibatis 2的手册中给出的jdbcType属性的解释:属性jdbcType用于显式地指定给本属性(property)赋值的数据库字段的数据类型。对于某些特定的操作,如果不指定字段的数据类型,某些JDBC Driver无法识别字段的数据类型。一个很好的例子是PreparedStatement.setNull(int parameterIndex, int sqlType)方法,要求指定数据类型。如果不指定数据类型,某些Driver可能指定为Types.Other或Types.Null。但是,不能保证所有的Driver都表现一致。对于这种情况,SQL Map API允许使用parameterMap子元素parameter的jdbcType属性指定数据类型。
正常情况下,只有当字段可以为NULL时才需要jdbcType属性。另一需要指定jdbcType属性的情况是字段类型为日期时间类型的情况。因为Java只有一个Date类型(java.util.Date),而大多数SQL数据库有多个-通常至少有3种。因此,需要指定字段类型是DATE还是DATETIME。
属性jdbcType可以是JDBC Types类中定义的任意参数的字符串值。虽然如此,还是有某些类型不支持(即BLOB)。本节的稍后部分会说明架构支持的数据类型。
注意!大多数JDBC Driver只有在字段可以为NULL时需要指定jdbcType属性。因此,对于这些Driver,只是在字段可以为NULL时才需要指定type属性。
注意!当使用Oracle Driver时,如果没有给可以为NULL的字段指定jdbcType属性,当试图给这些字段赋值NULL时,会出现“Invalid column type”错误。
<think>好的,我现在需要帮助用户解决一个问题:数据库中类型为date的字段,在Java实体类中应该定义成什么类型。首先,我得回忆一下数据库中的date类型Java中的日期时间类型之间的对应关系。 用户可能在使用像MySQL这样的数据库,因为不同的数据库对date类型的处理可能略有不同。比如,MySQL的DATE类型只包含日期(年月日),而其他数据库可能有类似的处理。Java中处理日期时间的类型有几个,比如java.util.Date、java.sql.Date,还有Java 8引入的java.time中的LocalDate等。 接下来,我需要考虑用户的具体使用场景。用户可能在开发一个使用Hibernate或者MyBatis这样的ORM框架的应用程序。如果是Hibernate,通常会推荐使用Java 8的日期时间API,比如LocalDate,因为Hibernate从5.x版本开始支持这些类型。而如果用户还在使用旧版本的Java,可能需要用java.util.Date或者java.sql.Date。 然后,我需要思考用户可能遇到的问题。例如,使用java.util.Date时会包含时间部分,而数据库中的date类型可能只存储日期,这可能导致时间部分被忽略或出错。这时候,使用java.sql.Date可能更准确,因为它只包含日期部分。但java.sql.Date是继承自java.util.Date,使用时需要注意时区的问题。 另外,用户可能关心如何在不同框架中正确映射这些类型。比如,在MyBatis中,可能需要注册类型处理器来处理java.time.LocalDate到数据库date类型的转换。或者在使用JPA时,如何通过注解来指定映射关系,比如@Temporal(TemporalType.DATE)来指定java.util.Date或java.sql.Date只映射日期部分。 还要考虑用户是否希望使用最新的Java特性,比如Java 8的日期时间API,这些类型更清晰,并且避免了旧API的一些问题,比如线程安全性可变性。推荐用户使用LocalDate可能更好,但需要确保他们的环境支持Java 8及以上版本。 可能用户没有提到但需要注意的点包括时区处理。数据库中的date类型通常没有时区信息,而Java中的LocalDate也不包含时区,所以它们是匹配的。但如果用户的应用需要考虑时区,可能需要使用其他类型,比如ZonedDateTime,但这时候数据库可能需要使用timestamp with time zone类型,而不是date。 此外,用户可能在使用JSON序列化时遇到问题,比如将LocalDate序列化为字符串格式,可能需要配置相应的序列化器,比如Jackson的JavaTimeModule。这也是需要注意的地方,但用户可能没有提到。 总结一下,用户的核心需求是将数据库的date类型正确映射到Java实体类中的适当类型,避免数据转换错误,并确保在不同层(如持久层、业务层、展示层)之间正确处理日期数据。需要根据用户的具体技术栈需求,推荐最合适的类型,并指出注意事项。</think>在数据库中定义为 `DATE` 类型的字段(仅存储日期,不含时间),在 Java 实体类中推荐以下定义方式,根据技术场景选择最合适的类型: --- ### 一、基础方案(传统方式) #### 1. **`java.sql.Date` 类型** - **适用场景**:纯 JDBC 操作、需要严格匹配数据库 DATE 类型 - **示例代码**: ```java import java.sql.Date; public class User { private Date birthDate; // 仅包含年月日 // Getter/Setter } ``` - **注意点**: - 调用 `PreparedStatement` 时无需额外转换 - 使用时需注意 `toString()` 格式为 `yyyy-MM-dd` #### 2. **`java.util.Date` + 注解** - **适用场景**:JPA/Hibernate 框架 - **需配合注解**: ```java import javax.persistence.Temporal; import javax.persistence.TemporalType; import java.util.Date; public class User { @Temporal(TemporalType.DATE) // 强制截断时间部分 private Date birthDate; } ``` - **缺点**:底层仍存储时间部分(值为 `00:00:00`) --- ### 二、现代方案(推荐) #### 1. **`java.time.LocalDate`(Java 8+)** - **最佳实践**: ```java import java.time.LocalDate; public class User { private LocalDate birthDate; // 直接映射 DATE 类型 } ``` - **优势**: - 类型语义明确(仅日期) - 不可变对象(线程安全) - 内置日期计算 API(如 `plusDays()`) - **框架支持**: | ORM 框架 | 是否需要转换器 | |-----------------|-----------------------------| | Hibernate 5.2+ | 自动支持 | | MyBatis | 需注册 `LocalDateTypeHandler` | | Spring Data JPA | 直接使用 | #### 2. **JPA 2.2+ 标准映射** ```java @Column(name = "birth_date", columnDefinition = "DATE") private LocalDate birthDate; ``` --- ### 三、类型转换对照表 | 数据库类型 | Java 类型 | 精度匹配 | 时区处理 | |------------|--------------------|----------|----------------| | DATE | `LocalDate` | 完全匹配 | 无时区 | | DATE | `java.sql.Date` | 精确到日 | 依赖 JVM 时区 | | DATE | `java.util.Date` | 包含时间 | 需手动截断时间 | --- ### 四、不同场景下的序列化处理 #### 1. **JSON 序列化(Spring Boot 示例)** ```java @JsonFormat(pattern = "yyyy-MM-dd") // 指定输出格式 private LocalDate birthDate; ``` - 需在 `pom.xml` 添加依赖: ```xml <dependency> <groupId>com.fasterxml.jackson.datatype</groupId> <artifactId>jackson-datatype-jsr310</artifactId> </dependency> ``` #### 2. **MyBatis 类型处理器** ```xml <!-- mybatis-config.xml --> <typeHandlers> <typeHandler handler="org.apache.ibatis.type.LocalDateTypeHandler"/> </typeHandlers> ``` --- ### 五、常见问题解决方案 1. **时区偏移问题** 当数据库时区与应用时区不一致时,建议: - 统一使用 UTC 时间存储 - 在 JDBC URL 中添加时区参数: ``` jdbc:mysql://host/db?useLegacyDatetimeCode=false&serverTimezone=Asia/Shanghai ``` 2. **日期范围校验** 使用 Bean Validation: ```java @PastOrPresent private LocalDate birthDate; @Future private LocalDate expireDate; ``` --- **最终建议**: - 新项目 **优先选择 `LocalDate`**(需 Java 8+) - 旧系统维护 **使用 `@Temporal(TemporalType.DATE)` + `java.util.Date`** - 涉及跨时区系统 **强制使用 UTC 时间存储**
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值