Reference Guide
Table Of Contents
- 1 Introduction
- 2 Establishing Your Test and Development Environments
- 3 Developing Applications
- Introduction
- Authentication
- REST API
- Audit Logging
- Alert Logging
- Configuration
- High Availability
- OpenFlow
- Metrics Framework
- GUI
- SKI Framework - Overview
- SKI Framework - Navigation Tree
- SKI Framework - Hash Navigation
- SKI Framework - View Life-Cycle
- SKI Framework - Live Reference Application
- UI Extension
- Introduction
- Controller Teaming
- Distributed Coordination Service
- Persistence
- Backup and Restore
- Device Driver Framework
- 4 Application Security
- 5 Including Debian Packages with Applications
- 6 Sample Application
- Application Description
- Creating Application Development Workspace
- Application Generator (Automatic Workspace Creation)
- Creating Eclipse Projects
- Updating Project Dependencies
- Building the Application
- Installing the Application
- Application Code
- 7 Testing Applications
- 8 Built-In Applications
- Appendix A
- Appendix B
- Bibliography
@Override
public void prepareDelete(CassandraAlert transportable,
DataStoreContext context) throws Exception {
SeverityComposite deleteColumn =
new SeverityComposite(transportable.getSeverity(),
transportable.getId().getValue());
context.getContext().delete(COL_FAMILY, ROW_KEY,
ColumnName
.<SeverityComposite, Void>
valueOf(deleteColumn));
}
@Override
public void prepareUpdate(CassandraAlert oldT, CassandraAlert newT,
DataStoreContext context) throws Exception {
...
}
}
In this code, SeverityComposite is the object that represents a composite column for
AlertsBySeverity. AlertsBySeverity implements CfQueryOperations interface. This interface contains
following methods.
1. prepareTransaction–prepares a secondaryColumn family row write transaction.
2. prepareMutation–prepares a secondary Column family row write.
3. prepareDelete–prepares a delete of a secondary index column.
4. prepareUpdate–prepares an update operation on AlertsBySeverity.
When a write query is issued from business logic, a new row is created or an existing row is
updated in the main column family.
In addition, there is need to create/update the secondary column families to keep the queries
updated. The above mentioned interface operations provide an abstraction to perform a write on
all secondary column families along with the main column family.
The secondary column family needs to define the necessary serializers for composite columns and
a RowKey. In the demo code, every secondary column family has exactly one very wide row. This
is done to achieve faster lookup during a read operation. If the data exceeds the upper limit of the
number of columns (2 billion columns), other methods such as sharding can be used to partition
the secondary index.
In the example, AlertsBySeverity is shown. Similar code needs to be written for each secondary
column family that is needed by the query operations of the application.
Once all secondary column families are defined along with main column family, the DAO needs
to provide the following methods. The example code of these methods as defined in the demo
application is presented here.
convert()
This method is used during read operations. When a row needs to be returned to the application,
it converts the data from storable format to a DTO.
100