I have two content types with node references and backreference. Content type A nodes have a single reference to content type B nodes and Content B nodes have multiple references to content type A nodes. Every time a node of type A is saved in creates a duplicate in node B. If the node B is edited and saved it will drop all the duplicates. Node Revisions are off. Using Drupal 6.14, Content 6x-.2.5, Backreference 6x-1.0.

Comments

denisanokhin’s picture

I have the same problem. The dublicates are disappered after cache clearing.

loominade’s picture

Status: Active » Needs work

i have the same problem. this makes the module useless for me :/

loominade’s picture

the error only appears if the left node is a single field and the right node is multible. to avoid this I hacked _backreference_linkback_multiple_field like that:


function _backreference_linkback_multiple_field($right_table, $right_field_column, $left_nid, $right_vid, $right_nid)
{
	$result = db_query("SELECT $right_field_column, nid FROM {". $right_table ."}");
	while($row = db_fetch_object($result)) 
	{
		if($right_nid == $row->nid && $left_nid == $row->$right_field_column)
		{
			$dup_item = true;
		}
	}
  
  if(true == $dup_item)
  {
	return 0;
  }
  // This is a new reference, so we need to insert it after other references.
  // This was a race condition, but the LOCK TABLES should handle that.
  $delta_row = db_fetch_array(db_query_range("SELECT delta, $right_field_column, nid FROM {". $right_table ."} WHERE nid = %d ORDER BY delta DESC", $right_nid, 0, 1));
  $delta = $delta_row['delta'];
  
  if ($delta == 0 && empty($delta_row[$right_field_column]) && !empty($delta_row['nid'])) {
    // If there's a row with a delta of 0 but which has no data in the nid column, then we want to update this existing null row.
    db_query("UPDATE {". $right_table ."} SET $right_field_column = %d WHERE vid = %d AND delta = 0", $left_nid, $right_vid);
  }
  else {
    $delta = (is_null($delta) || $delta === FALSE) ? 0 : $delta + 1;
    db_query('INSERT INTO {'. $right_table .'} (vid, delta, nid, '. $right_field_column .') VALUES (%d, %d, %d, %d)', $right_vid, $delta, $right_nid, $left_nid);
  }
}

there should be a better way, for example when a doubble reference is wanted

seancorrales’s picture

I think I resolved the issue by making both node references multiple values. Previously, I had one multi (unlimited) and the other single. The single field is only there to make the back reference work so making it a multi value wasn't a big deal for me on this case.

my-family’s picture

The same problem. #4 helps (thanks a lot), but it is a little bit problematic for editor (the multiple value is really confusing in my case).

Otherwise the module is great and I hope it is possible to fix it.

jcfiala’s picture

Version: 6.x-1.0 » 6.x-1.1
Status: Needs work » Postponed (maintainer needs more info)

Man, I cannot reproduce this.

my-family, you just posted - can you explain to me how your nodes are set up, the multiplicity of the fields, and what other fields you might have set up?

I set up an a_type with a 'field_a_to_b' nodereference field that points to b_type, that takes one value. I also added a text field in case having more than one field was part of the cause.

I set up a b_type with a 'field_b_to_a' nodereference field that points to a_type, that takes unlimited values. I also added a text field to the b_type to give it more than one field.

No matter how many a_types I create and point to the b_type, it doesn't show any duplicates in the b_type's list.

This is with drupal 6.19, cck 6.x-2.8, and Backreference 6.x-1.1. I did not have revisions turned on with either node type.

I need to be able to reproduce this to put a patch in the code.

my-family’s picture

reply to #6: APOLOGIES for my fault (blush), I had still 6.x.-1.0 version of Back Reference. It seems to be fixed in 6.x.-1.1. (after update there are no more duplicates).

I can also confirm that this release fixes the problem described in http://drupal.org/node/790282 (resp. http://drupal.org/node/682120).

Tank you very much.

jcfiala’s picture

Status: Postponed (maintainer needs more info) » Fixed

Rock!

I'm happy to hear that this one's been fixed without us noticing it. Thanks for so quickly following up and letting me know the score.

Status: Fixed » Closed (fixed)

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