我想大家都知道 timestamp mysql中的列类型用于及时存储“时刻”。
根据localdatetime官方文档，此类为：
iso-8601日历系统中没有时区的日期时间，如2007-12-03t10:15:30。localdatetime是一个不可变的日期时间对象，表示日期时间，通常以年-月-日-小时-分-秒的形式查看
并且通常用于存储带有时间的日期，而不是时间上的“时刻”（它不会像其他“时刻”数据类型（如instant）那样使用utc作为参考来存储）。
那么为什么hibernateMap LocalDateTime 字段到 timestamp 数据库中的字段？据我所知，它们的用途不同！
这给我想储存生料的地方带来了麻烦 LocalDateTime 值，但hibernate会通过内部转换我的所有数据库来破坏这一点 datetime s到“时刻”优先（特别是java.sql.timestamp）
这是虫子吗？设计缺陷？还是我错了？
顺便说一下，我已经尝试过这样设置我的实体
public class MyEntity implements Serializable {
@Id
private Long id;
@Column(name = "my_date_time_field", columnDefinition = "DATETIME")
private LocalDateTime myDateTimeField = LocalDateTime.now();hibernate在从数据库中获取数据时仍然会进行一些awkard转换，因为它认为我获取的是“时刻”而不是“本地日期/时间”值（仍然使用 TimestampTypeDescriptor 在内部，它转换为 Timestamp 在做其他事情之前）。
pd：我知道用utc处理所有日期/时间是标准的。由于客户的要求，我不能这样做。他们只希望看到数据库中的本地日期和时间，而不希望看到它们被转换，即使它们位于不同的时区。他们明确地告诉我，他们不在乎“时刻”的概念，因为他们的业务根本就不是这样运作的（经过数周的解释和争论，我很确定他们知道这会带来什么后果）。
1条答案
按热度按时间vawmfj5a1#
之所以这样做是因为jdbc驱动程序只能支持
java.sql.Date,java.sql.Time及java.sql.Timestamp类型，并且没有检查驱动程序支持使用哪些类型的标准机制setObject对于参数。即使mysql驱动程序支持它，也无法知道是否任何过时的中间件抽象层不会尝试验证该参数并拒绝它。因此，为了确保最大的兼容性
java.time.*类型转换为java.sql.*类型，而jdbc驱动程序只提供java.time.*您必须对它们在内部的使用方式做出一些假设。这不是hibernate中的设计缺陷，而是他们在可用标准中对未定义行为的处理方法。即使jdbc标准中引入了解决这一问题的机制，支持在所有级别上传播到足够的程度，使他们能够利用它，也需要几年的时间。