Why can't we just ignore the nid?

Senpai's picture
public
Senpai - Fri, 2007-10-26 21:56

We're all building sites that have functionality based upon the nid, right? Why can't we break out of that mold of doing nodeapi adjustments to certain nodes based upon a sequentially incrementing number, and try to use something like auto_nodetitle.module to trigger from?

I'm envisioning a scenario like the one posed by jmburnz on http://drupal.org/node/140430#comment-227293 where he says:

A fair amount of content was added to the dev site before it was branched and went live (enough to populate each site section). At times I've needed some additional test content - that is no problem as I can just create it without worrying about what is going over on the live site.
We have used vids, tids & nids as you describe, but these were all set in stone before the site went live.

Well, kidlets, what happens when your node->nid isn't the same on both the live and dev server? How do you perform actuation on content when the users are deleting old content and re-creating new nodes during the week that you've been rolling additional features onto your mirrored dev server?

We could programmatically alter nodes that had a human-readable title if that node's title was unique among all the other nodes. Sure, the uid IS unique, but its also not resettable. At all. Try this little experiment. Use Devel to create 100 random nodes for testing your newest content type. Now delete those nodes by any means necessary. Use the admin pages. Truncate the db. I don't care what you do, you'll never get those uid's back, cause the sequences table is frozen at 101, and it can't simply be reset without throwing off several other things that rely on a uid that's never been used before.

Now think about this. It wouldn't matter to a common user if they deleted a node, then recreated it with the same title, would it? A user doesn't freakin care what that node's number is. They think it's the same piece of content as the last one they had. It'd be like creating a PDF on your computer's desktop. Throw it away, and then re-create it, and when you double-click that second PDF, it will open up, rather than throwing back a <?php $node->nid != '100', 'youcrazyjackass!'; ?> What do you mean, "it's not there"? "I saved it again, and called it the exact same thing!!? It IS there!"

Having a unique element for every piece of content is a necessary evil in the CMS world. But imagine for a moment if we could merge our dev and live databases without loosing content or changing the exact node that nodeapi needed to see in order to do it's thing? How cool would that be, eh? If I want to aim my hook_nodeapi rifle at the piece of content with a <?php $title = '2008 Cherry Festival'; ?> and that title just happens to be unique across the entire site, then nodeapi would activate itself on the "2008 Cherry Festival" story. Every time. No matter what db that story existed upon.

No matter what version of which database was pushed upwards into testing. Or pulled downwards from live to dev. It wouldn't matter.

I wonder if auto_nodetitle can accomplish this for us? I'm gonna check it out. Developers, how would you handle this $node->nid situation?


UUIDs

fgm@drupal.org's picture
fgm@drupal.org - Wed, 2008-07-02 10:12

Titles tend to repeat over time, so relying on such an identifier is error-prone, especially in the long term.

OTOH, adding UUIDs to drupal entities (nodes, comments, users, vocabularies, terms...) seems more reliable to make them portable, and does not prevent adding such content- or title- based additional identifiers.

I have a module in the works for this : it is easy for nodes and users, less so for some other entities, however.