The Enterprise Row Model is arguably the most powerful of the row models in ag-Grid and presents the ultimate 'big data' user experience, allowing the user to navigate through very large data sets using a mixture of server side grouping and aggregation while using infinite scrolling to bring the data back in blocks to the client.
The best way to learn what the Enterprise Model does is to break it down into the core features. You may benefit from the combination of all these features or just be interested in a subset. The features of the enterprise row model are:
Each time the grid requires more rows, it will call the
The method is passed a
params object that contains two callbacks (one for
success and one for failure) and a request object with details what row the grid
is looking for. The interface for the
params is as follows:
The request gives details on what the grid is looking for. The success and failure callbacks are not included inside the request object to keep the request object simple data (ie simple data types, no functions). This allows the request object to be serialised (eg via JSON) and sent to your server. The request has the following interface:
Studying the interfaces above alone probably won't describe the whole story in an understandable way. The best thing to do is look at the examples below and debug through them with the web console and observe what is passed back as you interact with the grid.
Below shows an example of pre-defined grouping using the olympic winners dataset. It is pre-defined as we set the grid with specific columns for row grouping and do not allow the user to change this. Then the datasource knows that the grid will either be asking for the top level country list OR the grid will be looking for winners for a particular country.
In your application, your server side would know where to get the data based on what the user is looking for, eg it could go to a relational database table to get the list of countries and then a web service to get the winners for the country as the user expands the group (a web service to get the winners per country is improbable, however the example demonstrates you do not need to go to the same datastore for the different levels in the grid).
In the example, the work your server would do is mocked for demonstrations purposes (as the online examples are self contained and do not contact any servers).
The example demonstrates the following:
The concept of 'Slice and Dice' means the user can decide what they want to group, aggregate and pivot on by dragging the columns around in the grid.
When the user changes the status of the columns (ie the user changes how the data is grouped, aggregated or pivoted) then the grid data is cleared out and loaded again from scratch using the new configuration.
A mock data store running inside the browser is used in the below example. The purpose of the mock server is to demonstrate the interaction between the grid and the server. For your application, your server side would need to understand the requests from the client and build SQL (or the SQL equivalent if using a no-SQL data store) to run the relevant query against the data store.
The example demonstrates the following:
enableRowGroup=truewhich means they can be grouped on. To group you drag the columns to the row group panel section. By default the example is grouping by Country and then Year as these columns have
enableValue=truewhich means they can be aggregated on. To aggregate you drag the column to the Values section. When you are grouping, then all columns in the Values section will be aggregated.
enablePivot=truewhich means they can be pivoted on when Pivot Mode is active. To pivot you drag the column to the Pivot section.
Achieving pivot on the server side is difficult. If you manage to implement it, you deserve lots of credit from your team and possibly a few hugs (disclaimer, we are not responsible for any inappropriate hugs you try). Here are some quick references on how you can achieve pivot in different relational databases:
To understand Pivot Mode and Secondary Columns please refer to the relevant sections on Pivoting in In Memory Row Model. The concepts mean the same in both In Memory Row Model and the Enterprise Row Model.
Secondary columns are the columns that are created as part of the pivot function. You must provide these to the grid in order for the grid to display the correct columns for the active pivot function. For example, if you pivot on Year, you need to tell the grid to create columns for 2000, 2002, 2004, 2006, 2008, 2010 and 2012.
Secondary columns are defined identically to primary columns, you provide a list of
Column Definitions to the grid. The columns are set
columnApi.setSecondaryColumns() and passing a list of columns and / or column
groups. There is no limit or restriction as to the number of columns or groups you pass - the only
thing you should ensure is that the field (or value getter) that you set for the columns matches.
If you do pass in secondary columns with the server response, be aware that setting secondary columns will reset all secondary column state. For example if resize or reorder the columns, then setting the secondary columns again will reset this. In the example above, a hash function is applied to the secondary columns to check if they are the same as the last time the server was asked to process a request. This is the examples way to make sure the secondary columns are only set into the grid when they have actually changed.
If you do not want pivot in your enterprise row model grid, then you can remove it from the tool
panel by setting
It is not possible to put up a full end to end example of the Enterprise row model on the documentation website, as we cannot host servers on our website. Instead we have put a full end to end example in Github at https://github.com/ag-grid/ag-grid-enterprise-mysql-sample/.
The example puts all the olympic winners data into a MySQL database and creates SQL on the fly based on what the user is querying. This is a full end to end example of the type of slicing and dicing we want ag-Grid to be able to do in your enterprise applications.
The example does not demonstrate pivoting. This is because pivot is not easily achievable in MySQL.
Selecting rows and groups in the enterprise row model is supported. Just set the property rowSelection to either single or multiple as with any other row model.
When you select a group, the children of that group may or may not be loaded
into the grid. For this reason the setting
selects all the children of the group when you select a group) does not make
sense. When you select a group, the group row only will be marked as selected.
The example below shows both simple 'click' selection as well as multiple 'shift-click' selections. Selecting groups is not allowed as clicking on groups is reserved for opening and closing the groups.
Below shows another example using checkbox selection. The example shows:
By default, the grid will not show row counts beside the group names. If you do want
row counts, you need to implement the
getChildCount() callback for the
grid. The callback provides you with the row data, it is your applications responsibility
to know what the child row count is. The suggestion is you set this information into
the row data item you provide to the grid.
Providing node ID's is optional. If you provide your own node id's
then you must make sure that the rows have unique ID's across your entire data
set. This means all the groups and all leaf level nodes must have unique
id's, even if the leafs are not part of the same group. This is because
the grid uses node id's internally and requires them to be unique.
If you do not provide node id's, the grid will provide the id's for you, and will make sure they are unique.
To enable Dynamic Row Height when using the enterprise row model you need to provide an implementation for the 'getRowHeight' Grid Options property. This is demonstrated in the example below:
The grid has the following API to allow you to interact with the enterprise cache.
Purges the cache. If you pass no parameters, then the top level cache is purged. To purge a child cache, then pass in the string of keys to get to the child cache. For example, to purge the cache two levels down under 'Canada' and then '2002', pass in the string array ['Canada','2002']. If you purge a cache, then all row nodes for that cache will be reset to the closed state, and all child caches will be destroyed.
|getEnterprisePageState()||Returns an object representing the state of the cache. This is useful for debugging and understanding how the cache is working.|
Below shows the API in action. The following can be noted:
getChildCount()to set the child count for each group. Your application is responsible for figuring out the child count (maybe it's an attribute you set on the data?), the example sets a random number.
To enable pagination when using the enterprise row model, all you have to do is turning pagination on with
pagination=true. Find an example below: