问题标签 [jpa]

有没有办法在 Maven 项目中设置第二个 persistence.xml 文件，以便它用于测试而不是用于部署的普通文件？

我尝试将 persistence.xml 放入 src/test/resources/META-INF，它被复制到 target/test-classes/META-INF，但似乎是 target/classes/META-INF（来自 src/main 的副本/resources) 得到首选，尽管mvn -X test以正确的顺序列出类路径条目：

我希望能够针对简单的 hsqldb 配置运行测试，而无需更改 JPA 配置的部署版本，最好是在项目签出后直接进行，无需进行任何本地调整。

我正在使用 Java 和 Hibernate 的 JPA 实现构建一个数据库 Web 应用程序。应用程序跟踪对象。它还必须从遗留源批量导入对象。

例如，假设我们正在跟踪人员。该数据库有名为 Person 和 Address 的表。有对应的 JPA 实体和 DAO 类。

在 JPA 层之上是负责各种操作的服务层。一个操作是从外部遗留源（例如电话簿中的人）导入一组可能很大的数据。对于每个人，它必须检查它是否已经存在于数据库中。然后它必须根据需要创建或更新人员。每个人都有一个地址，因此还必须进行适当的交叉引用和地址创建。

我的问题是，对于大型数据集，此操作可能会很慢。我目前的算法是：

你会建议什么来提高性能？

在我的脑海中，我能想到：

1. 更改导入逻辑以使用查询检索数据并将其存储到数据库。例如，不是在 for 循环中检查人员是否存在，而是在一个查询中将所有人员键提交到数据库，该过程每个检索到的人员在内存中。
2. 在 DAO 类中添加我自己的缓存。
3. 使用外部缓存解决方案（例如 memcached）。

我总是可以通过重组以最小化查询来选择#1。缺点是我的服务层现在非常了解 DAO 层。它的实现现在由较低的数据库层决定。还有其他问题，例如使用过多的内存。这种从数据库中抓取然后在内存中处理的方法似乎非常本土化，并且与 JPA 等现成的解决方案背道而驰。我很好奇其他人在这种情况下会怎么做。

编辑：缓存无济于事，因为在循环中被查询的每个人都是不同的。

我正在尝试通过观察所有更改然后立即持久化有问题的对象来创建一个使对象模型与数据库保持同步的应用程序。模型中的许多对象在大型列表或树中都有子对象。

当我从数据库加载一个对象时，我依靠一种单向级联关系来检索它的所有子对象并将它们包含在应用程序中。

但是，可以更改需要持久性的父对象中的字段，并且我可以确定没有任何子对象受到影响。所以我想持久化父级，而不用所有级联子级持久化访问数据库。

例如

持久化父对象时如何覆盖级联选项？或者我应该将其设置为 REFRESH 并确保我永远不需要级联持久化？

有人可以透视JPA和Hibernate之间的区别。还是这些互补的概念可以一起使用？

我想创建一个使用 RPC 的简单 Google Web Toolkit 应用程序。对于持久性，我想使用 Java Persistence API 之类的东西。

这是否意味着我必须使用像 Glassfish 这样的应用服务器？还是我可以坚持使用简单的 Web 容器？

就具体库而言，我应该如何进行？顶联？休眠？...

我有：“图像”1：许多“imageToTag”许多：1“标签”

我想发出一个查询，该查询将返回至少具有标签 [a, b, c] 的所有图像。我不清楚如何在 JPQL 中对此进行建模。我可以动态构建查询字符串，但这对性能和安全性不利。有任何想法吗？

我们使用带有 BMP（bean 管理的持久性）的 EJB2.x 实体 bean。EJB3 似乎不支持 BMP。我们曾希望保持最新状态并升级到 EJB3。有谁知道 3.0 中是否有任何 BMP 选项可用？

据我所知，使用 3.0，所有实体 bean 都必须使用 JPA 和定义为 ORM。有一些使用本机 SQL 的选项，但这仍然只是使用 JPA 实现 ORM 的一种方式。

我不确定是否有另一种 EJB3 方法可以实现与 EJB2.x BMP 实体 bean 相同的功能。我们目前使用标准的 ejbStore 方法通过本机 SQL 更新数据库，使用 ejbLoad 方法查找所有 bean 并在事务回滚时刷新 bean。我认为您可以使用 EJB3 会话 bean 来做到这一点，但我不确定。

也许我们应该迁移到 Spring 而不是迁移到 EJB3 bean。

因此，如果我的 JPA 查询是这样的： Select distinct p from Parent p left join fetch p.children order by p.someProperty

我正确地得到了由 p.someProperty 排序的结果，并且我正确地得到了我的 p.children 集合急切地获取和填充。但我想让我的查询类似于“按 p.someProperty，p.children.someChildProperty 排序”，以便填充在每个父对象中的集合由 someChildProperty 子排序。

当我考虑为这些调用实际生成的 sql 时，这似乎很直观，但当它尝试映射回分层对象时，我猜想更少。

我正在使用 Hibernate 的 JPA 实现，并且看到性能很差，因为为每个获取的实体发出了多个 SQL 查询。如果我使用连接的 JPA 查询，它只会生成一个 SQL 查询，但找不到行将为空关系。

例如，考虑这个简单的模式。一个人住在一个​​地址并受雇于一家公司。地址和雇主都是可选的，因此可以为空。

上面没有显示的是每个 JPA 实体都有某种 ID（键）：

我看到的问题是对 Person 的单个 JPA 查询会导致对数据库的多个 SQL 查询。例如，以下 JPA 查询：

导致 SQL 查询：

以及每个检索到的人的以下一对 SQL 查询：

这对性能有很大的影响。如果查询结果集为 1000 人，则生成 1+1000+1000=2001 条 SQL 查询。

所以我尝试通过强制加入来优化 JPA 查询：

或者：

这会导致一个带有一堆连接的 SQL 查询。问题是如果地址或雇主为空，则连接查询将找不到它。

所以我要么使用慢的无连接查询，要么使用不检索行的快速连接查询将使关系为空。我一定在这里遗漏了一些东西。肯定有一种快速和完整查询的方法。

Hibernate 是否有可行的替代方案？最好是不基于 JPA 的东西。

我们的问题是我们正在构建一个复杂的（例如，许多对象相互引用）有状态的 RIA 系统。似乎 Hibernate 被设计为主要用于一次性应用程序 - JSF 等。

问题主要是延迟加载。由于在初始化和实际加载惰性集合之间可能有多个 HTTP 请求，因此每个事务的会话是不可能的。一个长期存在的会话（每个应用程序一个）也不能很好地工作，因为一旦事务遇到障碍并引发异常，整个会话就会失效，因此延迟加载的对象会中断。然后有各种各样的东西对我们不起作用（比如隐式数据持久化来自初始化事务之外的数据）。

撇开我拙劣的解释不谈，最重要的是 Hibernate 做了我们不喜欢的魔法。似乎 TopLink 也好不到哪里去，它也是在 EJB 之上编写的。

因此，无状态持久层（甚至是足够亮的面向对象的数据库抽象层）是我们最需要的。

有什么想法，还是我在要求一些不存在的东西？

编辑：我为我模棱两可的术语感到抱歉，感谢大家的更正和有见地的回答。那些纠正我的人，你们都是正确的，我的意思是JPA，而不是EJB。