[Agavi-Users] RESTful 1:n entity synchronisation strategy

[Hash]

Dear Agavi Users,

I am looking for advice on the best approach to synchronisation of data entities with a 1:n relationship in a REST system.

Consider the form http://pastebin.com/c9NJH72k

The primary entity is Person, which has one or more Address. When a user wants to edit a Person via a form, they can add and remove addresses and the form is dynamically updated with Javascript. The form is posted with the person id in the URL.

In the case of adding a new addresses, there is no problem. In the case of editing addresses, also there is no problem since existing entities are identified by a hidden address id.

However the main problem arises when handling removal of addresses. What is the best way to handle the post back of data where addresses are removed?

I've considered the problems and have come up with a few ideas:

1. When the data is posted back all existing address entities are deleted and any new ones specified in the form are added. However this leads to problems with associations to other entities as primary keys will always change.
2. The form dynamically includes a 'removed_address_id' and deletes those records specifically. However, this means there is a strong JS dependency.
3. The system performs some sort of synchronisation by loading all addresses for a person and then removes, updates or adds the records accordingly. However this seems to present a possible overhead when dealing with many associations.

Is there a more fundamentally better approach to designing this common scenario?

Kind regards

Hash (hzilla)
_______________________________________________
users mailing list
us...@lists.agavi.org
http://lists.agavi.org/mailman/listinfo/users

[Mike Seth]

On 04/21/2012 03:58 PM, Hash wrote:
> Dear Agavi Users,
>
> I am looking for advice on the best approach to synchronisation of data entities with a 1:n relationship in a REST system.
>

> [...]

> 3. The system performs some sort of synchronisation by loading all addresses for a person and then removes, updates or adds the records accordingly. However this seems to present a possible overhead when dealing with many associations.
>
> Is there a more fundamentally better approach to designing this common scenario?
>

There isn't one, really, but your option 3 is less complicated and
load-imposing than it seems. In a UI scenario where secondary entities
such as addresses are associated directly with a primary entity, it is
very likely that the secondaries are rather few - otherwise you would
find it necessary to have a separate UI to manage them. The
implementation then is quite simple. Submitted address records that do
not have an ID field are new records. Those that do are existing ones,
and you will be validating these IDs anyway, in order to ensure that the
user isn't overwriting objects that do not belong to them. At this
point, you can preload the IDs or bodies of the addresses associated
with the person object being edited, and through simple logic e.g.
array_diff() determine the IDs that were deleted. The remainder of
records are those that need updating, and you can either refresh them
all directly, or hash previous and current versions and only update
those where the hashes differ (in which case you might want to load the
entire bodies of related records into the cache at validation stage).

Bear in mind that overall, such update operations will be more seldom
than any others in most cases. The performance impact is negligible, if any.

Some ORMs have built-in tools to assist with this kind of problems.

[Hash]

Hello Mike, thanks for the advice. Good to get a steer on a good design. Although it gets more complicated still when considering n:n relations! Anyway i have implemented a concise and effective solution for the time being which I can reuse wherever i come across this scenario again.

thanks

Hash