> ## Documentation Index
> Fetch the complete documentation index at: https://docs.activeviam.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Adding new cube measures

This page provides a description of how we can add a measure. It features an example in which we use the ‘CustomProjected’ field from a store which we
previously added. For a walk-through on how this store was added to the cube,
see [Adding and Populating a New Store](../etl/creating-and-loading-a-custom-store).

The techniques employed are generic examples that can be
extended, adapted and repeated for any use case that we need. In all cases, we make minimal changes to the Reference Implementation.

 

## Step 1 - (Optional) Modify the selection description

If the field we want to turn into a measure is not currently in our schema selection, then the first step is to add it.

The cube selection is made by retrieving all fields from a datastore except unwanted ones, so adding an extra field to an existing store will add it to the
selection. Only extra datastore fields will need a change on the selection.

Fields are added to the schema selection by creating a Spring Bean with type `UnaryOperator<CanUseOtherReference>` and qualifier
`SchemaSelection_CUBENAME_` (for example,
`SchemaSelectionStandardisedApproachCube`).

For example:

```java theme={"languages":{"custom":["/engine/python-sdk/0.9/languages/pycon.tmLanguage.json"]}}
    @Qualifier("SchemaSelectionStandardisedApproachCube")
@Bean
    UnaryOperator<CanUseOtherReference> extraSchemaSelections() {
		return builder -> builder
		.usingReference(storesToPath(SA_SENSITIVITIES_STORE_NAME, "TESTSTORE"))
		.withAllFields()
		.except(AS_OF_DATE, RISK_CLASS);
		}
```

## Step 2 - Define measure

 

In this case we need to extend the `SAMeasureBuilder` class for creating measures.

```java theme={"languages":{"custom":["/engine/python-sdk/0.9/languages/pycon.tmLanguage.json"]}}
public class ExtendedSAMeasureBuilder implements SAMeasureBuilder {

    @Override
    public void measures(ICopperContext context) {
        Copper.sum("CustomProjected").publish(context);
    }
}
```

To read more about creating measures with Copper,
see [Creating and publishing measures.](/engine/java-sdk/6.1/copper/copper_measures/)

## Step 3 - Application config

Navigate to the configuration class where the original MeasureBuilder class (`SAMeasureBuilder`) was being used, in this case
`com.activeviam.frtb.ref.cfg.applications.cubes.impl.SACubeConfigurer`, and replace the old MeasureBuilder class with the newly extended one

`/frtb-starter/src/main/java/com/activeviam/frtb/starter/cfg/impl/`

```java theme={"languages":{"custom":["/engine/python-sdk/0.9/languages/pycon.tmLanguage.json"]}}
@Configuration
@Import(value = {
...
        ExtendedSAMeasureBuilder.class,
        //      SAMeasureBuilder.class
...
})
```

### Measure Beans

<Note>
  This is currently only supported by InternalModelApproachCube, StandardisedApproachCube and StressCalibrationCube.
</Note>

Below is an example of a measure bean definition for the SA.

`/frtb-starter/src/main/java/com/activeviam/frtb/starter/cfg/impl/`

```java theme={"languages":{"custom":["/engine/python-sdk/0.9/languages/pycon.tmLanguage.json"]}}
@Qualifier(CUSTOM_MEASURE)
@SAMeasure
protected CopperMeasure customMeasure() {
	return Copper.sum("CustomProjected");
}
```

When creating measure beans this way, be sure to include our configuration class which contains our beans in the application config class `FRTBConfig` located
in `/frtb-starter/src/main/java/com/activeviam/frtb/starter/cfg/impl/`

## When using DirectQuery

When using DirectQuery, perform the steps as listed above. There are no additional requirements. However, you must ensure that your remote database and datastore description are
configured correctly. For information on how to add tables and fields to the remote database when using DirectQuery, see the dedicated section in [Adding and Populating a New Store](../etl/creating-and-loading-a-custom-store#when-using-directquery).

### Perfomance impact of datastore lookups

Datastore lookups and GetByKey queries are not recommended when using DirectQuery. If you have
data coming from a DirectQuery remote table and you need to perform frequent datastore lookups or any GetByKey queries, then it is more efficient to
cache the table in an in-memory datastore store. For
more information on caching tables with DirectQuery, see [Caching Remote Tables](../../dev-direct-query/customization-and-internals/caching-remote-tables).

## Suggested further reading

[Adding New Cube Hierarchies](./add-a-new-cube-hierarchy)

[Adding New KPIs](./add-a-new-kpi)