IntervalBlock:Merge about openespi-common-java HOT 5 CLOSED

To be clear, the current inplementation, while not efficient, does accomplish the update of the IntervalBlock correctly does it not? (and it could be that a simple assignment statement might work as well). I suspect that if you are working with large IntervalBlocks (each with a large number of interval readings) you might have time problems with large transactions as you update the entire collection.

BUT, you are not guaranteed to have a 1.x.1 association of old IntervalReadings to new IntervalReadings. Durations and Starts may change. In that case, the evaluation of what needs replaced and what does not may become rather complex.

from openespi-common-java.

I'm still not clear on the behavior needed for IntervalBlock Merge.

Do we need both a merge and a replace functionality?
Are both behaviors available via PUT api or do we need to support PATCH to gain access to merge?
when a merge (not a replace) of the IntervalReadings collection happens, are alignment boundaries of the IntervalReadings matched b/f replacement?
What happens if the alignment boundaries of the IntervalReadings do not match?

from openespi-common-java.

Any other comments on this merge.vs.replace behavior? If we need both, I can put in a PATCH API.

from openespi-common-java.

You point out well the kind of issues you will have with a PATCH for IntervalBlock. Probably best to stick with PUT as replace. If poster wants a merge, he will know what he wants and do a READ / MODIFY / WRITE pattern.

from openespi-common-java.

The IntervalBlock should be kept manageable in size if the application expects to update interval blocks with any frequency.

from openespi-common-java.