In the process of insert the hook_nodeapi in apachesolr.mode call this function apachesolr_entity_update().

This function do a process to determine the status of the node ($node->status) for this case the variable $entity is the alias of $node and in this one get the $node->status. So the $status_callback($id, $type) do a reload $node and broken it in some cases.

I test it commenting the code when determine the callback to see the node status. And then use this.

$status = TRUE;
$status = $status && $entity->status;

I bealive in the case of Drupal 6 to determine the node status we don't need another process.

In my website the callback function apachesolr_index_node_status_callback($entity_id, $entity_type) destroy my articles.

Please take a look.

CommentFileSizeAuthor
#15 1693092-12.patch683 byteskillua99
#12 1693092-11.patch651 bytesnick_vh
#11 1693092-10.patch655 byteskillua99
#9 1693092-9.patch632 bytesnick_vh
node-status-0.patch1.28 KBkillua99

Comments

nick_vh’s picture

nick_vh
he/him
Location Ghent
commented
Status: Needs review » Needs work

Removing so much code? You are removing the status callback all together?
please explain in more detail what is the problem here and how you want to fix it?

killua99’s picture

killua99 commented

As you can see I remove a lot of code, and the status_callback. I don't know yet how Drupal 7 handle the status of an entity (or node) but Drupal 6 is pretty easy, it's in the $node object.

I figure out that drupal 6 always is gonna call this function:

function apachesolr_index_node_status_callback($entity_id, $entity_type)

Because the hook_nodeapi() it's only for nodes. 

+++ b/apachesolr.module
@@ -1908,19 +1908,8 @@ function apachesolr_entity_update($entity, $type) {
-    $status_callbacks = apachesolr_entity_get_callback($type, 'status callback', $bundle);

find the function callback apachesolr_index_node_status_callback()

+++ b/apachesolr.module
@@ -1908,19 +1908,8 @@ function apachesolr_entity_update($entity, $type) {
-          $status = $status && $status_callback($id, $type);

callback of the function apachesolr_index_node_status_callback()

So if we're gonna determine if the node status is === 1 or not we don't need this. Actually when I remove this lines my nodes start to save in the right way and more faster.

The function apachesolr_index_node_status() have this.

  $node = node_load($entity_id, NULL, TRUE);
  $status = ($node->status == 1 ? 1 : 0);
  return $status;

In the insert action when the node it's not 100% finish we call it to see the status and validate it. Actually the status is always there it's comming in the $node object and it's only for nodes. I didn't remove for the term or other thing.

For me this change means performance and secure way to save a new node or edit them.

jonathanpglick’s picture

jonathanpglick commented

I think I'm having the same problem. When I save a new node of a type that's enabled in the Apache Solr Search Configuration (bottom of /admin/settings/apachesolr), all CCK field values are lost. If the node is then edited and saved, it works correctly.

I haven't been able to completely figure out what's happening but it seems like the call to node_load() inside apachesolr_index_node_status_callback() is causing the trouble.

jonathanpglick’s picture

jonathanpglick commented

Okay, I updated the weight of the cck module ('content') to -10 so its hook_nodeapi() definitely runs before apachesolr's and that fixed the problem for me. Something to keep in mind.

nick_vh’s picture

nick_vh
he/him
Location Ghent
commented 
/**
 * Status callback for ApacheSolr, for nodes.
 */
function apachesolr_index_node_status_callback($entity_id, $entity_type) {
  // Make sure we have a boolean value.
  // Anything different from 1 becomes zero
  $node = node_load($entity_id, NULL, TRUE);
  $status = ($node->status == 1 ? 1 : 0);
  return $status;
}

I'm trying to understand it here, but it does not make a lot of sense. Can we see if changing this to a direct sql query resolves the issue?

drumm’s picture

drumm
he/him
Location NY, US
commented

Drupal.org has this problem too, causing #1825814: Apachesolr 6.x-3.x and CCK cause corrupt field caching.

CCK caches field values on node load, see content_load(). If this triggers a node load before CCK has gotten to saving the values, then CCK will cache empty values.

drumm’s picture

drumm
he/him
Location NY, US
commented
Priority: Normal » Critical

Updating to critical since a bad field cache looks like data loss, and becomes a likely-permanent data loss if the node is saved.

Ways to solve this:

  • Don't call node_load() in the middle of node save; you won't get a complete node. Rewrite to run later or get the data another way.
  • or, make sure apachesolr's weight in the system table is higher than content's.
  • or, in CCK, have content_insert() call cache_clear_all(), like content_update() and content_delete() do.
nick_vh’s picture

nick_vh
he/him
Location Ghent
commented

I'm in favor of a direct SQL query. it's pluggable enough so someone can easily modify it to their needs. Let me make a patch

nick_vh’s picture

nick_vh
he/him
Location Ghent
commented
Status: Needs work » Needs review
StatusFileSize
new 1693092-9.patch632 bytes

Status: Needs review » Needs work

The last submitted patch, 1693092-9.patch, failed testing.

killua99’s picture

killua99 commented
StatusFileSize
new 1693092-10.patch655 bytes

Try this.

nick_vh’s picture

nick_vh
he/him
Location Ghent
commented
Status: Needs work » Needs review
StatusFileSize
new 1693092-11.patch651 bytes
nick_vh’s picture

nick_vh
he/him
Location Ghent
commented

Yeah, I figured that I forgot the argument..

nick_vh’s picture

nick_vh
he/him
Location Ghent
commented

Killua, you can mark it as RTBC and I'll commit your patch, it's a little cleaner than mine;-) But! Don't forget, confirm first if this actually solves the problem. But I think it does

killua99’s picture

killua99 commented
StatusFileSize
new 1693092-12.patch683 bytes

Yes I saw that hehe ... and just to know I have in my production site this path.

Its the same, only with the $node obj thing to keep it idk more „drupal way“

nick_vh’s picture

nick_vh
he/him
Location Ghent
commented

no that is not necessary. I prefer the patch #11

Status: Needs review » Needs work

The last submitted patch, 1693092-12.patch, failed testing.

killua99’s picture

killua99 commented
Status: Needs work » Reviewed & tested by the community

I'm actually using this "kinda" patch in deploy. SO I guess is fine. It solves tons of conflicts with CCK thinks. For me is a patch to be commited A.S.A.P

nick_vh’s picture

nick_vh
he/him
Location Ghent
commented
Status: Reviewed & tested by the community » Fixed

Committed to 6.x-3.x

Status: Fixed » Closed (fixed)

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

hussainweb’s picture

hussainweb
Primary language English
commented

Just so that anyone is trying to find this:

The patch at #11 helped me fix the problem with cck fields not being saved. I did not think of this to be a ApacheSOLR problem at all at first. It worked fine for most content types because filefield_paths was clearing the cache after apachesolr caused it to be set. But for a new profile type (from content_profile module), this caused me a lot of headache and after hours of debugging, I isolated the problem to ApacheSOLR and not content_profile as I originally thought.

Thanks for the patch!