I was checking out this really great module, and was looking at how it was storing the data so I could use the table for a custom SQL query for a project I am working on.

I tested something and I noticed something that I believe will be undesirable in the long run. I created a view and added all the draggable things that was needed and such. I also turned on the "Use arguments as well as view ID to order nodes." check box. When I go to the view it works perfectly. So I got to looking in the MySQL side of things and found the draggableviews_structure table and started to select stuff from that table to find out how to join it to some other tables for a custom query.

What I found was that if the view has items that have gone away, some of the items in the draggableviews_structure table would not be removed. While I noticed the message that the structure was repaired, I am still seeing some records that were removed from the view are still in this table if I look at the table in MySQL.

Here's an example

If a view pulled in nodes 7,8, and 9 and ordered them via this module as 1,2, and 3. if node 8 became unpublished, or was changed to where it would not be pulled by the view, the view would change to 7 and 9, and even if I went into the view and got the message about the structure being repaired, I would still see a record in the table for node 8. I think that if this continues that the table will become bloated with useless records that may never get back into the view.

would the repair of the structure be able to remove these records or are they left there because there is no way to remove them due to the cost of having to check each one for validity in the view before removing, especially with large views of hundreds of nodes.?

Granville

Comments

sevi’s picture

sevi commented

A very, very tricky issue. I don't know a solution right now.

Removing entries of e.g. unpublished nodes is definitely wrong, because un-publishing and re-publishing should leave the view unchanged.

graper’s picture

graper commented

hmmm, that's a very interesting point, but if a node is unpublished and the order is changed, wouldn't the un-published node's order in the structure be invalid? i.e. given my example, if node 9 was given order number 2, but 8 was still in the structure table also with order 2, and node 8 was re-published, how would the conflict be resolved?

I guess it would be a matter of if the structure was changed or not which would dictate if the order should be maintained or not for un-published nodes.

Granville

sevi’s picture

sevi commented

Invalid structures cannot be prevented anyway.

hmmm, that's a very interesting point, but if a node is unpublished and the order is changed, wouldn't the un-published node's order in the structure be invalid? i.e. given my example, if node 9 was given order number 2, but 8 was still in the structure table also with order 2, and node 8 was re-published, how would the conflict be resolved?

All nodes will first be ordered by the existing order-values (randomly if ambiguous), eg.:
...
node9 - 2
node8 - 2
..
and then re-numbered:
..
node9 - 2
node8 - 3
..
So node8 would stay (approximately) at its position (assumed not all nodes have order-number 2 -> the result would be completely random :)).

If we would wanted to remove entries of unused nodes, we would have to check the scope of all views. Some views may display published nodes, others may display nodes with the date from 2008-2009, others may display unpublished nodes..
Wouldn't we need way too much processor load for this? ..every time a node gets changed or deleted.

..The more I think the less I know about this issue. Is there a way to keep the database free of unused entries? I just don't know how to go on with this issue..

Greetings,
sevi

graper’s picture

graper commented

I think we've both been thinking about this and gone in circles.

If a node is deleted, the table should be updated to remove the node id, this prevents bloat of nodes that are no longer in the system remaining in the structure.

as for unpublishing a node, you are correct, if the node is unpublished than the structure should remain cause if the structure is not repaired, it should be go right back into the same order.

However, if a node is unpublished and the structure is repaired, when the node is re-published, then maybe a warning message that says the order of the node needs to be set and a link to the view so they can set the order. The only issue would be how do you detect if it's in the wrong order at the time the node is changed? Would that also be a concern for cpu load? Guess it depends on how many nodes are in a particular view cause it should only catch the nodes in the view.

If anything, no code can be written and it just documented that when a node is re-published that the view should be looked at to ensure proper custom order.

thanks for the great module.

Granville

istryker’s picture

istryker commented
Status: Active » Closed (won't fix)

6.x in now unsupport. Closing this issue.