Re: [netconf] restconf collections

[Kent Watsen <[e-mail]>]

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.

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?

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

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


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


K.