没有 @MapKeyColumn 或 @MapKeyTemporal 注释的时间映射键的默认 TemporalType 是什么？
我正在为我的实习创建一个 JPA 2.0 Annotation 合规工具包。 现在，我想知道何时需要 @MapKeyTemporal 注释以及何时可选...
我知道当您使用 @MapKeyColumn 定义映射键的列时，可以通过查看来导出键应映射到的类型列的类型（以及列定义中的类型）。因此，在这种情况下，不需要 @MapKeyTemporal 注释。
当您附加@MapKeyTemporal注释时，列名称默认为ATTRIBUTE +“_KEY”。
当不注解@MapKeyColumn和@MapKeyTemporal时，列名默认为ATTRIBUTE + "_KEY"，但是key默认是什么类型呢？或者你应该得到一个错误？
我寻找了类似的情况，发现了@MapKeyEnumerated。 它是相同的，因为它与 @MapKeyColumn 相关，并且它是一个可以映射到多个数据类型的值（@MapKeyTemporal 的 java.sql.Date/java.sql.Time/java.sql.Timestamp ，以及EnumeratedType.ORDINAL/EnumeratedType.STRING（对于 @MapKeyEnumerated）。 我发现一处不同： @MapKeyEnumerated 有一个默认值。此默认值是 EnumeratedType.ORDINAL。
我的问题： 当使用具有基本类型为时间类型的映射键的映射时，映射键为了持久化而转换为的默认 TemporalType（根据 JPA 2.0）是什么？
I'm working on creating a JPA 2.0 Annotation compliancy kit for my internship.
Right now, I'm wondering when a @MapKeyTemporal annotation is required and when it's optional...
I know that when you define the column of the map key using @MapKeyColumn, the type the key should be mapped to can be derived by looking at the type of the column (and otherwise the type in the columndefinition). Thus, in this case, no @MapKeyTemporal annotation is necessary.
When you attach the @MapKeyTemporal annotation, the column name is defaulted to ATTRIBUTE + "_KEY".
When you don't annotate @MapKeyColumn and @MapKeyTemporal, the column name is defaulted to ATTRIBUTE + "_KEY", but to what type does the key default? Or are you supposed to get an error?
I looked for a similar situation and found @MapKeyEnumerated.
It's the same because it's related to @MapKeyColumn and it's a value that can be mapped to multiple datatypes (java.sql.Date/java.sql.Time/java.sql.Timestamp for @MapKeyTemporal, and EnumeratedType.ORDINAL/EnumeratedType.STRING for @MapKeyEnumerated).
I found one difference:
@MapKeyEnumerated has a default. This default is EnumeratedType.ORDINAL.
My question:
When using a map that has a map key whose basic type is a temporal type, what's the default TemporalType (according to JPA 2.0) to which the map key is converted for persistence?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
答案似乎是，当 java.util.Date 或 java.util.Calendar 用作地图的键时，没有默认类型。规范本身（我确实认为随规范一起提供的 javadocs 作为规范的一部分）对于 MapKeyTemporal 的使用非常严格。 MapKeyTemporal 声明的 Javadoc：
我认为，如此严格，他们忘记了您提供的情况，具有来自 MapKey 引用的属性的类型信息。在 MapKey 的情况下指定类型没有太大意义，因为类型已经在作为映射值的实体中指定。另外，实体中相应字段的映射键可能具有不同的时间类型，这也是不可取的。
如果未指定 MapKeyTemporal 并且没有其他方法来确定键的类型，则 EclipseLink（参考实现，尽管它并不总是遵循规范）会产生以下异常：
Answer seems to be, that there is no default type when java.util.Date or java.util.Calendar is used as key of the map. Specification itself (I do consider javadocs delivered with specification as part of specification) is very strict about usage of MapKeyTemporal. Javadoc for MapKeyTemporal claims:
I think with such a strictness they forgot case that you present, having type information from attribute referenced by MapKey. It does not make too much sense to specify type in the case of MapKey, because type is already specified in the entity that is value of the map. Also allowing possibility to have different temporal type for key of the map for corresponding field in the entity is not desirable.
If MapKeyTemporal is not specified and if there is no other way to figure out type of the key, EclipseLink (reference implementation, though it is not always following specification) produces following exception:
基本上，您并不是在询问 MapKeyTemporal 是否有默认类型，而是询问 JPA 2.0 或规范的实现是否使用 Temporal Types 的默认值。
这意味着数据库中在日期和时间戳之间存在更重要的类型，但情况可能并非如此。
另外，如果你有一个 Calendar，实现可能会调用 getTime()，然后从那里构造一个新的 Sql 类型，它如何决定实现？
提醒 ：
时间存在的第一个原因很简单，因为 java.util.Date 类的键可以是 Java 中的三种时间类型（Time、Timestamp 和 sql.Date）中的任何一种，而这在 Java 中并不重要，在这些是不同类型的数据库中确实如此。
如果我不指定时间类型，没有什么可以阻止我为同一实体使用不同的 sql 类型，从而在运行时中断。
Basically, you are not asking if there is a default type for MapKeyTemporal but if implementations of JPA 2.0 or the spec are using a default value for Temporal Types.
Which implies that there is a more important type in a database between Date and Timestamp, that is probably not the case.
Also if you have a Calendar, the implementation probably calls getTime() and then constructs a new Sql type from there, how does it decide on the implementation ?
Reminder :
The first reason for the existence of temporal is simply because a key with the class java.util.Date can be either of the three time types in Java (Time, Timestamp and sql.Date), while this doesn't matter in Java, it does in a database where these are distinct types.
If I do not specify a temporal type, nothing stops me from having different sql types for the same Entity, breaking at runtime.