Last modified: 2006-02-08 02:58:29 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 3104 - Watchlist notification broken in MySQL
Watchlist notification broken in MySQL
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
1.6.x
PC Windows XP
: Normal normal with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-10 19:34 UTC by Joel Natividad
Modified: 2006-02-08 02:58 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Joel Natividad 2005-08-10 19:34:36 UTC
Kate merged ORACLE_WORK for WatchedItem.php and it broke MYSQL.

r1=1.17&r2=1.18">http://cvs.sourceforge.net/viewcvs.py/wikipedia/phase3/includes/WatchedItem.php?r1=1.17&r2=1.18

Setting wl_notificationtimestamp to '0' got it working again in MySQL.
Comment 1 Brion Vibber 2005-08-17 08:48:00 UTC
NULL is the correct way this should be done; '0' is just plain wrong.

I've changed the table definition for MySQL so that this actually can be inserted/
updated properly. Can you clarify if anything else needs to be done still or if just the 
failure to do action=watch was the subject of this bug?
Comment 2 Joel Natividad 2005-08-17 11:11:15 UTC
I agree that NULL is the correct way and the table structure of the MySQL table
is the root cause.

As for this bug, nothing else needs to be done in my book, as soon as the new
tables.sql is checked in.
Comment 3 T. Gries 2005-08-17 17:13:18 UTC
Yes, I also agree. 
A special routine checking for NULL value might be needed (according to MySQL
syntax).
Comment 4 T. Gries 2005-08-17 17:23:18 UTC
> Yes, I also agree. 
> A special routine checking for NULL value might be needed (according to MySQL
> syntax).
## "SELECT ... foo=null;" is wrong, we need "SELECT ... foo IS NULL;" instead

Such a construction might be needed to become (more) database independent

See 
http://cvs.berlios.de/cgi-bin/viewcvs.cgi/enotifwiki/enotifwiki/includes/Database.php?annotate=1.1.1.1

1457                    /*
1458              	 * Returns a string to match in a database query for an
undefined timestamp value
1459              	 */
1460              	function wl_notificationtimestampIsNULL() {
1461              		return 'wl_notificationtimestamp = 0'; 		# for VARCHAR(14)
1462              
1463              		## depending on your table definition it can also be
1464              		## return 'wl_notificationtimestamp IS NULL'; 	# for DATETIME
1465              
1466              		## underlying problem:
1467              		##
1468              		## MySQL queries need different syntax when testing against
NULL value
1469              		## "SELECT ... foo=null;" is wrong, we need "SELECT ... foo
IS NULL;" instead

This is implemented so in EnotifWiki.

Please correct me, if I am wrong.
Comment 5 Brion Vibber 2006-02-08 02:58:29 UTC
This has been working for months.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links