Drop all use of $qid

This makes sense to me, especially considering that D7 only has 500 users. For D6 what would the feasibility of supporting both $qid and $name? For example,

function nodequeue_load($name) {
  // Determine if machine name is being used.
  if (!is_numeric($name)) {
    $queues = nodequeue_load_queues_by_name(array($name)); // New function
  }
  // Backwards compatibility: fall back to using $qid
  else {
    $qid = $name;
    $queues = nodequeue_load_queues(array($qid));
  }
  return !empty($queues) ? array_shift($queues) : array();
}

I'm not very familiar with nodequeue so I don't know how painful that road would be. We can now assume that all queues have a machine name (derived or otherwise) so the only real concern is maintaining compatibility with other modules.

As I said in #1154536: Allow Queues of Entities other than Nodes, my thoughts for a 7.x-3.x branch would be to move away from nodes and generalize to entities. I'm pretty sure this move should be done in a whole new project though (entityqueue?) ..

Since this new project would basically replace nodequeue for D7, I don't know what to say about the future of nodequeue for D6. Sure, we can create a new branch that would drop $qids in favor of $names, but would there be enough users for that branch to actually worth the effort of creating and maintaing it?

My personal opinion is that in a couple of months (after Drupal 7.2 maybe) the question of starting a new project with D6 vs. D7 will be gone and everybody will move towards D7.

In conclusion, I agree with @rickvug that in 6.x-2.x we should support both $qids and $names and in 7.x-2.x we should make the switch to $names only.

I've been working on the D7 port of UUID and my approach has been that anything in core that doesn't have a machine name should get a UUID. In D7 vocabularies use machine names. In this context I would support ditching $qid in node queue.

Some time ago I suggested to ezra-g that node_queue should depend on UUID for D7 so the node references would be UUIDs. This would make node queue portable between environments. I still hope to have time to work on this, or to help someone else who is interested in doing it.

Summary: +1 from me.

+1 to ditching qid everywhere. I'd love to see this in D6, too, although I can understand why the nodequeue maintainers might not be psyched about a new D6 branch to work on...

@amateescu I noticed that subqueues still use integers for their keys as well as to reference queues. Would you say that this issue is blocking #373174: Export and import capability for nodequeue ?

@rickvug, I don't think so, because the main export object (the queue) has a machine name.

Unfortunately, I'm a little swamped at work and I can only take care of some small bug fixes for a little while. Also, I would really like to see what ezra-g thinks about this before I start working on a patch.

Making a new 6.x branch seems like a lot of work with little benefit and some significant potential drawback. Many users won't ever switch to the new 6.x version and the users who want to use names instead of qids will know how to do that with the current 6.x branch. And, we'd get a second D6 branch to maintain which splits the userbase and adds maintenance work.

So, +1 on this for D7, -1 on this for D6.

@ezra-g: Sure, I can understand not wanting a new branch. I guess you're saying 6.x-2.x will support both names and ints, and we'll make exporting work via names, but leave all the int support in place for backwards compatibility. That's cool with me, I guess. I retract my support of doing this in D6. Too much work without enough benefit.

@dww that's correct. Thanks for your feedback.

To be clear: I'm still in favor of #1160024: Default views should use $name rather than $qid and any other issues that fix 6.x-2.x to not use int qid by default. I'd also be in favor of an issue to add @deprecated (assuming that's a PHPDoc directive) or equivalent to the documentation for any of the API functions that rely on $qid instead of a machine name.

@amateescu If subqueues do not have unique keys what will happen when moving queues across environments? Is the expectation that on import the queues will be created, assigning unique qid and subqueue ids as required? It would be ideal to have true exportables (ie. a default hook) but more traditional import/export would still be a major win.

@rickvug You were right in #5, this issue should block #373174: Export and import capability for nodequeue (at least for 7.x-1.x).

I see everybody agrees that $qids should be dropped in 7.x, so let's do import/export right from the start, get a stable 7.x-1.0 release out with all these great features and then we can see about 6.x-2.x.

#11: I guess the expectations should be set in #373174: Export and import capability for nodequeue , and I would certainly prefer true exportables if we're already doing so many changes in the 7.x-1.x branch. Can you show me an example of how a default hook would look like for nodequeue?

I'm gonna have a crack at this.

Here is an initial patch updating nodequeue to use queue names instead of qid.

What's done:

• Change database schema to remove 'qid' fields and adjust keys and indexes.
• Port nodequeue admin forms and API functions to work with 'name' instead of 'qid'.

Still to do:

• Update views, actions and drush integrations.
• Update smartqueue, nodequeue_service and nodequeue_generate modules.
• Update advanced help pages.
• Write upgrade path.

For a follow up patch:

Remove sqid from subqueues.

Sorry about the patch name, it doesn't match issue #, but has the correct content.

Updated patch, removing name value form element, that was originally passing qid, it's not needed anymore.

Please disconsider this patch.

Updating views and actions integrations.

Updating views and actions integrations.

Wow, great work on this patch :) There's only one thing that worries me if we decide to go ahead with this change, and that is: possibly breaking custom code in almost 5.000 Nodequeue 7.x-2.x installs..

@amateescu: you've said on IRC that you have some ideas for this patch. Can you write them down here, or ping me on IRC when you're available to chat? Thanks!

Discussed on IRC with @recidive and the conclusion was that this should go into a new branch. Can't wait to test the final patch :)

I don't know what to do with the nodequeue_handler_argument_subqueue_qid views handler.

Is it at all being used? Should we just get rid of this, as there's already a name argument that uses default string handler?

Finished patch, including schema update, attached.

From the list of things I outlined in #14, it's just missing "Update advanced help pages.". The advanced help pages are currently not up to date.

Upgrade path is not complete. Need to fill out the new created name fields.

Ok, added code to fill out name fields.

I had to move smartqueue module table update to nodequeue.install, to avoid problems which loosing nid/name mapping. I guess this should not be a problem.

Fixing upgrade path. Need to change serial fields to int before trying to remove primary keys.

When executing update 7300 I get the following error on nodequeue_queue table
SQLSTATE[42000]: Syntax error or access violation: 1075 Incorrect table definition; there can be only one auto column and it must be defined as a key

@jamiecuthill: Can you please try this one?

Update function now works.

I noticed this problem though.
nodequeue.module line 1608
nodequeue_queue_position takes param $qid but uses $name in the query condition.

@jamiecuthill: thanks for testing. I've corrected the $qid that was left.

@amateescu: can we get this commited to a branch? I'd like to do some more cleanup and also work on finishing #373174: Export and import capability for nodequeue .

Done. Created a 7.x-3.x branch and committed the patch from #31. Great work!

http://drupalcode.org/project/nodequeue.git/commit/bfee6ea

Bumping version so we know when/where this happened.

I think there is a problem with this patch please see my issue #1572622: No add to queue link
thanks