2

While creating a new information for Drupal 8, I came across 2 approaches to create a new column on the entity table on database: * use hook_schema() (as I was used on Drupal 7) (https://gist.github.com/pedrorocha-net/3ed63f33b513d9c9ff86) * extends ContentEntityBase and use BaseFieldDefinition (https://gist.github.com/pedrorocha-net/70d6a84c3ddba1c5939d)

Both alternatives creates the table for me, with the data, but I think the latter already provides me more integration with other Drupal components e.g. Views module. By the other hand, being an "Entity" I believe brings some "weight" to the data, as it works with some wrappers(on Drupal 7 at least).

What i'm doing is port the Voting API module, so this question about extra weight can really impact on sites with more content.

Any thoughts?

||improve this question
  • What kind of extra weight are you expecting? – kiamlaluno♦ Aug 16 '15 at 20:40
  • I had many problems in requests with hundreds of entities loaded on D7, using Entity API and EntityWrapper, so I got a little concerned on exactly the places to use or avoid Entity API. The answer @berdir gave below helped a lot to show me that I don't have exactly an "extra weight" issue on this use case. – pedrorocha Aug 17 '15 at 14:31
  • 1
    In Drupal 7, the Entity API module provides wrappers around Drupal entities, which are merely stdClass objects, and it has more overhead compared to the native entities used by Drupal 8. – kiamlaluno♦ Aug 17 '15 at 14:54
  • Yeah, i'm seeing this now that i'm looking more into the implementation. The wrappers on D7 already load everything, that was a huge problem on my specific case at the time, but compared with extending @ContentEntityType now, it looks very different. What is the best place to discuss such topics? Any specific IRC channel for D8 apis best practices discussion? For reference, if anyone has interest in look the code, it's on github.com/pedrorocha-net/votingapi/blob/8.x-1.x/src/Entity/… – pedrorocha Aug 17 '15 at 15:03
4

The question that you are really asking is if you should be using the entity system or not. You only have one option depend on the answer to that.

Yes, there is considerable overhead especially when using content entities. But things like nodes and comments are entities too, and you can have hundreds of thousands of those. It doesn't really depend on how many are stored but how many are accessed and processed on typical requests. If it's common to load a large amount of them (not just calculate aggregates like how many votes but actuall load the whole thing), then entities might not be such a good match.

Drupal Core only has two primary types of entities, content and config entities. You could also define your own lightweight entity type that is completely custom, but then you again need your own storage class, table creation and so on.

But as you said yourself, being a (content) entity gives you a lot functionality, like CRUD, views integration, REST and many more that you possibly don't need for your use case.

||improve this answer
  • You're right: it's more about a design decision than anything(a discussion was started at drupal.org/node/2379167). That's exactly my doubt, as I wasn't so into the cons of Entity API on D8, while. Indeed, you gave me one particular insight now that really makes the difference: the "weight" issue is about how many entities are loaded on a request(I had problems on D7 with hundreds of users and nodes on a request), not how many are stored. This makes the point for this use case, as votes usually are not loaded(only the total amount). Thanks for the help – pedrorocha Aug 17 '15 at 14:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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