So far, I am still not able to use Accelerated tables. The problem here is that I don’t want all the columns of a row to be fetched in advance. Instead, there are some columns (that can have a lot of data as well), which I only want to fetch upon certain actions by users.
However, currently, if I try to access any column that was not included in fetch_only, it will go on a recursive trip and load every column (even rows of the linked column). In my app, doing this would mean the possibility of loading the entire database due to the amount of linked data it has.
Instead, an easier way would be to have a fetch method inside the row as well. So I can just do this:
row = app_tables.my_tables.get(q.fetch_only("A","B")) #Fetching only "A" and "B" columns for now
... #User does an action which requires some new columns to be loaded
row.fetch("C","D")
row["C"]
A workaround might be to get the row again (with the new columns as well). But that doesn’t seem like the most optimised approach.
Are you saying that when a user fetches a column outside of the ones specified in fetch_only, the row object fetches all of the columns?
That would indeed be annoying.
I personally haven’t been in this situation, as with large datasets, I have started using client readable views. I will write a query in form 1 that uses fetch_only(‘A’, ‘B’) and a different query in form 2 that uses fetch_only(‘A’, ‘B’, ‘C’, ‘D’).
Also, another thing I started doing, is using fetch_only for large queries (searching through cols ‘A’ and ‘B’) but when I need a column like ‘C’ and ‘D’ (i.e. some more details), that’s usually when I’m in a detail screen and I can use a .get query instead of a .search query.
I think implementing this would probably be the equivalent to what would happen when you did the feature row.fetch("C","D") .
Any way I can think of the client would have to do another round trip to the server, and the server would return a new row object with more data. So it might actually be the most optimised way to do it without fetching all of the data on every row that you did not need the extra columns.
I would expect this feature behind the scenes to simply pass the row object (so really just the id) back to the server, then somehow do a get_by_id for the row, returning to the client a row object with just the columns/data requested.
Can anyone think of some other way that would save more than a handful of milliseconds?
Actually that makes sense. In any case, the round trip to server will be one.
But it still comes with various problems of its own due to the fact that there will be multiple row object for the same row. The rows will be passed through several forms (and there is a caching system too). What happens when I need the “A” and “B” column again after fetching “C” and “D”?
Of course, none of this is impossible. It just requires further complicating things. A fetch method will be easy to use and make sense too.
Also, speaking of the non-Accelerated Tables way, it fetches all the row columns which are not simple objects or linked row(s) unless you try to access them. Not the best way either but it’s usually simple object and linked rows which have the large data (at least in my case)
Yes, good catch I thought of this also, I would assume if the feature was implemented by anvil it would update the row on the client side with additional data instead of just replacing it in place.
(So you would use a method on the row object itself to request the additional column data so it does not become orphaned)
I am unsure if that would include any technical hurdles, since there are limitations on “creating” row objects on the client side for security I think?
… and you are also right about cashing many decisions would have to be made, so it makes sense as a FR since it deals with making row objects and it is probably better than everyone trying to make their own special sauce.
I don’t see any issues with security. Anvil is already doing the job of fetching additional columns. It is just doing it without control. We just want that control.
Both FRs address complex cases, where you want to make sure that what you want and only what you want is fetched. This is important on the server side for performance reasons, but is much more important in the client side, for both security and performance reasons.