Errors on cron run
| Project: | Node Expire |
| Version: | 6.x-2.03 |
| Component: | Miscellaneous |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | reviewed & tested by the community |
When I run a cron manually from the Status Report screen, I get the following error:
* user warning: Duplicate entry '8' for key 'PRIMARY' query: INSERT INTO node_expire (nid, expire, expired) VALUES (8, 0, 0) in /mydomainname/includes/common.inc on line 3422.
* user warning: Duplicate entry '9' for key 'PRIMARY' query: INSERT INTO node_expire (nid, expire, expired) VALUES (9, 0, 0) in /mydomainname/includes/common.inc on line 3422.
* user warning: Duplicate entry '10' for key 'PRIMARY' query: INSERT INTO node_expire (nid, expire, expired) VALUES (10, 0, 0) in /mydomainname/includes/common.inc on line 3422.
* user warning: Duplicate entry '11' for key 'PRIMARY' query: INSERT INTO node_expire (nid, expire, expired) VALUES (11, 0, 0) in /mydomainname/includes/common.inc on line 3422.
#1
Same problem here... only difference is that I get it for only two records.
#2
Same problem
Duplicate entry '506' for key 1 query: drupal_write_record /* Administrator : drupal_write_record */ INSERT INTO node_expire (nid, expire, expired) VALUES (506, 0, 0) in /home/folder/data/www/domain/includes/common.inc on line 3422.
#3
Try changing the code at line 53 in node_expire.nodeapi.inc from:
case 'insert':$update = array();
if (isset($node->node_expire)) {
$update[] = 'nid';
}
to
case 'insert':$update = array();
if (isset($node->expire)) {
$update[] = 'nid';
}
It wasn't properly detecting if it was editing an existing record.
#4
Hi, smsearcy!
Thanks for your reply.
You code work fine, my problem is completely solved.
#5
Here's a patch for code change in comment #3. I think I created it correctly, please let me know if there is a problem.
#6
I ran into an issue with my previous patch of not being able to add an expiration date to an existing node without an expiration date (I think because it was attempting to update a non-existent record in {node_expire}), so I rewrote the insert/update section. This hopefully will also address #466680: Nodes saved in node_expire table with value of 0 then unpublished by not saving an empty expiration date in the table (and will clean up the table).
case 'update':case 'insert':
db_query('DELETE FROM {node_expire} WHERE nid = %d', $node->nid);
if (empty($node->expire)) {
// don't save an empty expiration date in the database
break;
}
$node->expire = strtotime($node->expire);
$node->expired = FALSE;
db_query('INSERT {node_expire} (nid, expire, expired) VALUES(%d, %d, %d)', $node->nid, $node->expire, $node->expired);
break;
I've attached a patch, which hopefully is correctly formatted (I'm stuck running Windows).
#7
Minor formatting change to previous post, and removed the second point from the case statement.
case 'update':case 'insert':
db_query('DELETE FROM {node_expire} WHERE nid = %d', $node->nid);
if (!empty($node->expire)) {
$node->expire = strtotime($node->expire);
$node->expired = FALSE;
db_query('INSERT {node_expire} (nid, expire, expired) VALUES(%d, %d, %d)', $node->nid, $node->expire, $node->expired);
}
break;
#8
Here's a slight variation on the above patch- removes the the $update array and uses the drupal_write_record fuction instead of the db_query. It also prevents makes the delete query conditional. I'm not sure if there is ever a condition where this would be the case, but seems like it might be a good idea to check for it.
#9
Excellent! Thank you so much for posting this -- I installed the arthurf patch (#8 above) and it seems to be working for me.
Any idea how to stop node expire from subtracting a day from the expiration date every time a node is edited? (See http://drupal.org/node/435658)
#10
I tested arthurf's patch (#8) when adding/modifying/deleting expiration dates on new and existing nodes and didn't find any issues. Thank you.
#11
Hi guys! Isn't it time to make a new release of this module? With all this patches... I'm lost! ;-)
Can someone post the MUST patches of this module? Just a simple list to make it work in a good way.
Thank you!
#12
Hi, I think committing the working patches in a .dev would be the best way, because maybe there is also a working order for the patches to commit properly, right? Then after testing making a 2.04 or 2.1 please.
Thanks a lot in advance for considering this!
Greetings, Martijn
#13
I'm having this same error. How test/stable is the patch? Does anyone know when it will make it's way into 2.04/the next version?
#14
The patch in #8 works for me too. I took a quick peek at the PHP code and it makes sense to me.
Maybe if we RTBC this, one of the committers will take notice.
#15
Yeah, I tested the patch as well and it seems to fix the problem so far.
#16
Subscribe, I've been having the same issue
#17
Just to let you know, I too have run this patch (#8) five months since the last report and it worked fine. I guess it's reassuring that the patched code hasn't gone stale in that time.
:-)