Summary: there's a remnant of old age hanging around in your code. It only silently corrupts your mysql tables a little bit(?) but it breaks PostgreSQL.
Note: I don't know whether this is a proper bugfix or just a sub-ideal workaround. (Reason being I do not yet fully understand:
- the whole drupal_write_record() internals
- your intentions
but I am quitting thinking about it for now. The above little patch has some use in that it fixes some more PostgreSQL breakage, at least for our friend bfo ;)
---
What is currently there:
function weblinks_submit($form, &$form_state) {
$form_state['values']['url'] = strip_tags(trim($form_state['values']['url']));
$form_state['values']['click_count'] = 0;
$form_state['values']['last_click'] = 0; // <------ THE CULPRIT
$_REQUEST['destination'] = 'weblinks';
}
...
function weblinks_update($node) {
$node->last_status = $node->last_checked = NULL;
if ($node->revision) {
$node->last_click = NULL;
$node->click_count = 0;
}
weblinks_write($node);
}
In update_6113(), you converted the 'last_click' column from an int (timestamp) to a date column and explicitly did not convert the cases where the value was 0 (i.e. the new column kept NULL values for those). That line up there in weblinks_submit still assumes it is an int. So updates to a weblink now update the 'last_click' column to "0000-00-00 00:00:00". (And PostgreSQL throws a datatype related error on update weblinks set last_click='0', so nothing is updated at all.)
So I removed that line.
Now, what I'm not really sure about:
1) drupal_write_record() has (afaict atm) no support for updating colums to NULL. Which means that if we set $node->last_click to NULL, that won't make a difference. In other words, click_count is always updated to 0 but last_click is NOT updated after I remove that line. (Not good?)
2) If in weblinks_submit() you are always setting click_count to 0, then I am not sure why the whole if(...)block in weblinks_update() is needed anyway. I have not looked at how that 'update the click fields' system in your module works. It seems to me that you could remove that code from the submit hook and move everything into the update hook -- but maybe I don't understand Drupal / the different code flows in your module well enough yet.
Which is why I'm just handing this to you for further review :) (e.g. to see if there should or should not be an explicit 'update weblinks set last_click=NULL' statement in the update hook, and when...)
| Comment | File | Size | Author |
|---|---|---|---|
| weblinks_noresetlastclick.patch | 497 bytes | roderik |
Comments
Comment #1
rmiddle commentedi don't think that is the right solution to the problem although you are right that is a section of code that got missed when we upgraded from int(11) dates to date fields.
Thanks
Robert
Comment #2
nancydruI am looking at it now. Part of the problem is one of those two hooks (and I can't remember now which one, or maybe it was hook_insert) has some code that was needed for the conversion modules, so I have to do some investigation to remind me. I'm also not sure how much those two hooks interact, so I want to check that too.
I have looked a drupal_write_record, and I think it does handle NULL values, because even if a variable is NULL it is still ISSET. But I will check that closely too.
Then I will look at the database to decide whether to set the empty value to "0000-00-00 00:00:00" or NULL. Does it matter to Postgres?
*EDIT* Yes, both update and submit run, with update second. Yes, drupal_write_record will write a NULL.
Comment #3
roderikabout drupal_write_record(), you are probably right. It was probably my weird (debugger) configuration that led me to believe that !isset(NULL).
So if applicable: sorry for causing confusion.
I was just assuming that you wanted to set NULL (after the type change of the fields)... but if not: you cannot set "0000-00-00 00:00:00" in Postgres, that gives a "date/time field value out of range" error.
(You could set it to "0000-01-01 00:00:00" if you wanted.)
Comment #4
nancydruWe now set it to NULL. The submit function is gone and the update/insert functions now do that work.
Committed.
Comment #5
nancydruIncluded in 6.x-2.1.