请求工厂正在发送回整个 List即使只改变一个元素
当我加载具有实体代理嵌套集合的实体代理（例如：包含联系人代理列表的 AddressBook 实体代理）并且如果我对内部列表（联系人列表）进行更改（例如删除项目）并调用坚持下去，Request Factory 正在发送整个联系人列表。这是预期的行为，还是应该只发送一条命令来删除服务器上的项目？
问题是，请求工厂仅发送字段级别更改的增量，还是也计算集合的增量？
ContactProxy
interface ContactProxy extends EntityProxy {
...
//Getters and setters for firstName, lastName, phoneNumber etc...
...
}
AddressBookProxy
interface AddressBookProxy extends EntityProxy {
...
List<ContactProxy> getContacts();
void setContacts(List<ContactProxy> contacts);
...
}
焦点代码：
//Assume I received an abProxy from a previous context.
AddressBookRequestContext context = requestFactory.requestContext();
abProxy = context.edit(abProxy);
abProxy.getContacts().remove(0);
context.persist().using(abProxy).fire();
上面的代码正在发送在先前上下文中收到的整个联系人列表，但我预计只向服务器发送删除命令。我做错了什么吗？
现在，当我对 AddressBook 实体代理中的单个联系人进行更改并进行调用以保留时，它仍然会发送整个联系人列表。使增量适用于此类集合级别更改的解决方法是什么。
When I load an entity proxy which has a nested collection of entity proxies (eg: AddressBook entity proxy containing a list of Contact proxies) and if I make changes to the inner list ( the List of Contacts) like removal of an item, and call a persist on it, Request Factory is sending the entire list of contacts. Is this the expected behaviour, or is it supposed to send only a command to delete the item on the server also?
The question is, does request factory send deltas just for field level changes, or does it calculate deltas for collections also?
ContactProxy
interface ContactProxy extends EntityProxy {
...
//Getters and setters for firstName, lastName, phoneNumber etc...
...
}
AddressBookProxy
interface AddressBookProxy extends EntityProxy {
...
List<ContactProxy> getContacts();
void setContacts(List<ContactProxy> contacts);
...
}
Focus code:
//Assume I received an abProxy from a previous context.
AddressBookRequestContext context = requestFactory.requestContext();
abProxy = context.edit(abProxy);
abProxy.getContacts().remove(0);
context.persist().using(abProxy).fire();
The above piece of code is sending the entire list of contacts received in the previous context, but I expected to send only a delete command to the server. Am I doing something wrong?
Now when I make a change to a single contact in the AddressBook entity proxy and make a call to persist, it is still sending the entire list of contacts. What is the workaround to get deltas working for these kind of collection level changes.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您要将列表从 10 个元素的列表修改为 9 个元素的列表，因此 RF 发送 9 个元素的新列表（并将在服务器端使用新列表调用 setter）。
但是，它只发送联系人的 ID，而不发送其属性，因为这些属性没有更改（是的，这意味着必须在服务器端检索所有联系人，以便填充包含 9 个元素的新列表，然后将其设置到地址簿中）。
不过，RF 可能还有改进的空间：当您
edit()代理时，它会自动编辑它引用的所有代理（递归地），因此所有 10 个联系人都是edit()>ed，因此所有 10 个联系人 ID 都会发送到服务器，从数据库中检索所有 10 个联系人并进行验证，即使之后只使用其中的 9 个。因此（这可以被视为一项功能），如果已删除的联系人自最初在客户端检索以来已被更新，服务器将发送一个EntityProxyChange用于响应中与客户端的联系。简而言之：没有什么魔法，一切都是有代价的，所以在设计你的“API”时要小心；您可能想要向
RequestContext添加一个removeContact方法，而不是修改列表（并再次检索地址簿 - 在同一个RequestContext中批量处理） – 在客户端获取更新）You're modifying the list from a list of 10 elements to a list of 9 elements, so RF sends the new list of 9 elements (and will call the setter with the new list on the server side).
However, it only sends the IDs of the contacts, not their properties, because those haven't changed (and yes, it means all contacts will have to be retrieved on the server-side, in order to populate the new list of 9 elements, before setting it into the address book).
There's probably room for improvement in RF though: when you
edit()a proxy, it automatically edits all the proxies it references (recursively), so all 10 contacts areedit()ed, and thus all 10 contacts IDs are sent to the server, an all 10 contacts are retrieved from the database and validated, even though only 9 of them are used afterwards. As a result (and that could be seen as a feature) in the event the removed contact has been updated since originally retrieved on the client, the server will send anEntityProxyChangefor the contact to the client in the response.In a few words: there's no magic, everything comes to a cost, so be careful when designing your "APIs"; you might want to add a
removeContactmethod to yourRequestContextinstead of modifying the list (and retrieve the address book again –batched in the sameRequestContext– to get the update on the client-side)