D
dbeavon
Guest
>> why wouldn't you simply use the existing READ/WRITE-JSON methods That is a good point about JSON. I'm going to have to re-test the performance of that. My recollection is that the deserialization from JSON took a several hundred milliseconds for 100,000 rows of data. At the time it wasn't fast enough for what I was doing and it somewhat defeated the purpose of the cache. (As I recall, I had an active orders screen with several thousand order items on it. And I wanted to incorporate the product-master descriptions for each of the distinct products that was present in the order items. So I tried to deserialize the entire product master out of JSON into a product-master temp-table. This deserialization was quite a bit slower than what I needed. To make a long story short, it was faster to calculate the distinct products and use it to perform individual "find" operations against the remote database. I was disappointed by the inability to use a locally cached product-master, especially since it seems like a really good fit for keeping in cache, and a good fit for updating on an infrequent basis, eg. every ten minutes. It seems to me that it would have been cleaner to use the local cache, without placing an unnecessary burden on the remote database via client/server . But as things turned out, the overhead and complexity involved in deserializing a large product master - from JSON into a TT - was just enough to make that approach less desirable than simply relying on the source database). I think the only reason the local JSON didn't quite work was because of the cpu requirements for deserializing and re-indexing the product master every time that cached data was needed by a new ABL session. Perhaps things would have worked better if the number or records was < 10,000 rows instead of ~100,000. But as the quantity of cached data decreases, it also eliminates the motivation for having a local cache in the first place! The best kind of local cache is something that wouldn't need to be deserialized and re-indexed prior to using it. It should be a matter of detaching/attaching (ie. there shouldn't be so much preparation work in order to use the cache). Note that my request for ProDataSet:ReadSqliteDatabase would also have an overhead penalty, but hopefully not as much as JSON since the format would be binary on both sides. ... Furthermore (and don't tell anyone this) but the request to have a ProDataSet:ReadSqliteDatabase is just the initial step towards something better. What I *really* want is a client-session startup parameter which specifies that all temp-table data in ABL will be entirely hosted in an embedded SQLite database. That would allow us to totally eliminate serialization and deserialization overhead in ABL sessions.
Continue reading...
Continue reading...