How to use load_data_map

load_data_map is a parameter of the fetch/content/tree and fetch/content/list template functions.

This article will show how to use it and explain the functionality behind it.

General usage

load_data_map is a parameter of the fetch/content/tree, fetch/content/list and some other template fetch functions.

It is a flag which can be set true() or false(). The default behavior of load_data_map is to load the data_map of the fetched nodes, but if there are more than 15 nodes fetched it will not load the data_maps. The value of 15 is not configurable, because it is hard coded into the eZContentFunctionCollection class.

Approach of load_data_map is to avoid database queries. But used wrongly it can make the template inefficient.

I will now explain the usage within some examples:

Example 1: Default behaviour

<ul>
{def $articles = fetch( 'content', 'list', hash( 'parent_node_id',     $node.node_id,
                                                 'class_filter_type',  'include',
                                                 'class_filter_array', array( 'article' ) ) )}
{foreach $articles as $article}
     <li><a href={$article.url_alias|ezurl()}  alt="{$article.name|wash()}">{$article.name|wash()}</a></li>
{/foreach}
</ul>

This will fetch all articles within the current node. If there are more than 15 children the data_maps will not be loaded.

Example 2: Fetch all children without data_map

<ul>
{def $articles = fetch( 'content', 'list', hash( 'parent_node_id',     $node.node_id,
                                                 'class_filter_type',  'include',
                                                 'class_filter_array', array( 'article' ),
                                                 'load_data_map',      false() ) )}
{foreach $articles as $article}
     <li><a href={$article.url_alias|ezurl()}  alt="{$article.name|wash()}">{$article.name|wash()}</a></li>
{/foreach}
</ul>

This is a very efficient way to list and link all articles of the current node. We only need the name and the url of each article and can therefor avoid loading the data_maps.

Useless to say that it is wise to use limit and offet with a large data set.

Example 3: Fetch all children with data_map

{def $articles = fetch( 'content', 'list', hash( 'parent_node_id',     $node.node_id,
                                                 'class_filter_type',  'include',
                                                 'class_filter_array', array( 'article' ),
                                                 'load_data_map',      true() ) )}

In this fetch function call all articles within the current node will be fetched with loading the data_map.

Even if therer are 100 oder 1000 articles, the data_map of each article will be fetched. Inside eZ Publish this is be done within one single database query, but all attributes of the data_maps will be converted into PHP objects. This is very time and resource consuming.

Example 4: How to make it inefficient

<ul>
{def $articles = fetch( 'content', 'list', hash( 'parent_node_id',     $node.node_id,
                                                 'class_filter_type',  'include',
                                                 'class_filter_array', array( 'article' ),
                                                 'load_data_map',      false() ) )}
{foreach $articles as $article}
     <li><a href={$article.url_alias|ezurl()}  alt="{$article.data_map.alt_title.content|wash()}">{$article.name|wash()}</a></li>
{/foreach}
</ul>

In this example we fetch all children without the data_maps, but will call the alt_title attribute within the loop.
Lets  have a look what will happen inside eZ publish: The fetch function has not loaded the data_map, therefore it is NULL. This will trigger eZ Publish to load the data_map from the database on the first access of it.
So we will have one extra database query for each node in the list. This might make the template ineffivent.

Conclusion

load_data_map is a parameter to increase the performance of fetch/content calls. Used correctly it can avoid unnecessary database queries. But used wrongly it might cause some inperformant side effects due a mass of database queries.

So you should use it carefully and inspect the result in the Debug output of eZ Publish.