如何使用 JDOQL 查询与 datanucleus-appengine 2.0.0-final 来应用提取组
升级到 datanucleus-appengine 的 2.0.0 最终版本后,通过查询 API 使用 JDOQL 查询时,现在似乎会忽略提取组。我不确定这是库中的错误还是我做错了。
我定义了一个“用户”实体,其中包含对其他实体的多个 1:M 列表引用。我们通过获取组来控制这些引用的获取,例如:
@PersistenceCapable(identityType = IdentityType.APPLICATION, detachable="true")
@FetchGroups({@FetchGroup(name="bits",
members=@Persistent(name="userHistory"),
@Persistent(name="userBranding")}),
@FetchGroup(name="content", members={@Persistent(name="userContent")})})
public class User implements Serializable {
@PrimaryKey
@Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
private String username;
@Persistent
private String email;
@Persistent(mappedBy = "contentUser", defaultFetchGroup = "false")
@Element(dependent = "true")
@Order(extensions = @Extension(vendorName = "datanucleus", key = "list-ordering",value="contentKey asc"))
private List<Content> userContent;
@Persistent(mappedBy = "historyUser", defaultFetchGroup = "false")
@Element(dependent = "true")
@Order(extensions = @Extension(vendorName = "datanucleus", key = "list-ordering", value = "createdDate asc"))
private List<History> userHistory;
@Persistent(mappedBy = "brandingUser", defaultFetchGroup = "false")
@Element(dependent = "true")
private List<MediaBranding> userBranding;
...
}
根据上面的定义,我的理解是:
- 当仅使用默认获取组时,不会获取任何关系。
- 如果指定了“bits”获取组,则应获取 userHistory 和 userBranding。
- 如果指定了“content”提取组,则应提取 userContent。
当使用 JDOQL 通过电子邮件字段获取用户时,无论指定哪个获取组,都不会获取任何关系。如果我使用 getById() 来获取用户,则获取组将按预期应用。
我已关闭 L2 缓存(在 jdoquery.xml 中设置为 NONE)。
我用来获取的测试用例如下所示(使用版本 2.0.0-final 失败,使用版本 1.0.10 通过)。
@SuppressWarnings("unchecked")
@Test
public void testAddRetrieveUserByJDOQLQueryFetchGroups() {
PersistenceManager pm;
User u = persistUserAndFriends();
pm = getPMF().getPersistenceManager();
User result = null;
try {
pm.getFetchPlan().addGroup("bits");
pm.getFetchPlan().addGroup("content");
log.info("Groups in fetch plan: " + pm.getFetchPlan().getGroups());
Query query = pm.newQuery(User.class);
query.setFilter("email == emailParam");
query.declareParameters("java.lang.String emailParam");
List<User> results = (List<User>) query.execute("[email protected]");
assertEquals(1, results.size());
result = results.get(0);
pm.makeTransient(result, true);
} finally {
pm.close();
}
assertNotNull("User history should be fetched", result.getUserHistory());
assertNotNull("User branding should be fetched", result.getUserBranding());
assertEquals("Should be two history children", 2, result.getUserHistory().size());
assertEquals("Should be two branding children", 2, result.getUserBranding().size());
assertEquals("Should be a content child", 1, result.getUserContent().size());
}
我是否以错误的方式处理这个问题?
After upgrading to the 2.0.0-final version of datanucleus-appengine, fetch groups now appear to be ignored when using JDOQL queries via the Query API. I'm not sure whether it's a bug in the library or I'm doing this wrong.
I have a 'User' entity defined which contains multiple 1:M List references to other entities. We control the fetching of these references via fetch groups, e.g:
@PersistenceCapable(identityType = IdentityType.APPLICATION, detachable="true")
@FetchGroups({@FetchGroup(name="bits",
members=@Persistent(name="userHistory"),
@Persistent(name="userBranding")}),
@FetchGroup(name="content", members={@Persistent(name="userContent")})})
public class User implements Serializable {
@PrimaryKey
@Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
private String username;
@Persistent
private String email;
@Persistent(mappedBy = "contentUser", defaultFetchGroup = "false")
@Element(dependent = "true")
@Order(extensions = @Extension(vendorName = "datanucleus", key = "list-ordering",value="contentKey asc"))
private List<Content> userContent;
@Persistent(mappedBy = "historyUser", defaultFetchGroup = "false")
@Element(dependent = "true")
@Order(extensions = @Extension(vendorName = "datanucleus", key = "list-ordering", value = "createdDate asc"))
private List<History> userHistory;
@Persistent(mappedBy = "brandingUser", defaultFetchGroup = "false")
@Element(dependent = "true")
private List<MediaBranding> userBranding;
...
}
With the above definition, my understanding is:
- None of the relations are fetched when only the default fetch group is used.
- If the 'bits' fetch group is specified, userHistory and userBranding should be fetched.
- If the 'content' fetch group is specified, userContent should be fetched.
When using JDOQL to fetch the user by the email field, regardless of which fetch groups are specified, none of the relations are fetched. If I use getById() to fetch the User, the fetch groups are applied as expected.
I have turned L2 caching off (set to NONE in jdoquery.xml).
The testcase I'm using to fetch is shown below (it fails using version 2.0.0-final, passes with version 1.0.10).
@SuppressWarnings("unchecked")
@Test
public void testAddRetrieveUserByJDOQLQueryFetchGroups() {
PersistenceManager pm;
User u = persistUserAndFriends();
pm = getPMF().getPersistenceManager();
User result = null;
try {
pm.getFetchPlan().addGroup("bits");
pm.getFetchPlan().addGroup("content");
log.info("Groups in fetch plan: " + pm.getFetchPlan().getGroups());
Query query = pm.newQuery(User.class);
query.setFilter("email == emailParam");
query.declareParameters("java.lang.String emailParam");
List<User> results = (List<User>) query.execute("[email protected]");
assertEquals(1, results.size());
result = results.get(0);
pm.makeTransient(result, true);
} finally {
pm.close();
}
assertNotNull("User history should be fetched", result.getUserHistory());
assertNotNull("User branding should be fetched", result.getUserBranding());
assertEquals("Should be two history children", 2, result.getUserHistory().size());
assertEquals("Should be two branding children", 2, result.getUserBranding().size());
assertEquals("Should be a content child", 1, result.getUserContent().size());
}
Am I going about this the wrong way?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论