I did send a reply to Alex last night--something seems to have
dropped it on the floor; I don't know if it's on my side or the
list software. Brion's mail seems to imply the latter, but
since it hasn't happened to me other times that I rememeber,
I'll reserve judgment.
At any rate, thanks, Alex, for pointing out that my new namespace
fields were not indexed. I also strongly agree that NOW is
exactly the right time to think about tweaking the database
structure--all the infrastructure is in place now, but little
of the hairy structure-sensitive code of the special pages is
written, and the new codebase is well-enough encapsulated that
making database changes should be easy. Finally, the new code
already requires a database upgrade, so that's no excuse not to
do other useful changes. I'm updating the conversion script as
as I go.
To test my assumption of encapsulation I did in fact replace the
namespace fields in both the "cur" and "old" tables with integers.
This should keep the database smaller and speed it up. Making the
change took a lot less time than updating the database itself, so
it looks like the new codebase passed that test.
I'm also not thrilled with the linked/unliked tables. I'm thinking
of replacing them with a single "X links to Y" table using integer
indexes.
I'm also open to suggestions about how to change cur_ind_title.
Finally, I mostly agree with Axel's contention that "approval"
of articles is just metadata--the piece of information that person
X approved of article Y should just be stored somewhere, and used
when needed to make collections or whatever. I would call the
users authorized to make such approvals "editors", rather than
"sysops"--the latter seems more like the folks who can do techie
things like direct database access, etc.
Doing that would be easier with yet another database change I
considered earlier--replacing the odd linked-list mechanism of
old page versions seems awkward. It could be replaced by simply
using revision numbers that would be common to both the "cur" and
"old" tables. Or an even more radical change--merge both of those
tables in to one, and create a "current_revision" table. Ideas?
--
Lee Daniel Crocker <lee@piclab.com> <http://www.piclab.com/lee/>
"All inventions or works of authorship original to me, herein and past,
are placed irrevocably in the public domain, and may be used or modified
for any purpose, without permission, attribution, or notification."--LDC
dropped it on the floor; I don't know if it's on my side or the
list software. Brion's mail seems to imply the latter, but
since it hasn't happened to me other times that I rememeber,
I'll reserve judgment.
At any rate, thanks, Alex, for pointing out that my new namespace
fields were not indexed. I also strongly agree that NOW is
exactly the right time to think about tweaking the database
structure--all the infrastructure is in place now, but little
of the hairy structure-sensitive code of the special pages is
written, and the new codebase is well-enough encapsulated that
making database changes should be easy. Finally, the new code
already requires a database upgrade, so that's no excuse not to
do other useful changes. I'm updating the conversion script as
as I go.
To test my assumption of encapsulation I did in fact replace the
namespace fields in both the "cur" and "old" tables with integers.
This should keep the database smaller and speed it up. Making the
change took a lot less time than updating the database itself, so
it looks like the new codebase passed that test.
I'm also not thrilled with the linked/unliked tables. I'm thinking
of replacing them with a single "X links to Y" table using integer
indexes.
I'm also open to suggestions about how to change cur_ind_title.
Finally, I mostly agree with Axel's contention that "approval"
of articles is just metadata--the piece of information that person
X approved of article Y should just be stored somewhere, and used
when needed to make collections or whatever. I would call the
users authorized to make such approvals "editors", rather than
"sysops"--the latter seems more like the folks who can do techie
things like direct database access, etc.
Doing that would be easier with yet another database change I
considered earlier--replacing the odd linked-list mechanism of
old page versions seems awkward. It could be replaced by simply
using revision numbers that would be common to both the "cur" and
"old" tables. Or an even more radical change--merge both of those
tables in to one, and create a "current_revision" table. Ideas?
--
Lee Daniel Crocker <lee@piclab.com> <http://www.piclab.com/lee/>
"All inventions or works of authorship original to me, herein and past,
are placed irrevocably in the public domain, and may be used or modified
for any purpose, without permission, attribution, or notification."--LDC