Open lbwexler opened 3 years ago
The latter two could be handled by one or more overrideable methods on Store - e.g. rawDatasAreEqual()
and recordsAreEqual()
. Apps could then check something like an app-specific timestamp or hash in either, or could make the latter trivial if the first one passes, etc.
Hand waving here around how raw data equality check would fit in with / influence new record comparison. Seems like it could support a use case where an app knows that raw data change is sufficient to detect record change. New records would only be created if rawData changed, and then all such new records would be applied without further equality checks. Overridden recordsAreEqual()
could always return false to trigger that latter behavior, although would want to think through / revise the names to clarify that the comparison method was only used during load/update.
Consider providing
loadDataAsync()
, a variant that uses async loops for processing. Final result only installed if no intervening changes made to store, otherwise exception is thrown.Consider checking raw data for equality -- would require less parsing, and allocation of provisional records. Useful when many records are unchanged.
Consider allowing apps to specify a timestamp like-field to determine raw-data equality. Could either be determinative, or just used as an initial filter.