EXPORT
ed variables are saved in one of three ways:
TABLE
, or are not currently
in a LOOP
or non-ROW
SQL
, are written to the
state table (vortex
). These are known as state-table
variables. Variables which have large values, only change once per
invocation, or are used globally are best saved this way. A user
name, or "shopping cart" list of items selected so far are typical
examples.URL
, or are in a loop, have
their current value(s) saved, but encoded to the URL instead.
These are known as URL state variables. Variables which have small
values, or multiple values per invocation (with each value to go to
a different URL) are best saved as URL state variables. A good
example is the id field for each result of a first-level query: each
id goes to a different URL, for details on that hit. URL state
variables also avoid the overhead of reading and writing to the
state table, and thus let the script run somewhat faster.QUERY
are saved as a
URL-encoded query-string to the special variable $urlq
.
This can be useful for tracking script usage in web server logs, as
the Vortex variables will be in plain view. It can also be used to
export variables to another script.
When $url
is printed, its value will reflect both the
encoded URL state variables (if any), as well as a handle to the
state-table variables. Similarly, when $urlq
is printed,
query-string variables are reflected in it.
The state table is written to only once during a given script
invocation, to save transaction time. It is written the first time
$url
is printed when at least one state-table variable is set.
At that point all state-table variables are saved.
URL state variables, however, are saved to the $url
value
every time it is printed (the same is true for $urlq
).
Any EXPORT
ed variables that are not set when
$url
/$urlq
is printed are not exported at that time.