Drupal 6 modules typically defined their own tables, had their own code to maintain them and then used nodeapi to hook into the system. Or, defined node types but still maintained their own tables. In Drupal 7 instead you should just create fields, instance them on node types you want to work with. Instead of altering a form directly you can write a widget. Display your data with a formatter. Don't worry about data storage, field API handles that for you. And then there is the EntityFieldQuery class to help with finding things. For example, scheduler should use a field instead of its own table and then use EntityFieldQuery in cron to find the unpublished nodes which needs publishing:

Note that updating the node table directly would skip all the hooks (and there are quite a few) that would allow modules to react to this change so please don't do that. In general, if you write a SQL query in Drupal 7, think twice whether it can be done with an API instead and use that instead.

Also note that entity bulk updates are not solved well in Drupal 7, if you have a lot of entities such a loop would take quite some time. This likely will be a contrib module and a whole another article :)

Update: to clarify, although I used node as an example in this post, this is also equally true to any entity type, comments, users, taxonomy terms etc. I did use entity_load instead of node_load_multiple however, to show how the querying part is not node specific at all.

Commenting on this Story is closed.