Allow to disable lazy behavior in row objects

[stefano.menci]

The lazy behavior of the row objects is good for lazy developers: you don’t want to think about what columns you actually need and trust that the automatic management will be good most of the times, and can live with performance hits caused by sometimes fetching too much data and sometimes fetching too little and incurring in lazy loading.

I use Anvil because I’m lazy and I like to have Anvil doing tons of legwork on my behalf.

But sometimes I don’t want to be too lazy. Sometimes I want to be sure I don’t fetch more than I need and I want to be sure I fetch all I need.

I would like to have an option like:

row = my_table.get(
    q.fetch_only('col1', col2=q.fetch_only('col3')),
    tables.no_laziness,
)
> print(row['col1'])
'abc'
> print(row['col2']['col3'])
'def'
> print(row['col4'])
Exception: lazy loading is disabled

It is possible to do something similar by first creating a client_readable, then searching into it: if I setup both the client_readable and the search with the same columns, I get what I am looking for.

The problem with this workaround is that it’s slow (3 to 5 times slower in the few tests I have done) and it’s tedious (it defeats the purpose of using Anvil).

[duncan_richards12]

I like the idea, but it seems like the end result is the same as client readable right? Wouldn’t the real request be to just make the client readable path faster?

I know the limiting the linked row’s column is the most tedious, but we have a feature request for that:

[Accelerated Tables] set columns for linked rows with q.only_cols

| fetch_only(*only_cols, **linked_cols) | | Methods defined here: | | __eq__(self, other) | Return self==value. | | __hash__(self) | Return hash(self). | | __init__(self, *only_cols, **linked_cols) | Initialize self. See help(type(self)) for accurate signature. | | ---------------------------------------------------------------------- | Data descriptors defined here: | | __dict__ | dictionary for instance variables (if defined) | | …

[stefano.menci]

Even if the query on a client readable became faster, I would still need to specify the list of columns, including the linked tables, in both the client readable definition and in the search arguments, because the search iterator would still return Row objects with some lazily loaded columns.

Client readables are designed to be searched, while searches are designed to return Row objects. Yes, creating a client readable and searching it returns Row objects, but feels hacky.

I could even argue that, because this FR has not been implemented yet, client readables are often misused as a workaround.

When you want to allow searches on the client, you do need a client readable. That’s what they are for.

But when you want to restrict the amount of data returned to the client without the need to do any search on the client, you still need to make a client readable, which doesn’t feel right.

The right way to send Rows from a table without certain columns to the client would be to send Rows without certain columns to the client, not to make a virtual table without those columns and then search that.

[duncan_richards12]

I suppose that’s true, but it seems like more of an argument of the names being appropriately descriptive of what they do and more of a semantics argument.

Honestly it seems that fetch only and only cols in the client readable method are already unnecessarily doing double duty. To me having one method with different params or methods to do both with the different purposes/destinations would be better than having parallel developments like have till now.