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 On 22 Apr 2012, at 06:42, Mike Seth wrote: > 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 _______________________________________________ users mailing list [email protected] http://lists.agavi.org/mailman/listinfo/users
