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
