Datasets

📘

Datasets are intended to serve as a “package” of data that can contain one or more items.

Each Dataset Item can contain a set of rows of different information. The primary use case for a dataset is to provide commonly used and infrequently changing data to be used and cached in a client environment. Each provider implements its own form of caching (or can opt to not implement caching). A good example of a dataset is the built-in Dataset MJ_Metadata. This dataset has the following definition:

Dataset: {
Name: "MJ_Metadata",
Description: "Core Metadata for MemberJunction",
Dataset Items: [
{
Code: "ApplicationEntities",
Entity: "Application Entities",
WhereClause: NULL,
DateFieldToCheck: "UpdatedAt"
},
{
Code: "Applications",
Entity: "Applications",
WhereClause: NULL,
DateFieldToCheck: "UpdatedAt"
},
{
Code: "Authorizations",
Entity: "Authorizations",
WhereClause: NULL,
DateFieldToCheck: "UpdatedAt"
},
{
Code: "Entities",
Entity: "Entities",
WhereClause: NULL,
DateFieldToCheck: "UpdatedAt"
},
{
Code: "EntityFields",
Entity: "Entity Fields",
WhereClause: NULL,
DateFieldToCheck: "UpdatedAt"
},
/ more dataset items in the actual system /
]
}

In the above sample (pseudo-JSON to illustrate what’s in the Dataset and Dataset Item entities), you can see that the MJ_Metadata Dataset contains a collection of various types of metadata that are commonly used in any application environment. The advantage to defining all of this in a single Dataset is that retrieval and storage of this dataset is done with a single request to the API making it network efficient. A few key points to note about the structure of each Dataset Item:

• Code: this is simply a name that can be reliably used in retrieving the dataset item from within the Dataset, this is preferable compared to using the entity name or an index into the array. In the case of Entity, the reason it is preferable is that you might actually include the same Entity in a single dataset more than once with different WhereClause properties to filter on different things.
• Entity: The name of the entity for the data
• WhereClause: either null or a valid SQL WHERE clause to filter the entity
• DateFieldToCheck: the single requirement for an entity to participate in a Dataset is that it must have a date field that can be used to determine if the data has changed since it was last cached. Most of the time, you should use the built in CreatedAt/UpdatedAt fields that you can add to any entity in MemberJunction simply by defining them in your table, then run CodeGen, and MJ will handle the rest of the code needed to ensure that these fields are managed automatically for you to date/time stamp records when they are created and updated respectively.