I could use some help here...

My understanding is that an entity is a subset of a node. In other words, an entity consists of fields stored in the DB, without all of the additional overhead (and associated DB fields) of a node for its display, translation, etc. Please correct me if I am misled or incorrect.

So I am building a system wherein many nodes reference, in a one-to-many or many-to-one functionality, what are essentially entities and not necessarily nodes. In other words, I do not need to display these entities by themselves. They will be displayed by views embedded in the output of their parent nodes.

I could, of course, just make every minute data storage element a node, but something tells me that this would invoke a bunch of unnecessary overhead, not only in terms of processing, but also data storage as well.

As an example: An Item (which rightly is a node) might have, say, two or three possible "modes of fabrication," each consisting of a "method" and a "quantity per operation". I would like to have the Mode (with quantity associated with it as a field) be a database entity which also has a node reference field pointing to its parent node (the item to which it pertains). I don't need the Mode to be a node, as it only provides concise data to its parent node (the Item to which it is associated by the aforementioned node reference field).

I have installed the Entity Plus and Entity UI modules, but I cannot find a way to construct an entity. Any help is appreciated. Thanks.

—Eric

 

Comments

I was just talking with a friend about this earlier tonight. Unfortunately, I'm not the best person to answer this - but I can give you thoughts to keep you going until someone else jumps in. 

1) In Drupal 7 I believe that you could create a custom entity through the UI with the Entity Construction Kit module https://www.drupal.org/project/eck/. To my knowledge (and I looked), this module does not exist for Backdrop CMS. 

2) I believe that the only way to create custom entities for Backdrop CMS would be with custom code. Personally, I would try googling "Drupal 7 Create Custom Entity" - I think you will find lots of documentation. Much of it MIGHT be useful, but I'm not sure. If you are in a rush, you could give this a try. Otherwise, wait for someone with more info. 

3) My last thought is that you MIGHT be able to accomplish what you are looking for with taxonomy. Taxonomy terms are fieldable and you can reference them. Based upon your description, I think that is how I would likely handle your use case, but I may be missing something. Create a vocabulary for "mode of operation" and add your custom fields. 

My understanding is that an entity is a subset of a node. In other words, an entity consists of fields stored in the DB, without all of the additional overhead (and associated DB fields) of a node for its display, translation, etc. Please correct me if I am misled or incorrect.

You are close on this one, but I understand it to be the opposite. Nodes are a subset of entities. Nodes are entities that come with extra overhead. Entities are the most basic form of content. Nodes, Taxonomy Terms, Files are all different types of entities. You are looking for an entity type that is different/simpler than a node and if I'm correct, taxonony terms might work for you. 

BWPanda's picture

As Tim said, the hierarchy is as follows:

  • Entities
    • Nodes
    • Taxonomy terms
    • Users
    • etc.

It sounds like what you're wanting is either a Field Collection or a Multifield (or possibly Paragraph). All of them essentially allow you to do something like this:

  • Item (node)
    • Title (field)
    • Body (field)
    • Modes of Fabrication (field collection/multifield/paragraph)
      • Method (field)
      • Quantity per Operation (field)

As the previous people have mentioned, "Entities" in Backdrop and Drupal are not a subset of Nodes, back rather the other way around: Nodes are Entities, as well as other data structures in Backdrop such as Taxonomy Terms, Files, Users, etc. 

I wanted to mention a module I recently created called Basic Entity Plus Example  that provides a ready-made example of a custom entity.  The entity provided there is a "cousin" of Nodes, but it gives you the flexibility to customize it without messing up the original Node architecture. A few notes about the entity provided in the example:

  • It's "fieldable", meaning that you can add Backdrop fields to it through the UI
  • It's "bundeable", meaning that you can create, through the UI, new "types" of that entity, the same way you create new "content types" of nodes. Each of those types can have different fields
  • It's accessible through Views, meaning you can create views to display all the content entered in those entities, and you can create relationships to other entities

One more word about your project: whether you end up using custom entities or different content types (nodes), you will need to use a field that allows you to create references among entities/nodes. I recommend Entity Reference , which creates a new field type you can add to your nodes or to your custom entities.

Last word: custom entities created with Entity Plus and Entity UI like the one example I created are NOT "lighter" than Nodes. They are very similar in many ways: they use at least two DB tables: one for storing the entity content, and one for defining different entity bundles. In addition, every field you create (whether it's nodes or entities) create one or two additional tables to store the content of the fields, and sometimes the revision (old content).

I've used custom entities for a long time, and can help answer any quick question you may have. Try using Backdrop's Zulip channel for quick answers. 

 

Great responses, but to answer one of your questions, proably the main question, how to create an Entity, it can actually be quite simple, in fact. You need an Entity Class file, and you need to implement hook_entity_info() and hook_autoload_info() at minimum. 

For the hook_entity_info() lots of examples available but the minimum code required:

function entity_test_entity_info() {
  $return = array(
    'entity_test' => array(
      'label' => t('Test entity'),
      'entity class' => 'TestEntity',
      'controller class' => 'EntityDatabaseStorageController',
      'base table' => 'entity_test',
      'fieldable' => TRUE,
      'entity keys' => array(
        'id' => 'id',
      ),
    ),
  );
  return $return;
}

For your entity class, the minimum code is:

class TestEntity extends Entity {
  public $id;

  /**
   * Implements EntityInterface::id().
   */
  public function id() {
    return $this->id;
  }

  /**
   * Implements EntityInterface::entityType().
   */
  public function entityType() {
    return 'entity_test';
  }

  /**
   * Implements EntityInterface::label().
   */
  public function label() {
    return 'label';
  }

  /**
   * Implements EntityInterface::uri().
   */
  public function uri() {
    return array(
      'path' => 'test/' . $this->id,
    );
  }

}

And autoload to tell Backdrop where your Entity class lives:
 

function entity_test_autoload_info() {
  return array(
    'TestEntity' => 'entity_test.entity.inc',
  );
}

You'd need a db table called test_entity or whatever you define in 'base table' in entity_info, And thats it, you have an Entity. 

If you did $first_entity = entity_create('test_entity; array('id' => 1)); then $first_entity->save() it should work fine and save to your db. All the load, etc functions should work.

But of course this is the minimum.

Fantastic answer, @docwilmot. Since the OP also mentioned his intention to use Views to display the custom entities, I wanted to add that, AFAIK, core does not provide views integration for custom entities (pls correct me if I'm wrong). Entity Plus, which the OP also mentioned, will provide that out of the box.   

To all: Thanks for this immense body of assistance! And BTW: I totally said it backwards: nodes are a type of entity, that's clear. I think my use of the word "subset" points to why I got it wrong: I was thinking in terms of the data structure itself, wherein (in my mind) you take an entity, then ADD more data to it to make it into a node. Thus in that sense the structure of the entity would be a subset of the structure of the node. This is just my perception, which could be incorrect...

I shall attempt to digest all of the great info you all have provided. Thanks!

Okay... after some investigation, here is my analysis. Please straighten me out if I'm off on a wild tangent, or if I have missed something here.

I have looked at the entity_example module, which offers me a very clear path to creating the module I think I'm looking for—with all of the heavy lifting already done for me. But I would like to solicit your collective input in case I'm thinking wrong, or proposing something that has already been done, which I'm just not clued in to.

What I think I'm looking for is a way to create "entity types" in the same way that we currently create "content types" in the UI. My reasoning is this: All I need is a collection of fields, without most of the trappings of a content type. For instance, I don't need any of the following attributes for my entity:

  • Title
  • Publishing settings
  • Rating Settings
  • URL alias pattern
  • Revision settings
  • Menu settings
  • Display settings
  • Comment Settings
  • etc.

Now, it's entirely possible that the above list, in fact, imposes no overhead if unused. In other words, all those settings may not be stored with the node—they might be stored in separate tables with references to the node(s) in question. My gut tells me that at least for some (especially those provided by add-on modules) this is the case.

Looking back at the entity_example... It seems to me that its administration menu location is logically one level higher than where it should belong. I envision a menu hierarchy that would look like the following:

  • Structure
    • Content types
    • Custom blocks
    • File types
    • ...
    • Entity types

Please tell me if I'm wrong here: Each content type represents a particular bundle. Is this correct? If so, then I am looking for a means to create Entity bundles, to each of which could be added fields. Unless I am wrong, the "entity_example_basic entity" type comprises a bundle, right? It should therefore reside one level lower, under the "Entity types" level of my own invention above.

The reason for this treatise is NOT to correct anyone! Rather, it is my own long-winded way of asking you, the community, if I have a clear understanding of things.

Now, for my current use case, it appears that the Field Collection module would likely provide everything I need, especially since it automagically attaches a node reference field to the field collection, pointing to its parent node (or possibly an entity reference field to the parent node, pointing to the field collection).

In a broader, more generalized use case, however, I anticipate that the ability to manually create entity types (manually creating node or entity reference fields therein) would be preferred. In particular, the Field Collection module offers a very intuitive way to create a one-to-many (node->entity) relationship (via the multiple values field option), I am not sure if it is possible to point more than one node to the same Field Collection (many-to-one). 

The back story: I am a manufacturer. I have been using, for years now, an ERP system which I built in Drupal 6, and I am now re-implementing that into a Backdrop site. I have never built a module. I have accomplished everything using Computed Fields, and it works amazingly well. Of course, Drupal 6 didn't have much to say about entities, as I recall... And of course Drupal 8 was a big fail for me, which is why I am now so bullish on Backdrop.

My ERP system comprises, say, a few thousand "orders ( or jobs)," each of which has 1 to 10 "line items," each of which references one of several hundred "items." So the scale is not huge, as you can see. I am, nonetheless, always looking to the future, and wondering if I might want to publish this animal, in which case things ought to be done right. BackdERP... any takers?

Anyway, I really appreciate the level of response and support that this community has given me!

Summary questions:

  1. Am I correct in my understanding of the meaning of "bundle"?
  2. Am I correct in that the entity_example is a particular bundle, providing no means of building other bundles, short of replicating the module itself?
  3. Is my concern for the overhead of nodes (content types) at all valid, or should I just relax a little, and make everything a node and not worry about it?