2

So I want to create an entity that can have as many user-created fieldable bundles as possible.

My first thought was to look at the Profile2 module, however I notice that there appear to be two separate entities as part of it - the profile2 entity, as well as a profile2_type.

  // Add bundle info but bypass entity_load() as we cannot use it here.
  $types = db_select('profile_type', 'p')
    ->fields('p')
    ->execute()
    ->fetchAllAssoc('type');

  foreach ($types as $type => $info) {
    $return['profile2']['bundles'][$type] = array(
      'label' => $info->label,
      'admin' => array(
        'path' => 'admin/structure/profiles/manage/%profile2_type',
        'real path' => 'admin/structure/profiles/manage/' . $type,
        'bundle argument' => 4,
        'access arguments' => array('administer profiles'),
      ),
    );
  }

I want to have separate entities with only one instance, but unlimited bundles. Do I need to create two separate tables to accomplish this, or should it be possible with one table? I think it should be possible, but I'm not quite sure.

1 Answer 1

1

You have to register entities using hook_entity_info() so the system knows about them.

If you look at those docs it tells you about the different entity properties.

The one you are interested in at the moment is the bundle entity key and the bundles array.

You can see from the docs that you have to specify a list of bundles, otherwise it will be assumed you only have a single bundle with the same name as the entity type.

The example I would probably look at is node, because it is in Drupal core, so check out node_entity_info().

You can see it works similar to the profile2 one in that it gets its node bundle information from the database from where users have defined content types via the content type UI (and also from hook_node_info() for modules defining content types).

So you need a table for the bundle information, similar to the node_type table.

You also need your table to store entity data, similar to the node table.

If you want to support revisions you also need a revision table, similar to the node_revision table.

I can't see how it is possible with a single table unless you are storing 2 completely different types of data in a single database table, which would be bad.

Another thing to consider is that the system needs to know about bundles to provide UI screens for managing fields. You have to manage the fields before the user creates any content so at the time you need those UI pages there is nothing in the node table so it couldn't pull bundle data from there at that point. If you pulled bundle data from the main node table you wouldn't be able to administer the fields until a node was created of that bundle type.

I'm also not sure why you are apprehensive about having 2 tables.

2
  • Not apprehensive, just trying to figure out precisely how it works. It seemed unnecessary to me - but I think you've explained it in a way that makes sense. I'll try to replicate it and if it works I'll give you the answer.
    – Jack Ryan
    Dec 20, 2014 at 22:16
  • I added another extra note near the bottom about a single table system.
    – rooby
    Dec 20, 2014 at 22:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.