InMemoryDataProviderWrapper: Data Provider on Steroids

The features of different data providers vary widely. Depending on the data source, sorting, native aggregate functions or filters at database level may be available directly. Or not. For example, none of this is available in file-based formats such as JSON or XML, or even in “web” formats such as REST. These are typically read “front to back” and therefore cannot offer sorting or native aggregation. With List & Label 29, we have something new to offer.

native aggregate functions and sorting

The InMemoryDataProvider has been around for a long time. I’ve written about it here before. However, there is one important limitation: this provider does not support relations that do not result from key fields. You can’t simply “pack” XML into it; it’s only suitable for “flat” formats like CSV or XLS. However, the basic technology has been around for a long time. When I discovered this customer wish in our Idea Place, it sparked the idea of extending this technology to cover any data provider structures.

The result is the InMemoryDataProviderWrapper. Using it is very simple:

// The RestDataProvider or the SchemaAwareJsonDataProvider are also suitable here
XmlDataProvider provider = new XmlDataProvider(@"c:\temp\text.xml");
using (ListLabel LL = new ListLabel())
// the wrapper around the XML provider is created here. This one line is the only change
InMemoryDataProviderWrapper wrapper = new InMemoryDataProviderWrapper(provider);
LL.DataSource = wrapper;

The highlight: wrapping doesn’t change the structure, i.e. the project files that have already been created for the XML can remain unchanged. The test XML for this blog post is from here. Previously, without the wrapper, sorting wasn’t available. Now, sorting can be selected with an otherwise completely identical structure:

sort order for report

Another option is working with native filters:

use native filters

A selection of native aggregate functions is also available:

overview native aggregate functions

The provider uses the least amount of memory possible – tables are only loaded into memory when they’re actually needed. This means there’s no complete caching of the (possibly very large) file, but caching on demand. And if the features are no longer needed at some point, the wrapper can be removed at any time without having to change the project files.

Thank you very much for the suggestion in the Idea Place. I’m happy about this new member in our data provider zoo.

Related Posts

Leave a Comment