What do you do if you have a sequential-only table and you
need to do random access on it?
The Tables.randomTable
utility method
takes any table and returns one which is guaranteed to provide random access.
If the original one is random, it just returns it unchanged,
otherwise it returns a table which contains the same data as the
submitted one, but for which isRandom
is guaranteed to
return true.
It effectively does this by taking out a RowSequence
and
reading all the data sequentially into some kind of (memory- or disk-based)
data structure which can provide random access, returning a new
StarTable object based on that data structure.
Clearly, this might be an expensive process. For this reason if you have an application in which random access will be required at various points, it is usually a good idea to ensure you have a random-access table at the application's top level, and for general-purpose utility methods to require random-access tables (throwing an exception if they get a sequential-only one). The alternative practice of utility methods converting argument tables to random-access when they are called might result in this expensive process happening multiple times.
Exactly what kind of random-access structure
Tables.randomTable
uses to store the data
(the two basic alternatives are in memory or on disk) is determined
by the default
uk.ac.starlink.table.StoragePolicy
;
this can be set from outside the program by defining the
startable.storage
system property, as explained in
Appendix A.4.
If you know you want to store the data in a particular way however,
you can use one of the predefined storage policy instances.
Here is how you can randomise a table by stashing its data in a
temporary disk file:
table = StoragePolicy.PREFER_DISK.randomTable( table );You might want to do this if you know that its data size is likely to exceed available RAM. Note however that writing temporary disk files may be disabled in certain security contexts (e.g. running as an applet or an unsigned WebStart application).
Table input handlers use StoragePolicy
objects too
if they need to cache bulk data from a table. These are passed
to their
makeStarTable
directly or by a StarTableFactory
If you don't set a policy directly on the factory, this too will use
the default one.