6

There are several types of data my website generates for every node. Node's popularity score, node's comment count obtained from a 3rd party API, etc... This data is set for every node.

In the past I've used to just add hidden fields to each node, i.e. field_popularity_score, field_comment_count, etc..., and had the fields updated on hook_cron; but I've ran into an issue. Each time those fields are updated, the node's revision date would change also.

Where should I be storing this data? I'd prefer to stay away from using the standard node fields, as it would break its purpose.

Update

Apparently, per this post, Drupal 5 used to allow storage of serialized data into $node->data.

Update

Interesting enough, Node object reference page lists $node->data as part of Drupal 7. I would love to hear if there is a way to use that field to store serialized data in Drupal 7.

|improve this question
  • You might run into a few issues down the line. Firstly, you might not be able to port your code over to Drupal 8 as I think they might have done away with $node->data. At least in the posts about $user->data there was talk about deprecating it. And secondly, how are you going to pull reports from this? You might not plan on doing it now, but in future you might. – J. Reynolds Dec 17 '14 at 5:40
  • 2
    $node->data was there in D5 era, but no longer used in 6 or 7. It's probably there to prevent PHP notices when accessing $node->data. Custom tables aer perfectly suitable for this. Just make sure you delete the keys in node_delete hook, and load them using a single query in node_load hook. – AyeshK Dec 17 '14 at 5:41
5

I would suggest making your own table in the database, it's a perfectly acceptable practice if you name the table something unique that isn't likely to collide with other modules.

The database API is an extremely useful resource for this.

[edit:] Thanks to J. Reynolds - in this instance you will definitely need to tell Views about your table.

|improve this answer
  • 1
    And essential then to this implementation would be to add views integration for the table. Drupal 7 Views Module Tutorial 7 of 10 - Integrating Your Module with the Views AP – J. Reynolds Dec 17 '14 at 5:24
  • Thanks. I was hoping it wouldn't involve a custom table, since you have to create a new field on node save, remove a field on node delete, etc.. That said, the thought of altering a Drupal database... just wish Drupal left us a hook for it :) – timofey.com Dec 17 '14 at 5:38
  • I think I understand the concept. Will be going with a custom database. – timofey.com Dec 17 '14 at 5:54
  • 2
    And of course you can always take this further and create a custom module using the Entity API. – Wtower Dec 19 '14 at 8:32
  • 1
    Maybe @Wtower meant to create a 'data' Entity, parallel to the nodes.... or a 'data' content type, parallel to the content type needing the custom data? For example, for a content type 'blog', create a content type 'blog-data', and upon a new node of content type 'blog', simply add a new node to content type 'blog-data'... hmmm, that can be an idea. – timofey.com Dec 22 '14 at 6:55
2

Set $node->revision = FALSE when saving your node and continue to use the field API. There are many advantages to using fields and they can be spooled up and destroyed programmatically (see commerce_price for an example) when your module is enabled an disabled.

Advantages are:

  • Use existing table schema from defined field types.
  • Integrates with display management tools (DS, Panels or "manage display"), with all the field formatters for that type.
  • UI is there if you need it. You can set #access => false or use form displays in D8.
  • More modules will be aware of your data and integrate with it (views was a good example).
  • Way less custom code to maintain.
  • Way less time consuming.

For a simple comment count or popularity score you should be staying well away from a custom table or the entity API.

Also, using $entity->data is also a recipe for a disaster. Not being able to filter or query on your data pretty much mitigates any advantage of using a relational database.

|improve this answer
  • Wow! Love the idea, thanks for taking your time to share. I totally forgot about using the #access permission. I will try to use this within the next few weeks and if this does work as it says, I'm definitely going with this option. – timofey.com Dec 22 '14 at 6:35

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.