Type 1 data

The majority of record based data is considered to be Type 1. This means that there is only one level of fields under the main container.

The figure below shows an example field structure for a simple full quote display for the symbol IBM.

Example of Type 1 data within a record

Here, the single container IBM has one level of five fields, Bid, Ask, Last, Volume and Accumulated Volume. Whenever an update comes in to Caplin Datasource SDK for any of these fields the value is over-written.

A user newly subscribing to IBM would then see this new value; the previous value would not be available.

Type 2 data

Type 2 data is often referred to as "level 2" data, as it is mostly used for level 2 quote data. Level 2 quote data enables several price quotes per symbol (coming from different market makers or traders) to be available at all times.

The field structure shown below might be applicable for a simple level 2 display for IBM, where there are three or more active market makers.

Example of Type 2 data within a record

In this case the IBM container (primary key) has a secondary key of Market Maker (MM). This allows a new subscriber to see the full set of quotes in the market by enabling them to view each set of quotes from each market maker.

A quote update in this example will always have a market maker associated with it, causing only a specific sub-set of fields to be overwritten.

Type 3 data

Type 3 data allows for the storage of update history by keeping all updates of this type and not overwriting the symbol/field pair. A common use for Type 3 record data is for holding and viewing daily trade activity where, typically, this mechanism will only be used for a day at a time before the cache is deleted and the update list starts again.

The figure below shows a Type 3 field structure, which is similar to a Type 1 field structure but with many instances.

Example of Type 3 data within a record

Each new update is placed as the first (most recent) item on the list. Subscribers would receive the whole list as part of the initial subscribe response. The size and purging frequency of this list is configurable separately to the size and purging frequency of the fields themselves.