I index node references for faceted search (apache solr). I need a mechanism to detect when a node needs reindexing because its referenced node has disappeared. Does this module provide a mechanism? Is there a hook that gets invoked to say "node 15 needs a reindex"?

I don't see a mechanism, but I thought I'd ask =)

Comments

robertdouglass’s picture

I'm thinking something like this:

function cck_referential_integrity_apply($field_type, $field_value) {
...
  // Expire cached objects related to the nodes we have just altered.
  foreach ($cached_nids as $nid) {
    module_invoke_all('cck_referential_integrity_update', $nid);
    cache_clear_all('content:'. $nid .':', content_cache_tablename(), TRUE);
  }
robertdouglass’s picture

Or, probably better...

function cck_referential_integrity_apply($field_type, $field_value) {
...
  // Let other modules know which nodes have been changed
  module_invoke_all('cck_referential_integrity_update', $cached_nids);

  // Expire cached objects related to the nodes we have just altered.
  foreach ($cached_nids as $nid) {
    cache_clear_all('content:'. $nid .':', content_cache_tablename(), TRUE);
  }
robertdouglass’s picture

Status: Active » Needs review
StatusFileSize
new1.81 KB

I found two places that need the hook invoked.

markus_petrux’s picture

Status: Needs review » Active

How about?

function cck_referential_integrity_apply($field_type, $field_value) {
...
  // Let other modules know which nodes have been changed.
  if (!empty($cached_nids)) {
    module_invoke_all('cck_referential_integrity_update', $cached_nids, $field_type, $field_value);
  }

  // Expire cached objects related to the nodes we have just altered.
  foreach ($cached_nids as $nid) {
    cache_clear_all('content:'. $nid .':', content_cache_tablename(), TRUE);
  }

The hook would only be invoked when necessary, and now you know if it is about a node or user reference field, and the related nid or uid, which is something you may not care, but just in case you may wish to process only node reference related stuff or whatever...

...or we could even provide the result of cck_referential_integrity_get_reference_fields($field_type) as an argument to this hook, and then you have a lot more information.

markus_petrux’s picture

Status: Active » Needs work

Oops, we posted previous comment almost at the same time. Well, I think it would be nice to provide context to this hook.

I'm setting the issue as needs work, and I'll look into it later or tomorrow if you haven't already. Probably it is possible to insolate this snippet into a separate function that is invoked from both places.

robertdouglass’s picture

Status: Needs work » Active
StatusFileSize
new2.72 KB

Good idea. I also added a block that redirects to admin/content/node/orphan-references when there are no more orphans. Sorry to mix issues but since the queue is quiet, and I have your attention ;-)

robertdouglass’s picture

Status: Active » Needs review
robertdouglass’s picture

Yes, the code is duplicate, but not massive. I'd be on the fence about isolating it. Too many functions makes hard to read. But your call.

markus_petrux’s picture

Status: Needs review » Fixed

I just committed a slight variation of your patch:

http://drupal.org/cvs?commit=261938

The result is that we are invoking hook_cck_referential_integrity_update($cached_nids, $updated_fields) to let other module know which nodes have been changed.

/** 
 * Let other module know which nodes have been changed.
 *
 * @param $cached_nids
 *   An array of node IDs.
 * @param $updated_fields
 *   An array of information about fields that have been updated.
 *
 * @see cck_referential_integrity_get_field_info()
 * @see cck_referential_integrity_apply()
 * @see cck_referential_integrity_orphan_references_check_one_field_submit()
 */
function hook_cck_referential_integrity_update($cached_nids, $updated_fields) {
}

Re: "I also added a block that redirects to admin/content/node/orphan-references when there are no more orphans"

I haven't included this. The main orphans report does not offer links to view orphans for fields that haven't. In case someone visits that page, then the message "Could not find orphans for this field." is rendered, and the breadcrumb in that page allows you to visit the main orphans report, so I think that drupal_goto() is not really necessary.

robertdouglass’s picture

Re: redirect. Ok. It still works without it, of course, but since people use this module to do batch operations (they mostly install it when they notice they've got a big problem), I thought the extra ease in workflow would be good. Yes it's true that you can no longer get to the report if there aren't orphans, but when using my version with the redirect, I find this to be a good thing, and a nice confirmation that the job is done. And it saves me a click.

markus_petrux’s picture

Robert: I believe I don't understand your workflow here. The main Orphans report is telling you how many orphans exist per table, and there's no link to browse orphan records for tables that do not have orphans. In this case, you can only view this report if you enter the URL manually. If you do, then it's up to you what to do next, but I would say it is just fine to render an empty table with a message that states there is no orphan record for the current selection. This is the pattern I've always seen in similar Drupal reports, or even in views (where you have the chance to configure the "empty" message).

Adding a drupal_goto() changes the most commonly used pattern, and I would only change it if there was a reason to do so.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.