Jens Frank wrote:
On Fri, Jul 25, 2003 at 01:42:29AM +0200, Timwi
wrote:
Lightning wrote:
Plus, I think there was a reason behing
programming
in php vs Perl, im not sure..
Read the section "Why are we using PHP instead of perl?" on
http://www.wikipedia.org/wiki/Wikipedia:PHP_script_FAQ
Selecting the language to use for Phase IV we should
think about the features it has to provide.
Well, the particular feature you have mentioned isn't specific to a
programming language. Yes, mod_perl allows you to store something in a
global hash and keep the data between requests, but obviously this will
only work if you have only a single webserver (which I hope we're not
going for).
This is a problem MemCacheD can solve - in fact, that's exactly what
MemCacheD is for. And APIs for MemCacheD are, as has been said,
available for both Perl and PHP (though the Perl one is the only one
currently in use at a frequently-visited production website,
livejournal.com.)
does it allow e.g. a design of
Recent Changes as a big array?
Although the theoretical answer to this is 'yes', this is optimising at
the wrong spot. I've said this before. The Recent Changes page is not a
performance problem as long as it only reads (provided of course it is
optimised enough). What really blocks the database is a write. With the
current software and database schema, article text is inserted into
'old' and then also modified in 'cur' every time you edit a page - which
is doubly bad because 'cur' is the table you read from when you to the
most basic thing: displaying an article. It also updates the search
index, which is accessed by the search function, which is probably the
second-most-used function.
Instead of writing a
dedicated Recent Changes table it would be enough
to write edits line by line to a journal and reload some
thousand lines of journal on a server restart.
I'm not exactly sure what you mean here by a 'journal' if not a
dedicated database table?
Then add to that that you designed a new db schema
and that all data will have to be converted from one to the other
Of course I have thought about this. My plan would be to convert
articles as they are requested by readers. That way the database would
get converted gradually on demand, thus minimising possible delay and
avoiding downtime.
This will be very hard to maintain if you want to have the special
pages reenabled. You will have to do lots of joins and subselects.
Nothing MySQL is very fast at.
Well no, I wasn't really planning to have the database-intensive Special
Pages (Orphans, Long articles, etc.) work with the old database.
Especially Recent Changes doesn't need to because virtually anyone only
uses the n most recent changes and no longer cares about those before
the switch. Instead, I was planning to provide a Special Page listing
all the articles that are still in the Phase-3 DB, and after a few weeks
they'll all have been converted. It doesn't matter as much that "Long
articles" and "Orphans" doesn't work reliably in this short interim
period as it would if editing or even viewing articles wasn't possible.
I don't think the database schema is the source of
our problems, I thinks
it's the RDBMS.
I have outlined the problems I see with the current DB schema in a
posting to this list dated 12.07.2003 03:58, Subject "Database design":
http://mail.wikipedia.org/pipermail/wikitech-l/2003-July/004829.html
The problem I mentioned above is only one of them.
I haven't
used $? yet :)))
I suddenly remember why I don't like Perl ...
Don't get me wrong, I'm not disagreeing that Perl /is/ sometimes quite
obfuscated - myself, I also hate the single-character variables ($/, $|,
$`, $[, etc.). But apart from $_, they are all very rarely used.
Please don't start a religious war about this ;-)
Greetings,
Timwi