Re: [netconf] restconf collections

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

Hi,

Kent Watsen <[e-mail]> wrote:
> 
> Firstly, thank you to those that responded showing interest in working
> on these I-Ds.  If anyone else is interested, please send me a PM.
> 
> Regarding solution, I want to take one more stab at a sketch here, as
> a last-chance for comments before the authors dive into producing the
> I-Ds.
> 
> Already it is assumed that there will be an RPC for NC, and query
> params for RC…that not what this email is about.
> 
> Here’s my proposal:
> 
> 	For all lists;
> 
> 		a) “limit” or “count”
> 		b) “offset" or “skip”
> 		c) “direction”  (i.e., forward/backward)
> 
> 	For non “ordered-by user” lists, but only for indexable columns:
> 
> 		d) “sort-by” or “ordered-by” (single column max)
> 		e) “where” or “filter” (compound expression of some sort)

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.

> 	Note: the lowercase “or” is just for the label selected (no semantic
> 	impact).
> 
> 
> The order of operation is “e —> a”.  That is, first the filter is
> applied (if any), then the sort is applied (if any), then the
> direction is applied (if any), then the offset/skip is applied (if
> any), and then the limit/count is applied (if any).
> 
> Now the tricky stuff.
> 
> 	- “key” and “unique” leafs are indexed by default, assuming
> 	  the leaf’s base type is indexable
> 	- a special extension is used to index other nodes
> 	- other indexable nodes must be a “leaf"
> 	- the leaf must be “mandatory true”
> 	- the leaf must not be under a “list” or “choice” node
> 	- the leaf must have an indexable base type
> 		- all built-in types supported except:
> 			- binary
> 			- instance-identifier
> 		- unions are indexable, but assumes all values stored
> 		   as a “string” in the DB.
> 		- “string” types may be coerced into more DB-friendly types
> 			- “yang:date-and-time” mapped to a DB “DateTime” type
> 
> Cons:
> 	- smart (e.g., netmask-based) filter/sorts is unlikely supportable
> 		- at least not without custom (not generic) code

We could define a few more XPath functions for such comparisons.



/martin

> 
> 
> Comments?
> 
> K.
> 
> 
>