On Mon, Jul 7, 2008 at 6:57 AM, Nicolas Dumazet nicdumz@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.