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.
_______________________________________________
users mailing list
[email protected]
http://lists.agavi.org/mailman/listinfo/users
