Re: [netconf] restconf collections

[Hongwei Li <[e-mail]>]

Thanks Kent
This is clear enough. Just want to make sure we cover that.
The next question is: can we avoid the slow-sort? Like to split the request
automatically or something else? IMO, this is more on implementation side.

On Fri, Oct 2, 2020 at 10:46 AM Kent Watsen <[e-mail]> wrote:

> Hi Hongwei,
>
> [HL] A user case for time series data (e.g., logs), customers want to get
>> the data in between Time A and Time B. Do we use timestamp filter here?
>>
>
> Some events have only one timestamp.  The database likely has a primary
> key (e.g., "record-id”) and a separate “timestamp” field.  For all intents
> and purposes, the logs are persisted in time-order, so no additional
> sorting is needed.  The physical order is good enough.
>
> However, other events may have distinct "time-generated" and
> "time-received” fields.  This is most notable for a “log-receiver” (or just
> “receiver", in rfc8639 parlance), as there may be a delay between when a
> log is generated by a publisher and when it is persisted by the receiver.   In
> this case, the user-expectation is undoubtedly to sort on “time-generated”. The
> “record-id” and “time-received” fields are physically in order (same as
> above), but “time-generated” could be all over the place, so a sort is
> needed.
>
> FWIW, if the goal is to find logs generated in a window of time around a
> timestamp, a fast-filter can be used to whittle down the result-set to a
> (hopefully) manageable size before the slow-sort as follows:
>
> filter
> "time-generated >= timestamp-of-interest - some-window”
> and
> “time-received <= timestamp-of-interest + some-window"
> sort-by
> “time-generated"
>
>
> K.
>
>