Re: [netconf] restconf collections

[Martin Björklund <[e-mail]>]

Hi,

Kent Watsen <[e-mail]> wrote:
> 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.

I disagree with both these statements.  This is an implementation
issue.

> 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...

This is one implementation strategy.  We should not design the
standard around one implementation.

> >>>> 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?

I agree that this can be useful.  But as has been pointed out earlier
in this thread, sorting implies a stateful solution which will consume
more resources and probably comes with some additional complexity.

At Cisco/tail-f we implemented such a solution; a more generic "query"
mechanism, for both NETCONF and RESTCONF.  Perhaps Per A can share
some details.


/martin




> > 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.
>