Entity is your friend

We are currently creating a website where you have episodes. Each episode has a video which has rights attached to it. The rights are fed into the system by an XML feed. Each right has a type, a start of availability, end of availability, a price. We need to store these somewhere...

Why not just use field_collection?

Field collection creates a hidden entity for you, lets you field it and makes all sorts of gymnastics to make them visible on the original node. We can create our own entity with much less effort. Also, we do not want these rights to be Drupal-editable. Likely, not even visible. Not even to node admins.

Why not use something like modal/micro/ECK?

Micro is abandoned, modal stores the types in another entity much like taxonomy terms/vocabulary which adds overhead we don’t need and ECK is not yet ready so we don’t need to evaluate it.

Why not a node?

Everything node offers is a nuisance to us. We do not need any of the attributes the node table stores, we do not need any node capabilities like view, edit, delete (ok, we need insert), search. Edit is, once again, a downright problem.

So we set out to write our own entity. Initially we will use Entity API but we are prepared to remove the dependency. We are using Entity API to provide CRUD services which in this case would be mostly served by drupal_write_record() just fine and to provide Views integration which -- given the five or so properties the entity has -- is not too big of a deal to write.

<?php
/**
 * @file example_entity.module
 * TODO: Enter file description here.
 */

function example_entity_entity_info() {
  $return = array(
    'example' => array(
      'label' => t('Example'),
      'base table' => 'example_entity',
      'fieldable' => FALSE,
      'entity keys' => array(
        'id' => 'rid',
        'bundle' => 'type',
      ),
      'bundles' => array(),
      'module' => 'example_entity',
      'controller class' => 'EntityAPIController',
    ),
  );
  return $return;
}

function example_entity_entity_property_info() {
  $info = array();
  $properties =& $info['example']['properties'];

  $properties['nid'] = array(
    'label' => t('Episode nid'),
    'type' => 'node',
    'description' => t('Episode node.'),
    'schema field' => 'nid',
  );
  $properties['type'] = array(
    'label' => t('Right type'),
    'type' => 'string',
    'description' => t('Right type.'),
    'schema field' => 'type',
  );

  return $info;
}

And that’s it. Of course you need a schema (you can copy-paste it together from say node_schema() using the definition of a serial, an int and a varchar) and an info too. Of particular interest are the module and controller class keys which trigger the default Views integration in Entity API. In hook_entity_property_info it seems the "schema field" does not default to the array key and so we need to provide it, the Views integration doesn’t work otherwise. That’s it, you have an entity up and kicking.