--- Comment #5 from Oliver Keyes <> ---
(In reply to Nemo from comment #4)
> But we still lack a use case. One server in the world with DB but without
> API isn't really convincing.
It's more than "one server"; it's going to be all our analytics machines, and
that's the crucial element. If the scenario was reversed - some strange
universe in which we had one production machine and the rest were
analytics-based - the argument wouldn't hold any water. Part of this, sure, is
that production is 90% of our use cases, but that's only part of it. The other
is simply that research and analytics /are/ a use case, and one of increasing
importance. We now have 6 researchers, 4 analytics engineers, a director-level
position and a Product Manager; arguing that this is not something worth
addressing, either by justifying it or solving it, simply because those people
can get their work done on only a few machines, ignores the tremendous
resources being thrown behind analytics.

A use case was provided with the original post ;p.

>The kind of information you need (like content
> namespace or not) also has nothing to do with l10n, so there is no reason to
> believe it would last forever in there if it's even available.

It's absolutely available; please do me the courtesy of assuming I did basic
research and attempted to solve the problem through other means before
submitting the bug. If you want to check yourself, look for namespaceNames and
namespaceAliases in lc_key.

Sure, namespaceNames are not /directly/ a localisation problem - they're
wiki-based as well as language based - but they are, most of the time,

More importantly, whether they do or do not last forever (which seems a very
strange test. /nothing/ we do lasts forever. well, other than the projects.
That's kind of why we're here), they're currently stored there. The solution to
the problem is for the language engineering team to either (a) explain why
serialised PHP is the best plausible way to store this data or (b) change it. 
I'm not asking for a solution proof against any possible permutation of future
events, because that's impossible, but the fact of the matter is that this
table is the source of the issue as it stands.

> On the "why", that's the format used in other tables too, for instance
> log_params, so your question should be rephrased as: document why and where
> the DB tables contain serialiased data.

Sure, if documentation was all I was asking for ;p. log_params is less crucial;
to my knowledge the only thing we tend to use it for is retrieving the patrol
status of a page (that is, whether it was patrolled automatically or manually),
and that's something you can extract with a minimal amount of effort because
it's not a complex piece of data - it's just the 1 or 0 closest to the end of
the string.

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