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

 

Most helpful answers

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?

I don't know the detailed architecture of entities and nodes, and I'm not able to evaluate the technical overhead of using nodes about using custom entities. From a practical perspective, using nodes could also mean less overhead because it's much less work to build the entities itself (and some of their features in case you need them).

By the way, are you aware of the setting "Hide path display" in the "Display settings" tab of the node configuration form? In my opinion it's a great start for custom-entity-like node types.

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. 

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
      • Page
      • Post
      • ...
    • Custom blocks
    • File types
    • ...
    • [Other] Entity types
      • Entity_example...

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 an entity reference field to the parent node, pointing to the field collection (or possibly it adds a node reference field to the field collection, pointing back to its parent node ).

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?
  4. Should I just man up, stop fiddling around with the UI, and write my own module? Would the thing be easier to manage if I accomplished the desired functionality programmatically? (Something tells me I should do this...)

@ericfoy - I hope that someone more confident in this subject matters chimes in here, but based upon my experience, I think your understanding is pretty accurate. Most of us don't talk much about 'entities' and 'bundles' in Backdrop, but my understanding is that in theory these terms are still accurate and work the same as they do in Drupal. This chart for Drupal 8 seems to be saying exactly what you are saying and I would assume this is true for backdrop.
https://www.drupal.org/docs/drupal-apis/entity-api/bundles

I think that you MIGHT be overly worried about the overhead of nodes, but given your situation, I MIGHT also be going the same direction that you are anyway, just because it feels cleaner. 

I've often went into a project thinking I MIGHT need a new custom entity, but it never seems to come to that. I usually find a way around it. Sometimes with a vocabulary or another entity provided by a contrib module (in Drupal Groups are an example). 

I will not speak to the issue of "Field Collections" - because I have not looked at them in a long time. 

Again - I really do hope that someone more conversant in "Entities" and "Bundles" chimes in here and offers their opinion (and corrects any mistakes I might be making). 

Olafski's picture

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?

I don't know the detailed architecture of entities and nodes, and I'm not able to evaluate the technical overhead of using nodes about using custom entities. From a practical perspective, using nodes could also mean less overhead because it's much less work to build the entities itself (and some of their features in case you need them).

By the way, are you aware of the setting "Hide path display" in the "Display settings" tab of the node configuration form? In my opinion it's a great start for custom-entity-like node types.

By the way, are you aware of the setting "Hide path display" in the "Display settings" tab of the node configuration form? In my opinion it's a great start for custom-entity-like node types.

Thank you for this tip. —Eric

@ericfoy, you are not alone in the struggle to understand the lingo of entities in Drupal (and Backdrop). It's confusing, and unfortunately sometimes the UI/end user terms do not coincide with the developer/programmer ones to describe the same thing (e.g. "Content" and "Content type" are only used by the end user). To add to the confusion, "type" and "bundle" are sometimes use interchangeably, but they mean different things (a "content type" for an end user is a "node bundle" for a developer).   

I suggest this article, which explains the terminology pretty well, as well as some the other linked resources at the bottom of that article.

The entity_example module provides a very basic example of a custom entity, but it's a great starting point to develop your own.

You are correct: the entity defined in the entity_example module you mentioned provides only ONE fixed bundle (named first_example_bundle), and the example does not provide a way to create other bundles through the UI. In order to create other bundles of that entity type you need to modify the code, specifically under the key 'bundles' of the function entity_example_entity_info(). 

If you want an example of a custom entity that uses the UI access to create new bundles I suggest the Basic Entity Plus Example I mentioned in my comment last week. It uses the module Entity UI to provide the bundle creation UI. 

Regarding the location of the menu links of entity_example: keep in mind that the links are not "fixed," and are actually defined  in entity_example_menu() and also under the 'admin' key under 'bundles' in entity_example_entity_info() (this 'admin' key tells the Field API where to place the field management admin UI).

As for using nodes exclusively to tackle your project - it IS possible! I wouldn't worry too much about overhead. In the end the number of tables end up being similar with nodes or custom entities (BTW, each new field you add to a node bundle usually creates two additional tables - this is also true for custom entities. Unless you reuse fields in different bundles). 

When I first starting working with Drupal 7 I needed, like you, 6 or 7 "content types" with different fields, and I worked exclusively with nodes and with the module Entity Reference to create relationships between those nodes. It was OK - there were some drawbacks to it, but you can make it work. Later I started using custom entities, mostly because you could customize their classes more easily and you could split all the admin interface away from the Content and Content Type areas of the admin ui. 

  

If you want an example of a custom entity that uses the UI access to create new bundles I suggest the Basic Entity Plus Example I mentioned in my comment last week. It uses the module Entity UI to provide the bundle creation UI. 

Well... there's a Duh for me! The first time I read your mention of this module, I just thought you were talking about the Entity Example module. So I was scratching my head, thinking, "What the heck is he talking about?" So now I get it.

Not only that, but This module obviously has already done most of the things I was carrying on about. Sorry to have bored everyone with a question that already has clear answers. And thanks, @argiepiano, for your patient endurance and willingness to help!

When I first starting working with Drupal 7 I needed, like you, 6 or 7 "content types" with different fields, and I worked exclusively with nodes and with the module Entity Reference to create relationships between those nodes. It was OK - there were some drawbacks to it, but you can make it work.

This is my exact experience! Perhaps one day I'll make a proper project out of this little web-app of mine.