The IndexedDataProviderCache provides random access to provider data with look ahead caching to optimize querying and take advantage of data coherence. The best example of this is in the swing table which is included in one of the examples. A swing table model knows the number of rows of data that exist (which could be thousands or millions) and lets the user scroll across the whole dataset. This means that the user can select any record from the available dataset at any point in time. In this event, it would be fetched from the data provider and returned to the user. However, the user will probably end up fetching the next x number of objects from the dataset as the next x number of rows in the table are displayed. For this reason, the cache not only fetches the requested row, but the next n number of rows where n is the batch size defined by an attribute on the cache. The IndexedDataProviderCache keeps hold of these items since they may well be reused when the table is repainted or the user starts to scroll backwards or forwards a few records at a time. This cache is limited in size, and records will start to be ejected on a least recently used basis. The IndexedDataProviderCache can be used to randomly browse thousands of records with no startup time and efficient memory use since it doesn't read all the data in at once. (The delay at the start is due to the creation of the database, not the loading of all the data).

You should not avoid calling fetchRecordCount from within the data provider. The most likely place you will call it is to determine whether there are more results to be returned. This can be an expensive call to count all records or rows of data from the source that should be avoided if possible. In the database data provider included, we fetch an extra row to see if there are more results after the set of rows we want. This extra row is then taken off the final results that are returned to the user.

With Spigot you can subclass either a SeamJPaQueryDataset or a SeamJpaNativeDataset so you can use either a Ejbql or Native query for fetching data. Also, there are adapter classes that can be used instead which adapts the interface to look more like an EntityQuery so you can just substitute one for the other.