Re: [netconf] restconf collections

[Qin Wu <[e-mail]>]

发件人: netconf [mailto:[e-mail]] 代表 Kent Watsen
发送时间: 2020年9月30日 5:57
收件人: Martin Björklund <[e-mail]>
抄送: [e-mail]
主题: Re: [netconf] restconf collections

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

[Qin] Umm, this seems a good choice. I feel sort-by is nice to have feature, in many cases, very useful. But we need to when sort-by is required and when is not.

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.