I was looking into bug 14414
https://bugzilla.wikimedia.org/show_bug.cgi?id=14414
and found that although querycache.value is declared as an int in tables.sql, it's being used to store many things. The default in QueryPage.php was to fallback to an empty string (I just changed this to 0, but this may have been too hasty in light of further digging: feel free to revert). Other places are storing things like img_timestamp here, which is in MySQL a varbinary(12) (e.g. a text string), which happens to be a series of digits, which just happens to map to an integer, so it fits in the 'value' column quite nicely. Other databases, not so nicely, as img_timestamp is an actual timestamp. Before I go much further, is the battle to fix the value mappings worth it, or should I just redefine querycache.value to be a text value for the Postgres schema? Any downsides in the code for the latter that people are aware of? Thanks.
P.S. There maybe other problems with regards to this bug, I'm just tackling this one issue right now.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Greg Sabino Mullane wrote:
Before I go much further, is the battle to fix the value mappings worth it, or should I just redefine querycache.value to be a text value for the Postgres schema? Any downsides in the code for the latter that people are aware of? Thanks.
Failure of all numeric sorting?
- -- brion
Before I go much further, is the battle to fix the value mappings worth it, or should I just redefine querycache.value to be a text value for the Postgres schema? Any downsides in the code for the latter that people are aware of? Thanks.
Failure of all numeric sorting?
(squints hard at QueryPage.php)
Is it being used that way anywhere? Believe me, I'd much rather change a single column type than modify a bunch of code...
wikitech-l@lists.wikimedia.org