Skip to main content
RSS feed Subscribe to feed


Skip Navigation LinksHome  Extending the Spotfire Platform  Creating Extensions to the Spotfire Platform  Creating a Virtual Table Column Producer

©Spotfire 2011

Creating a Virtual Table Column Producer

Some columns contain data that loads slowly, typically because of slow databases. Loading this kind of data into ordinary columns is impractical. Virtual column producers create columns that render only the cells actually viewed: Cell values are fetched on a need-to-view basis.


A virtual column producer creates and owns virtual columns. It also keeps the settings necessary to produce them. The actual values are produced by a virtual value worker. At the moment cells are about to become visible in the table, the virtual columns ask a worker for the cell values. The values are fetched asynchronously and stored in an internal datacache.


Due to the nature of virtual columns, specifically the cell-based loading, they differ from regular columns in important respects:

  • Virtual columns do not support filters.
  • It is usually not possible to calculate the number of unique values or the max value.
  • Virtual columns can not be use to sort by, since this would require fetching all values.
  • Virtual columns open in the Spotfire Web Player, unless they require prompting for credentials.

Tutorials and Examples

Concepts and Classes

Custom virtual column producers are implemented using the CustomVirtualColumnProducer class.


Regular prompting is performed by the Prompt method with model object as the virtual column producer itself. If the prompt mode is Allowed, it will check with the implementor if prompting is really necessary. If promting is used, the actual creation of virtual columns is either driven by setting properties tied to the configure columns trigger, or changing the inputs of a virtual column. These properties are usually set at the end of the prompt session.

Another type of prompting concerns credentials. Credentials are not stored in the file. When creating or loading a file, the producer will have a credentials model without credentials set. In this case, a CredentialsModel<myproducer> must be registered with an appropriate view in the viewregistry.

The Data Cache

The values stored in the datacache is shared per producer type. A datacache key consists of the input values, the external id of the produced column, and the model key provided by the virtual column producer. The VirtualValueRequest provides the input values and the external id, while the model key may be provided by the GetCacheKeyCore implementation of the virtual column producer:

Virtual value request

If several requests with the same key arrives, only the first does actual work; the other are updated with the result when the first returns. Finally, all requests with that key are answered from the cache.

The cache is never actively emptied by the virtual columns framework. When memory becomes sparse, old items are discarded by the data cache itself.


As noted above, the virtual column producer creates, owns and stores the settings necessary to create virtual columns. Columns available as input are retrieved as data column signatures in AvailableInputs.

Different inputs can be defined for different output columns by a public nested class defining identifiers. These are associated with a number of VirtualColumnInputCollection in the base class via CreateInputs. In ConfigureColumnsCore each defined output column is given one of the defined identifiers. This can then be used to get/set the inputs through the protected GetInputs/SetInputs methods.


Virtual column represents the actual column. It contains metadata as well as the possibility to internally get row values. The ExternalId property serves to allow the implementer to identify specific columns within the producer. Setting the column name requires it to be unique among the available inputs of the producer it belongs to.

See Also

  • VirtualColumnsConfigurator
    This helper class is used for declaring the columns produced by a producer. It is first created internally, then filled in with all columns by the implementer, and finally those descriptions are matched to any existing columns to be added, updated or removed.
  • VirtualValueRequest
    Provides input data values, meta data properties about the result, as well as the place to store the resulting data value. The value parameter in SetValidResult must be of the same type as the datatype given in properties.
  • VirtualValueWorker
    Does the actual data fetching. Fetching is performed either by overriding DoWorkCore or DoBatchWorkCore to get one or several VirtualValueRequests.
  • VirtualColumnCollection
    Owns the created columns. The content updates are event driven and performed by the parent producer. Hence lacks methods to add or remove columns.
  • VirtualColumnProducerCollection
    Owns the producers.
  • DataValueTuple
    A general readonly data value collection serving as input of a request.
  • VirtualColumnAvailableInputCollection
    The collection of all available inputs that is provided to the virtual column producer by its parent. In the table, it includes the data columns of the current data table and all virtual columns that are not dependent on the current producer.
  • TableColumnCollection
    Extended with methods handling virtual columns.