https://bugzilla.wikimedia.org/show_bug.cgi?id=1211
--- Comment #53 from Aryeh Gregor <simetrical+wikib...@gmail.com> 2010-06-02 18:02:32 UTC --- (In reply to comment #51) > Schema changes are in no way blocked by bug 16012, that was a misconception. I > did a couple of schema changes during the deployment of 1.16wmf4, and I'm > happy > to do more in the next deployment. There are some conditions which need to be > met for easy migration, but those won't change when bug 16012 is implemented. > The table can be any size, as long as it fits into the free disk space, since > MySQL needs to make a copy when it does an ALTER TABLE. Okay. > Do you mean the category page query? Presumably that would be cl_to=xxx not > cl_from=xxx. Yes, right. I always get them confused. cl_page and cl_category would have made much more sense as column names. Although less consistent with pagelinks. > You don't need bug 450 to be fixed. You can keep the current (cl_to, > cl_sortkey, cl_from) index and add an additional (cl_to, cl_namespace, > cl_sortkey, cl_from) index. Then we can support both UIs. I think that by "fixing bug 450" I meant that you'd need to store the namespace in the categorylinks table somehow. > When namespace breakdowns are enabled, there would be some complexity involved > in making the main category page query skip subcategories and files, but I > think it would be possible to do it efficiently, even in MySQL 4.0, by using > ranges and unions. > > For instance, we could have a union with the first subquery having a condition > like (cl_sortkey > $offset AND cl_namespace < NS_CATEGORY), and the second > subquery having a condition like (cl_namespace > NS_CATEGORY). Yes, this is true. Maybe I hadn't seen that hack yet in 2008. > The category page view with the namespace breakdown would have to page through > the results one namespace at a time, it wouldn't display, say, pages in all > namespaces that start with the letter "L". As in the current scheme, the UI > has > to reflect the indexes. The query would have ORDER BY cl_namespace, > cl_sortkey. Do you mean it would have WHERE cl_to='X' AND cl_namespace=Y ORDER BY cl_sortkey? It wouldn't make sense in any UI to display the first 200 results from the main namespace only, so you'd have to go through fifty pages to get to the files. You could cut it down to one query by doing a UNION, with different WHERE clauses in each part of the union. > Breaking namespaces out into a new table would be the only decent solution, > assuming we need that feature. If we're displaying different namespaces under different headings as bug 450 suggests, we'd presumably want to keep the total count for each namespace present in the UI. It could be dropped, but it doesn't seem like there's any point. (In reply to comment #52) > To fix the current bug and not include namespaces in the sorting order would > require a boolean cl_is_subcat field, defined to be the same as > cl_namespace=NS_CATEGORY. Then the index would be (cl_to, cl_is_subcat, > cl_sortkey, cl_from). I don't see why this is necessary or advantageous. You could just do several queries, maybe UNIONed together, one for each namespace, and that will work with a (cl_to, cl_namespace, cl_sortkey, cl_from) index. The only advantage would be that pages can't get moved between the category namespace and other namespaces, so if we only stored subcategory-ness, we wouldn't have to update anything extra on page moves, and there'd be little to no risk of errors creeping in. This is an advantage of sticking to the current subcats/pages/files approach, but we can't have that if we want to fix bug 450. (Not sure if we need to or not.) -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug. _______________________________________________ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
