https://bugzilla.wikimedia.org/show_bug.cgi?id=60563
--- Comment #6 from Krinkle <krinklem...@gmail.com> --- Summary from bug 59623: So yeah, I think the best approach would be to go for the pure integer vs. non-integer approach. If giving the cache store an integer, we keep it as it. The cache store may or may not support this type natively, but at least we send it to the cache store as-is, and it will store it as either an integer or string. Then, anything that isn't an integer (not just arrays an objects, but even booleans and plain strings) we php serialise(). So that on the way out, we'll either get a serialised packet that we unserialise, or a number-like value which either is an integer already (if the backend supports it) or a string that we'll then cast to a number within the bagostuff class before returning it to the consuming code. Again, the reason we don't want to serialise just everything is to still allow the backend to optimise by being able to store number values efficiently and allow operations on them like INT/DECR and what not. A minor down side to this is that simple strings will inflate a bit in terms of occupied space (s:3:"foo"; vs "foo"), but has the upside of never being ambiguous. And besides, there is no advantage in storing strings as bare strings (other than saving a few bytes) as there are (afaik) no operations we need the backends to do on the values themselves. This seems like a perfect solution, but I foresee two possible issues: 1) Are there other types that we need the backends to perform native operations on? For example, for integers there is INT/DECR which is why we use that is the deciding factor. But this works only as long as there are no other types we need to distinguish (e.g. do some backends have native boolean value store types with toggle commands on them, and if so, is that worth it?) 2) We'll still need to keep the fallback code for interpreting non-serialise non-number values because production environments will have existing cache values that aren't serialised the same way yet. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
