--- Comment #6 from Krinkle <> ---
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

Reply via email to