Page MenuHomePhabricator

Make a Feed query construction less clever/sneaky for new qsprintf() semantics
ClosedPublic

Authored by epriestley on Nov 25 2018, 9:40 PM.
Tags
None
Referenced Files
F14105947: D19837.diff
Wed, Nov 27, 3:57 AM
Unknown Object (File)
Thu, Nov 21, 1:29 PM
Unknown Object (File)
Tue, Nov 19, 6:11 AM
Unknown Object (File)
Fri, Nov 15, 8:29 AM
Unknown Object (File)
Oct 21 2024, 3:02 AM
Unknown Object (File)
Oct 13 2024, 11:41 PM
Unknown Object (File)
Oct 9 2024, 10:45 AM
Unknown Object (File)
Sep 12 2024, 9:07 AM
Subscribers
None

Details

Summary

Ref T13216. Ref T13217. Currently, we build this query in a weird way so we end up with (1, 2, 3) on both 32-bit and 64-bit systems.

I can't reproduce the string-vs-int MySQL key issue on any system I have access to, so just simplify this and format as ('1', '2', '3') instead.

The issue this is working around is that MySQL would (I think?) sometimes appear to do something goofy and miss the key if you formatted the query with strings. I never really nailed this down and could have either been mistaken about it or it could be fixed in all modern versions of MySQL. Until we have better evidence to the contrary, assume MySQL is smart enough to handle this sensibly now.

Test Plan

Ran daemons with Feed publish workers, no longer received query warnings.

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable