Docs‎ > ‎Integrate Menu‎ > ‎Data Sources‎ > ‎

Non-persistent Attributes

Non-persistent attributes (NPAs) are pseudo-columns (attributes) that you can add to your API project without affecting the database schema. Use NPAs in resources, Data Explorer, and rules, such as derivations and validations.

Use NPAs for:
  • Retrieval logic. For example, you might store a first and last name but create an API that returns the full name.
  • Update logic. Use derivations to compute values and roll-up sum/count aggregates, as shown in the Business to Business example.
NPAs are useful when:
  • You cannot alter the database schemas. For example, another application that does not change the value is using the NPA. 
  • You want to minimize data-maintenance tasks. For example, you want to further speed development.
Treat NPAs (mostly) like a regular column: 
  • Return values in resources.
  • Define derivations for use in other reactive logic rules.
  • View in Data Explorer.
Important! NPAs can incur substantial performance overhead as compared to stored columns.

Compute Rules as SQL Expressions

You can tune the API Server using NPAs. This is analogous to SQL optimizer hints. Live API Creator can compute rules as SQL expressions if the rules follow certain restrictions. It computes rules that compute the value of non-persistent attributes faster than other rules.

Add and Use Non-Persistent Attributes

The Business to Business Example uses NPAs to provide a discount to customers who eat healthy. In the following example, you complete the following process to add and use the NPA:
  1. Add the NPA attribute to your data source.
  2. Specify the derivation rule for the NPA's value.
  3. Use the NPA in resources.

Add the Non-Persistent Attribute to your Data Source

Add the NPA attributes to your data source. With your API project open, from Integrate menu, click Data Sources, Non-persistent attributes, Add, and then save your changes. The following image illustrates an NPA named fullname:

Specify the Derivation Rule

Specify the derivation rule for its value. From the Manage menu, click Rules, By topic, and specify the derivation rule. The following image shows the rule:

Use the NPA in a Resource

From the Create menu, click Resources, Attributes. The following image illustrates using the NPA fullname in the resource SalesRep:

NPA Best Practices

A classic design decision in applications development is whether to persist derived data. Historically, it has been a trade-off:
  • Performance. Non-persisted data can perform orders of magnitude slower. This most often occurs with aggregates, when there are a large number of children per parent, or when aggregations chain. For example, it can be expensive to compute a balance by adding up all the items for all the orders of a customer, or to compute a department budget by recursively summing all the sub departments.
  • Data Consistency. All applications must update the derivations properly to avoid consistency errors.
The challenge has been that it is not always clear how data distributions will turn out. Recoding all the accessing logic to switch strategies can be very expensive. These are often discovered near the end of development when full test data volumes are loaded, and can result in significant rework and delays.

While the dilemma remains, Live API creator can eliminate the cost of rework. If you add/drop NPAs, Live API Creator adjusts your logic accordingly. For example, Live API Creator uses adjustment logic in maintaining aggregates.

Consider the following when establishing Best Practices for your project:
  • If you are dealing with an existing system and not to change the schema, use NPAs.
  • If you can change the schema to define persistent attributes, complete the following:
    1. Define the attributes as NPAs. This eliminates the SQL required to synchronize your data with your rules.
    2. If your logic is all tested and you then discover performance issues, delete the NPAs and alter the schema to define the persisted columns.
Live API Creator re-optimizes your logic. Recoding is not required, though note you will still need to synchronize your data as described above. Such flexibility is quite analogous to using relational databases, where you can add/drop indices without recoding. Just as the relational optimizer makes use of the new index, the API Server optimizes your update logic in the same manner.