Full fetch_only/only_cols functionality for Tables get methods

[hugetim]

I’d like to be able to fetch_only/only_cols when retrieving Data Tables rows via anvil.users.get_user, as well as the standard Data Tables get and get_by_id.

Related:

@hugetim

Adding fetch_only capability to anvil.users.get_user is at the top of my personal wish list.

@splinter

fetch_only capability on get_user would be very helpful from a security perspective, limiting access to more sensitive fields but still being able to store them in the user row would be a significant improvement.

[p.colbert]

This may help:

@meredydd

We will be updating get_user() so that it does not fetch all columns on every load (ie it will act as though it’s got a fairly minimal q.fetch_only(...) clause). This will ship in the next few days

…

[stucork]

Passing a q.fetch_only arg is already implemented for the standard .get() and .get_by_id() methods .

q.only_cols works at the table level so once you’ve created a client_readable table with the q.only_cols argument then calling any method on this restricted table will be subject to those restricted columns.

[hugetim]

Wow, ok. Then this is done as far as I’m concerned. I guess it’s only a documentation request now.

[hugetim]

On second thought, I’d still like to see ‘fetch_only’ capabilities for users.get_user.

[p.colbert]

@hugetim

‘fetch_only’ capabilities for users.get_user.

Full agreement there. We ought to be able to configure which User columns the Client can read and write. Doing so in Client-side code leaves it open to hacking.

[jshaffstall]

The workaround I’ve seen suggested for that is to create a client-readable view using only_cols and fetch the current user from it. That means forgoing the convenience of users.get_user() and making a server call, but it’d get you a row from the user’s table without the columns you consider private.

Agreed that it would be nicer to be able to use fetch_only and only_cols directly with users.get_user().

[p.colbert]

@jshaffstall

The workaround I’ve seen … it’d get you a row from the user’s table without the columns you consider private.

I’m happy to do that. In that case, I’d make get_user() completely inaccessible. Except… dependencies might still be using it.