Re: [netconf] restconf collections

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

Hi,

Kent Watsen <[e-mail]> wrote:
> Hi Martin,
> 
> > I don't think d) and e) should be restricted to obu lists, and I don't
> > think they should be restricted to "indexable" columns.
> > 
> > And I think "expression of some sort" should be XPath.
> > 
> > Also, since the main objective is efficient retrieval, "sort-by"
> > can perhaps be removed.  Consider large lists in operational state
> > that also change often.
> 
> Your last paragraph, if I read it correctly, says “maybe don’t do
> ‘d’”, which if applied to the first part of your response becomes "I
> don't think 'e' should be restricted to OBU-lists”, which is something
> I can agree with.  As for ‘d’ being a reasonable thing to support for
> OBU-lists, please explain the use-case.

If we agree to not do d) then we don't need any use cases for it ;-)

Anyway, if you want to sort on different fields you probably want to
do this regardless of how the list is orderd on the server.

> Regarding “I don’t think they should be restricted to ‘indexable’
> columns”, we need to keep in mind that, if the DB-backend can’t do it,
> then the server logic will need to it, likely by retrieving all
> records and brute-forcing its way through them, which would not only
> be painfully slow, but a lot of implementation complexity.  That said,
> I’m unsure what use-case you have in mind whereby a non-indexable
> column is being filtered/sorted.  Only a couple of the built-in types
> aren’t indexable, right?

My comment was for both d) and e) (sort and filter).  As for filter,
an example is to get interfaces and with oper-status == 'down'.

> Yes, XPath is the “right answer”, but we need to ensure it’s
> constrained enough to be mappable to common DB-backends.

So the client talks to the server, and the server talks to the "db"
backend (note that in many implementations  operational state is
typically not stored in a real database).  So we have:

  client ->  server ->  backend

If we don't have any filter capabilities, the client has to get
everything, and then filter.  If we support XPath and the backend
doesn't support it, the server will have to filter.  This is still
more efficient than filtering in the client.

In ConfD/NSO we moved more and more filtering logic towards the
backend, to speed up performance.


> Updating my previous response (per above, plus adding leaf-list, plus
> locking-in names, which I’m choosing only to NOT sound like SQL):
> 
> 
> 	For all lists and leaf-lists:
> 
> 		a) count		(uint, default: 0)
> 		b) skip		(uint, default: 0)
> 		c) direction	(enum: forwards/backwards, default: forwards)
> 
> 
> 	For non “ordered-by user” lists only (N/A to leaf-lists), but
> 	only for indexable columns:
> 
> 		d) sort-by		(string: a single column/leaf name)
> 
> 
> 	For all lists and leaf-lists, but only for indexable columns (note:
> 	for
> 	a leaf-list, it is its own indexable column):
> 		e) filter		(a constrained Xpath expression)
> 
> 
> 	Again: sequence of operation is e —> a.
> 
> 
> We haven’t discussed “feature” statements yet, but it seems reasonable
> to me for both ‘d’ and ‘e’ to be optionally implemented.
> Additionally, it may be that additional Xpath expressions can be
> unlocked by feature statements).

I think e) is way more important than c).  I suggest focus on a + b +
c.

> > We could define a few more XPath functions for such comparisons.
> 
> Sure, but I wonder if, e.g., a netmask filter, is supportable by
> common DB-backends.  I’m hoping we have some DB-experts on the list!

See above.  It can be quite efficient even if the backend doesn't
support it.


/martin