Writing a new Features Reporter class

Implementing a FeaturesReporter involves the following steps:

Implement the FeaturesReporter class interface (see directly below). In addition to below, you can also use code_templates to generate the the class .hh and .cc files.
Implement the FeaturesReporterCreator class interface (like you would for a mover).
Register the FeatureReporter with the FeaturesReporterRegistrator (rosetta/main/source/src/protocols/init/init.FeaturesReporterCreators.ihh and rosetta/main/source/src/protocols/init/init.FeaturesReporterRegistrators.ihh)
Add the FeatureReporter to the FeatureReporterTests (rosetta/main/source/test/protocols/features/FeaturesReporterTests.cxxtest.hh) Unit Test.
Consider adding the FeatureReporter to the features integration test (rosetta/main/tests/integration/tests/features).
Document the FeatureReporter in the Features Database Schema page.
Add new types in organizational page

FeatureReporter Class Interface

The FeatureReporter (rosetta/main/source/src/protocols/features/FeaturesReporter.hh) base class interface has the following components, which should be implemented by a new FeaturesReporter:

Required Methods

type_name : Returns the a string for the type of the feature reporter
schema : Return SQL statements that setup tables in the database to contain the features. To support all database backends, use the schema generation framework (write_schema_to_db function).
report_features : Extract all features to the database

Optional Methods

features_reporter_dependencies : Returns a vector of the names of the features reporters that this one depends on. (In the rosetta_scripts, the ReportToDB mover enforces this dependency by requiring the FeaturesReporters listed here to be defined higher in the list.)
parse_my_tag : How in rosetta scripts the <Feature name=(& type_name string)/> subtag to the ReportToDB mover is parsed.
load_into_pose : If the data is used to initialize an aspect of a pose, put the logic here.
delete_records : Delete all records from the database associated with a structure.

As an example consider the PoseCommentsFeatures (rosetta/main/source/protocols/features/PoseCommentsFeatures.hh) feature reporter. Arbitrary textual information may be associated with a pose in the form of (key, val) comments (See rosetta/main/source/src/core/pose/util.hh). The PoseCommentsFeatures FeaturesReporter extracts all defined comments to a table pose_comments using the struct_id and key as the primary key. The struct_id references the the structures table that identifies each of the structures in the database.

In the report_features function, sessionOP is an owning pointer to the database where the features should be written. See the database interface for how to obtain and interact with database sessions.

string
PoseCommentsFeatures::type_name() const { return "PoseCommentsFeatures"; }

string
PoseCommentsFeatures::schema() const {
  return
    "CREATE TABLE IF NOT EXISTS pose_comments (\n"
    " struct_id INTEGER,\n"
    " key TEXT,\n"
    " value TEXT,\n"
    " FOREIGN KEY (struct_id)\n"
    " REFERENCES structures (struct_id)\n"
    " DEFERRABLE INITIALLY DEFERRED,\n"
    " PRIMARY KEY(struct_id, key));";
}

Size
PoseCommentsFeatures::report_features(
  Pose const & pose,
  Size struct_id,
  sessionOP db_session
){  
  typedef map< string, string >::value_type kv_pair;
  foreach(kv_pair const & kv, get_all_comments(pose)){
    statement stmt = (*db_session) <<
      "INSERT INTO pose_comments VALUES (?,?,?)" <<
      struct_id << kv.first << kv.second;
    stmt.exec();
  }

  return 0;
}

A FeatureReporter may optionally be constructed with a ScoreFunction. For example, see the RotamerRecoveryFeatures class (rosetta/main/source/protocols/features/RotamerRecoveryFeatures.hh).

Writing a new Features Reporter class

FeatureReporter Class Interface

See Also