I guess itโs still 2020 so weโre still releasing features and telling nobody :[
This just needs a process and it completely fell between the cracks โ itโll be one of the first things we do in January.
Wrt how itโs implemented, the problem with chained/nested derefs was one of parsing โ [A].[B].[C] doesnโt match any expresion syntax supported by an Excel/sheets formula parser. In the past, Iโd tried changing the parser we use, but that ended up being very messy and I abandoned it. @Natalie took another crack at it, and she used a smart pre-processing technique that let us parse these expressions. Once that was done, then the rest of it was relatively within our grasp (it was code we are familiar with in our expression system).
You can think of a dereference expression as doing a โlookupโ on the fly. A two-step nested deref has two lookups one after the other. Each lookup is efficient because it is looking something up based on its key and that is an equality comparison on a unique value.
Until we had this chained deref expression, youโd have to break this up by pre-computing virtual columns. That is essentially pre-computing all but the first hop of the chained deref lookup, and storing their results as virtual columns. So this pre-computation happens for all the rows, not just for the particular row you might care about. The precomputation happens in our server at sync time.
So which is preferable? If youโre in any case going to have to compute the chained deref for all N rows of your table, then maybe youโre better off with the VC approach. Youโre using our server to do it and you need more space for the data, but then itโs a little less work in your app on your device. However, if you only need this chained deref occasionally (letโs say you use it in a form to fill in a value), then itโs going to be better without the VC. In general though, Iโd be surprised if a sync time was increased from 5s to 20s because of a VC that just precomputed and cached a deref expression. So that seems odd.
LinkedIn
Twitter
