Duplicate entities when 2 different entity types have the same entity_id

I can confirm same happens when you use 2 draggable views for the same entity.

The above fix seems to work for entries that was already in the draggableviews_structure table. Adding new content then gets ignored from the view. Maybe it needs a weight before?

The join should be modified to add an extra condition that the base_table view_name be the same as the view being executed.

This fixes the problem in the correct way. It should cover both the case when different entities have the same id, or there are several draggable views for the same entity.

Just found out that this extra condition will result in an empty configuration table. Looking at the D7 module, they've used a views join handler with the same conditions. I'm guessing this will require a similar solution (see https://api.drupal.org/api/drupal/core!modules!views!src!Plugin!views!jo...).

Upping this to major. The module provides random results in any configuration that where more than 1 draggable view is used.

I couldn't find enough info on using a custom join handler (how do you specify you're using one??).

However, I did find info on query substitutions which are what we need here. This moves the condition to the join expression, fixing the problem I mentioned in #5.

I've tested the patch from #7 on a site and so far, so good. I've got a view of nodes on a page that I've set to use DraggableViews. I've another view (the stock Taxonomy Term view, extended to use DraggableViews) that interacts with the exact same nodes and I can now successfully manipulate items in either view without creating duplicates or anything unexpected. I need to poke around a bit more, but this looks promising.

Still not working for me, for the same entity type it still duplicating entries. If somehow we can use the "view_display" db field of draggable views inside join(like in D7 there is an option to select a "views display to sort" ) to display our sorted content for different-2 display of a view.

@narendra.rajwar27, I don't get how it is possible you still get a duplicate..

Please note that if your database is "contaminated", the output will still have duplicates. This patch only fixes the display and generation of the view, but it doesn't change the results when you've generated the draggable weights without it.

I can confirm that the patch works for me, thank you @jcnventura

The patch did not work for me

Verified the patch works for me. However it could be improved to also include the display name in the join condition. If you need different sort orders between your view displays the patch won't work. I worked around this with multiple views.

@dotist, can you elaborate why the patsh didn't work for you? Other users report it's working, may your case is special in some way.

Patch #7 worked for me.
My particular case was:
When I generate a view as a block and then change to a page, to have the path, in the draggableviews_structure table I saw that there was identical identity_id with 2 different weight and in the view both elements were painted.

I also faced duplicate items in the following case:
2 different views showing pages depending on the pages' taxonomy tags.
Pages that were tagged for twice would appear as duplicate (both when sorting via a custom "order view" or when showing the main view itself)

Patch 7 did the trick to suppress the duplicate entries.

However, this (obviously) doesn't work with the extra "order view" :/

7 worked for me too, again an entity referencing multiple taxonomy terms was duplicated in the results. Many thanks jcnventura.

Patch #7 fixed the sorting issue for me. But somehow the Global: DraggableViews Weight views field stopped working in my case (used in another view). But not sure it is related.

Patch #7 dit it for me. I had this problem with multi language. Every node with more language was duplicated. With patch #7 it was OK.

Note: this is listed as a patch for the "8.x-1.x-dev" version but patch #7 dit not patch on this version; but it dit on 8.x-1.0 !! Before I figured that out.. lots waste of time.. so for the next one.. know this :-P patch #7 on version 1.0

And yes, as mentioned above, a sorting set in a view is not working in an onther view.

Thanks,
Marchello

Guys can you try https://www.drupal.org/files/issues/2767437-n14.patch from #2767437: Allow sort handler to select the view that stored the order and let me know if it solves your problem. This is more of a solution that will get committed.

1. patch #7 does not meet coding standards need to convert array() to []
2. patch #7 leaves out the display_name (only has views_name)
3. patch https://www.drupal.org/files/issues/2767437-n14.patch does fix the problem, however you have to resave the 'sort->draggableviews weight' as you are forced to pick a view_name (display_name) from a dropdown. #2767437: Allow sort handler to select the view that stored the order needs an update hook to resave all views and select the 'current view (display X)'

Examples of #3 working
code:

  public function query() {
    parent::query();
    $table = $this->query->getTableInfo($this->tableAlias);
    if (!empty($this->options['source']) && $table) {
      list($view_name, $view_display) = explode('|', $this->options['source']);
      $table['join']->extra = [['field' => 'view_name', 'value' => $view_name]];
      $table['join']->extra[] = ['field' => 'view_display', 'value' => $view_display];
    }
  }

mysql snippet from draggableviews_demo (order)

SELECT node_field_data.langcode AS node_field_data_langcode, draggableviews_structure.weight AS draggableviews_structure_weight, node_field_data.created AS node_field_data_created, node_field_data.nid AS nid
FROM 
{node_field_data} node_field_data
LEFT JOIN {draggableviews_structure} draggableviews_structure ON node_field_data.nid = draggableviews_structure.entity_id AND (draggableviews_structure.view_name = 'draggableviews_demo' AND draggableviews_structure.view_display = 'draggableviews_demo_order')
ORDER BY draggableviews_structure_weight ASC, node_field_data_created DESC
LIMIT 11 OFFSET 0

notice the (draggableviews_structure.view_name = 'draggableviews_demo' AND draggableviews_structure.view_display = 'draggableviews_demo_order')

Will leave issue open for now until #2767437: Allow sort handler to select the view that stored the order patch gets an update_hook(), as people will notice the title of this issue if they are having this issue.

EDIT: Wrong issue

https://www.drupal.org/files/issues/2767437-n14.patch is the only patch I could get working (and I tried several).

#7 Thanks!

+        'extra' => array(
+          array('field' => 'view_name', 'value' => '***VIEW_ID***'),
+        ),

should become

        'extra' => [
          [
            'field' => 'view_name',
            'value' => '***VIEW_ID***',
          ],
        ],

Fixed the coding standards issues wrt the array notation but we should close this issue in favor of https://www.drupal.org/project/draggableviews/issues/2767437.

As @iStryker stated in his comments in his comment #33 on issue 2867159, this issue is a duplicate of #2767437: Allow sort handler to select the view that stored the order and this issue's code is taking the wrong approach to solving this (as it is similar to #2867159: DraggableViews displays multiple node instances when used in multiple views)and will not be committed.

#2767437: Allow sort handler to select the view that stored the order is taking the correct approach to solving this issue.

I have switched to using the patches in #2767437: Allow sort handler to select the view that stored the order and suggest others switch too to test them.

I am therefore closing this as a duplicate.