--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a
lot about anticipated traffic volume.
On Thursday, 14 November, 2019 03:52, Dominique Devienne <ddevie...@gmail.com>
wrote:
>On Sat, Nov 9, 2019 at 1:20 PM Mario M. Westphal <m...@mwlabs.de> wrote:
>> Thanks to all the friendly people who commented on my question. Much
>> appreciated :-)
>> I was able to solve this with a small trick:
>> I created a small 'state' struct with a rowid and the result (float)
>> for that row.
> Sounds like you re-invented https://www.sqlite.org/c3ref/get_auxdata.html
> but with global state, no?
> I replied to your original thread with that link, before seeing this
> message. Using the built-in SQLite
> mechanism for function caching is much better, because it's clean, and
> properly handles the lifetime
> of the cache, tying it to the statement execution lifetime.
get/set auxdata is apparently intended to cache auxillary data associated with
a CONSTANT provided to a function parameter, not the dynamic result of a
computation. I suppose you could attempt to store your cache results against
argument 2 (the table column), however that will probably not achieve the
effect desired since this is not the purpose of get/set auxdata (read the web
page describing it). And storing it against argument 1 will not work because,
although that is a constant, how would you ever know when the *value* of
argument 2 changed?
Maybe I will write a wee test to see if it does work as you think or if it only
works as documented.
> Of course, if you want to tie your cache to a longer lifetime, *across*
> statement executions,
> you can use a global cache independent of SQLite, as it seems you did,
> but
> global state like
> this is rarely a good idea in my experience :). YMMV. --DD
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
