2

I am trying to figure out if there is a difference between saving an instance of an entity and saving the definition of an entity.

My use case is this: I wrote a small module that defines an entity, which I then used in other code on my site. All of this worked just fine, and I thought that once I had created some instances of my entity, and that those instances were stored in my database, I could then disable the little module that defined my entity. I thought, in other words, that defining an entity would be like defining a Content Type, and that once you had done so the new entity, like a new Content Type, would "stick around".

That, however, is not how things work. If I disable the little module that defines the new entity, that entity disappears from my system, and the code that uses that entity fails. Re-enabling the little entity-defining module returns everything to normal and the site works again.

I think I may have missed a step here [entity_save?] but find nothing in the documentation that discusses saving the definition of a programatically defined entity.

Two more things. First, I have noticed that the "model" module, which provides a template for creating your own entities, exhibits the same behavior that my little module did: if I disable that module, the entities that I used it to define vanish from my system. I have also noticed that the Entity Construction Kit [ECK] creates, in addition to the base table, two additional tables, one of which, eck_bundles, looks like it has entity properties. I have not been willing to disable the ECK, though, because the documentation says that Drupal needs it.

Another way of posing my question would be this: "Do you have to keep the code that defines your entity in your system, or is there some way of storing the entity definition for subsequent use?"

I am running Drupal 7.39

Improve this question
6
  • Drupal version?
    – Jimmy Ko
    Jun 28, 2016 at 14:33
  • An "entity" is an instance of an "entity type", same way as a node is an instance of a content type - with that in mind is your query actually Do you have to keep the code that defines your entity type in your system ? (emphasis mine), or do you mean entity in that statement?
    – Clive ♦
    Jun 28, 2016 at 15:09
  • Thank you for that clarification. Yes, I meant to say "entity type" in both uses in that sentence, which should read: "Do you have to keep the code that defines your entity type in your system, or is there some way of storing the entity type definition for subsequent use" In the examples that I cited, the instances of the entity type are still in the base table, but the entity types themselves have vanished.
    – Wyckham Seelig
    Jun 28, 2016 at 16:02
  • ECK is a contributed module, it is not necessary to have if you want to create new entities, bundles and entity CRUD. It grants you a UI and wizard and tries to be similar to how you create content types for nodes in the UI. Behaviors like what you describe are reasons why I always created entities and types with code instead of contributed modules. Keep in mind that the node module does it's own thing in regards to its entities, it does not apply to everything that implements an entity type.
    – Kevin
    Jun 28, 2016 at 17:17
  • That said, I would bet the records are still in the database. Disabling the module(s) makes their definitions not discoverable (D7), which likely impacts the admin list pages that would show them. Using modules that build types with wizards basically ensure you are married to them, unless they have a way to export definitions without requiring a dependency on said module. For modules that implement directly via code, no, you cannot simply disable them.
    – Kevin
    Jun 28, 2016 at 17:19

1 Answer 1

Reset to default
0

Yes, the module providing the entity type needs to be enabled for the entity to work correctly, and any module using that entity should include the defining module as a dependency. Drupal modules are generally not factories that produce configuration and can then go away (the major exception being modules generated with the Features module which can behave this way at times), they generally provide ongoing functionality that Drupal will expect to be available on demand.

In your case Drupal loads the class from that module under a variety of conditions (not the least of which is anytime you load an instance of that entity) and so needs to continue to be active as long as you use the entity. That module is also the place to define any special behaviors of the new type of entity you have defined (like changes to the save/load process, or other actions the entity may provide).

Improve this answer
2
  • Thank you very much for this. "Drupal modules are generally not factories that produce configuration and can then go away ..." is particularly well said. I ultimately decided to refactor my entity definition module, and incorporated its code in the module that uses the entity. This way, if I decide to make my module available, I'll be able to distribute one module instead of two. Do you think that this is a good decision?
    – Wyckham Seelig
    Jun 30, 2016 at 14:41
  • Without knowing the details of your project all I can say is that it could be a good way to go. If the entity is useless without the rest of the code than one module likely makes sense. If it gets too confusing to maintain as one module (sometimes the .module file can get overly complex or other issues) separating into a module and submodule also often makes sense.
    – acrosman
    Jun 30, 2016 at 15:21

Your Answer

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

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