On Mon, Jul 7, 2008 at 6:57 AM, Nicolas Dumazet <nicdumz(a)gmail.com> wrote:
I am, however, considering to disallow category moves
over an existing
category (again, the *category*, not its attached page) :
* When the user does this, he probably expects the categories to be
merged together.
* However as said before, the move has to be reversible: the proper
way to do this is to redirect the former category to the latter;
reversing this is only deleting a redirect.
* But actually, after that redirect, there will be one page for two
category objects. If we merged A and B to B, category A will redirect
to category B, while the only valid Page will be B. That might not be
a big problem, but it differs from the structure I currently use : 1
Category object <-> 1 Page object
So you're saying that basically, just as you can't move a page over an
existing page, but have to manually create the redirect, so too here
you can't move a category over an existing category, but have to
manually create a redirect. If I got that right, it seems reasonable
to me.
There is a little problem with that constraint, though
: if a category
once contained pages, it will still exist. It means that the user can
be asked not to move a category to an... empty category.
The easy answer here is "just check for category membership, and allow
the move when no categorylinks entries point to the target category";
however, how will we deal with CategoryLinksUpdate Jobs that might be
pending ? In other words, the target category might appear empty at
the query time, when a move / redirect change is undergo.
Should I try to address that ? If on moves, I make the job_title the
target category title, searching the job table for
job_cmd=categoryLinksUpdate AND job_title=target could help, but how
does it sound ?
If the database query is that simple, and appropriate indexes are
available, it shouldn't be a problem to use that as a criterion.
Don't rely on cat_count, by the way, to determine whether the category
is empty. SELECT 1 FROM categorylinks WHERE ... LIMIT 1 is just as
fast and considerably more accurate (if combined with the job queue
check). Of course you could always have race conditions of various
sorts unless you take out nasty locks, so hopefully the world won't
fall apart if you move over an existing category somehow by mistake.