Request factory is sending back the entire List<EntityProxy> even if only one element is altered

Question

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.

Answer 1

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 are edit()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 an EntityProxyChange for 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 removeContact method to your RequestContext instead of modifying the list (and retrieve the address book again –batched in the same RequestContext– to get the update on the client-side)