Our data managers routinely analyze Drupal content in external mapping and analysis programs and generate lists of nodes that require updates. I'm looking for a solution that will allow them to update this arbitrary list of nids, preferably within a friendly UI.


We've recently migrated from a custom database application to Drupal. In the past our data managers would perform a sql in query (SELECT * FROM table WHERE ID IN (27, 83, 99, ....)) or upload a temporary table to the database, do a join and perform updates. I'm looking for a way for them to do the same thing, but inside of Drupal so the proper update hooks are fired.

So far my Google skills and searches on drupal.org are failing me. It seems this should be a common problem? Is there a best practice when performing these sorts of one-off query/updates?

Some related solutions I've considered

  • Views contextual filters using either default arguments or arguments in the url (Create a view from specific Node ID's) - This is limited to only a few dozen nid's as a default argument or maximum url length. Not suitable for long lists of nid's
  • Researched using Node Queue with the solution above but the UI doesn't seem to allow bulk adding of nodes, but perhaps I'm overlooking something.
  • Custom module to expose a table to views (Join a custom table on a View) - not ideal since requires programming every time a new update needs to be performed
  • Write a custom query and update to perform IN queries (Using IN clause in db_query) - again requires code, which I'm not opposed to if I can work up a reusable solution that our data managers (not programmers) can use to maintain our data.

An ideal solution would be a fiter criteria that allowed our data managers to paste a long csv string. Something like "In list" which operates similar to the "Is between" functionality.

I'm overlooking something obvious! Ideas?

1 Answer 1


You could try Feeds as well .... but ...

Use either a CSV file or one of its other Migrate Sources, for instance it can use another database table as your source of change-data. But I recommend the Migrate module.

Your CSV can hold the primary key and whatever fields you need to update. You could use the new hash() functionality in Migrate 2.6 to check for changes in your data so that content is either Updated or Inserted as needed.

  • Migrate is great, but not exactly an end user solution, especially for these non-standard but everyday tweaks.We have a database of several hundred thousand observations which we routinely update confidence levels, add attributes and such to a subset. There's no specific pattern. I suppose I could establish a standard export and then migrate update using the edited export file, but that seems hackish and opens up the possibility of corrupting existing data since I'd have to include all the fields to capture all possible updates.
    – Brent
    Jul 3, 2013 at 16:08
  • Your solution is workable and better than anything I linked to... but would prefer the ability to explicitly pull up a subset in views. +1
    – Brent
    Jul 3, 2013 at 16:12
  • I've spent many days researching this, and it looks like your answer is the best answer out there at this time. There really is room for some contrib modules in this space. Accepting. Thanks again!
    – Brent
    Nov 12, 2013 at 19:42

Your Answer

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

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