Hi @splinter,
Sorry to hear you’ve stubbed your toe on the limitations of Data Table views - that sounds like a pretty frustrating experience! We will update the docs to make those limitations clearer, and hopefully keep future developers out of the rabbit hole you fell down. In general, we are aware that the view support hasn’t kept up with newer features like table queries; some of this is for structural reasons in the implementation (detailed below if you’re curious) which we are working to address (watch this space)!
If you’re curious about what’s going on under the hood, I can talk a little about the reasons for these restrictions:
-
Searching using view rows: This is the simplest to address (it’s a straightforward refactor), and we agree it ought to be possible. As @stefano.menci points out, it’s more or less equivalent to
my_table.get_by_id(view_row.get_id()), which is allowed if you have access to the relevant table. -
Establishing relationships: Because Data Tables use a capability/“possession-is-permission” model, having access to a row also gives you access to everything that row links to. And if you navigate via a link, you get the full, unrestricted row. If we let you make links to restricted-column rows, then you could make a link to a restricted row, then follow that link and get the unrestricted version of it. Not safe! So, sadly, this restriction is likely to stay (at least on the client side; we can make it possible on the server because the server code can already access anything on the underlying table).
-
Lack of support for complex queries: This is an artefact of our “Live Object” system (which you can see me describing towards the end of this talk from PyCon 2018). The way that client-writable views work is to embed the view restrictions into the ID of the LiveObject that represents the view (because that’s covered by the signature). However, those IDs can only be JSON, and rich queries support complex Python objects which don’t necessarily have a single JSON encoding.
Our existing LiveObject implementation is being retired and replaced by something considerably more capable, which will give us a lot more flexibility. We will then be able to make views considerably more powerful (not to mention improving the performance of ordinary data table operations).
Thanks for your patience, sorry about the stubbed toes, and - as I say - watch this space!