On 2017/06/15 10:15 AM, Paul Sanderson wrote:
Thanks Richard - the View approach is fine for my needs - just wanted to
know what the rationale was for the imposter tables given the ability to
simulate the imposter table with a view.
I'm thinking the easiest way to describe it is perhaps in programming
terms -
a view is like a function that computes and produces a result that may
or may not be a simple reflection of an internal variable,
and
an imposter table is rather more like a variable that lives at the same
memory address as another data structure so that querying it queries the
underlying structure direct (this part is also achievable by a view),
but changes to it also change in the underlying data structure (very
unlike a view).
This is great if you are looking for a way to update an index
independently from its data, but is also, as has been pointed out
numerous times, quite dangerous - but then, breaking it is mostly
fixable by a simple REINDEX.
Not sure if you can install such an imposter table on a corrupt database
file, moreso than a View anyway, but that actually might have some
utility towards retrieving or fixing (or at least gaining a better
understanding of) a corrupted data table / index, which I think Paul
might be interested in.
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users