是否可行和/或建议支持两个JPA实现？-IsitfeasibleandorrecommendedtosupporttwoJPAimplementations?

We noticed the same thing when we were using TopLink Essentials and migrated to EclipseLink. Our code broke in many places even though EclipseLink is based on the same code base!

当我们使用TopLink Essentials并迁移到EclipseLink时,我们注意到了同样的事情。尽管EclipseLink基于相同的代码库,但我们的代码在很多地方都破了!

We have found out that most of the cases were due to the fact that TopLink Essentials didn't adhere fully to JPA specification (for example native queries return List of Vectors etc.). I would expect that the portability between EclipseLink and Hibernate would be better, but probably not perfect.

我们发现大多数情况是由于TopLink Essentials没有完全遵守JPA规范(例如本机查询返回向量列表等)。我希望EclipseLink和Hibernate之间的可移植性会更好,但可能并不完美。

In some point of time you will probably want to use some vendor specific extensions, such as caching. For this reason I would recommend to pick a JPA provider and first use only functionality specified in the JPA spec. If after a while you are still happy with the specific provider, stick with it and start to take advantage of vendor specific functionality.

在某些时候,您可能希望使用某些特定于供应商的扩展,例如缓存。出于这个原因,我建议选择一个JPA提供程序,并首先只使用JPA规范中指定的功能。如果过了一段时间,您仍然对特定提供商感到满意,请坚持使用并开始利用特定于供应商的功能。

I don't think your choice of application server limits your JPA options or vice versa. At least I'm not aware of any limitations.

我不认为您选择的应用程序服务器会限制您的JPA选项,反之亦然。至少我不知道有任何限制。

No, it's not true - application servers do not enforce any JPA implementations and you should be able to use OpenJPA with various application servers. Just like you can use Hibernate anywhere you can use any other JPA implementation. Yes, you may have some jar conflicts and troubleshooting to get done before things get right...

不,这不是真的 - 应用程序服务器不强制执行任何JPA实现,您应该能够将OpenJPA与各种应用程序服务器一起使用。就像您可以在任何地方使用Hibernate一样,您可以使用任何其他JPA实现。是的,您可能会遇到一些jar冲突和故障排除,以便在事情正确之前完成...

No, it's not impractical to make your code work for two or more JPA implementations. But the purpose of this exercise without concrete need is rather impractical. In general, you are better off picking JPA implementation that satisfies your requirements the best... But, again, I can imagine circumstances when using different JPA implementations interchangeably may become a necessity: customer requirements, license constraints, different database support, different platform support (e.g. mobile, embedded, ...).

不,让您的代码适用于两个或更多JPA实现并不是不切实际的。但是,没有具体需要的这项工作的目的是相当不切实际的。一般情况下,最好选择最能满足您要求的JPA实现......但是,我可以想象,当交换使用不同的JPA实现时,情况可能成为必需:客户需求,许可限制,不同的数据库支持,不同的平台支持(例如移动,嵌入式,......)。

Usually, a JPA implementation is a superset of the specification. If you are careful to minimize the dependency on vendor specific features, the application should be portable.

通常,JPA实现是规范的超集。如果您小心地将对供应商特定功能的依赖性降至最低,则应用程序应该是可移植的。

But in practice there can be subtle differences between implemantations which make it hard to make an application truly cross-JPA.

但实际上,实现之间可能存在细微的差异,这使得很难使应用程序真正跨越JPA。

In my opnion it is best to stick to the standard as much as possible so that porting to an other JPA implementation should be possible with minimal changes. If you are developing an application for a specific company in a specific context it does not make much sense to test it against multiple JPA implementations and vice versa.

在我的意见中,最好尽可能坚持标准,以便尽可能少地更改移植到其他JPA实现。如果您正在特定上下文中为特定公司开发应用程序,则针对多个JPA实现进行测试没有多大意义,反之亦然。