Re: [netconf] restconf collections

[Kent Watsen <[e-mail]>]

Hi Olaf,

> I agree sorting is less important (than a,b,e).

Noted.


> Is it not also somewhat beyond the present yang concepts where there is
> already ordered-by and key indices?
> Supplying a differing sorting could in effect require a different set of
> index(es) which could be quite costly in runtime for large data sets.
> If you want to sort differently, should it not be present in the
> underlying model, ie as declaring a secondary set of keys, for example,
> as an extension of the original yang model (thus being out of scope here)?

A couple messages I sent yesterday alluded to defining an extension statement that could be added to nodes in the YANG modules.

Now I’m thinking that one-size doesn’t necessarily fit all, and something like a server-specific “node-tag” would be more flexible.  (https://tools.ietf.org/html/draft-tao-netmod-yang-node-tags <https://tools.ietf.org/html/draft-tao-netmod-yang-node-tags>)

Maybe the answer is somewhere in-between, i.e., an extension that acts like a “hint” and a node-tag indicating if the server delivered it.  Bad news w/ an extension is that legacy modules would need to be revved or augmented.

One thing, though, filtering on non-indexed nodes is guaranteed to have slow performance, thus it seems that we need to enable indexing for more than just a list’s keys.

My conjecture is that, once we have the indexes for filtering (e), they can be used for sorting (d).  At least, that’s the way it works with some DB-backends I’m familiar with...


>>>> Yes, XPath is the “right answer”, but we need to ensure it’s
>>>> constrained enough to be mappable to common DB-backends.
> 
> I would think a (strongly) constrained XPath would be a very nice solution.

+1


> To me reverse direction seems a subset of ordering/sorting?

Indeed.  In some DB-backends, “direction" is a sub-statement to the “sort” statement.


> If sorting is less important, so would an alternate direction?

Maybe, but an independent “direction" works with OBU-lists, which is why I teased it out.

And, besides, that assumes sorting is less important.  I do hear a consensus beginning to form in that direction, so we’ll see...

All I know is that there are tons of UIs that enable column sorting (e.g., an email client).  Do we feel data models defined by YANG are somehow immune to this?   

I hear folks expressing concern around sorting big data (e.g., logs), which I grok, but what about for non-OBU CT lists (e.g., admins)?  Wouldn’t we like to sort by name, last-time-connected, etc.?  Can not supporting sorting on big data set be expressed via some combination of extension + node-tag, or implicitly disabled if the pre-filter fails to whittle the result set down to something that can be sorted reasonably?


> Unless there are some important use-cases, reverse order having the
> advantage of the same sorting mechanism/indexes, just in reverse (not
> introducing other keys, for example)

Sorry, I didn’t parse that.  Can you say another way?


K.