On 8 September 2011 17:57, Daniel Friesen <[email protected]> wrote: > On 11-09-08 04:25 AM, Niklas Laxström wrote: >> On 8 September 2011 13:36, Max Semenik <[email protected]> wrote: >>> On Thu, Sep 8, 2011 at 2:18 PM, Aaron Schulz <[email protected]> wrote: >>> >>>> Yay for log_params. I was thinking JSON would be appropriate here, so I'm >>>> glat to see that. >>>> >>>> >>> Even though data in those fields is small enough, can >>> serialize()/unserialize() be used instead? It's faster and doesn't require >>> the mess of ServicesJSON to work correctly. >> Do those cause actual problems or is it just matter of preference? In >> my opinion JSON is much better for anyone who wants to dig the logs >> without using PHP. Also, is (un)serialize guaranteed to be stable >> across PHP versions? >> >> -Niklas > We already use serialize in HistoryBlob/Revision, the job queue, > caching, file metadata, the localization cache, ... > > So if you add any new fields to the db you should really stick to > (un)serialize. > We're already using serialize everywhere and we even use binary storage > which is troublesome for anyone trying to stare at the database with > most phpmyadmin installs. People being minorly inconvenienced when > reading the database raw is the last of our issues. > If you want to argue the irrelevant minority that would be slightly > inconvenienced reading the database raw I'll argue the irrelevant > minority that would be slightly inconvenienced trying to do db queries > to mw code externally and have to parse json which isn't as simple as > (un)serialize. > ;) I'll also wager that HipHop makes the gap in speed between > (un)serialize and json farther.
Very well, r96585. -- Niklas Laxström _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
